PDA

View Full Version : معماری نرم افزار



رضا ارزانی
یک شنبه 05 فروردین 1386, 00:14 صبح
با عرض سلام و تبریک سال نو
من اطلاعاتی راجع به معماری نرم افزار می خواستم .معماری تک لایه و ....... را می دونم فقط اطلاعاتی راجع به معماری نرم افزار می خوام.
با تشکر

whitehat
دوشنبه 06 فروردین 1386, 11:53 صبح
با سلام
دوست عزیز اگر منظور شما از معماری نرم افزار بصورت کلان است باید گفت که معماری یک لایه ، چند لایه و ... بخشی از معماری نرم افزار می باشد.معماری نرم افزار از بخش های متعددی تشکیل شده و بسته به نوع متدلوژی شما دارای جزئیات مختلفی می باشد. یک معماری نرم افزار نشان می دهد که نرم افزار از چه ساختاری تشکیل شده ، چگونه در محیط استقرار می یابد ، در دید کلان چه وظایفی را انجام می دهد و چه توقعی از سیستم را برآورده می کند.
اگر به جزئیات بیشتری نیاز دارید بپرسید :)

manager
دوشنبه 06 فروردین 1386, 13:05 عصر
مقدمه
از بدو مطرح شدن نرم افزار تاکنون ، معماری های متفاوتی بمنطور طراحی و پیاده سازی ارائه شده است . معماری های فوق از یکطرف برخاسته از امکانات و ماهیت سخت افزار ها در زمان خود و از طرف دیگر نمایانگر نوع و نگرش انتظارات طرح شده توسط کاربران است . بخاطر داشته باشیم که نرم افزار دارای ماهیتی پویا بوده و در هر زمان می بایست خود را با خیل عظیم نیازها و انتظارات جدید کاربران تطبیق نماید. چراکه نرم افزار عصاره خواسته های انسانی بمنظور بالفعل شدن بر روی بستر سخت افزار در گذر زمان است . بدیهی است از گذشته تاکنون، هم طیف خواسته های انسانی تغییر کرده و خواهد کرد و هم سخت افزارها دچار تغییر و تحول گسترده ای بوده و خواهند بود. در این راستا لازم است نرم افزار نیز با رعایت کامل اصل انعطاف پذیزی ، پذیرای تمامی تحولات از گذشته تاکنون بوده و بتواند در هر زمان رسالت خود را بخوبی انجام دهد. بر همین اساس از گذشته تاکنون معماری های متفاوتی بمنظور طراحی و پیاده سازی نرم افزار ارائه شده است . هر معماری دارای شاخص ها و ویژگی های منحصر بفرد خود بوده و نرم افزارهائی که با اتکاء بر هر یک از معماری های فوق پیاده سازی می گردنند ، خصایص خود را از معماری بکارگرفته شده به ارث خواهند برد. در این بخش به رفتارشناسی هر یک از معمارهای ذیل پرداخته تا از این طریق زمینه های لازم بمنظور شناخت معماری بکارگرفته شده در برنامه های تحت وب فراهم گردد.
معماری MainFrame
معماری File Server
معماری سرویس گیرنده / سرویس دهنده
معماری Two-Tier
معماری Three-Tierمعماری MainFrame
ویژگی :
- معماری فوق در دهه های ۱٩٦۰ الی ۱٩۷۰ مورد توجه و استفاده جدی قرار داشت .
- کامپیوتر اصلی ( Host) مسئولیت انجام تمامی پردازش ها را برعهده دارد.
- کاربران با استفاده از ترمینال ها ، قادر به ایجاد ارتباط با سیستم اصلی (host) می باشند.
- ترمینال ها هوشمند نبوده و صرفا" به یک صفحه کلید و نمایشگر محدود می باشند.
- فشردن کلیدهای صفحه کلید ، تنها چیزی است که ارتباط بین کاربران(ترمینال ها ) و سیستم اصلی را معنی خواهد کرد.
- داده ها و منطق برنامه بر روی یک سیستم (Host) یکسان ذخیره می گردنند. .

مزایا :
- امنیت در این نوع معماری بسیار بالا است .
- با توجه به تمرکز داده ها و منطق ، مدیریت متمرکز و اعمال آن آسان خواهد بود.

معایب :
- هزینه تهیه ، اجاره و پشتیبانی این نوع سیستمها بسیار بالا است .
- برنامه ( منطق ) بهمراه داده های مربوطه در یک محل مستقر و از یک محیط پردازش یکسان استفاده می کنند.
- اغلب برنامه های نوشته شده بر اساس معماری فوق محیط های رابط کاربر گرافیکی را حمایت نمی نمایند



http://www.srco.ir/tutorial/images/mainframe.jpg




