تحقیق الگوها و سبک های متداول معماری نرم افزار

خلاصه
با گسترش روزافزون دامنه تقاضاهای کاربران کامپیوتر وبه دنبال آن اندازه سیستم های نرم افزاری ،دیگر روش ها و سبک های کلاسیک تولید نرم افزار،پاسخ گوی این نیازمندیها نبوده اند.در دنیای امروز،طراحی یک نرم افزار موفق تنها انتخاب و یا ایجاد ساختمان داده های مناسب و الگوریتم های کارآمدنیست.حجم نرم افزارهای تجاری سالهای اخیر،مهندسان نرم افزار را بر آن داشته که برای غلبه بر پیچیدگی های حاصل از این جحم بالا،به دنبال تکنیک های استفاده مجدد از نرم افزار و روش های component-based بروند.علی رغم تمام نکات مثبتی که در استفاده از این روش ها وجود دارد،باید به این نکته هم اشاره کرد که مشکلات و مسائل جدیدی نیز به همراه این دید نوین،پا به دنیای نرم افزار گذاشته اند:در این سیستم نرم افزاری بزرگ که متشکل از اجزای گوناگون خواهد بود،نحوه سازمان دهی و ارتباطات این اجزا با یکدیگر چگونه باشد تا نیازمندی های تعیین شده برای نرم افزار برآورده شوند؟پاسخ به این پرسش ،وظیفه اصلی معماران نرم افزار است.
با توجه به اهمیتی که شاخه نسبتاً نوظهور معماری نرم افزار روز دنیا پیدا کرده است،در این مقاله سعی خواهیم کرد روش ها وسبک های موجود و متداول معماری نرم افزار را بررسی کرده،مزایا و معایب هر کدام را بیان کنیم و به این مسئله بپردازیم که هر سبک،مناسب کدام کلاس از نرم افزارهایی است که امروزه تولید وروانه بازار می شوند.

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

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

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

معماری سازمان4
سازمانهای امروزی موجودات پیچیده ای هستند که توصیف فنی جنبه های مختلف سیستمهای اطلاعاتی آنها نیازمند بکارگیری معماری خاصی است که معماری سازمانی خوانده می شود.اگر بخواهیم تعریف معماری سازمان را از12،610IEEE STDداشته باشیم باید گفت [20]:معماری سازمانی عبارتست از تنظیم قوانین و مقرراتی برای تعریف یک ساختار واحد و منسجم ،که شامل اجزاءفوق با یکدیگر می باشد.
بسته به اینکه معماری ،در چه حوزه یا موضوعی از سازمان انجام شود،می توانیم معماری های مختلفی داشته باشیم،لذا انواع معماری سازمانی که به آنها لایه های معماری نیز اطلاق می شوند عبارتند از:
– معماری حرفه: بالاترین سطح معماری سازمانی به حساب می آید و هدف این معماری ،شناسایی وتوصیف حوزه های ماموریتی،خطوط ماموریتی و وظایف سازمانی است.
– معماری داده ها : دومین سطح از معماری سازمانی محسوب می شود که به منظور توصیف سر فصلهای اطلاعاتی،مدلهای منطقی داده ها و مدلهای فیزیکی داده ها بکار می رود.
– معماری سیستمهای اطلاعاتی: سومین سطح از معماری محسوب شده و به منظور توصیف فرآیندهای کاری،سیستمهای اطلاعاتی،برنامه های کاربردی و روشهای تعامل سیستمها به کار می رود.
– معماری فناوری: آخرین سطح از معماری محسوب شده و شامل مدلهای مرجع فنی و استانداردهای فنی است که باید در سطح سازمان رعایت شوند.
ارتباط میان این چهار نوع معماری به صورت هرمی است که معماری حرفه در نوک هرم،پایه ایست برای معماری داده ها و معماری داده ها پایه ای برای معماری سیستمهای اطلاعاتی،و معماری سیستمهای اطلاعاتی پایه ای برای معماری فناوری می باشند.

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

معماری خط تولید6
اکثر شرکتهای تولید کننده نرم افزار،نرم افزارهای زیادی توسعه داده اند که برخی مشخصه های آنها مانند موارد زیر با هم یکسان بوده است:
– معماری یکسانی دارند.
– روی یک سکو7 با مشخصات یکسانی اجرا می شوند.
– قسمت های زیادی از حرفه8 آنها با هم مشابه می باشد.
– مدیریت و سازماندهی اجزاء نرم افزاری آنها یکسان می باشد.
و…
قسمتهای مشابه در این دسته از نرم افزار ها را دارائیهای مرکزی می گویند.9 این دارائیهای مرکزی خاصیت قابلیت استفاده مجدد دارند و می توانند موارد زیر باشند: Component, Framework,Library, Tools, A development or Execution platform
برای هر یک از این دارائیهای مرکزی یک معماری در نظر گرفته می شود،بطوری که تمام محصولات در این دسته بتوانند از آن معماری استفاده کنند.به این معماری،معماری خط تولید گفته می شود.

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

مولفه: مولفه ها به عنوان بلوکهای اولیه و موجودیتهایی محاسباتی در ساخت سیستم شرکت کرده و از طریق محاسبات داخلی و ارتباطات خارجی خود کارها را انجام می دهند.یک مولفه از طریق یک یا بیشتر درگاه10 با محیط ارتباط برقرار می کند.این درگاه می تواند یک واسط کاربر،یک متغیر مشترک،یک نام رویه که از یک مولفه دیگر صدا زده شده است،یک مجموعه از رویدادها که می توانند از یک مولفه ایجاد گردند و مکانیزمهای دیگر باشد.
خصوصیات یک مولفه،اطلاعاتی را برای تحلیل و پیاده سازی نرم افزار مشخص می کند.
اتصال دهنده: اتصال دهنده ها تعاملات بین مولفه ها را تعریف کرده و قواعد حاکم بر آنها را توصیف می نمایند.یک اتصال دهنده درگاه های دو یا چند مولفه را بهم متصل می نماید.خصوصیات مختلفی نیز به آنها نسبت داده می شوند،به عنوان مثال سرعت،ظرفیت و میزان عکس العمل اتصال دهنده از جمله این ویژگیها هستند.
واسط: زمانی که اتصال دهنده بین دو مولفه ارتباط بر قرار می کند،مولفه یک واسط تعریف می نماید و هر مولفه می تواند چند واسط داشته باشد.یک واسط تنها به یک مولفه مربوط می شود و هر واسط یک مولفه،می تواند به چندین واسط در مولفه های دیگر وصل شود.به عنوان مثال در معماری Bus-Oriented واسط هر مولفه به اتصال دهنده Bus متصل است و لذا به چندین واسط در مولفه های دیگر وصل می شود.صفات همچنین می تواننددر مورد واسط ها بیانگر برخی ویژگیهای آنها باشند،مانند جهت ارتباط،ظرفیت بافر و …
پیکربندی:پیکربندی که گاهی تحت عنوان توپولوژی نیز از آن یاد می شود گراف همبندی است که از مولفه ها و اتصال دهنده ها تشکیل شده است و ساختار معماری را توصیف می نماید.

