الگوهای معماری نرم افزار

الگوهای طراحی و معماری-2
Domain LogicDomain Model – بخش اول : منظور از اين مدل، object modelي از دامنه مساله است که هر کلاس آن شامل رفتار و ساختار موجوديتي(Entity) از موجوديتهاي آن دامنه است، براي مثال، "سند حسابداري"، که از مجموعه اي از آرتيکلها، تاريخ، شماره عنوان و وضعيت ساخته مي شود، از سويي مي تواند متد يا رفتاري با نام BALANCE را در خود داشته باشد که تراز بودن آن را مشخص مي کند، يادآوري مي کنم در روشي مانند Transaction Script متدي در يک کلاس که تراکنش ثبت سند را انجام مي دهد وجود دارد که تراز بودن سند را بررسي مي کند در حالي که در الگوي حاضر اين متد درون خود کلاس سند قرار مي گيرد. نمودار Domain Model ، شبيه به نمودار Database Model است،با اين تفاوت که در آن موجوديتها علاوه بر ساختار، داراي رفتار و پروسس بوده و در مدل، شبکه اي پيچيده از ارتباطات (Association)بين اشيا و رابطه ارث بري (Inheritance) بين آنها وجود دارد. خلاصه اينکه Domain Model متشکل از شبکه اي از اشيا به هم مرتبط از موجوديتهاي دامنه مساله است، هر موجوديت در دامنه مساله فارغ از سايز و اندازه اش و پيچيدگيش، داراي معناي خاص و واضحي است براي مثال "شرکت" موجوديتي بزرگ و "سفارش خريد" موجوديتي کوچک در دامنه مساله سيستم "پيگيري سفارشات" است که هر دو در مدل، کلاسهايي نظير براي خود دارند. بديهي است استفاده از Domain Model در يک برنامه به معناي قرار دادن تمام شبکه اشياء ساخته شده براي مساله در آن دامنه است، پس بهتر است از همين ابتدا ذکر کنم که خيال کندن بخشي از يک مدل و قرار دادن آن د برنامه اي ديگر را از ذهنتان بيرون کنيد، اين کار در ادامه پروژه تان به فاجعه منجر خواهد شد. در مدل مورد بحث، ميتوان اشياء را به دو دسته تقسيم کرد، اشيايي که داراي ساختاري معادل با موجوديت هاي مساله هستند و اشيايي که تنها قوانين و آلگوريتمهاي محاسباتي مختلف را در خود دارند و به اقتضاي نيازهاي غير عملکردي در سيستم بوجود آمده اند، براي مثال مي توان به شي کارمند و احکام حقوقي او در سيستم حقوق دستمزد و شي محاسبه کننده کسورات بر اساس نوع بيمه کارمند اشاره کرد، دو شي اولي داراي ساختاري از اطلاعات دامنه مساله و دومي در برگيرنده آلگوريتمهاي محاسبه کسورات بر حسب نوع بيمه و قرارداد کارمند است. لازم به ذکر است که در الگوي Domain model اولويت با ترکيب الگوريتمها در کلاس نماينده موجوديتهاست و تنها بايد بر حسب ضرورتهاي طراحي و بر اساس الگوهاي طراحي نسبت به استخراج آلگوريتمها و محاسبات و قرار دادن آنها در کلاسهاي جداگانه اقدام کرد. مدلهاي حاصل از اين الگو را مي توان به دو دسته ساده و پيچيده تقسيم کرد، در Domain Model هاي ساده به ازاي هر جدول در بانک اطلاعاتي يک کلاس ...