معماری File server
ویژگی :
- چرخش ۱٨۰ درجه ای نسبت به معماری MainFrame.
- از سرویس دهنده یا سرویس دهند گان متعدد، بصورت متمرکز استفاده می گردد.
- منابع متفاوتی نظیر چاپگر و یا فضای ذخیره سازی ( هارد ) به اشتراک گذاشته می شوند.
- سرویس دهنده فایل های مورد نیازو ذخیره شده توسط منابع اشتراکی را برای کاربران ارسال خواهد کرد.
- کار درخواست شده توسط کاربر ( منطق و داده ) بر روی سیستم کاربر اجراء خواهد شد.
- منطق برنامه برروی سیستم کاربر ( سرویس گیرنده ) اجراء خواهد کردید.
- داده ها بر روی سرویس گیرنده مستقر خواهند شد.

مزایا :
- برای استفاده از معماری فوق نیاز به صرف هزینه های بالا نخواهد بود .
- از لحاظ بکارگیری منابع دارای انعطاف پذیری مناسبی است .

معایب :
- تمامی منطق برنامه بر روی سرویس گیرنده اجراء خواهد شد .
- وجود محدودیت های خاص نظیر میزان حافظه و یا نوع پردازشگر سرویس گیرندگان، بکارگیری برنامه را با مشکل مواجه می سازد.
- بهبود عملکرد برنامه و یا اعمال اصلاحات مورد نظر همواره یکی از چالش های جدی است .




http://www.srco.ir/tutorial/images/FileServer.jpg




معماری Client Server
ویژگی :
- در معماری فوق از سرویس دهند گان و سرویس گیرند گان با خصایص متفاوت استفاده می شود.
- اصل تقسیم کار دنبال و سرویس دهنده عملیات سنگین با پردازش بالا و سرویس گیرنده عملیات سبک را انجام خواهند داد.
- دو بخش متفاوت یک برنامه ، در جهت انجام عملیات با یکدیگر تشریک مساعی می نمایند.
- سرویس گیرنده با ارسال درخواست و سرویس دهنده با پاسخ به درخواست جلوه ای از همیاری در پردازش عملیات را بنمایش می گذارند.
- پلات فورم و سیستم های عامل سرویس دهنده و سرویس گیرنده می تواند متفاوت باشد.
- عملیاتی را که یک برنامه انجام می دهد بین سرویس دهنده و سرویس گیرنده تقسیم می گردد.

مزایا :
- بهره گیری مناسب از پتانسیل های سخت افزاری موجود با توجه به اصل تقسیم عملیات ها
- بهینه سازی استفاده و بکارگیری منابع اشتراکی .
- بهینه سازی توانائی کاربران از بعد انجام فعالیت های متفاوت

معایب :
- عدم وجود امکانات لازم برای کپسوله نمودن سیاست های راهبردی نرم افزار
- کاهش کارائی برنامه همزمان با افزایش تعداد کاربران همزمان
- بهبود عملکرد برنامه و یا اعمال اصلاحات مورد نظر همواره یکی از چالش های جدی است .


http://www.srco.ir/tutorial/images/ClientServer1.jpg


تاکنون مدل های متفاوتی از معماری فوق پیاده سازی شده است .

۱ - پردازش های مبتنی بر میزبان . مدل فوق بمنزله یک مدل سرویس دهنده / سرویس گیرنده تلقی نشده و مشابه مدل MainFarme است .


http://www.srco.ir/tutorial/images/HostBased.jpg


۲ - پردازش های مبتنی بر سرویس دهنده . در این مدل سرویس دهنده تمامی پردازش های مربوطه را انجام و سرویس گیرنده مسئولیت ایجاد بخش رابط کاربر را برعهده خواهد د اشت.


http://www.srco.ir/tutorial/images/ServerBased.jpg




۳ - پردازش های مبتنی بر سرویس گیرنده . تمامی عملیات بر روی سرویس گیرنده انجام خواهد شد. عملیات مربوط به بررسی صحت داده ها و سایر عملیات مربوط به منطق بانک های اطلاعاتی بر روی سرویس دهنده انجام خواهد شد.




http://www.srco.ir/tutorial/images/clientBased.jpg




٤ - پردازش های مبتنی بر همیاری .در این مدل سرویس دهنده و سرویس گیرنده بمنظور انجام یک فعالیت با یکدیگر تشریک مساعی خواهند کرد.


http://www.srco.ir/tutorial/images/CoBased.jpg




معماری Client Server : Two Tier