مراحل فرآیند معماری نرم افزار
مراحل آفرینش یک معماری نرم افزار که با استفاده از آن معماری بتوان به طراحی تحقق بخشید و پیاده سازی و مدیریت ساخت سیستم نهایی را ایجاد کرد،شامل فعالیتهایی به شرح زیر است:
الف: ایجاد یک مورد کاری12 برای سیستم
سوالاتی پیرامون میزان هزینه برای تولید محصول،قیمت نهایی،میزان سود و محدودیتهایی محیطی سیستم و…سوالاتی هستند که به معماری سیستم مرتبط اند و به تنهایی توسط معمار قابل تصمیم گیری نیستند هر چند که،چنانچه معمار در رایزنی و مشورت برای پاسخ به این سوالات و ایجاد مورد کاری دخالت نکند،ممکن است رسیدن به اهداف کاری میسر نباشد.
ب: فهم نیازمندیها
راههای زیادی برای شناخت و استخراج نیازمندیها،از سهامداران سیستم وجود دارد.به عنوان مثال در تحلیل شیءگرا از سناریوها یا موارد کاربری برای به تصویرکشیدن نیازمندیها استفاده می شود. یک تکنیک پایه برای فهم نیازمندیهای یک سیستم در حال تولید،شناخت محدوده تغییرات و تفاوتهای آن سیستم در مقایسه با سیستم های مشابه قدیمی تر است.این کار بدین سبب بسیار جاافتاده که امروزه سیستمی را نمی توان پیدا کرد که خیلی از سیستم های مشابه دور باشد و شناخت نیازمندیهای یک سیستم با فهم خصوصیات و نیازمندیهای سیستم های قبلی مشابه،رابطه مستقیم دارد.محصول خروجی مرحله آنالیز،که دامنه مساله را مدلسازی می کند،تفاوتهای بین سیستم های اجرایی مشابه را معرفی می کند.
گذشته از فهم نیازمندیها،کیفیت های مطلوب سیستم تحت ساخت،شکل معماری آن را می سازد.حال اینکه چگونه می توان به نیازمندیهای متضاد،میانه روی کرد و به میزان و تعادلی مناسب در معماری رسید احتیاج به تاکتیک هایی دارد که معماران نرم افزار از آنها در جهت رسیدن به این صفات کیفیتی مطلوب استفاده می کنند.
ج- آفرینش یا انتخاب معماری
طبیعی است برای ایجاد یک معماری،متدی معین و مشخص که تمام شرایط و قیود آن از قبل تعیین شده باشند وجود ندارد.بلکه عموماً روشی ارائه می شود که در آن روش طراحی به صورتی انعطاف پذیر تولید شود و در طی تحلیل با توجه به نیازمندیها سیستم مطلوب،شکل محکم تری به خود بگیرد.در ابتدا چند مدل طراحی پیشنهاد می شود ولی به تدریج برخی از آنها رد می شوند.انتخاب منطقی بین این طراحی های کاندید،یکی از کارهای مهم و بزرگ معمار نرم افزار است.
د-نمایش و اعلام معماری
برای اینکه معماری بتواند به عنوان ستون فقرات طراحی یک پروژه نقش خود را به بهترین نحو ایفا کند باید به صورتی واضح و شفاف و نامبهم بین همه سهامداران معرفی و ارائه شود. مدل نمایشی باید حاوی اطلاعات مفید،غیر مبهم و قابل خواندن توسط افراد در زمینه های مختلف باشد که معماری ارائه شونده،نیازمندیهای کیفیتی و رفتاری مطلوب را بر آورده می سازد.معماری را می توان با استفاده از زبان های رسمی بنام زبان توصیف معماری13 نمایش داد.
ه: تحلیل یا ارزیابی معماری
ارزیابی معماری در مورد خصوصیاتی که ارائه می دهد بسیار ضروری است،زیرا می خواهیم مطمئن شویم که سیستمی که براساس آن معماری بنا می شود نیازهای سهامداران خود را برآورده می سازد.به عبارت دیگر اگر کمی گسترده تر به موضوع نگاه کنیم،باید گفت تکنیکهایی در مورد تحلیل و ارزیابی مشخصه های کیفیتی یک معماری لازم خواهند بود تا بتوانیم ازمیان مدلهای طراحی موجود برای یک سیستم،مدل مطلوب را انتخاب نمائیم.
این تکنیکها را می توان به صورت زیرخلاصه کرد
1- تکنیکهای پرسشی که خود شامل موارد زیر هستند:
– تکنیکهای مبتنی بر سناریو
– تکنیکهای مبتنی بر پرسشنامه
– تکنیکهای مبتنی بر لیستهای مرجع
2- تکنیکهای اندازه گیری که شامل موارد زیر هستند:
– تکنیکهای مبتنی بر متریکها
– تکنیکهای مبتنی بر شبیه سازی
و: پیاده سازی سیستم بر پایه معماری
در این مرحله باید مطمئن باشیم که توسعه دهندگان سیستم،به ساختارها و پروتکل های ارتباطی بر اساس معماری،متعهد هستند.اولین قدم در این راه داشتن یک معماری واضح وصریح و قابل تبادل است.بهتر محیطی دلشته باشیم که به توسعه دهندگان سیستم در شناخت و بکارگیری معماری کمک و راهنمایی شود.
ز- حصول اطمینان از پیاده سازی درست معماری
نهایتاًوقتی معماری ساخته و به کار گرفته شد،به فاز نگهداری منتقل می شود.باید در این فاز تضمین شود که معماری هنوز به شکل نمایش داده شده خود متعهد است.
1 معرفی سبک های معماری نرم افزار
همانگونه که اشاره شد،در دهه اخیر،نیاز به روش ها و راه حل های نوینی برای طراحی نرم افزار های بزرگ و پیچیده احساس شده است و این امر به دلیل آنست که روشهای قدیمی و کلاسیک جوابگوی نیازهای روز بازار نرم افزار نبوده اند.در طراحی نرم-افزار به شیوه کلاسیک ،سعی می شد دید بالا به پایین 1به نرم افزار به طور مستقیم به اجرا در آید.به این معنی که ابتدا نرم افزار /سیستم در بستر محیط هدف2 (محیطی که نهایتاًنرم افزار می بایست در آن نصب شده و مورد استفاده قرار بگیرد)مورد بررسی قرار گرفته و ارتباطش با اجزای دنیا خارج مشخص می شد(خروجی این مرحله در روشهای ساخت یافته معمولاًنموداری به نام نمودار متن است)،سپس نرم افزار به اجزای کوچکتری تقسیم می شد و هر جزءنیز به طور جداگانه مورد بررسی قرار می گرفت(Decomposition) علی رغم آنکه دید بالا به پایین به تولید و طراحی نرم افزار همچنان مورد استفاده طراحان این سیستم ها قرار می گیرد،نحوه به کارگیری آن،دستخوش تغییرات اساسی شده است.
تولید نرم افزار که کمک روشهای کلاسیک که نمونه ای کلی از آن ذکر شد،در مورد نرم افزارهای بزرگ امروزی بسیار دیر به جواب می رسد.(اگر اساساً قادر باشد به جوابی برسد).منظور از یافتن جواب،پیدا کردن شیوه ای برای طراحی نرم افزار تعیین شده،با پارامترهای کیفیت مورد توافق مشتریان و شرکت یا سازمان تولید کننده است.به همین جهت و در جستجوی یک ایده نوین طراحی که بتواند قابلیت تولید3 بالاتری داشته ،پاسخ گوی نیاز های بازار نرم افزاری،متخصصان این امر حاضر به پرداخت بهای چالش های مطرح در معماری نرم افزار شده و به دنبال روشهای مبتنی بر استفاده از اجزای از پیش ساخته رفتند که این خود ،بحث معماری نرم افزار را پیش مطرح می کند. موارد زیر نمونه هایی از دلایلی هستند که آشنایی با معماری نرم افزار را برای هر طراح نرم افزاری اجتناب ناپذیر و ضروری می سازند:
– آشنایی با مدل های کلی طراحی نرم افزار ،نقش اساسی درک روابط کلی میان اجزای نرم افزار بازی می کند.و طراح را قادر می سازد که سیستم جدید را در غالب مدل بهبود یافته سیستم پیشین ایجاد نماید که این خود می تواند باعث کاهش هزینه های نهایی تولید نرم افزار شود.
– انتخاب مدل مناسب معماری برای یک نرم افزار زمینه ساز موفقیت آن خواهد بود،حال آنکه انتخاب مدل غلط می تواند فاجعه آمیز باشد.بنابراین طراح سیستم می باید انواع مدل ها و سبک های معماری و مشخصات آنها را بخوبی بشناسد تا بر حسب نیازمنیهای نرم افزار در دست تهیه ،معماری مناسب آن را انتخاب نماید.
– شناخت جزئیات هر یک از سبک های معماری،به معمار سیستم در انتخاب طراحی بهتر از میان گزینه های موجود کمک می کند.
در این مقاله سعی خواهیم کرد تعاریف مناسب از الگوها و سبک های معماری نرم افزار ارائه کرده سبکهای رایج را به همراه مشخصات ،مزایا و معایب هر کدام بیان نماییم در قسمت بعدی به تعریف مفاهیم الگو و سبک معماری پرداخته ،تفاوت های آنها را از دید صاحب نظران این رشته بررسی می کنیم و نهایتاًتعریفی نسبتاًجامع از سبک معماری نرم افزار ارائه می نماییم.

