با عرض سلام و تبریک سال نو
من اطلاعاتی راجع به معماری نرم افزار می خواستم .معماری تک لایه و ....... را می دونم فقط اطلاعاتی راجع به معماری نرم افزار می خوام.
با تشکر
Printable View
با عرض سلام و تبریک سال نو
من اطلاعاتی راجع به معماری نرم افزار می خواستم .معماری تک لایه و ....... را می دونم فقط اطلاعاتی راجع به معماری نرم افزار می خوام.
با تشکر
با سلام
دوست عزیز اگر منظور شما از معماری نرم افزار بصورت کلان است باید گفت که معماری یک لایه ، چند لایه و ... بخشی از معماری نرم افزار می باشد.معماری نرم افزار از بخش های متعددی تشکیل شده و بسته به نوع متدلوژی شما دارای جزئیات مختلفی می باشد. یک معماری نرم افزار نشان می دهد که نرم افزار از چه ساختاری تشکیل شده ، چگونه در محیط استقرار می یابد ، در دید کلان چه وظایفی را انجام می دهد و چه توقعی از سیستم را برآورده می کند.
اگر به جزئیات بیشتری نیاز دارید بپرسید :)
مقدمه
از بدو مطرح شدن نرم افزار تاکنون ، معماری های متفاوتی بمنطور طراحی و پیاده سازی ارائه شده است . معماری های فوق از یکطرف برخاسته از امکانات و ماهیت سخت افزار ها در زمان خود و از طرف دیگر نمایانگر نوع و نگرش انتظارات طرح شده توسط کاربران است . بخاطر داشته باشیم که نرم افزار دارای ماهیتی پویا بوده و در هر زمان می بایست خود را با خیل عظیم نیازها و انتظارات جدید کاربران تطبیق نماید. چراکه نرم افزار عصاره خواسته های انسانی بمنظور بالفعل شدن بر روی بستر سخت افزار در گذر زمان است . بدیهی است از گذشته تاکنون، هم طیف خواسته های انسانی تغییر کرده و خواهد کرد و هم سخت افزارها دچار تغییر و تحول گسترده ای بوده و خواهند بود. در این راستا لازم است نرم افزار نیز با رعایت کامل اصل انعطاف پذیزی ، پذیرای تمامی تحولات از گذشته تاکنون بوده و بتواند در هر زمان رسالت خود را بخوبی انجام دهد. بر همین اساس از گذشته تاکنون معماری های متفاوتی بمنظور طراحی و پیاده سازی نرم افزار ارائه شده است . هر معماری دارای شاخص ها و ویژگی های منحصر بفرد خود بوده و نرم افزارهائی که با اتکاء بر هر یک از معماری های فوق پیاده سازی می گردنند ، خصایص خود را از معماری بکارگرفته شده به ارث خواهند برد. در این بخش به رفتارشناسی هر یک از معمارهای ذیل پرداخته تا از این طریق زمینه های لازم بمنظور شناخت معماری بکارگرفته شده در برنامه های تحت وب فراهم گردد.معماری MainFrame
- معماری MainFrame
- معماری File Server
- معماری سرویس گیرنده / سرویس دهنده
- معماری Two-Tier
- معماری Three-Tier
ویژگی :
- معماری فوق در دهه های ۱٩٦۰ الی ۱٩۷۰ مورد توجه و استفاده جدی قرار داشت .
- کامپیوتر اصلی ( Host) مسئولیت انجام تمامی پردازش ها را برعهده دارد.
- کاربران با استفاده از ترمینال ها ، قادر به ایجاد ارتباط با سیستم اصلی (host) می باشند.
- ترمینال ها هوشمند نبوده و صرفا" به یک صفحه کلید و نمایشگر محدود می باشند.
- فشردن کلیدهای صفحه کلید ، تنها چیزی است که ارتباط بین کاربران(ترمینال ها ) و سیستم اصلی را معنی خواهد کرد.
- داده ها و منطق برنامه بر روی یک سیستم (Host) یکسان ذخیره می گردنند. .
مزایا :
- امنیت در این نوع معماری بسیار بالا است .
- با توجه به تمرکز داده ها و منطق ، مدیریت متمرکز و اعمال آن آسان خواهد بود.
معایب :
- هزینه تهیه ، اجاره و پشتیبانی این نوع سیستمها بسیار بالا است .
- برنامه ( منطق ) بهمراه داده های مربوطه در یک محل مستقر و از یک محیط پردازش یکسان استفاده می کنند.
- اغلب برنامه های نوشته شده بر اساس معماری فوق محیط های رابط کاربر گرافیکی را حمایت نمی نمایند
معماری File server
ویژگی :
- چرخش ۱٨۰ درجه ای نسبت به معماری MainFrame.
- از سرویس دهنده یا سرویس دهند گان متعدد، بصورت متمرکز استفاده می گردد.
- منابع متفاوتی نظیر چاپگر و یا فضای ذخیره سازی ( هارد ) به اشتراک گذاشته می شوند.
- سرویس دهنده فایل های مورد نیازو ذخیره شده توسط منابع اشتراکی را برای کاربران ارسال خواهد کرد.
- کار درخواست شده توسط کاربر ( منطق و داده ) بر روی سیستم کاربر اجراء خواهد شد.
- منطق برنامه برروی سیستم کاربر ( سرویس گیرنده ) اجراء خواهد کردید.
- داده ها بر روی سرویس گیرنده مستقر خواهند شد.
مزایا :
- برای استفاده از معماری فوق نیاز به صرف هزینه های بالا نخواهد بود .
- از لحاظ بکارگیری منابع دارای انعطاف پذیری مناسبی است .
معایب :
- تمامی منطق برنامه بر روی سرویس گیرنده اجراء خواهد شد .
- وجود محدودیت های خاص نظیر میزان حافظه و یا نوع پردازشگر سرویس گیرندگان، بکارگیری برنامه را با مشکل مواجه می سازد.
- بهبود عملکرد برنامه و یا اعمال اصلاحات مورد نظر همواره یکی از چالش های جدی است .
معماری Client Server
ویژگی :
- در معماری فوق از سرویس دهند گان و سرویس گیرند گان با خصایص متفاوت استفاده می شود.
- اصل تقسیم کار دنبال و سرویس دهنده عملیات سنگین با پردازش بالا و سرویس گیرنده عملیات سبک را انجام خواهند داد.
- دو بخش متفاوت یک برنامه ، در جهت انجام عملیات با یکدیگر تشریک مساعی می نمایند.
- سرویس گیرنده با ارسال درخواست و سرویس دهنده با پاسخ به درخواست جلوه ای از همیاری در پردازش عملیات را بنمایش می گذارند.
- پلات فورم و سیستم های عامل سرویس دهنده و سرویس گیرنده می تواند متفاوت باشد.
- عملیاتی را که یک برنامه انجام می دهد بین سرویس دهنده و سرویس گیرنده تقسیم می گردد.
مزایا :
- بهره گیری مناسب از پتانسیل های سخت افزاری موجود با توجه به اصل تقسیم عملیات ها
- بهینه سازی استفاده و بکارگیری منابع اشتراکی .
- بهینه سازی توانائی کاربران از بعد انجام فعالیت های متفاوت
معایب :
- عدم وجود امکانات لازم برای کپسوله نمودن سیاست های راهبردی نرم افزار
- کاهش کارائی برنامه همزمان با افزایش تعداد کاربران همزمان
- بهبود عملکرد برنامه و یا اعمال اصلاحات مورد نظر همواره یکی از چالش های جدی است .
تاکنون مدل های متفاوتی از معماری فوق پیاده سازی شده است .
۱ - پردازش های مبتنی بر میزبان . مدل فوق بمنزله یک مدل سرویس دهنده / سرویس گیرنده تلقی نشده و مشابه مدل MainFarme است .
۲ - پردازش های مبتنی بر سرویس دهنده . در این مدل سرویس دهنده تمامی پردازش های مربوطه را انجام و سرویس گیرنده مسئولیت ایجاد بخش رابط کاربر را برعهده خواهد د اشت.
۳ - پردازش های مبتنی بر سرویس گیرنده . تمامی عملیات بر روی سرویس گیرنده انجام خواهد شد. عملیات مربوط به بررسی صحت داده ها و سایر عملیات مربوط به منطق بانک های اطلاعاتی بر روی سرویس دهنده انجام خواهد شد.
٤ - پردازش های مبتنی بر همیاری .در این مدل سرویس دهنده و سرویس گیرنده بمنظور انجام یک فعالیت با یکدیگر تشریک مساعی خواهند کرد.
معماری Client Server : Two Tier
ویژگی :
- مشابه مدل Client Server در بخش قبل می باشد.
- در این مدل از یک سرویس دهنده و یک سرویس گیرنده در شبکه استفاده می گردد.
- مدل فوق از سه بخش که در دو لایه سرویس دهنده و سرویس گیرنده قرار خواهند گرفت، تشکیل می گردد.
- بخش های رابط کاربر ، مدیریت پردازش ها و مدیریت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
- منطق برنامه بین دو محل فیزیکی توزیع می گردد.
مزایا :
- مناسب ترین روش برای پردازش های توزیع شده در یک شبکه با حداکثر یکصد کاربر
- سهولت در امر پیاده سازی
- نسبت دهی مستقیم رابط کاربر با منابع تامین داده ها
معایب :
- عدم وجود امکاناتی برای کپسوله نمودن سیاست های راهبردی نرم افزار
- کاهش کارائی برنامه همزمان با افزایش تعداد کاربران همزمان ( بیش از یکصد )
-عدم وچود انعطاف لازم از بعد انتقال یک برنامه از سرویس دهنده ای به سرویس دهنده دیگر بدون انجام تغییرات اساسی
معماری Client Server : Multi-Tier
ویژگی :
- مدل فوق در سال 1990 عرضه شده است .
- در این مدل از یک Tier میانی دیگر بین سرویس گیرنده ( رابط کاربر) و سرویس دهنده بانک اطلاعاتی استفاده می شود.
- لایه میانی شامل مجموعه ای از ابزارها برای دستیابی به منابع سیستم ، صرفنظر از نوع پلات فورم است .
- لایه میانی مسئولیت مدیریت پردازش ها را برعهده خواهد گرفت .
- لایه میانی مسئولیت تجزیه و یا ترکیب نتایج حاصله از منابع داده ئی نظیر بانک های اطلاعاتی را برعهده دارد.
- بخش های رابط کاربر ، مدیریت پردازش ها و مدیریت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
- لایه میانی خود می تواند به دو و یا بیش از دو بخش با عملکردهای متمایز تقسیم گردد (Multi-Tier)
- مدل فوق گزینه ای مناسب برای پیاده سازی نرم افزار بر روی اینترنت است .
مزایا :
- افزایش کارآئی ، انعطاف پذیری ، قابلیت استفاده مجدد و توان پشتیبانی
- ارتقاء کارآئی همزمان با افزایش تعداد کاربران
- مخفی نمودن پیچیدگی ها ی موجود با توجه به ماهیت پردازش های توزیع شده از دید کاربران
- ارائه امکانات لازم به برنامه نویسان بمنظور طراحی و پیاده سازی نرم افزار ها با یک رویکرد مشابه
- ارائه امکانات لازم به برنامه نویسان بمنظور تبعیت از روش های یکسان برای دستیابی به داده ها
http://www.srco.ir/tutorial/images/3tier_3.gif
منبع : این مطالب هم از سایت شرکت داده پردازی و هم از سایت شرکت سخاروش اقتباس شده است.
اینترنت بستری مناسب برای پیاده سازی برنامه های توزیع شده است . وجود زیر ساخت های لازم در این زمینه شرایط مطلوبی را برای پیاده سازی برنامه های توزیع شده ، فراهم آورده است .
دستیابی به یک وب سایت و یا ارسال و دریافت پیام های الکترونیکی نمونه هائی از برنامه های توزیع شده بر روی بستر اینترنت می باشند.
برنامه های پست الکترونیکی نمونه ای مناسب در این زمینه می باشند.
برنامه های Chat نمونه دیگری از برنامه های توزیع شده بر روی بستر اینترنت می باشند.
می شه در این مورد بیشتر توضیح بدین ؟!!!!!!!!!!!!!!!!:متفکر:نقل قول:
نوشته شده توسط whitehat
رضا ارزانی :
اگر در مورد معماری خاصی سوال داشتی بپرس؟
ممنون، خوب بود!
از دید مهندسی نرم افزار ، معماری سیستم شامل کلیه موارد لازم برای توسعه نرم افزار می باشد، نوع متدلوژی میزان پرداختن به جزئیات را مشخص می کند. (مثلا جزئیاتی که در روش های agile بکار میرود بسیار کمتر از متدلوژی ها سنگین وزن می باشد)
فرض کنید شما می خواهید بر اساس متدلوژی RUP می خواهید یک سند معماری نرم افزار را برای نرم افزار خود تهیه کنید. شما باید در این سند حتما دیدگاه های 4+1 را حتما پیاده سازی نمائید و سپس بر اساس Customizationی که انجام داده اید نیاز های غیر وظیفه ای را در این سند بگنجانید ، در صورتی که در متدلوژی دیگری شما این قسمت را ممکن است حذف می کنید یا دیدگاهها را خیلی خلاصه تر ترسیم می نمائید. یا در متدلوژی ssadm شما اصلا نیازی ندارید که وارد جزئیات پیاده سازی (بصورتی که معین کنید هر مولفه بر روی چه سخت افزاری نصب می شود) شوید. بر اساس متدلوژی های مختلف جزئیات مختلفی را برای تهیه معماری نرم افزار خواهید داشت.
می خواستم از دوستان بخوام اگر کتاب مناسب و معتبری در زمینه معماری نرم افزار می شناسند. معرفی کنند. (فارسی یا لاتین بودنش مهم نیست).
من کتاب های زیادی تو اینترنت با عنوان Software Architect پیدا کردم ولی هیچ کدوم مفاهیمی چون معماری N-Tier یا کلاینت سرور یا .. رو شرح نداده بودند !!!
اگر محبت کنید و نام چند تن از نامداران این عرصه رو هم نام ببرید ممنون می شم.
برای این کار بهتره به مقالات مربوط به مهندسی نرم افزار که مفهوم خاصی را توضیح می دهند مراجعه کنید ، با این کار در زمان صرفه جویی می کنید. بطور کلی معماری نرم افزار چیزی است که یک مهندس نرم افزار باید آنرا تهیه کند ، در سطح کلان معماری های بسیار زیادی بصورت Template در اینترنت موجود است (مانند مثال شما) اما هر پروژه ای معماری خاص خود را می طلبد و بهتر است برای یادگیری دقیق یک پروژه ساده برای خود تعریف کنید و بر اساس آن معماری را پیاده سازی کنید. یکی از بهترین مراجع ، مستندات شرکت Rational می باشد. من 2 مقاله ضمیمه می کنم که یکی مربوط به معماری N-Tire برای طراحی پروژه های Data Intensive و دیگری یک سند معماری است که امید وارم مفید باشه
متن زیر از پایانامه ی کارشناسی آقای یاسر صفری نیا اقتباس شده است :
تعاریف معماری نرم افزار:
معماری نرم افزار ساختار بنیادی و اسکلت سیستمی است، که قرار است ایجاد شود. در کل هیچ تعریف استاندارد و همه پذیری برای معماری نرم افزار ارائه داده نشده است، اما بیش از یکصد تعریف فنی برای معماری نرم افزار در سایت دانشگاه کارنگی ملون موجود است. برگزیده این تعاریف به شرح زیر میباشند:
تعریف بوچ، رامبو و ژاکوبسن:
معماری نرم افزار مجموعه ای از تصمیمات اساسی در مورد سازماندهی یک سیستم نرم‌افزاری، گزینش عناصر ساختاری و چگونگی ارتباط میان آنها می باشد.
تعریف گارلن و پری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 بیشتر توضیح داده خواهند شد.
لطفا در مورد رویکرد مبتنی بر ساختار بیشتر توضیح بدید
با پوزش از تاخیر پیش امده....
سیستم‌های امروزی به اندازه‌ای بزرگ هستند که درک کل آنها کار ساده‌ای نیست، بنابراین گام به گام ساختارهای سیستم را مورد کندوکاو قرار می‌دهیم. در این راستا باید ساختار یا ساختارهای سیستم مورد بررسی، کاملاً مشخص شوند و منظرها نیز به روشنی تعریف گردند.
منظرها، مجموعه‌ای از مولفه های مرتبط را نمایش می‌دهند و چگونگی ارتباط (اعم از خواندن و نوشتن) موفه ها را با ذینفعان سیستم مشخص می‌کنند. در واقع منظرها شامل المان‌ها و روابط بین آنها میباشند. ساختارها نیز مجموعه‌ای از خود المان‌ها، اعم از سخت‌افزاری ونرم‌افزاری، میباشند.
ساختار معماری می‌تواند بنا به طبیعت مولفه هایش، به سه دسته تقسیم گردند:
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: این منظر، نحوه نگاشت المان ها به فرایند ها و نُودهای ارتباطی را نشان می دهد، که منظر مترادف آن در معماری ،منظر تخصیص است.
آقایون من یه پیشنهاد دارم.
این مطالب در مورد مدلهای معماری نرم افزار رو بصورت مقاله های PDF در بیارین اگه زحمت نیست و اونجوری گسترش شون بدیم ؟!
گزارش سمينار كارشناسي ارشد
سبكهاي معماري نرم افزار
توسط حسين هاشميان
شامل:
1- مفهوم و تعريف معماري نرم افزار
2- مشخصه هاي كيفيتي در معماري نرم افزار
3- سبكهاي معماري نرم افزار
4- قابليت اطمينان در سبكهاي چندريختي
5- نتيجه گيري
(98 صفحه) Download پسورد: 100110
مي شه لطفا راهنمايي كنيد كه چه طور مي شه مطلب فوق رو دانلود كرد؟متاسفانه نمي تونم دانلود كنم.نقل قول:
نوشته شده توسط xxxxx_xxxxx
متاسفانه چند وقتي هست Persindrive به مشكل برخوردهنقل قول:
نوشته شده توسط mitil_mitil
از ضميمه اين پست دانلود كنيد
دوستان سلام،
برای آموزش معماری نرم افزار، استودیوهای روباکو یک دوره ویژه به نام "ارتقا از برنامه نویس به معمار نرم افزار" داره که توصیه میکنم حتما سیلابسشو اینجا ببینید. علاوه بر اون اگه برنامه نویس پلاتفرم جاوا باشید یه استودیوی دیگه هم هست که مشخضا پترن ها (الگوهای) معماری موفق روی Java EE آموزش داده میشه توش.
موفق باشید
www.rubako.ir
سلام
کتابی هست که سبک های معماری رو مفصل توضیح داده باشه کامل (لاتین یا فارسی )
ممنون