ویژگی :
- مشابه مدل Client Server در بخش قبل می باشد.
- در این مدل از یک سرویس دهنده و یک سرویس گیرنده در شبکه استفاده می گردد.
- مدل فوق از سه بخش که در دو لایه سرویس دهنده و سرویس گیرنده قرار خواهند گرفت، تشکیل می گردد.
- بخش های رابط کاربر ، مدیریت پردازش ها و مدیریت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
- منطق برنامه بین دو محل فیزیکی توزیع می گردد.


مزایا :
- مناسب ترین روش برای پردازش های توزیع شده در یک شبکه با حداکثر یکصد کاربر
- سهولت در امر پیاده سازی
- نسبت دهی مستقیم رابط کاربر با منابع تامین داده ها


معایب :
- عدم وجود امکاناتی برای کپسوله نمودن سیاست های راهبردی نرم افزار
- کاهش کارائی برنامه همزمان با افزایش تعداد کاربران همزمان ( بیش از یکصد )
-عدم وچود انعطاف لازم از بعد انتقال یک برنامه از سرویس دهنده ای به سرویس دهنده دیگر بدون انجام تغییرات اساسی


http://www.srco.ir/tutorial/images/2tier.gif




معماری Client Server : Multi-Tier

http://www.dpi.net.ir/.%5Ccontent/fa/software/technology/architecture/muti-tier-arc.gif

ویژگی :
- مدل فوق در سال 1990 عرضه شده است .
- در این مدل از یک Tier میانی دیگر بین سرویس گیرنده ( رابط کاربر) و سرویس دهنده بانک اطلاعاتی استفاده می شود.
- لایه میانی شامل مجموعه ای از ابزارها برای دستیابی به منابع سیستم ، صرفنظر از نوع پلات فورم است .
- لایه میانی مسئولیت مدیریت پردازش ها را برعهده خواهد گرفت .
- لایه میانی مسئولیت تجزیه و یا ترکیب نتایج حاصله از منابع داده ئی نظیر بانک های اطلاعاتی را برعهده دارد.
- بخش های رابط کاربر ، مدیریت پردازش ها و مدیریت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
- لایه میانی خود می تواند به دو و یا بیش از دو بخش با عملکردهای متمایز تقسیم گردد (Multi-Tier)
- مدل فوق گزینه ای مناسب برای پیاده سازی نرم افزار بر روی اینترنت است .


مزایا :
- افزایش کارآئی ، انعطاف پذیری ، قابلیت استفاده مجدد و توان پشتیبانی
- ارتقاء کارآئی همزمان با افزایش تعداد کاربران
- مخفی نمودن پیچیدگی ها ی موجود با توجه به ماهیت پردازش های توزیع شده از دید کاربران
- ارائه امکانات لازم به برنامه نویسان بمنظور طراحی و پیاده سازی نرم افزار ها با یک رویکرد مشابه
- ارائه امکانات لازم به برنامه نویسان بمنظور تبعیت از روش های یکسان برای دستیابی به داده ها





http://www.srco.ir/tutorial/images/ThreeTier.jpg





http://www.srco.ir/tutorial/images/3tier_3.gif



منبع : این مطالب هم از سایت شرکت داده پردازی و هم از سایت شرکت سخاروش اقتباس شده است.

manager
دوشنبه 06 فروردین 1386, 13:10 عصر
اینترنت بستری مناسب برای پیاده سازی برنامه های توزیع شده است . وجود زیر ساخت های لازم در این زمینه شرایط مطلوبی را برای پیاده سازی برنامه های توزیع شده ، فراهم آورده است .


http://www.srco.ir/tutorial/images/Sample1.jpg


دستیابی به یک وب سایت و یا ارسال و دریافت پیام های الکترونیکی نمونه هائی از برنامه های توزیع شده بر روی بستر اینترنت می باشند.


http://www.srco.ir/tutorial/images/Cllent2.jpg


برنامه های پست الکترونیکی نمونه ای مناسب در این زمینه می باشند.


http://www.srco.ir/tutorial/images/Cllent4.jpg


برنامه های Chat نمونه دیگری از برنامه های توزیع شده بر روی بستر اینترنت می باشند.


http://www.srco.ir/tutorial/images/Cllent6.jpg


منبع : شرکت سخاروش (http://www.srco.ir)

manager
دوشنبه 06 فروردین 1386, 14:15 عصر
با سلام
....معماری نرم افزار از بخش های متعددی تشکیل شده و بسته به نوع متدلوژی شما دارای جزئیات مختلفی می باشد. ...
اگر به جزئیات بیشتری نیاز دارید بپرسید :) می شه در این مورد بیشتر توضیح بدین ؟!!!!!!!!!!!!!!!!:متفکر:

رضا ارزانی :
اگر در مورد معماری خاصی سوال داشتی بپرس؟

CodeMasterX
سه شنبه 07 فروردین 1386, 02:18 صبح
ممنون، خوب بود!