1.1 مقایسه الگو4 ها و سبک5 ها
برای آنکه بتوانیم تفاوت مفاهیم الگو و سبک را بیان نماییم،بهتر است ابتدا با تعریف الگو آشنا شویم و سپس به سراغ تفاوتهای آن به سبک برویم.
تعریف1. به طور کلی،را راه حلی برای یک مسئله طراحی ،در حضور مسائل دیگر می دانیم.
در توضیح این تعریف،باید به این نکته اشاره کنیم که در نیای نرم افزار عمدتاًمسائل موجود مستقل از یکدیگر نبوده و نیازمندیهایی که برای سیستم مطرح می شوند معمولاً با یکدیگر همبستگی ها و روابطی دارند.به این معنی که در هنگام طراحی یک نرم افزار،به عنوان مثال نمی توانیم بخشی از کل سیستم را بطور مجزا و منفرد6 و بدون هیچ گونه وابستگی با سایر بخش ها یا نیازمندیها در نظر گرفته طراحی مناسب را برای آن انجام دهیم و سپس آن را به بقیه سیستم اضافه کنیم چرا که حد اقل انتظاری که از سیستمهای واقعی می رود آنست که مشخصه های کیفیتی از پیش تعیین شده (نظیر زمان پاسخ مطلوب کار برآن امنیت سیستم…)در همه قسمتهای سیستم حضور داشته باشند و این امر طراحی قسمتهای گوناگون را به این مشخصه ها وابسته خواهد ساخت در نتیجه ناگزیر هستیم در مورد یک مسئله طراحی وابستگی های آن به سایر مسائل را نیز مد نظر قرار دهیم .با این حال ،مجموعه ای از راه حل ها را که در یک زمینه خاص مطرح می شوند.به تنهایی الگو نمی نامیم .یک راه حل طراحی باید دارای مشخصه هایی باشد تا بتوان آن را الگو دانست:
– همانطور که از نام آن انتظار می رود الگو یک راه حل تکرار شونده است به این معنی که زمانی به این راه حل الگو می گوییم که گونه ای انتزاعی از آن در جندین سیستم مختلف یافت شود .
– الگو،یک راه حل طراحی موفق است.بدیهی است که روشهایی را که در طراحی ما را به بن بست و شکست رسانده اند.مجدداً استفاده نخواهیم کرد،زیرا مایل نیستیم فجایع را تکرار کنیم!
تعریف 2.زبان الگو7 به مجموعه ای از الگوها و قوانینی برای ساخت و ساماندهی الگوهای جدید از روی الگوهای اولیه گفته می شود.
در دنیای یک زبان الگو ،الگوها نقش مجموعه لغات زبان را بازی می کنند،در حالیکه قوانین گرامر زبان را تشکیل می دهند که مشخص می سازند یک الگوی جدید به چه نحوی باید ساخته شود،و همچنین در برخورد با یک الگوی جدید و ناشناخته ما را قادر می سازند که تشخیص دهیم آیا این الگو ،یک الگوی معتبر این زبان هست یا خیر.به کمک این تعریف می توانیم خط مرزی میان الگو و سبک ترسیم کنیم.
سبک های طراحی در حقیقت راه حل نیستند، بلکه چارچوبی برای راه حل ها مشخص می کنند.منظور از این که چارچوب راه حل راتعیین می کننداین است که با انتخاب سبک،فضای راه حل های 8 مسئله تقلیل می یابد.به این ترتیب جستجو در این فضا برای یافتن راه حل مناسب ساده تر می شود و به این ترتیب شانس ما برای پیدا کردن روش بهتر طراحی،افزوده می گردد.با این دید،سبک ها بیشتر به زبانهای الگو شباهت دارند تا به الگوها ذکر این نکته ضروری است که خط مرز مشخص شده میان الگو و سبک بسیار ظریف و گاه شکننده است بدان معنی که در بسیاری از مواقع بر سر آنکه یک روش طراحی را می باید سبک نامید و یا الگو توافق کلی وجود ندارد.اما برای آنکه در گیر این ظرافت ها نشویم ،شباهت ها و تفاوتهای الگو و سبک را به این صورت خلاصه می کنیم:
الگو و سبک در طراحی از آن جهت به هم شباهت دارن که هر دو با این فلسفه به وجود آمده اند که طراح را در انتخاب راه حل مناسب یاری دهند و به همین منظور هر کدام راه کارها و دستورالعمل هایی را تجویز می کنند.اما الگو وسبک عمدتاًدر سطح درشت دانگی با یکدیگر تفاوت دارند الگو معمولاًجزئی و دقیق تر یک راه حل بر ای مسئله طراحی پیشنهاد می کند به عنوان مثال اگر گفته شود در یک سیستم از الگوی طراحیBridge استفاده شده است ،هر چند به صورت کلی این دید را بدست می آوریم که پیاده سازی یک نوع داده ای انتزاعی ،در قالب یک کلاس واسط9 و یک کلاس پیاده ساز 10 انجام شده است.همچنین می دانیم که این کار برای جدا سازی پیاده سازی از واسط صورت گرفته تا در صورت تغییر در پیاده سازی،با تابت نگاه داشتن کلاس واسط برنامه های استفاده کننده از واسط دستخوش تغییر نشده و تغییرات در سیستم منتشر نشوند.به علاوه به این نکته واقف خواهیم بود که این کار هزینه ای در زمان اجرا به ما تحمیل خواهد کرد در نامگذاری فایل ها و کلاسها می باید قوانینی را رعایت کنیم ،و بسیاری موارد دیگر[5].پس همانطور که ملاحظه شد،یک نام ساده می تواند اطلاعات جزئی زیادی،حتی تا سطح پیاده سازی در اختیار ما قرار دهد.اما زمانی که از سبک صحبت می کنیم،همچنان تنها نام سبک اطلاعات مفیدی در مورد مشخصه های سیستم به دست خواهیم آورد اما این بار اططلاعات چندان جزئی نخواهند بود. به عنوان مثال زمانی که می گوییم سبک معماری یک نرم افزار،Pipes-and- Filters است،همانطور که در ادامه اشاره خواهد شد،در مورد اینکه اجزای نرم افزار چه ویژگی هایی خواهند داشت،نحوه ارتباط میان این اجزا چگونه خواهد بود،انتقال کنترل اجرا در سطح نرم افزار به جه شکل صورت خواهد پذیرفت،و مواردی از قبیل دید واضحی بدست می آوریم ،اما هیچ کدام از این موارد به دقت و ریز دانگی مواردی که در مورد الکو ذکر شد،نیستند.
حال که توانستیم تا حدی مشخص کنیم چه مفاهیمی در اصل سبک نیستند وقت آن است که به این سوال پاسخ دهیم که چه مفاهیمی سبک هستند؟دربخش بعدی تعاریف سبک معماری نرم افزار را از نگاه صاحب نظران این رشته به همراه یک جمع بندی در انتها خواهیم دید.