الگو های طراحی (Design Pattern)
الگو های طراحی (Design Pattern) :<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> کسی وجود دارد که قبلاً مسله شما را حل کرده است. در مهندسی نرم افزار یک الگوی طراحی، یک روش حل قابل تکرار برای مسائلی هست که عموماً در طراحی نرم افزار با آن برخورد می کنیم. یک الگوی طراحی یک قالب یا شرح برای چگونگی حل مسائلی است که می تواند در شرایط مختلف استفاده شود.یک الگوی طراحی، راه حلی است که برای مستند سازی ارزشمند تشخیص داده شده است، بطوریکه توسعه دهند گان دیگر می توانند آن را در حل مسائل مشابه به کار ببرند.همانگونه که طراحی شی گرا ادعا می کند که استفاده مجدد از کتابخانه ها و قطعات را افزایش می دهد، ادعا می شود که استفاده از الگو های طراحی، استفده مجدد از کتابخانه ها و قطعات را افزایش می دهد. الگو ها تکنیک هایی هستند که افراد زمانی از آنها برای حل مسائل خاص استفاده کردند. و به عنوان راه حل های خوب شناخته شده اند. سپس این تکنیک ها مستند سازی شده اند تا توسعه دهندگان هنگام برخورد با مسائل مشابه از این مستندات استفاده کنند و مسائل خود را حل کنند. تاریخچه الگو های طراحی : استفاده از الگوها برای اولین بار به ذهن یک معمار به نام الکساندر خطور کرد. الکساندر با این مشکل روبرو شد که یک طرح خوب و با کیفیت برای یک ساختمان چگونه می تواند باشد. او برای حل مشکل خود، ساختمانها، خیابانها، شهرک ها و هر مکانی که یک انسان برای خودش می سازد را مورد مطالعه و بررسی قرار داد. او کشف کرد که بناهای خوب از نظر طراحی دارای ویژگیهای مشترک هستند. او کشف کرد که بناهای خوب دارای ویژگیهای مشابه هستند واین ویژگیهای مشابه را الگو نامید. هر الگو بیانگر یک مسئله و مشکل است که می تواند بارها و بارها روی بدهد همراه با راه حل آن مسئله، وشما می تواند از این راه حل برای میلیون ها بار استفاده کند بدون نیاز مجدد برای پیدا کردن راه حل. در اوایل دهه 1990، بعضی از توسعه دهندگان نرم افزار با کارهای الگساندر برخورد کردند.آنها با این سوال روبرو شدند که اگر الگو های طراحی معماری در این رشته به صورت صحیح جواب می دهد آیا می توان الگوهای را برای طراحی نرم افزار بوجود آورد. در نرم افزار چه مسائل وجو دارد که بارها رخ می دهد و تقریبا با روشهای مشابه می توان آنها را حل کرد؟ آیا امکان استفاده از مفهوم الگوها در طراحی نرم افزار وجود دارد، آیا می توان راه حل های را برا اساس الگوها بعد از شناسایی الگوها ایجاد کرد.سوالات بالا، سوالاتی بودند که توسعه دهندگان مطرح کردند و پاسخ آن را یافتند. پاسخ سوال بلی بود. مرحله بعدی شناسایی الگوها بود و توسعه استانداردهای برای مستند سازی الگوها. در ...
الگوهای معماری(Architectual Patterns) -مدل های مرجع(Reference Models) - معماری های مرجع(Reference Ar

الگوهای معماری Architectual Patterns یک الگوی معماری توضیحی از گروهی از اجزا(Element) و روابط بین آنها با مجموعه ای از محدودیتها(Constraint) برا ی استفاده از آنهاست.یک الگو می تواند به عنوان مجموعه ای از محدودیتها بر روی یک معماری در نظر گرفته شود-بر روی اجزا و الگوهای ارتباطی بین آنها-و این محدودیتها مجموعه یا خانواده ای از معماری هایی که آنها را برآورده سازند معرفی می کنند.برای مثال Client –Server یک الگوی معماری معمول است،Client , Server دو نوع از اجزا(Element) هستندعبارت Client –Server نشان دهنده وجود چندین Client است ،خود Client ها و مجموعه فعالیتهای آنها مشخص نمی شوند و تنها پیاده سازی پروتکل ارتباطی آنها بر عهده هریک از Client ها و Server گذاشته می شود در معماری بررسی می شوند.معماری های بیشماری بر اساس این تعریف از نوع معماری Client –Server خواهند بود اما هریک از آنها متفاوت از دیگری است. یک الگوی معماری یک معماری نیست،اما کماکان تصویر قابل استفاده ای را از سیستم برای ما می سازد و محدودیتهای کارایی را بر معماری و نهایتا سیستم اعمال می کند. یکی از مفاهیم و مزایای بسیار خوب الگوها ارائه واضح و شفافی از پارامترهای کیفی از ابتدا است،در واقع همین امر دلیلی برای انتخاب یک الگوی خاص توسط معمار است .برخی از الگوهها راهکارهای خاصی برای پارامترهای همچون کارایی(Performance) و برخی راهکارهایی برای امنیت بالا(Security) و .. ارائه می دهند انتخاب الگوی معماری اولین تصمیم گیری اصلی معمار برای ایجاد معماری یک سیستم است. مدل های مرجعReference Models یک مدل مرجع تقسیم بندی عملیات سیستم(Functionality) با جریان داده ها بین اجزا سیستم است.در واقع یک مدل مرجع فرم استانداردی از شکستن مسائل بزرگتر شناخته شده از پیش به مسال کوچک تر است که بتوان با حل هر مساله کوچک و جمع بندی آنها نهایتا مساله بزرگتر را حل کرد.مدلهای مرجع در واقع مربوط به حیطه مسایل بزرگ و پیشرفته است.برای مثال بررسی اجزا یک کامپایلر و چگونگی کار کردن آنها با هم و چگونگی جریان دادهها بین آنها در واقع یک مدل مرجع برای سیستم کامپایلر است. معماری های مرجعReference Architecture معماری مرجع در واقع یک مدل مرجع است که بر اجزا و جریان داده(Data Flow) بین اجزا نرم افزار نگاشت شده است.از آنجا که یک مدل مرجع عملیات سیستم را تقسیم بندی میکند یک معماری مرجع آنرا بر اجزا سیستم نگاشت می کند الزاما این نگاشت یک نگاست یک به یک نیست یعنی گاها ممکن است یک عملیات از عملیات های مدل مرجع بر چند جز ار سیستم نگاشت شوند تا آنرا با همکاری هم انجام دهند ویا ممکن است یک جز از سسیستم چند عمل را انجام دهد. الگوی معماری،مدل مرجع و معماری مرجع خود هیچ یکمعماری نیستند،آنها ...
الگوهای طراحی، محاسن و معایب (Design Patterns Pros & Cons)

دوست خوبم، احسان در نوشته‏ای به بررسی مزایا و معایب الگوهای طراحی پرداخته است. در اینجا نکاتی را در تکمیل نوشته‏هایش آورده‏ام. خلاصه:- جایگاه الگوهای طراحی در حل مشکل طبقه‏بندی و دسته‏بندی (classification)- تجربی بودن الگوهای طراحی- الگوهای طراحی و استفاده مجدد- الگوهای طراحی به مثابه فرهنگ لغت مشترک- نقش الگوهای طراحی در آموزش طراحی شیءگرا- تعمیم الگوهای طراحی در سایر حوزه‏ها- ایده: حرکت به سمت کشف الگوهای مشابه در سیستمهای نرم‏افزاری مبتنی بر تئوری آشوب- کوچک بودن الگوهای طراحی در مقابل پیچدگی و بزرگی روزافزون مسائل موجود- نیاز به توسعه الگوها جهت پاسخگویی به مسئله- افزایش تنوع و تعداد الگوهای طراحی - چارلی چاپلین و یادگیری الگوهای طراحی توضیح: طبقه‏بندی وسیله‏ای است که ما به کمک آن دانش را مرتب می‏نماییم. اولین چیزهایی که در دوران دبستان یاد گرفتیم، طبقه‏بندی موجودات روی زمین بود. جانداران و بی‏جانها، جانداران به گیاه، حیوان و انسان دسته‏بندی می‏شوند و تا آخر.در طراحی شیءگرایی، شناخت مشترکات بین چیزها به ما کمک می‏کند تا اشتراکات را در قالب تجریدها(abstraction) و مکانیزمها(mechanism) نشان دهیم و این کار ما را به سمت معماری کوچکتر و ساده‏تر هدایت می‏کند. متأسفانه دسته‏بندی چیزها مثلاً کلاسها، سیستمها و غیره کار ساده‏ای نیست. فاکتورهای زیادی در شناخت و دسته‏بندی اجزای راه حل وجود دارند. از این رو در تحلیل و طراحی شیءگرایی مانند خیلی از حوزه‏های مهندسی، مجموعه‏ای از توصیه‏ها، راهنمایی‏ها و قواعد سرانگشتی جهت دسته‏بندی اجزای مسئله (مثلاً کلاسها و اشیا) وجود دارد. شناخت کلاسها، اشیاء و کلاً اجزای راه حل یکی از مشکلترین بخشهای تحلیل و طراحی شیءگرایی است. شناسایی اجزا، هم شامل کشف و هم شامل ابتکار و نوآوری است. در پروسه کشف، تجریدهای موجود در مسئله شناسایی شده و در پروسه نوآوری، تغییر شکل تجریدها به شکلی که جواب مسئله داده شود، صورت می‏گیرد. نکته جالب آن که کشف و ابتکار هر دو با مشکل طبقه‏بندی و دسته‏بندی مواجه هستند. یکی از مهمترین نکات مثبت الگوهای طراحی کمک آنها به مشکل کشف کلاسها و المانهای راه حل و کمک به توسعه ابتکاری است که در الگو وجود دارد. به عنوان مثال اگر مسئله‏ای با الگوی سازگارساز(Adpater) حل می‏شود، شناخت اجزای راه حل انجام شده و شما باید ابتکار موجود در الگو را برای تطابق با مسئله واقعی خود توسعه دهید. یکی دیگر از نکات مثبت دیگر در الگوهای طراحی این است که آنها ماحصل تجربه‏اند و نه مباحث آکادمیک. به عبارت دیگر برای خلق یک الگو، لازم نیست شما در آزمایشگاههای مهندسی نرم‏افزار ...
الگوهای طراحی(desing pattern)
الگو های طراحی (Design Pattern) :<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
برنامه نویسی شی گرا - Object Oriented Programming
انواع روش های آنالیز و طراحی شی گراعناوین موجود :پیشگفتار :چرا نرم افزار را مهندسی میگویند ؟متودولوژی USDP و UMLفرآیند توسعه نرم افزاری :فرآیند توسعه نرم افزار – متدولوژی و متدولوژی ساخت یافتهمتدولوژیهای ساخت یافته در سه مقوله وحدت دارند و آنها شامل موارد زیر می شوند :متدولوژی های ساختیافته به دو دسته تقسیم می شوند :متدلوژیهای ساختیافته ... متدلوژیهای شیئ گراروشهای فرایندگرا:روشهای داده گرا :مشکلات متدولوژیهای ساختیافته :مفاهیم پایه Object OrientedClass :متدولوژیالگو های طراحی (Design Pattern) :تاریخچه الگو های طراحی :قالب مستند سازی برای الگوهای طراحی :دسته بندی الگو ها :برنامه نویسی شی گرا :الگوهای طراحی Design Patternانواع معماری های تولید نرم افزار :معماری MainFrame ویژگی : مزایا : معایب :معماری File server ویژگی :مزایا : معایب :معماری Client Server ویژگی : مزایا :معایب :معماری Client Server : Two Tier ویژگی : مزایا : معایب : معماری Client Server : Three Tier ویژگی : مزایا :برنامه نویسی شیء گراشئ چیست ؟کلاس چیست؟معرفی معماری اطلاعات تعریف معماری :معماری اطلاعات :تاریخچه معماری اطلاعات :برخی اصول راهبردی معماری اطلاعات :بررسی معماری سرویس گرا معرفیویژگیهای سرویس و محاسبات سرویس گرامعماری سرویس گرای مقدماتیمعماری سرویس گرای توسعه یافتهمعماری سرویس‌گرا چیست؟ معماری‌های سرویس‌گرا دارای خصوصیات اصلی زیر هستند:چرا SOA؟معماری سرویسزیربنای SOA SOAP, WSDL, UDDIWS-I Basic ProfileJ۲EE و .Net کیفیت سرویس‌هاقابلیت اطمینانخط‌مشیهماهنگ‌سازیمدیریتSOA سرویس‌ وب نیستمزایای SOA معماری برنامه های مبتنی بر دادهغیر ساختیافته:ساختیافته - غیر رابطه ای:سلسله مراتبی:بانک های اطلاعاتی رابطه ای:بانک اطلاعاتی شی گرا:محیط های متصل (Connected)محیط های غیرمتصل Disconnected مزایا:معایب:مدل های متفاوت برنامه ها برای دستیابی به داده هاClient-tire Data Service Tire Interoperability منابع: دانلود پروژه
بررسي و شناخت متدولوژي RUP
چکیده :Rational Unified Process نام کاملترين فرآيند توسعه نرم افزار مي باشد که از ترکيب چند فرآيند ومتد ديگر ايجاد شده و به اختصار به آن RUP گفته مي شود. اين فرآيند بستر مناسبي براي توسعه مکانيزمهاي مديريتي در اختيار کسب و کارها قرار مي دهد. با توسعه آن نسبت به نظام بهره مندي از تجربيات ديگر افراد و سازمانها ، فرآيند ISRUP بستري مناسب براي بهبود مستمر کسب و کارها ايجاد مي کند. براي تحليل طراحي و پياده*سازي سيستم مورد نظر از متدولوژي RUP استفاده مي*شود. RUP يك فرآيند مهندسي نرم*افزار است. اين فرآيند يك روش نظاممند براي تخصيص كارها و مسئوليتها در يك تيم توسعه نرم*افزار مي*باشد و هدف آن توليد نرم*افزار با كيفيت بالاست كه نيازهاي كاربران نهايي را توسط يك برنامه و با بودجه قابل پيش*بيني تأمين نمايد. RUP يك فرآيند محصول ( ProcessProduct ) است كه توسط شركت Rational، تهيه و پشتيبان شده است. تيم توليد RUP به منظور كسب آخرين تجارب و تكامل هاي روز از نزديك با مشتريان و شركاء كار مي*كنند. فرآيند RUP بهره وري تيم را با فراهم نمودن دسترسي تمام افراد تيم به يك پايگاه دانش سهل الوصول به همراه راهنماها، الگوها و ابزارهاي كمكي براي همه فعاليتهاي بحراني توسعه، افزايش مي*دهد. با تأمين دسترسي همه اعضاي تيم به يك پايگاه دانش، افراد در هر قسمت از يك زبان، فرآيند و ديد مشترك براي توسعه نرم*افزار برخوردار هستند. درفعاليتهاي RUP، بجاي تمركز بر روي توليد مستندات بزرگ كاغذي، مدلهايي توليد مي*شوند كه بخوبي سيستم در حال توسعه را ارائه مي*نمايند. فرآيند RUP، راهنمايي براي استفاده مؤثر از زبان يكپارچه مدل*سازي، UML مي*باشد. UML، زباني استاندارد براي تبادل شفاف نيازها، معماري و طراحي است. زبان UML در ابتدا توط شركت رشنال ايجاد شد و هم اكنون توسط موسسه استانداردهاي OMG ( Object Management Group ) پيشتيباني مي*شود. فرآيند RUP توسط ابزارهايي پشتيباني مي*شود كه هر يك بخشهاي بزرگي را فرآيند را به صورت خودكار انجام مي*دهند. آنها براي استفاده و نگهداري از محصولات متنوع- مخصوصاً مدلها- در فرآيند مهندسي نرم*افزار مورد استفاده قرار مي*گيرند. فرآيند RUP فرآيندي قابل شكل*دهي است. هيچ فرآيند واحدي براي همه نرم*افزارها مناسب نمي*باشد فرآيندRUP، همانطور كه براي سازمانهاي بزرگ توسعه نرم*افزار مناسب مي*باشد، براي تيمهاي كوچك نيز مفيد است. اين فرآيند مي*تواند براي تطبيق موقعيتهاي مختلف سازش پيدا كند. فرآيندRUP، چگونگي استفاده مؤثر روشهاي تجاري براي توسعه نرم*افزاري در گروههاي نرم*افزاري را بيان مي*كند. اين روشها كه بهترين تمرينها( Best Practices ) ناميده مي*شوند به طور مشترك در همة صنايع مورد استفاده ...
یک دوره آموزش کامل RUP
یک دوره کامل و خوب rup ، متشکل از چیست ؟کلیه اشخاص دارای تخصص‌های متنوع تولید نرم‌افزار شامل برنامه‌نویسان، طراحان، تحلیلگران سیستم و کسب و کار، معماران، تست‌کنندگان، مهندسین فرایند، مدیران پروژه، مدیران پیکربندی، تست و ... که می‌خواهند RUP را به عنوان چهارچوب فرایند متداول برای تولید نرم‌افزار فراگیرند و نحوه جایگیری تخصص و فراورده های مرتبط با خود و ارتباط آن ها با سایر نقش های مورد انتصاب RUP و جایگاه و نحوه تولید آن‌ها را فراگیرند.تحلیل گران فرایند کسب و کار که تمایل به انجام مهندسی مجدد سازمانی با استفاده از RUP دارند.مدیران شرکت های نرم افزاری که نیاز به درک RUP و مقایسه آن با سایر متدولوژی‌ها نظیر XP و ارتباط آن با چهارچوب‌های فرایند نظیر CMMI برای تصمیم‌گیری متناسب دارند.سرفصلمعرفی RUPمفاهیم پایه و پیش‌نیاز دورهمقایسه RUP و روش‌های چابک و چهارچوب‌های ارزیابیفاز درکدرک محدوده سیستمVision DocumentSupplementary SpecificationsBrainstorming Sessionsشناسایی و توصیف مختصر Actor‌ها، Use-Case‌ها و تدوین واژه نامه سیستمUser interface Prototype و Storyboard هاشناسایی عمکردهای حیاتی سیستمشناسایی Use-Case‌های حیاتی سیستم، انواع آن‌ها و توصیف کامل هریکشناسایی سناریوهای صفات کیفی حیاتی سیستمارائه حداقل یک راه‌حل ممکنArchitectural Proof-of-Conceptشناخت زمان، هزینه و ریسک‌هاRisks, issues and risk listSoftware Development Planتعیین فرایند و ابزارتعداد تکرارها و معیار‌های آنDevelopment Caseفاز تشریحفاز ساختفاز انتقالدیسیپلین‌های RUPدیسیپلین مدل‌سازی کسب و کارتوسعه مجموعه سیستم‌های مرتبط با استفاده از RUPمعرفی EUP و RUP4SOARUP به عنوان رویکرد کلی شامل عمل نمودن مبتنی بر موارد استفاده ، توسعه تکراری، معماری محور بودنRUP به عنوان فرایند مهندسی نرم‌افزار قابل پیکربندی متناسب با پروژه های متفاوتابزار RUPمفاهیم معماری نرم افزار شامل معماری نرم‌افزار، مدل مرجع، پیش ران‌های معماری، الگوهای معماری و ...مفاهیم مهندسی فرایند شامل فرایند نرم افزاری، چهارچوب فرایند، مهندسی فرایند و ...یادآوری مستند موارد کاربردی انواع آنیادآوری تحقق مورد استفادهمعرفی روش‌های چابکمعرفی Extreme Programmingمعرفی مفهوم چهارچوب‌ ارزیابی و CMMIمقایسه RUP و روش های چابک و چهارچوب های فرایندمعرفی دیسیپلین‌های نه‌گانه (مدلسازی کسب و کار، نیازمندی ها، تحلیل و طراحی، پیاده‌سازی، تست، استقرار، مدیریت تغییرات و پیکربندی، محیط)اهداف هر دیسیپلینارتباطات دیسیپلین هافعالیت‌ها و فراورده های مهم هر دیسیپلیناهداف و دلایل انجام مدلسازی کسب و کارراه های انجام مدل سازی کسب و کار (تولید نرم‌افزار، تولید مجموعه نرم‌افزار، مهندسی مجدد ...
مهندسی نرم افزار
1 مقدمه مهندسی نرم افزار هنگامی که صحبت از مهندسی می⁭شود منظور تحلیل و طراحی مبتنی بر اصولی است که منجر به تولید محصولی با کیفیت بالا میگردد. تحلیل، طراحی و ساخت يک محصول باید مبتنی بر مراحلی از قبل تعیین شده باشد. مجموعه⁭ای از مراحل که از قبل مشخص شده⁭اند و به هدف خاصی می⁭رسند را فرایند گویند. پس می⁭توان گفت که مهندسی مبتنی بر فرایند است. هنگامی که محصولی به صورت مهندسی ساخته میشود هدف کیفیت بالا است برای رسیدن به کیفیت بالا باید معیارهایی وجود داشته باشد که قابل اندازه⁭گیری باشد. در نتیجه مهندسی را میتوان به صورت کلی تحلیل و طراحی و ساخت يک محصول با کیفیت مبتنی بر فرایند و با استفاده از اندازه⁭⁭گیری معیارها بیان کرد. حال که با مفهوم مهندسی آشنا شده⁭ایم به تعریف نرم افزار بپردازیم. نرم افزار اصولا در دنیای مدرن غیر قابل اجتناب است. نرم افزار کامپیوتر محصولی است که مهندسان نرم افزار آن را طراحی و ایجاد می کنند و شامل برنامه هایی است که در کامپیوتری از هر اندازه و با هر معماری اجرا می شوند، همچنین شامل مستنداتی است حاوی متن ها ، فرم ها و داده هایی شامل ترکیبی از اعداد و متن و اطلاعات تصاویری ، ویدئوئی و صوتی . به عبارت دیگر نرم افزار یک محصول برای استفاده از سخت افزار کامپیوتری می باشد که خود ارئه دهنده محصول دیگر تحت اطلاعات می باشد و شامل اجزاء زیر می⁭باشد: دستوراتی که در صورت اجرا شدن باعث انجام عمل و کارایی خواسته شده می شوند . ساختمان داده های که باعث می شوند برنامه ها بطور مناسبی اطلاعات را دستکاری کنند . مستنداتی که توصیف کنندۀ عملکرد و استفاده از برنامه⁭هاست نرم افزار توسط مهندسین نرم افزار طراحی و ساخته میشود و مانند هر محصول مهندسی دیگر با به کارگیری فرایندی ایجاد می شود که باعث ایجاد نتایجی با کیفیت بالا می گردد . نرم افزار یک جزء منطقی سیستم است و نه یک جزء فیزیکی و توسعه داده می شود و به شکل معمولی ساخته نمی شود. نکته: اگر از برنامه عقب باشیم ، افزودن افراد جدید باعث عقب افتادگی بیشتر می شود . نصیحت : - قبل از شروع با سخت کوشی سعی کنید آنچه را که می خواهید انجام دهید ، بفهمید . - امکان سنجی پروژه دائم در حال تغییر است اما این تغییرات به راحتی سازماندهی می شوند- زیرا نرم افزار قابل انعطاف است . - هرچه زودتر کد نویسی را شروع کنید ، برای اتمام کار مدت طولانی تری لازم است . تعریف IEEE از مهندسی نرم⁭افزار : بکار گیری روشی سیستماتیک ، اصولی و قابل برسی برای توسعه ، اجراء و پشتیبانی نرم افزار می باشد. 2 فرایند زمانی که یک محصول یا یک سیستم انجام می شود ، مهم ...
این طرح برنده مسابقه طراحی معماری اندونزی شد

مجتمع تجاری اداری Agung Sedayu این طرح به عنوان برنده مسابقه طراحی ساختمان پایدار در کشور اندونزی انتخاب شده است مجتمع تجاری اداری Agung Sedayu توسط گروه معماری Kuiper Compagnons در شهر جاکارتا در کشور اندونزی طراحی شده است و قرار است در آینده نزدیک عملیات احداث آن آغاز شود.این طرح به عنوان برنده مسابقه طراحی ساختمان پایدار در کشور اندونزی انتخاب شده است و دارای بیشترین همخوانی با تکنیک های روز معماری پایدار، در مقایسه با دیگر شرکت کنندگان این مسابقه بوده است. این طراحی با توجه به الگوهای معماری شهر جاکارتا، مصالح بومی در منطقه، اقلیم شهر جاکارتا و نوع بافت شهر، انجام شده است.ایده ی اصلی طراحی این مجموعه، از توپوگرافی یک دره ی باریک برداشت شده است و در نهایت دو ساختمان با پیچ و تابی موزون و چرخشی گام به گام به سمت داخل و هسته مرکزی شکل گرفته است.این مجموعه شامل 6 طبقه پارکینگ می باشد که 3 طبقه در زیرزمین تعبیه شده است. همچنین در طبقه چهارم این مجموعه، یک باغ سرتاسری طراحی شده است. گروه معماری و طراحی این پروژه با مطالعه بافت گیاهی شهر جاکارتا، تمامی گونه های گیاهی موجود در منطقه را در این باغ به کار برده اند و فضای منحصر به فردی را ایجاد کرده اند.از طبقه چهارم تا طبقه شانزدهم، دو ساختمان از یکدیگر جدا شده و چرخش زیبایی را به نمایش می گذارند. سیستم سازه ای این مجموعه به گونه ای طراحی شده است که در مقابل عواملی همچون زلزله و سونامی بسیار مقاوم می باشد.با توجه به مستعد بودن منطقه در بروز حوادثی همچون زلزله و سونامی، تیم طراحی سازه، از ابتدای امر توجه کاملی را به این موضوع داشته اند.یکی از مهم ترین اضول معماری پایدار در مجتمع تجاری اداری Agung Sedayu استفاده حداکثری از تهویه طبیعی به منظور کاهش استفاده از خنک کننده های مکانیکی می باشد. همچنین فرم کامل و جزییات ساختمان، با هدف استفاده کامل از نور خورشید در نما، و بهره مندی از جهت باد غالب، طراحی شده است.نمای این مجموعه، کاملا انعطاف پذیر می باشد و با توجه به میزان باد و نور خورشید، رفتار متفاوتی را از خود نشان می دهد. تمامی آب باران در این مجتمع تصفیه شده و مورد استفاده مجدد قرار خواهد گرفت. همچنین پانل های خورشیدی موجود در سقف، انرژی خورشیدی را به انرژی الکتریکی تبدیل می کنند.در کلیه تراس های این مجموعه، پمپ حرارتی زمین گرمایی، برای بهره مندی از انرژی بیکران کره زمین تعبیه شده است. در طراحی این مجتمع علاوه بر الگوبرداری از دره ی تنگ، از صنایع دستی اندونزی و نوعی سبد محلی نیز استفاده شده است و در آینده نزدیک این مجتمع علاوه بر نمادی مدرن برای شهر جاکارتا و کشور اندونزی، ...