whitehat
پنج شنبه 09 فروردین 1386, 18:59 عصر
از دید مهندسی نرم افزار ، معماری سیستم شامل کلیه موارد لازم برای توسعه نرم افزار می باشد، نوع متدلوژی میزان پرداختن به جزئیات را مشخص می کند. (مثلا جزئیاتی که در روش های agile بکار میرود بسیار کمتر از متدلوژی ها سنگین وزن می باشد)
فرض کنید شما می خواهید بر اساس متدلوژی RUP می خواهید یک سند معماری نرم افزار (http://www-128.ibm.com/developerworks/rational/library/05/0816_Louis/#download) را برای نرم افزار خود تهیه کنید. شما باید در این سند حتما دیدگاه های 4+1 را حتما پیاده سازی نمائید و سپس بر اساس Customizationی که انجام داده اید نیاز های غیر وظیفه ای را در این سند بگنجانید ، در صورتی که در متدلوژی دیگری شما این قسمت را ممکن است حذف می کنید یا دیدگاهها را خیلی خلاصه تر ترسیم می نمائید. یا در متدلوژی ssadm شما اصلا نیازی ندارید که وارد جزئیات پیاده سازی (بصورتی که معین کنید هر مولفه بر روی چه سخت افزاری نصب می شود) شوید. بر اساس متدلوژی های مختلف جزئیات مختلفی را برای تهیه معماری نرم افزار خواهید داشت.

manager
پنج شنبه 16 فروردین 1386, 21:57 عصر
می خواستم از دوستان بخوام اگر کتاب مناسب و معتبری در زمینه معماری نرم افزار می شناسند. معرفی کنند. (فارسی یا لاتین بودنش مهم نیست).
من کتاب های زیادی تو اینترنت با عنوان Software Architect پیدا کردم ولی هیچ کدوم مفاهیمی چون معماری N-Tier یا کلاینت سرور یا .. رو شرح نداده بودند !!!
اگر محبت کنید و نام چند تن از نامداران این عرصه رو هم نام ببرید ممنون می شم.

whitehat
جمعه 17 فروردین 1386, 11:56 صبح
برای این کار بهتره به مقالات مربوط به مهندسی نرم افزار که مفهوم خاصی را توضیح می دهند مراجعه کنید ، با این کار در زمان صرفه جویی می کنید. بطور کلی معماری نرم افزار چیزی است که یک مهندس نرم افزار باید آنرا تهیه کند ، در سطح کلان معماری های بسیار زیادی بصورت Template در اینترنت موجود است (مانند مثال شما) اما هر پروژه ای معماری خاص خود را می طلبد و بهتر است برای یادگیری دقیق یک پروژه ساده برای خود تعریف کنید و بر اساس آن معماری را پیاده سازی کنید. یکی از بهترین مراجع ، مستندات شرکت Rational می باشد. من 2 مقاله ضمیمه می کنم که یکی مربوط به معماری N-Tire برای طراحی پروژه های Data Intensive و دیگری یک سند معماری است که امید وارم مفید باشه

delphi developer
جمعه 17 فروردین 1386, 16:46 عصر
متن زیر از پایانامه ی کارشناسی آقای یاسر صفری نیا اقتباس شده است :
تعاریف معماری نرم افزار:
معماری نرم افزار ساختار بنیادی و اسکلت سیستمی است، که قرار است ایجاد شود. در کل هیچ تعریف استاندارد و همه پذیری برای معماری نرم افزار ارائه داده نشده است، اما بیش از یکصد تعریف فنی برای معماری نرم افزار در سایت دانشگاه کارنگی ملون موجود است. برگزیده این تعاریف به شرح زیر می‌باشند:


تعریف بوچ، رامبو و ژاکوبسن:
معماری نرم افزار مجموعه ای از تصمیمات اساسی در مورد سازماندهی یک سیستم نرم‌افزاری، گزینش عناصر ساختاری و چگونگی ارتباط میان آنها می باشد.
تعریف گارلن و پری6:
معماری نرم افزار ساختار اجزاء یک سیستم و چگونگی ارتباط میان آنها و اصول و قواعدی است که بر طراحی و توسعه تدریجی آنها در طول زمان تأثیر می‌گذارند.
تعریف بوهم:
معماری نرم افزار مجموعه ای از اجزاء نرم افزاری، نحوه ارتباط مابین آنها و محدودیت‌های حاکم بر آنها و مجموعه ای از نیازمندی های عوامل سیستم می باشد. معماری نرم افزار در کل استدلالی است که اثبات می کند اجزاء، ارتباطات و محدودیت های ذکر شده اگر پیاده سازی شوند مجموعه نیازمندی های عوامل را ارضاء می نمایند.
تعریف گارلن و شاو:
معماری نرم افزار توصیف عناصر سیستمی است که قرار است ایجاد گردد و چگونگی تعامل میان این عناصر، الگوهایی که نحوه تعامل میان این عناصر را هدایت می کنند و محدودیت های مربوط به این الگوها می باشد.
تعریف کروچن (1+4) :
کروچن معماری را از 5 منظر تعریف می نماید:
Logical View: نیازمندی‌های رفتاری را پشتیبانی می کند و نشان می دهد که سیستم چگونه به مجموعه ای از انتزاع ها تجزیه می شود.
Process View: این منظر به ما اجازه مطالعه و توصیف فرایندهای سیستم و چگونگی ارتباط آنها را می دهد. مروری بر فرایندها و ارتباطشان ما را در رفع خطاهای غیرعمدی کمک می‌کند.
Development View: این منظر برای توصیف ماژول های سیستم استفاده می‌شود. ماژول‌ها المان های پایه ای بزرگ از کلاس ها و اشیاء می باشند و با توجه به توسعه محیط تغییر می کند. این منظر یک روش خوب برای دیدن لایه های سیستم در معماری لایه‌ای است که در رویکردهای طراحی معماری بحث خواهد شد.
Physical View: منظر فیزیکی چگونگی نصب و اجرای برنامه‌ها را روی شبکه‌ای از کامپیوتر شرح می‌دهد. این دید به نیازمندی‌های غیروظیفه‌ای مانند در دسترس بودن، قابلیت اطمینان، کارایی ومقیاس پذیری اهمیت می‌دهد.
Plus one view) use case and scenario view): این منظر وظیفه‌مندی سیستم را شرح می دهد و در قالب سناریوها و usecase در می آورد، در واقع ساختار سایر دیدها را شرح می دهد و تحکیم می نماید.