1.2 تعریف سبک های معماری نرم افزار
شاو و گارلان، دو تن از صاحب نظران برجسته زمینه معماری نرم افزار،تعریف سبک معماری را اینگونه بیان می کنند:
سبک معماری نرم افزار،مجموعه واژگانی متشکل از اجزای11 نرم افزار و نوع اتصالات میان این اجزا را به همراه مجموعه قوانینی برای ترکیب اجزا و اتصالات با یکدیگر تعریف می کند[3] . با دقت در این تعریف می توان به شباهت سبک معماری نرم افزار از دید شاو و گارلان با زبانهای الگو پی برد.اگر مبنا را تعریف شاو و گارلان قرار دهیم خواهیم دید که بسیاری از نرم افزارها به ویژه نرم افزارهای تجاری،همگن نبوده و چندین سبک مجزا در طراحی آنها به کار رفته است که این خود مسائل جدیدی را مطرح می کند استفاده از سبکهای مختلف در بخش های مختلف یک سیستم تنها در صورتی مجاز است که سازگاری میان سبکها حفظ شود در این مقاله کوتاه نمی تولن به طور دقیق به بحث سازگاری سبکها پرداخت،با این حال سعی خواهیم کرد در معرفی سبکها متداول معماری با بیان شباهت ها و/یا تفاوت های آنها به سازگاری هم اشاره ای داشته باشیم.
در یک تعریف دیگر از سبک های معماری،جیکوبسن این چنین بیان می کند:سبک معماری یک سیستم ،نمایش زبان مدل سازی است که در طی فرآیند مدل کردن سیستم مورد استفاده قرار گرفته است.[2]در واقع جیکوبسن معماری نرم افزار و سبک معماری را با کل فرآیند مدل سازی سیستم معادل می داند و یک خاستار لایه ای هم برای آن ترسیم می کند(شکل1).
در این ساختار،معماری نرم افزار و سبکهای آن به عنوان پایه اصلی فلسفه سیستم مطر ح هستند.همانگونه که در معماری یک ساختمان،معماری سنگ بنایی برای همه تکنیک ها و روشهای آتی است،در نرم افزار هم به عقیده جیکوبسن،معماری چشم اندازی به ماهیت اصلی و ذات سیستم در حال توسعه ارائه می دهد.بر روی این لایه روشها قرار دارند که رویه های جزئی تری هستند که وظیفه دارند معماری نرم افزار را پیاده سازی نمایند.در لایه بعدی،پروسه یا فرآیند قرار دارند که دو عنصر زمان و افراد را به مجموعه روشها اضافه می کند تا کار ساخت سیستم،به صورت پروژه ای قابل برنامه ریزی و پیگیری در طول زمان در آید.در نهایت و بر فراز همه این لایه ها،ابزار قرار دارند که معماری،روشها،و فرآیند ساخت را یاری می رسانند.
نهایتاً،ریچارد هوبرت سبکهای معماری نرم افزار را به عنوان بخشی از معماری در تعریف خود از معماری نرم افزار می آورد:
معماری نرم افزار از 4 قسمت اصلی تشکیل شده است:1.متامدل معماری2.چرخه حیات توسعه سیتم3. ابزارها4. Formal Technology Projection .در این تعریف متامدل معماری،تقریباًمعادل سبک معماری نرم افزار در تعریف جیکوبسن است و وظیفه آن تعیین اصول و خط مشی اصلی ساخت سیستم نرم افزاری است.چرخه حیات توسعه سیستم مشخص می کند که این خط مشی در عمل به چه طریقی به اجرا در آید و ابزارها هم کمک می کنند که هر کدام از مراحل دیگر انتظاراتی که از آنها می رود را بر آورده سازند.مورد آخر را می توان به عنوان گسترشی از ابزارها به حساب آورد.به بیان کلی Formal Technology Projection مجموعه روشهایی است که در طی آن،یک مدل نظیر مدلهای تهیه شده با UML به یک تکنولوژی،متل دستورات ماشین و یا دستورات یک زبان برنامه نویسی نظیر زبان C نگاشته می شوند.این روشها برای پشتیبانی از معماری های مدل-گرا12 بوجود آمده اند و این امکان را فراهم می سازند که همانگونه که یک زبان سطح بالا به مجموعه ای از دستورات زبان سطح ماشین ترجمه می شود،یک مدل سطح بالای طراحی به مجموعه ای از دستورات زبان سطح ماشین ترجمه می شود،یک مدل سطح بالای طراحی به مجموعه ای از میان افزار 13 ها کامپایل شود.علاوه بر اینکه بسیاری از فعالیت ها در زمینه های فرمال از دید علوم کامپیوتر و تئوری جذابیتهای زیادی دارند،روشهای خودکار تولید نرم افزار در شاخه مهندسی نیز(بر اثر پیچیدگی های روز افزون و فراوان نرم افزارهای مورد تقاضای بازار)روز به روز اهمیت بیشتری می یابند و توجه بیشتری را به خود جلب می کنند.
تعریف 3. یک سبک معماری نرم افزار مجموعه ای است متشکل از :
– اجزا: عناصر اولیه هر نرم افزاری را تشکیل می دهند،نظیر پایگاه های داده،عناصر محاسباتی،و…
– اتصالات: توپولوژی و نحوه ساماندهی و ارتباط اجزا با یکدیگر را نشان می دهند.
– قوانین: مجموعه ای از محدودیتها و مقررات که نحوه ترکیب اجزا،محدودیت های اعمال شده روی اتصالات،و…را مشخص می کنند.
– مکانیزم تعامل: روشی که نشان می دهد اجزای نرم افزار از طریق توپولوژی تعیین شده چگونه با یکدیگر همکاری داشته و کنترل اجرا چگونه میان آنها منتقل می شود.به عنوان مثال فرآخوانی ها یک نمونه از این چنین مکانیزمی هستند.
برخی از منابع در رابطه با مورد آخر،مفهومی را با عنوان مدل فعال سازی 14 مطرح می کنند که معادل مکانیزم تعامل است.منظور از مدل فعال سازی اینست که:
– اولاًاجزا به چه نحو و در چه زمان هایی برای پردازش اطلاعات فعال می شوند.به زمان هایی که در طی آنها یک آلمان نرم افزاری فعال است ،زمان فعالیت می گوییم.
– اطلاعات به چه ترتیبی میان اجزا جابجا می شود.
به طور خلاصه مدل فعال سازی طریقه اجرای منطق اجزای مختلف نرم افزار،شیوه تبادل اطلاعات و همکاری میان آنها،و جریان کنترل میان این اجزا را مشخص می کند.
در پایان این بخش لازم است متذکر شویم که در طبقه بندی سبک های مختلف معماری که در ادامه معرفی خواهیم کرد همپوشانی و اشتراک وجود دارد.با این حال این طبقه بندی به ما کمک می کند که اطلاعات فراوانی را در قالب یک نام خلاصه کنیم.همانطور که در مورد الگوهای طراحی اشاره کردیم که از نام الگو می توان دید کلی از آنچه در دست پیاده سازی است پیدا کرد،در مورد سبک های معماری هم طیف وسیعی از افراد زینفع در یک پروژه شامل،مشتریان،تحلیلگران و طراحان سیستم،مدیریت شرکت یا سازمان تولید کنند نرم افزار،کد نویسان،و… با دانستن سبک معماری یک نرم افزار قادر هستند کلیات و مشخصات کلیدی محصول نهایی را درک کنند،و این امر می تواند کمک بزرگی به شفاف سازی ارتباطات افراد دخیل در پروژه،و نهایتاًموفقیت نرم افزار تولیدی در برآورده ساختن انتظارات بنماید.
در قسمت بعدی،طبقه بندی شاو و گارلان از سبک ها را بطور کلی بیان کرده و سپس به معرفی سبکهای زیر می پردازیم:
– سبکimplicit Invocation
– سبک Communicating processes
– سبک Pipes-and-filters
– سبکRepository
– سبک Blackboard
– سبکInterpreter
– سبک Layered
– سبکObject-Oriented
– سبکMain program and sub-routine

2 سبکهای متداول معماری نرم افزار
برای نخستین بار در سال 1994 ماری شاو و دیوید گارلان از دانشگاه کارنگی ملون آمریکا دست به طبقه بندی مدون سبک های معماری زدند که این طبقه بندی امروزه هم به عنوان مرجع در معماری نرم افزار مورد استفاده قرار می گیرد.هر چند این طبقه بندی بسیار خلاصه است و برخی سبک ها را در بر نمی گیرد،اما پس از گذشت یک دهه همچنان سبک های رایج معماری در نرم افزارهای کاربردی را بخوبی بیان می کند.شکل زیر که بیانگر این طبقه بندی است بر گرفته از[1]است.

در ادامه مواردی از این طبقه بندی را مختصراًتوضیح می دهیم.

2.1 سبکهای اجزای مستقل(Independent component)
این خانواده از سبکهای معماری که شامل دو زیر شاخه Event-Based systems , Communicating processes می باشد،عودتاًبر مبنای احضار ضمنی15 استوار می باشند،و هر چند احضار صریح 16 هم به عنوان زیر شاخه ای از سیستمهایEvent-Based در طبقه بندی آمده است در عمل توجه چندانی به عنوان یک سبک معماری به آن نشده و ما نیز به بحث پیرامون این شیوه(کلمه کلی تر شیوه را به کار می بریم تا وارد جزئیات اینکه آیا احضار صریح یک سبک هست یا نه نشویم)نخواهیم پرداخت.
در این سبک ها تلاش شده است فراخوانی عملیات 17 از اجرای آنها به نحوی جدا شود.به این معنی که در خواست کننده یک سرویس کاملاًمستقل از سرویس دهنده بوده و عمدتاًاز وجود آن هم اطلاعی ندارد حتی ممکن است در یک سیستم توزیع شده این دو جزء در دو پردازنده مجزا در حال اجرا باشند.البته می باید میان این سبک ها و روشهای نظیر Remote Procedure Call (RPC) یا معادل شئ گرای آن Remote Method Invocation (RMI) تفاوت قائل شد،زیرا در این دو روش اخیر همچنان فراخوانی سرویس ها یا متد ها به صورت صریح صورت می گیرد.

2.2.1. Implicit Invocation Event-Based Systems
در این سبک معماری دو رکن اساسی وجود دارد:
– عملیات
– رویدادها18
هر المان نرم افزاری هر دوی این موارد را با هم شامل می شود و در واقع تعدادی عملیات را (به عنوان عکس العمل)به تعدادی رویداد نسبت می دهد.ایده اصلی در پشت احضار ضمنی آنست که به جای آنکه یک عنصر نرم افزاری به طور مستقیم یک متد را فراخوانی کند،یک رویداد ایجاد کند خبر وقوع آن که در کل سیستم پخش همگانی 19 شود.همچنین هر عنصری به وقوع تعدادی از این رویدادها حساس است و به آن رویداد های مشخص،عملیاتی را نسبت داده است.به محض آنکه یک عنصر متوجه وقوع یکی از این رویدادها شود،عملیات تعیین شده و متناظر با آن را به اجرا در می آورد.به این ترتیب یک المان نرم افزاری با تولید یک رویداد به طور ضمنی باعث اجرای تعدادی عملیات می شود.نکته در این جاست که به دلیل عدم آگاهی تولید کننده رویداد از پاسخ دهنده یا پاسخ دهندگان به آن،یک پردازه20خاص،نمی تواند پیش بینی کند که پردازه های بعدی به چه ترتیبی اجرا می شوند و یا حتی اینکه چه پردازه هایی ممکن است به اجرا در آیند.به این دلیل گاهی به سیستم های مبتنی بر احضار ضمنی،امکان احضار صریح را هم به عنوان مکملی برای مدل تعامل اجزای نرم افزار اضافه می کنند.به این ترتیب مدل فعال سازی کاملاً بستگی به آن دارد که اجزای مختلف به چه زیر مجموعه ای از رویدادها علاقه(حساسیت)نشان دهند و عکس العمل ها چه جریان کنترلی را ایجاب نماید.
به عنوان نم.نه ای از استفاده از این سبک در نرم افزارها می توان به Trigger ها اشاره کرد. در اثر یک رویداد در سیستم نظیر بروز رسانی اطلاعات ممکن است یک یا چند Trigger فعال شوند و هر کدام عملیاتی را در قبال رویدادی که حس کرده اند،انجام دهند.البته خود این عملیات می تواند سبب ساز فعال سازی Trigger های دیگر بشود.در هر صورت المانی که در ابتدا رویداد را آغاز کرده است،ممکن است اصلاًاز وجود Trigger ها اطلاعی نداشته باشد.