طراحی معماری نرم‌افزار:
طراحی معماری نرم‌افزاری را با دو رویکرد مبتنی بر سبک و مبتنی بر ساختار مورد بحث و بررسی قرار می‌دهند.
رویکردهای مبتنی بر سبک:
در این رویکرد‌ها، طراحی معماری معادل انتخاب سبک می‌باشد و یک سبک معماری، معرف چهار ویژگی‌ زیر می‌باشد:
1-عناصر و رابطه‌های میان آنها در معماری
2-قیود و ضوابط حاکم بر نحوه ترکیب عناصر در معماری
3-تحلیل‌های قابل اجرا روی معماری
4-تفسیر معنایی عناصر که مطابق ضوابط این سبک با یکدیگر ترکیب می شوند

,Event –Based ,Client/Server ,Two-Tier ,Three-Tier ,Fileserver ,Main Frame
… ,Pipe & Filter ,Pipe line به عنوان نمونه‌هایی از سبک‌های معماری مطرح، می‌باشند. که ویژگی‌ها، مزایا و معایب برخی از این سبک‌ها به اجمال توسط manager مورد بررسی قرار گرفته است.
رویکرد های مبتنی بر ساختار:
این رویکرد ها که موضوع بحث پایان نامه مذکور نیز می باشد، براساس روشهای چندگانه تعریف می شود . از جمله این روش ها می توان Krutchen، ABD، ADD، Bosch (روش موازنه خصیصه های کیفی) و ... را نام برد که در صورت تمایل دوستان، دو روش ABD و ADD بیشتر توضیح داده خواهند شد.

setak
چهارشنبه 22 فروردین 1386, 09:45 صبح
لطفا در مورد رویکرد مبتنی بر ساختار بیشتر توضیح بدید

delphi developer
جمعه 31 فروردین 1386, 23:10 عصر
با پوزش از تاخیر پیش امده....

سیستم‌های امروزی به اندازه‌ای بزرگ هستند که درک کل آنها کار ساده‌ای نیست، بنابراین گام به گام ساختارهای سیستم را مورد کندوکاو قرار می‌دهیم. در این راستا باید ساختار یا ساختارهای سیستم مورد بررسی، کاملاً مشخص شوند و منظر‌ها نیز به روشنی تعریف گردند.
منظرها، مجموعه‌ای از مولفه های مرتبط را نمایش می‌دهند و چگونگی ارتباط (اعم از خواندن و نوشتن) موفه ها را با ذینفعان سیستم مشخص ‌می‌کنند. در واقع منظرها شامل المان‌ها و روابط بین آنها میباشند. ساختارها نیز مجموعه‌ای از خود المان‌ها، اعم از سخت‌افزاری ونرم‌افزاری، می‌باشند.
ساختار معماری می‌تواند بنا به طبیعت مولفه هایش، به سه دسته تقسیم گردند:
1.Module structures
Component and connector Structures.2
Allocation Structures.3

در کل این سه ساختار به دلیل سه نوع تصمیمی است که طراح معماری اخذ می‌نماید، این سه تصمیم عبارتند از:
اول،سیستم چگونه به صورت مجموعه‌ای از قطعه کدها (ماژول‌ها) ساختار بندی می‌شود؟
دوم،سیستم از نظر رفتار المان‌ها در زمان اجرا (مؤلفه‌ها) و تعامل بین آنها (رابطه‌ها) چگونه ساختار بندی می‌شود؟
سوم،سیستم از نظر رابطه با ساختارهای غیر نرم‌افزاری (مانند پردازنده‌ها، فایل‌های سیستمی، شبکه‌ها، تیم‌های توسعه و ...) چگونه ساختار بندی می‌شود؟

هرکدام از ساختارها، اجزایی دارند که در زیر به توصیف هر یک می‌پردازیم.
ساختارهای ماژول:
ساختارهای مبتنی بر ماژول شامل موارد زیر می‌شوند:

Decomposition: واحدها در این قسمت، ماژول‌هایی هستند که توسطه رابطه‌ی "is a submodule of" با یکدیگر ارتباط دارند. در این ساختار، ماژول های بزرگ آنقدر می‌شکند تا به ماژول‌های قابل فهم برسند. ترتیب واحدهایی که باید اجرا شوند نیز توسط معمار مشخص می‌شود. ماژول‌ها معمولا یک سری فرآورده‌های کمکی مانند تعیین واسطه‌ها، شبه کدها، طرح‌های تست و ... را به همراه دارند، همچنین ماژول‌ها در قابلیت انعطاف پذیری سیستم تأثیر زیادی دارند و به عنوان یک رکن بنیادی در سازماندهی پروژه توسعه مورد استفاده قرار می‌گیرند و شامل ساختار مستند سازی، طرح‌های تست و یکپارچه سازی می‌باشند. نام واحدها در این ساختار از قاعده‌ی Organization-Specification تبعیت می‌کند.

Uses: واحدهای این قسمت همان ماژول‌ها یا رویه ( برای تضمین در نظر گرفتن نکات مهم و حساس) و یا منابع مربوط به واسطه‌های ماژول‌ها هستند. Usesها توسط رابطه هایی با هم مرتبط می‌شوند. یک Uses هنگامی می‌تواند از Uses دیگر استفاده کند که اجرایش منوط به اجرای صحیح دیگری باشد. علت وجود Uses آن است که بتوان به راحتی یک وظیفه مندی را به سیستم اضافه یا از سیستم حذف کرد.

Layered :بعد از اینکه Uses ها آماده و اعتبار سنجی شدند، می‌توان آن‌ها را لایه بندی کرد به طوری که لایه nام تنها از لایه n-1 ام سرویس بگیرد. این کار باعث می‌شود طراحی خاصیت انتزاعی داشته باشد و پیاده سازی لایه‌های زیرین به وسیله لایه‌های بالایی پوشانده شود. این امر باعث تولید یک محصول قابل حمل می‌شود.

Class: ماژول‌های این ساختار کلاس نام دارند و با روابط "inherits-from" و "is-a-instance-of" با یکدیگر در ارتباطند. قابلیتی که این منظر ایجاد می‌کند گردآوری ماژول‌هایی است که رفتارها یا توانایی‌های مشابه دارند و همچنین تعیین پارامترهایی است که به زیر کلاس‌ها ارث می رسند. این ساختار قدرت استفاده مجدد و اعمال وظیفه‌مندی‌ها را به صورت افزایشی بالا می‌برد.

ساختارهای مولفه/اتصالگر:
ساختارهای مبتنی بر مولفه/اتصال دهنده شامل موارد زیر می‌شوند:

Process: یکی از مطالب اصلی در ساختارهای مبتنی بر ماژول است و به صورت پویا در زمان اجرای سیستم نمود پیدا می‌کند. واحدها در این قسمت، فرایند یا Thread هایی هستند که توسط تبادل داده، همزمان سازی و عملگرهای منحصر کننده با هم ارتباط دارند . نوع رابطه در این واحد از نوع الحاق است و نحوه اتصال مؤلفه‌ها واتصال دهنده‌ها را به هم نشان می‌دهند. این ساختار برای کمک به بالا بردن کارایی و مقبولیت اهمیت دارد.

Concurrency: امکان موازی کاری و تعیین محل تصادم منابع را می‌دهد. این‌جا واحدها از نوع مؤلفه‌ و رابطه‌ها از نوع Threadهای منطقی هستند. Threadهای منطقی معرف ترتیب انجام محاسبات می‌باشند که در بخش طراحی به Threadهای فیزیکی تقسیم می‌شوند. دلیل استفاده از این ساختار، تعیین نیازها برای مدیریت مشکلات وابسته به اجرای همروند می‌باشد.