2.2.2 سبکCommunicating Processes
در این سبک معماری،اصول و قواعد کلیImplicit Invocation Event-Based Systems تا حدودی پا بر جاست.با تفاوت که در این سبک تاکید اصلی بر روی تبادل پیغام21 میان المان های نرم افزار است.این ویژگی سبب می شود که مفاهیمی مانند وقوع رویداد و بخش همگانی رخداد معنی مشخصی به خود بگیرند:وقوع رخداد یعنی رسیدن پیغام به یک عنصر نرم افزاری ،و برای پخش همگانی خبر وقوع آن هم کافیست از طریق یکی از پروتکل های ارتباطی پیغام میان سایر اجزا منتشر شود.
استفاده از پیغام می تواند مشکلاتی هم در بر داشته باشد.در این قسمت به یکی از این مسائل اشاره خواهیم کرد و در بخش بعدی مزایا و معایب خانواده سبک های اجزای مستقل را به طور کلی بررسی می کنیم.مشکلی که در عمل در پیاده سازی بسیاری از سیستم ها بر اساس سبک Communicating Processes بوجود آمده است مسئله جامعیت22 نرم افزار است.به این معنی که در سیستم های قدیمی تر عمدتاً مکانیزمی برای تبادل پیغام پیش بینی نشده است و این سیستم ها اتصال گرا 23 طراحی و ساخته شده اند.در نتیجه زمانی که قصد در گسترش آنها بر طبق سبک نوین داریم می باید به نحوی به مسئله جامعیت سیستم بپردازیم.به این منظور نیاز به یک مبدل یا مترجم داریم که پیغام های مبادله شده در سیستم را به عنوان عامل هایی از یک محیط اتصال گرا به سیستم بشناساند و به این ترتیب کل سیستم را یکپارچه سازد،که البته بیهی است قرار دادن چنین واسطی میان بخش های مبتنی بر تبادل پیغام و سایر بخشها،می تواند کارایی کل سیستم را به میزان قابل توجهی کاهش دهد.

2.2.3 مزایا و معایب سبک اجزای مستقل
مزایا
-استفاده مجدد از نرم افزار24 اصلی ترین مزیت این سبک پشتیبانی قوی از استفاده مجدد از نرم افزار است.به دلیل عدم آگاهی اجزای مختلف نرم افزار از یکدیگر،وابستگی میان آنها به حداقل می رسد.در نتیجه اضافه کردن یک عنصر جدید به سیستم به سادگی انجام پذیر بوده و تنها کاری که باید انجام داد آنست که تعیین کنیم این عنصر جدید به چه رویدادهایی علاقه مند است.
– قابلیت گسترش: به دلیل Modularity بالای نرم افزارهای تهیه شده بر اساس این سبک،گسترش نرم افزار به سهولت انجام می پذیرد.
معایب
– کارایی: به دلیل ارتباط میان پردازه ای 25 هزینه ای از کارایی سیستم باید پرداخت کنیم که این تا حد زیادی به نوع ارتباطات اجزا با هم بستگی دارد .
– اگر ارتباطات از نوع نا هنگام باشند،میزان برقراری ارتباط المانها با یکدیگر به نسبت کمتر بوده و در هر بار برقراری ارتباط حجم بیشتری اطلاعات منتقل می شود.به این ترتیب کارایی افت چشم گیری نخواهد داشت.
اگر سیستمی که از یک سبک استفاده می کند،نیازمند ارتباطات همگام باشد،نظیر سیستم های محاوره ای26، در آن صورت تعدادی دفعات برقراری ارتباط زیاد،و در هر بار برقراری ارتباط حجم اطلاعات منتقل شده کم خواهد بود و این امر سبب کاهش محسوس کارایی کل سیستم خواهد شد.
– پیچیدگی: استفاده از این سبک باعث پیچیده تر شدن نرم افزار هم می شود به عنوان نمونه،عمل اشکال زدایی در این نرم افزارها می تواند مشکل و زمانگیر باشد،به این دلیل که همانطور که گفته شد،جریان کنترل میان المانها به وضوح مشخص نیست و نمی توان به راحتی تعیین کرد ایرادی که در حین اجرای یک متد رخ داده است،توسط چه بخشی از سیستم آغاز شده است.

2.2 سبکهای جریان داده(Data Flow)
این سبک از معماری،شامل دو زیر شاخه اصلی است: لوله ها و فیلترها و پردازش دسته ای که از این دو مورد تنها به مورد اول می پردازیم.سیستم های جریان داده سیستم هایی هستند که نحوه تبادل داده میان اجرای مختلف تعیین کننده مشخصات اصلی آنهاست.به بیان دیگر شیوه جریان داده در این سیستم ها شباهت زیادی به نحوه اجرای منطق زبان های برنامه نویسی دارد و معمولاًسیستم های جریان داده برای مدل کردن هر نوع جریان کاری 27 می توانند گزینه خوبی محسوب شوند.در این سیستم ها وجود حداقل دو المان که میان آنها داده به جریان در آید الزامی است.پردازش عمدتاًدر آنها به صورت ترتیبی انجام می شود،به این معنی که خروجی یک عنصر،ورودی عنصر/عناصر بعدی در مسیر جریان داده خواهد بود.در بخش بعدی،عمده ترین زیر شاخه این سبک یعنی سبک لوله ها و فیلترها را معرفی می کنیم.

2.2.1 سبک لوله ها و فیلترها
اجزای اصلی این سبک عبارتند از :
– فیلترها:عناصری که وظیفه پردازش داده های ورودی و تبدیل آنها را به اطلاعات خروجی بر عهده دارند.
– لوله ها: برقرار کننده ارتباط میان فیلترها هستند و داده ها و اطلاعات را جابجا می کنند.
– قوانین و محدودیتها: بر روی نوع لوله ها،ظرفیت آنها،نحوه ترکیب فیلترها با یکدیگر،و… که در ادامه به برخی از این موارد هم اشاره ای خواهیم داشت.
به هر ورودی یا خروجی به یک فیلتر در این سبک،یک در گاه 28 گفته می شود.فیلترهای استفاده شده در این سبک عمدتاً2 درگاه دارند (شکل 3).

تعریف 4. به هر مسیر جریان داده در یک نرم افزار مبتنی بر سبک لوله ها و فیلترها یک جط لوله گفته می شود.
یک مدل ساده از این سبک،این است که تنها یک مسیر برای جریان داده یا تنها یک خط لوله وجود داشته باشد.شکل 3 نمونه ای از خط لوله با فیلتر های 2 در گاهی را نشان می دهد.البته نسخه دیگری از فیلترها که 3 درگاه دارند،بسیار متداول تر است.در این مدل،از درگاه سوم معمولاًبه عنوان خروجی برای گزارش خطا استفاده شده و این خروجی را به یک فیلتر مجزا که وظیفه آن رسیدگی به خطاهاست،متصل می کنند.شکل 4 شمای کلی چنین سیستمی را نمایش می دهد.