Shared data: شامل مؤلفه‌ها و رابطه‌هایی است که داده‌ را تولید، انبار و مورد دسترسی قرار می‌دهند. ( ساختارهایی که حول یک یا چند انباره داده‌ی اشتراکی ایجاد می‌شوند). این ساختار چگونگی ایجاد و مصرف داده توسط المان‌هایی نرم افزار را در زمان اجرا نشان می‌دهد و از طریق آن می‌توان از کیفیت کارایی و یکپارچگی داده‌ها اطمینان حاصل کرد.

Client/Server: برای نمایش ساختاری است که به صورت Client ها و Serverها گروه بندی شده است که Client ها و Server ها در این ساختار مؤلفه‌ها را می‌سازند و پروتکل‌ها و پیغام‌هایی که رد و بدل می‌کنند، ارتباط دهنده‌ها را می‌سازند. دلایل استفاده از این ساختار، جداسازی محیط‌ها برای بالا بردن تغییرپذیری، ایجاد انتزاع فیزیکی و ایجاد کارایی زمان اجرا به وسیله فراهم آوردن سنجش بارگذاری می‌باشد.

ساختارهای تخصیص:
ساختارهای مبتنی بر تخصیص شامل موارد زیر می‌شوند:

Deployment: نحوه‌ی انتساب نرم‌افزار به پردازش سخت‌افزاری و المان‌های ارتباطی را مشخص می‌کند. این المان ها شامل نرم‌افزار (فرایندی از منظرِ مؤلفه-اتصال دهنده)، موجودیت‌های سخت افزاری و راه‌های ارتباطی می‌شوند. نوع رابطه‌هایی که در این ساختار استفاده می‌شوند، "allocated-to" و "migrates-to " می‌باشند که اولی نحوه‌ی قرار گرفتن المان‌های نرم‌افزاری در واحدهای فیزیکی را نشان می‌دهد و دومی نحوه اختصاص دهی پویا را نمایش می‌دهد. دلیل استفاده از این ساختار، فراهم شدن امکان استدلال در مورد کارایی، یکپارچگی داده، مقبولیت و امنیت می‌باشد. این ساختار خصوصاً برای سیستم‌های توزیع شده یا موازی بسیار مفید است.

Implementation: نحوه‌ی نگاشت المان‌های نرم‌افزار به ساختار فایل در توسعه، یکپارچه سازی و کنترل پیکربندی محیطی سیستم را مشخص می‌کند. دلیل استفاده از این ساختار، مدیریت فعالیت‌های توسعه و ساخت فرایندها می‌باشد.

Work Assignment: ساختاری جهت یکپارچه سازی ماژول و مسئولیت‌ها برای انتساب آنها به تیم‌های توسعه می‌باشد. این ساختار نشان می‌دهد که هر کسی چه کاری باید انجام دهد و نیز جنبه‌ی مدیریتی معماری را در بر دارد و لازمه‌ی آن شناخت نیازهای فنی تیم‌ها توسط معمار است.

ارتباط ساختارها با هم:
المان‌های موجود در ساختارهای مختلف می‌توانند با هم رابطه داشته باشند و به هم وابسته باشند واین رابطه از نوع " چند به چند" است. در بعضی پروژه‌های منحصر به فرد یک ساختار بر دیگر ساختارها برتری دارد و اغلب اوقات این ساختار، ساختار تجزیه است، آن هم به علت اینکه، این ساختار هسته‌ی اصلی پروژه را در بر دارد. بهترین راه نمایش ارتباط یک ساختار با دیگر ساختار سناریو است.
باید توجه داشت که همه سیستم‌ها، به همه ساختارها نیاز ندارند. سیستم‌های بزرگ تعداد بیشتری از ساختارها را نیاز دارند و سیستم‌های کوچک‌تری به تعداد کمتری از آنها نیازمند هستند. به عنوان مثال اگر سیستم‌ دارای یک فرایند بود و یا دارای ساختار توزیع شده نبود، نیازی به ساختارهای فرایند و توسعه ندارد.
ساختارها نقاط اهرمی و اولیه مهندسی را در معماری نشان می‌دهند . هر ساختاری به نوبه‌ی خود قدرت دستکاری یک یا چند خصیصه کیفی را در اختیار معمار می‌گذارد. ساختارها نمایانگر قدرت نگرش جداسازی حوزه‌ها برای ایجاد معماری هستند، همچنین نکات پایه‌ای مهندسی که معمار انتخاب کرده اولین کاندید برای تولید هسته اصلی مستندات معماری است.


حال کدام ساختارها را انتخاب کنیم؟
در پاسخ باید گفت هیچ راه کار خاصی وجود ندارد. تقریبا اکثراً تجربیات عملی، معماری سه لایه ای گفته شده را تأیید می کند، اما اینکه از چه ساختارهایی استفاده می شود بسته به محتوای پروژه و دید معمار (که چه ساختار هایی او را به خصیصه های کیفی نزدیک تر می کند) دارد.

معماری 1+4 کروچن در جهت از بین بردن تصادم بین ساختارها و جهت دهی آنها برای پوشش دادن کامل نیازمندی ها در سال 1995 ارائه شد. چهار منظر از این نگرش به صورت زیر می باشند:
Logical: المان ها از نوع انتزاع های کلیدی هستند که در دنیای شی گرایی به آنها شیء یا کلاس گفته می شود. منظر مترادف آن در معماری منظر ماژول است.
Process: دیدگاهی برای طبقه بندی همروندها و توزیع فعالیت هاست که منظر مترادف آن در معماری، منظر مولفه و ارتباط دهنده است.
Development: این منظر نحوه سازماندهی ماژول های نرم افزار، برنامه ها، زیر سیستم ها و واحدهای توسعه شرح می دهد. منظر مترادف آن در معماری منظر تخصیص می باشد که نحوه نگاشت نرم افزار بر محیط توسعه می باشد.
Physical: این منظر، نحوه نگاشت المان ها به فرایند ها و نُودهای ارتباطی را نشان می دهد، که منظر مترادف آن در معماری ،منظر تخصیص است.

CodeMasterX
یک شنبه 02 اردیبهشت 1386, 01:00 صبح
آقایون من یه پیشنهاد دارم.
این مطالب در مورد مدلهای معماری نرم افزار رو بصورت مقاله های PDF در بیارین اگه زحمت نیست و اونجوری گسترش شون بدیم ؟!

xxxxx_xxxxx
شنبه 19 بهمن 1387, 16:55 عصر
گزارش سمينار كارشناسي ارشد

سبكهاي معماري نرم افزار

توسط حسين هاشميان

شامل:
1- مفهوم و تعريف معماري نرم افزار
2- مشخصه هاي كيفيتي در معماري نرم افزار
3- سبكهاي معماري نرم افزار
4- قابليت اطمينان در سبكهاي چندريختي
5- نتيجه گيري

(98 صفحه) Download (http://persiandrive.net/606539) پسورد: 100110

mitil_mitil
سه شنبه 09 تیر 1388, 22:39 عصر
گزارش سمينار كارشناسي ارشد



سبكهاي معماري نرم افزار


توسط حسين هاشميان


شامل:



1- مفهوم و تعريف معماري نرم افزار


2- مشخصه هاي كيفيتي در معماري نرم افزار


3- سبكهاي معماري نرم افزار


4- قابليت اطمينان در سبكهاي چندريختي


5- نتيجه گيري




(98 صفحه) Download (http://persiandrive.net/606539) پسورد: 100110


مي شه لطفا راهنمايي كنيد كه چه طور مي شه مطلب فوق رو دانلود كرد؟متاسفانه نمي تونم دانلود كنم.

xxxxx_xxxxx
پنج شنبه 11 تیر 1388, 13:21 عصر
مي شه لطفا راهنمايي كنيد كه چه طور مي شه مطلب فوق رو دانلود كرد؟متاسفانه نمي تونم دانلود كنم.
متاسفانه چند وقتي هست Persindrive به مشكل برخورده
از ضميمه اين پست دانلود كنيد

rubako
سه شنبه 17 مرداد 1391, 03:58 صبح
دوستان سلام،
برای آموزش معماری نرم افزار،‌ استودیوهای روباکو یک دوره ویژه به نام "ارتقا از برنامه نویس به معمار نرم افزار" (http://rubako.ir/?utm_source=barnamenevis&utm_medium=forum&utm_campaign=studio%2Bpromo) داره که توصیه میکنم حتما سیلابسشو اینجا ببینید. علاوه بر اون اگه برنامه نویس پلاتفرم جاوا باشید یه استودیوی دیگه هم هست که مشخضا پترن ها (الگوهای) معماری موفق روی Java EE (http://rubako.ir/?utm_source=barnamenevis&utm_medium=forum&utm_campaign=studio%2Bpromo) آموزش داده میشه توش.

موفق باشید
www.rubako.ir

norsmor
سه شنبه 17 مرداد 1391, 04:30 صبح
سلام
کتابی هست که سبک های معماری رو مفصل توضیح داده باشه کامل (لاتین یا فارسی )
ممنون