از ویژگی های این سبک این است که هر فیلتر به محض دریافت ورودی،شروع به پردازش کرده و قبل از اینکه ورودی کاملاًمصرف شود،تولید خروجی آغاز می گردد یعنی هر المان پردازشگر مانند فیلتری عمل می کند که در مسیر یک سیال در جریان قرار گرفته و تبدیلاتی بر روی آن انجام می دهد.به همین دلیل نام فیلتر بر روی المانهای پردازشگر نهاده شده است.فیلترها معمولاً بر روی هم اثری نمی گذارند،مگر از طریق داده ای که یک فیلتر بالایی 29 برای یک فیلتر پایینی30 ارسال می نماید.به همین جهت عمدتاًدر منابع ذکر شده که فیلترها،حالات خود را به اشتراک نمی گذارند.علاوه بر این یک فیلتر ممکن اساساًاز وجود فیلتر های دیگر بی اطلاع باشد.(نظیر آنچه که در مورد سبک اجزای مستقل گفته شد).به این ترتیب هر فیلتر تنها لازم است بداند که انتظار دیدن چه نوع ورودی را دارد،و تا زمانی که ورودی به فرمت توافق شده به آن می رسد،تضمین کند که خروجی تولیدی چه فرمتی داشته باشد.از آنچه تاکنون گفته شد کاملاًروشن است که مدل فعال سازی در این سبک،یک مدل ترتیبی است.
قبل از آنکه به مزایا و معیب این سبک بپردازیم،جا دارد برخی ویرایش های صورت گرفته،محدودیت ها،قوانین اعمال شده در این سبک را معرفی کنیم.در این قسمت به انواع لوله هایی که ممکن است در این سبک بکار روند می پردازیم:
تعریف 5. لوله های نوع دار: به لوله های استفاده شده در این سبک می توان نوع اختصاص داد.متداول ترین انواع لوله عبارتند از:
– لوله جریانی31: کونه ای از لوله هل که هر جریان از بیت های دو دویی را انتقال می دهد.فیلترهایی که از این لوله ها داده دریافت می کنند لازم است ابتدا بر روی داده ها ی دریافتی پیش پردازش انجام دهند(داده ها سریال هستند و باید تبدیل به اشیا قابل تشخیصی نظیر اغداد صحیح،رشته های حرفی،آرایه ها و … شوند).همچنین فیلترهایی که خروجی خود را روی این نوع لوله ها قرار می دهند،می بایست ابتدا این خروجی را به فرمت سریال در آورند. – لوله شئی32: لوله ای را گویند که در آن اشیاء منتقل می شوند.در این جا منظور از شئ کلی تر از آنست که در بحث شئ گرایی می شناسیم و به معنای هر دسته بندی داده هاست که در برگیرنده یک مفهوم مشخص(و انتزاعی )باشد.
در لوله های نوع دوم ،یک شئ بصورت کلی در فیلتر مصرف شده و یا روی یک خط لوله جابجا می شود و امکان شکستن آن با اشیا کوچکتر وجود ندارد.در استفاده از انواع لوله ها باید دقت داشت که بکار گیری بیش از حد یا نابجای هر کدام می تواند به کارایی کلی سیستم لطمه وارد کند.به عنوان نمونه استفاده محض از لوله های شئ،سبب می شود سیستم به یک سیستم پردازش دسته ای تبدیل شود و دیگر جریان داده ها که زمینه ساز اصلی ویژگی های خوب این سبک نرم افزارهاست از بین برود.
تعریف6. لوله های با ظرفیت محدود:بعضی اوقات و به دلیل ملاحظات و نیازمندی های خاص نرم افزار بر روی حجمی از اطلاعات که یک لوله می تواند حمل کند،محدودیت عمال می شود.این کار به عنوان مثال می تواند به دلیل محدودیتهای پهنای باند در یک سیستمی صورت بپذیرد که بخشی از پردازشها روی شبکه انجام می شود،و فیلترها روی پردازه های مجزا توزیع شده اند.
به عنوان مثالی از این سبک،می توان به کامپایلرها اشاره کرد که در آنها مراحلPipe line شامل تحلیل لغوی،Parsing تحلیل معنایی و تولید کد می باشد.البته می دانیم که در عمل کامپایلرها عمل ترجمه را به صورت ترتیبی انجام نمی دهند،اما دید کلاسیکی که به کامپایلرها وجود داشته بسیار به این سبک نزدیک است.

2.2.2 مزایا و معایب سبک لوله ها و فیلترها
مزایا
– در این سبک رفتار کل سیستم به صورت ترکیب ساده ای از رفتار فیلترها مدل می شود.
– به دلیل استقلال فیلتر ها از هم،توسعه سیستم با سهولت انجام می شود.
– استفاده مجدد از نرم افزار توسط این سبک پشتیبانی می شود.
– سبک لوله ها و فیلترها به طور طبیعی از اجرای موازی کارها پشتیبانی می کنند.برای موازی سازی یک عمل،باید ابتدا قسمت هایی از آن که امکان موازی شدن دارند را یافت،سپس به ازای هر کدام از این بخشها یک خط لوله به سیستم اضافه کرد.
معایب
– به طور ذاتی این سبک تمایل دارد به سمت سیستمهای پردازش دسته ای سوق پیدا کند و همانطور که قبلاًگفته شد،یا از میان رفتن مفهوم جریان داده در نرم افزار(امکان تولید خروجی قبل از مصرف کامل تولید ورودی)افت کارایی قابل پیش بینی است.
– در صورت استفاده بیش از حد از لوله های جریانی هم افت کارایی خواهیم داشت.هر بار که یک جریان داده دودویی به یک فیلتر می رسد،آن فیلتر می بایست ابتدا داده ها را پیش پردازش کند تا بتواند بر روی آنها پردازش اصلی را صورت دهد و این کار(Redundant Parsing) سبب افت کارایی خواهد شد.
– به دلیل آنکه نرم افزارهایی که با این سبک ساخته می شوند ذاتاًبه تبدیلات متنوع و مکرر داده ها بستگی دارند،معمولاً این سبک برای نرم افزارهای محاوره ای انتخاب مناسبی نیست.

سبک Batch-Sequential/Pipeline
هر دو سبک Batch-Sequential/Pipeline به صورت متوالی اجرا می شوند.اگر چه در سبک Pipeline خروجی می تواند قبل از اینکه تمام ورودی مصرف شده باشد تولید گردد،ولی به هر حال معماری و نمودار حالت آنها را یکی در نظر می گیریم.
نمای معماری ونمودارحالت این دو سبک را می توان به صورت شکل 4-2- نشان داد درشکل 4-2 قسمت(الف)نمای معماری این سبکها نشان داده شده است به گونه ایکC1,C2,….Ckمولفه های معماری هستند ومولفه C2می تواند تنها به یکی از دو شاخه مولفه های بعدی انتقال یابد.
در شکل 4-2قسمت (ب)نیز حالت نمودارحالت نمای معماری دیده می شود که در حقیقت در این مورد تبدیل از دید معماری به نمودار حالت به صورت نگاشتی یک به یک از مولفه ها به حالتها صورت گرفته است و لذاs1,s2,…s k حالتهای زنجیره مارکو هستند.

با فرض اینکه معماری از Kمولفه تشکیل شده باشد در زنجیره مارکو مربوط به این سبکها وجود دارد.
ماتریس انتقال Mبه صورت زیر تشکیل می شود:

که M(I ,j)احتمال رسیدن با موفقیت از Siبه S jاست.

سبک parallel/Pipe and filter
در شرایط اجرای متوالی تنها یک مولفه در یک لحظه می تواند اجرا شود حال آنکه در شرایط اجزای همزمان مولفه ها معمولاًهمزمان با هم اجرا می شوند.در شرایط اجرای همزمان رفتار سیستم نرم افزاری می توان توسط زنجیره مارکو مدل شود،در حالیکه ممکن است یک حالت از زنجیره مارکو با اجرای چندین مولفه تعریف شود.
در سبک parallel/pipe & filterچندین مولفه میتوانند همزمان اجرا شوند.تفاوت میان این دو سبک این است که پردازش موازی معمولاًدر تک پرداز نده ای است.لذا نمای معماری و نمودار حالت را برای هر دو سبک به یک صورت در نظر می گیریم.
در شکل4-3(الف)نمای معماری سبک Parallel/Pipe & filterنشان داده است که مولفه های C2تا Ck-1در حالت Sp1در نمودار حالت مربوط در شکل 4-3(ب)آمده اند که عضوی از مجموعه حالات موازیSpاست.

همانطور که در شکل دیده می شود چنانچه Kمولفه در این معماری موجود باشند و L=K-2مولفه آن همزمان اجرا شوند در این صورت این تعداد مولفه در نمودار حالت در یک حالت قرار می گیرند و ولذا تعدادکل حالتهای موجود K-L+1خواهد بود.
بخاطر خصوصیت های سبک موازی احتمالات انتقال از مولفه C1بهCk-1,…C3,C2
همگی برابر P12هستند که در نمودار حالت از حالتS1بهSp1است. برای سادگی،نماد گذاری {ُSi}به معنی شماره سطر یا ستون حالت Siدر ماتریس Mاست.
برای محاسبه M({Sp1},{S k})لازم است تا کلیه احتمالات انتقالی از Ck-1,…,C3,C2
که در حالت Sp1است به وضعیت S kدر نظربگیریم و چون قابلیت اطمینان مولفه ها و احتمالات انتقال هر کدام از یکدیگر مستقل هستند.بنابراین مقدار ({M({Sp1},{S kبه صورت زیر محاسبه می شود:
بنابراین ماتریس Mبه صورت زیر بدست می آید:

2.3 سبکهای داده-محور(Data Centered)
این خانواده سبک شامل دو زیر شاخه اصلی است که هر کدام را توضیح می دهیم:
2.3.1 سبکRepository
امروزه اکثر شرکتها و سازمان های بزرگ دنیا وابستگی شدیدی به داده هایش دارند.حفظ داده های یک شرکت برای ادامه بقای آن به اندازه ای حیاتی است که کمپانی های بزرگ حاضرند میلیونها دلار صرف امنبت و نگهداری آنها کنند.در فضایی که تا این حد به حفظ داده ها اهمیت می دهد.بروز سبک های معماری نرم افزار مبتنی بر داده های مانا33 تعجب برانگیز نخواهد بود.با این انگیزه قوی،سبکی از معماری با نام Repository ظهور کرده است که مبنا را برای تبادل اطلاعات میان اجزاء افراد،و ارگانهای مختلف،به اشتراک گذاری داده ها قرار می دهد.اجزای اصلی این سبک عبارتند از:
– مخزن مرکزی داده ها که در حقیقت یک ساختمان داده های بزرگ است که میان پردازش ها و بخشهای گوناگون به اشتراک گذاشته می شود.
– المان های پردازشی که بطور بالقوه مستقل از هم هستند به این معنی که به کمک مخزن مرکزی داده ها قادرند همه نیازهای ارتباطی خود را بر آورده ساخته و نیازی به ارتباط مستقیم با یکدیگر ندارند.
گونه بسیار ساده شده این روش در بسیاری شرکت ها استفاده می شود و آن به اشتراک گذاری فایل هاست.فایل های مورد نیاز اجزای مختلف(المان های پردازشگر مختلف ) به همراه تعدادی ابزار اداری34 در اختیار این اجزا قرار می گیرد و مکانیزم معمولاًساده ای برای تعیین دسترسی ها و جلوگیری از تداخل وضع می شود.در مورد سیستم های کوچک این روش ممکن است جواب مطلوب بدهد،اما با گسترش سیستم مسائلی نظیر همگام سازی 35 داده ها در سر ساز شده و جلوی مقیاس پذیری36 و گسترش این روش را می گیرند.

2.3.2. سبک تخته سیاه(Blackboard)
بطور کلی در سبک های داده محور،سیاست های گوناگون می توانند انواع گوناگونی از سبک ها را تعریف کنند.به عنوان نمونه بر اساس شیوه دسترس خاصی که در روشRepository اتخاذ می شود،سبکی از معماری نرم افزار با نام تخته سیاه خلق می شود.در روش تخته سیاه،سه رکن اصلی حضور دارند:
– عناصر مستقل پردازش کننده اطلاعات که به آنها منبع دانش37گفته می شود.
– تخته سیاه که در حقیقت همان ساختمان داده های مشترک است.
روش کنترل که در واقع همان مدل فعال سازی است.در این زمینه در انتهای همین قسمت بیشتر صحبت خواهیم کرد.
منابع دانش به طور مستقیم با یکدیگر ارتباط برقرار نمی کنند و انتقال اطلاعات میان آنها از طریق تخته سیاه ممکن می شود.معمولاًنحوه بکار گیری تخته سیاه توسط KS ها،کاملاًفرصت طلبانه است و به محض اینکه تخته سیاه به حالت آزاد رفت هر کدام از KS ها که بخواهند از روی آن خوانده،ویا بر روی آن اطلاعاتی را بنویسند،می کوشند تا تخته سیاه را به خدمت بگیرند،که از این میان تنها یکی موفق می شود و بقیه می بایست تا آزاد شدن مجدد تخته سیاه صبر کنند.

شکل ۵. سبکمعماری تخته سیاه
یک نمونه از این سبک معماری در شکل 5 نشان داده شده است.در این شکل،KS ها معرف منابع دانش مستقل از هم هستند که به تخته سیاه دسترسی مستقیم دارند.
و اما در مورد مدل فعال سازی،کلاًسه جزء از سیستم ممکن است بدانند کنترل اجزا به چه ترتیبی است:
– خود تخته سیاه : تخته سیاه نحوه انتقال کنترل را به عنوان یک داده کنترلی مشترک در اختیار همه منابع دانش گذاشته و آنها هم طبق توافق از این مدل کنترلی پیروی می کنند
– منابع دانش: هر منبع می داند زمانی که با تخته سیاه کار دارد و همچنین تخته سیاه در وضعیت آزاد به سر می برد باید آنرا در اختیار بگیرد.این روش همان مدل رقابتی است که پیش تر توضیح دادیم.
– یک منبع خارجی به سیستم اضافه می کنیم که وظیفه آن اعمال مکانیزم کنترلی روی ks ها ست.
2.3.3. مثال هایی از بکار گیری سبکRepository و تخته سیاه
سبک تخته سیاه از قدیم عمدتاًبرای کاربردهایی که نیاز به پردازش و تفسیر پیچیده سیگنال ها داشته اند نظیر پردازش صوت یا تشخیص الگو استفاده شده است.در مورد سبک Repository نیز در قدیم سیستم های دسته ای با بانک های اطلاعاتی اشتراکی وجود داشته اند که از این سبک معماری استفاده می کردند.همچنین کاربردهایی وجود دارند که در ابتدا تصور می شده سبک های دیگر معماری استفاده می کردند.همچنین کاربردهایی وجود دارند که در ابتدا تصور می شده سبک های دیگر معماری مناسب آنها هستند،اما با گذشت زمان در عمل ثابت شده که سبک معماری Repository به نحو بهتری می تواند چنین نرم افزارهایی را ساماندهی کند.به عنوان نمونه در ابتدا فرض می شده که برای طراحی کامپایلر ها بهترین سبک موجود،سبک لوله ها و فیلترها است،ولی امروزه عمده کامپایلرها بهترین سبک موجود،سبک لوله ها و فیلتر ها است،ولی امروزه عمده کامپایلرهای موجود در بازار بر اساس یک مخزن داده اشتراکی عمل می کنند(جدول نشانه ها38 ،درخت ساختار نحوی،…)

2.4 سبکهای ماشین مجازی(Virtual Machine)
سبک ماشینهای مجازی به دو شاخه مفسرها و سیستم های rule-based تقسیم می شود که ما فقط مفسرها را بررسی می کنیم:

2.4.1 مفسرها(Interpreters)
مفسرها را گونه ای از ماشینهای مجازی می دانند.دلیل این امر آنست که یک مفسر می تواند یک لایه معنایی39 جدید روی تکنولوژی موجود درست کند،و این همان انتظاری است که از یک ماشین مجازی داریم.بخشهای مختلف یک مفسر عبارتند از:
– موتور تفسیر:وظیفه اصلی آن تفسیر و اجرای برنامه است.
– حافظه:که در بر گیرنده شبه برنامه40 می باشد.
– نمایشی از وضعیت کنترلی موتور تفسیر:این نمایش در بخشی از حافظه ذخیره سازی می شود.
– نمایش وضعیت کنونی برنامه: این نمایش هم در حافظه ذخیره سازی می شود.

شکل ۶. نمای کلی یک مفسر
مدل فعال سازی در این سبک بستگی زیادی به نحوه پیاده سازی موتور تفسیر دارد.اما به طور معمول موتور تفسیر دستورالعملهای یک شبه برنامه ترتیبی به اجرا در می آورد.همانند دیگر سبکهای معماری نرم افزار،این سبک را هم می توان به صورت ترکیبی در کنار چند سبک دیگر به کار برد.به عنوان یک مثال کلی،با ترکیب سبک مفسرها با سبک احضار ضمنی که ازTriggerاستفاده می کند،می توان یک موتور گردش کار ایجاد کرد که کنترل نحوه فعال شدن Triggerها توسط مفسر انجام می شود وکاربر سیستم می تواند با ارائه شبه مورد نظر خود،رفتار سیستم را کنترل کرده و گردش کار مورد نیاز خود را پیاده سازی کند.

2.4.2 مزایا ومعایب مفسرها
مزایا
– انعطاف پذیری:این سیستم ها می توانند بسیار انعطاف پذیر باشند،تا جایی که به عنوانمثال یک شرکت تولید نرم افزار می تواند برای مشتریانی که نیاز به مدل کردن گردش کار داشته و این گردش کار به تناوب دستخوش تغییر می شود،از یک نرم افزار مبتنی برسبک مفسرها استفاده کند.به جای آنکه قوانین تجاری محیط هدف(محیطی که نرم افزار نهایتاً در آن نصب و استفاده می شود)به صورت استاتیک در نرم افزار گنجانده شود،کاربران سیستم می توانند با شبه برنامه هایی این قوانین را به دلخواه خود تغییر دهند.
معایب
پیچیدگی: انعطاف پذیری بالای این گونه سیستم ها هزینه هایی را هم در هنگام تولید و تست به شرکت تولید کننده تحمیل می کند.بدیهی است که نمی توان تمام شبه برنامه هایی که کاربران ممکن است به عنوان ورودی به مفسر دهند را پیش بینی و امتحان کرد.در نتیجه هرگز نمی توان به طور کامل از درستی مفسر ساخته شده اطمینان حاصل کرد.

2.5 سبکهای مبتنی بر فراخوانی(Call/Return)
سه رده اصلی زیر مجموعه این خانواده از سبک ها عبارتنداز:از سبک لایه ای،و سبکMain program and sub-routine(سبک کلاسیک زبان های برنامه نویسی).مشخصه مشترک و اساسی همه این سبک ها،مدل فعال سازی یکسان آنهاست. در همه این سبکها یک رشته اصلی41 کنترل وجود دارد که این رشته فراخوانی عملیات و متدهای دیگر را برعهده دارد.
2.5.1 سبک معماری لایه ای
سیستم های لایه ای ذاتاً ماهیت سلسله مراتبی دارد.که یک لایه خدماتی را برای لایه بالایی خود فراهم کرده و به عنوان مشتری از لایه پایینی خود سرویس دریافت می کند.لایه ها ممکن است از نظر میزان شفافیت (دسترس پذیری )با یکدیگر متفاوت باشند در بعضی از سیستم ها هر لایه از دیدتمام لایه ها بجز لایه خارجی تر مجاور پنهان است البته گاهی به دلایل فنی برخی از توابع خاص با دقت انتخاب شده و در دسترس سایر لایه ها هم قرار می گیرند.به این صورت،اجزای نرم افزار یک ماشین مجازی را تشکیل می دهند(همانگونه که در بحث مفسرها هم ذکر شد).

نحوه ارتباطات میان لایه ها در این سبک،توسط پروتکلهای ارتباطی تعیین می شود.مشهورترین مثالهای این سبک معماری.پروتکل های لایه ای ارتباطی نظیرTCP/IPو یا مدل مرجع ISOهستند.البته این سبک معماری کاربردهای دیگری نظیر طراحی سیستم های عامل و یا سیستم های مدیریت پایگاه داده ها هم دارد.همچنین یک مدل معروف و 3لایه ای از این سبک که به مدل 3-Tierشهرت یافته،در طراحی نرم افزارهای تجاری فراوان مورد استفاده قرار می گیرد.
مزایا
– طراحی نرم افزارها در این سبک براساس افزایش تدریجی سطح انتزاع انجام می شود، واین روند به دلیل سازگاری با مدل طبیعی ادراک بشر می تواند فرآیند طراحی را ساده کند .
-به Modularityبالا بهبود نرم افزار در این روش به سادگی انجام می شود(مشابه سبک لوله ها و فیلترها).
– استفاده مجدد از نرم افزار در این سبک پشتیبانی می شود.

معایب
– تمام سیستم های نرم افزاری را نمی توان به سهولت به لایه هایی تقسیم کرد و این امر می تواند کاربرد این سبک را تا محدود به موارد خاص کند.
– کارایی ممکن است دردسرساز شود.سوال اصلی اینجاست که چه تعداد لایه داشته باشیم که همچنان سیستم در عمل قابل پیاده سازی باشد و منطق سطح بالای سیستم از پیاده سازی سطح پایین آن آنقدر فاصله نگیرد که در هنگام اجرا کارایی بسیار ضعیفی حاصل شود.این همان مشکلی است که مدل مرجع ISOتا حد زیادی به آن گرفتار شد.
– منتقدین این سبک معتقدند لایه بندی یک سبک نیست و تنها مشخصه ای طبیعی از سیستم های با ساختار مراتبی است[2].

2.5.2سبک معماری شی گرا(Object Oriented)
شی گرایی عمدتاً با مفهوم Encapsulationشناخته شود.منظورازEncapsulation تجمع عملیات اولیه در کنار نوع داده های انتزاعی42 در قالب موجودیتی به نام شی است برخی نویسندگان (3)اشیاء را اجزایی از نرم افزار می دانند که نقش مدیریتی دارند.به این معنی که مسئولیت حفظ جامعیت کل سیستم بر عهده آنهاست و ویژگی هایی نظیر پنهان سازی اطلاعات توسط آنها فراهم می شود.یک شی اصولاً به اشیاء دیگراجازه دسترسی به داده های خصوصی43 خود را نمی دهد(البته بجز به اشیایی از کلاسهای دوست)مگر آنکه پیغام درخواستی از طف آنها دریافت کند و درضمن،عملیاتی برای فراهم کردن آن داده بخصوص در پاسخ به پیغام درخواست،در شی دریافت کننده پیغام تعبیه شده باشد.به این ترتیب پنهان سازی اطلاعاتتوسط یک شی تضمین می شود.

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

2.5.3سبک معماری Main program and sub-routine
در این سبک معماری،ساماندهی سیستم تولید شده تا حد زیادی ماهیت زبان برنامه نویسی که در پیاده سازی سیستم به کار رفته است را منعکس می کند.البته از این سبک در قدیم که برنامه ها چندان پیچیده نبودند متداول بوده و امروزه حداقل در مورد نرم افزارهای تجاری بزرگ،به عنوان یک سبک معماری نرم افزار به کار نمی رود.
مشخصه اصلی این سیستم ها آنست که یک برنامه اصلی گرداننده کل سیستم بوده و در مواقع ضروری زیر برنامه هایی را فراخوانی می کند.که عمدتاً این سیستم ها از نبود Modularizationمطلوب رنج می برند و در نتیجه قابلیت توسعه چندانی ندارند.به دلیل محدودیت هایی که سیستم های تولید شده براساس این سبک دارند،بیش از این به بحث در مورد آن نمی پردازیم.

3سایر سبکهای معماری نرم افزار

3.1سبک فرآیندهای توزیع شده(Distributed Processes)
سیستم های توزیع شده،سازماندهی های ویژه ای را برای سیستم های چندپردازه ای45 بوجود آورده اند.بعضی از این سازماندهی ها با توپولوژی خاصی که دارند توصیف می شوند،نظیر توپولوژی حلقه46،و یا توپولوژی ستاره47.برخی دیگر توسط پروتکل های خاصی که برای ارتباط میان پردازه ها به کار می روند،شناخته شوند.گاهیسیستم های Client/Serverرا به عنوان نمونه خاصی از این سبک معرفی می کنند.در چنین سیستم هایی سرور معمولاًپردازشی است که سرویسی را برای پردازش های دیگر فراهم می کند.با این حال عمدتاً اینClientاست که از وجود سرور و مشخصات آن آگاه است(یا از طریق سرور دیگری می تواند این اطلاعات را کسب کند)،و نه سرور.

3.2 سبکهای خاص منظوره(Domain-Specific)
در دهه اخیر تلاشهای فراوانی به عمل آمده است که برای زمینه های خاص،مدل مرجع معماری تهیه شود.چنین مدلهایی،ساختارهای مخصوصی برای یک خانواده ازکاربردها ارائه می کنند،به عنوان مثال برای سیستم های حمل نقل یک مدل معماری ویژه پیشنهاد می نمایند.با تخصصی تر شدن مدل معماری،این مکان بوجد می آید که یک سیستم قابل اجرا و استفاده،به واسطه محدودیت های خوش تعریف اعمال شده روی توصیف آن به طور کاملاً خودکار یا نیمه خودکار تولید شود.

3.3 سبک انتقال حالت(State Transition)
سبک معمولی برای سیستم های واکنشی است.اجزا اصلی این سبک یک مجموعه از حالت ها به همراه مجموعه ای از انتقال حالت ها است.منظور از انتقال حالت،تغییر وضعیت سیستم از حالتی به حالت دیگر است(مشابه آنچه در State Transition Diagrams (STDدر روشهای ساخت یافته تولید نرم افزار و یا درActivity Diagramهای UMLدیده می شود).

3.4 سبک کنترل فرآیند(Process Control)
این سبک بیشتر در سیستم هایی که وظیفه آنها کنترل یک محیط فیزیکی (نظیر کنترل شرایط رطوبت و دما و…در یک گلخانه)است مورد استفاده قرارمی گیرد.اگر بخواهیم بسیار کلی این چنین سیستم هایی را توصیف کنیم،اجزای تشکیل دهنده آنها عبارت خواهند بود از:
– سنسورها:اطلاعات بازخور48را از محیط دریافت کرده و به واحدهای پردازشی می رساند.
– واحد(های)کنترل فرآیند: متناوباًاطلاعات دریافتی از سنسورها را مورد پردازش قرار داده و در صورت مشاهده انحراف در وضعیت کل سیستم به نسبت وضعیت مطلوب ازیش تعیین شده،تصمیمات لازم را اتخاذ می کند.
– عملگرها 49:تصمیمات اتخاذ شده توسط واحد یا واحدهای کنترل فرآیند را در محیط به اجرا در می آورند.

منابع:

[1]. Len Bass, Paul Clementsm Rick Kazman, "Software Architecture in Practice", 2nd Edition, 2003.
[2]. Stephen T. Albin, "The Art of Software Architecture: Design Methods and Techniques", 2003.
[3]. Mary Shaw and David Garlan, "An Introduction to Software Architecture", 1994.
[4]. http://www.wikipedia.org
[5]. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, "Design Patterns: Elements of
Reusable Object-Oriented Software", 1994.