دانلود مقاله معماری نرم افزار

چکیده با گسترش روز افزون استفاده از مدل­های فرایند مبتنی بر معماری، طراحی معماری نرم افزار اهمیت ویژه­ای یافته است.

یک طراحی معماری خوب، طراحی است که نیاز­های کیفی مورد انتظار مشتری را برآورده نماید.

در این گزارش روش ­های گوناگون طراحی معماری نرم افزار مورد بررسی قرار خواهد گرفت.

سپس ویژگی کیفی قابلیت تغییر به طور دقیق و جزئیات معرفی خواهد شد و سپس معماری یک سیستم مطالعه موردی با دیدگاه دستیابی به قابلیت تغییر طراحی خواهد شد.

مقدمه امروزه یکی از مهمترین ویژگی‌های هر سیستم نرم‌ افزاری، کیفیت می‌باشد.

با پیشرفت‌های انجام شده و گسترش ابزار‌های گوناگون برای توسعه نرم‌افزار، توسعه نرم‌افزار‌هایی که کارکرد‌های مورد نظر مشتریان را برآورده سازند، امری آسان و سریع گشته است.

در حال حاضر، تفاوت بین دو نرم‌افزار را توانایی نرم‌افزار‌ها در برآورده ساختن ویژگی‌های کیفی مورد انتظار تعیین می‌کند.

معماری نرم افزارِ یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد[Bass 03] .

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

همچنین معماری نرم‌افزار، اولین عنصر قابل ارزیابی در فرایند توسعه نرم‌افزار می‌باشد[Bass 03] .

بنابراین برای طراحی سیستمی که نیاز‌های کیفی مورد نظر را برآورده سازد، تولید معماری نرم‌افزار اولین گام در دستیابی به کیفیت در نرم‌افزار و همچنین ارزیابی ویژگی‌های کیفی است.

در مدل­های فرایند توسعه نرم­افزار مبتنی بر معماری[1] معمولاً ابتدا نیاز­های کیفی سیستم تعیین شده و سپس معماری نرم­افزار مربوطه طراحی می­گردد.

پس از طراحی معماری، می­توان به ارزیابی آن پرداخت و تغییرات لازم را در طراحی مورد نظر ایجاد داد.

بنابراین دو بخش اساسی در مدل­های فرایند توسعه نرم­افزار مبتنی بر معماری، بخش­های طراحی و ارزیابی معماری نرم افزار می­باشند.

این دو بخش در ارتباط مستقیم با یکدیگر می­باشند و هر یک مکمل دیگری می­باشد.

بنابراین فرایند طراحی معماری را می­توان شامل ساخت معماری نرم­افزار، ارزیابی آن و اصلاح معماری پیشنهادی دانست.

در این گزارش، هدف بررسی روش­های موجود در طراحی معماری نرم­ افزار بر اساس ویژگی­های کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزار­هایی برای این منظور می­باشد.

ادامه مطالب گزارش به این صورت طبقه بندی شده اند.

در بخش 2 توضیح مختصری در ارتباط با معماری نرم­افزار و مفاهیم مرتبط با آن ارائه می­شود.

این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد.

در بخش 3 طراحی معماری نرم­افزار، ویژگی­های یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت.

در بخش 4 روش­های طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت.

در بخش 5 خلاصه و نتیجه گیری ارائه خواهد شد.

در بخش 6 مراجع مورد استفاده در این گزارش معرفی می­گردد.

معماری نرم افزار چیست ؟

برای معماری نرم‌افزار، تعریفی که به طور عمومی پذیرفته شده باشد، وجود ندارد.

افراد مختلف، معماری نرم‌افزار را به اشکال گوناگون تعریف کرده‌اند.

این تعاریف، از لحاظ ظاهری متفاوتند ولی به مفهوم مشترکی اشاره می‌کنند.

در [Bass 03] معماری نرم افزار به صورت زیر تعریف شده است : معماری نرم افزار یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد.

از تعریف فوق می توان به نتایج زیر دست یافت :‌ • معماری، اجزای نرم افزار را تعریف می نماید.

همچنین در این تعریف، از جزئیاتی از اجزا، که در نحوه استفاده و ارتباط با اجزای دیگر کاربردی ندارند؛ صرف نظر می گردد.

• هر سیستم نرم افزار شامل چندین ساختار می باشد؛ و هیچ یک از این ساختارها، به تنهایی معماری نرم افزار نمی­باشد.

بلکه این ساختارها در کنار یکدیگر معماری نرم افزار را تشکیل می دهند.

• هر سیستم نرم افزاری دارای یک معماری می باشد.

(زیرا هر سیستم نرم افزاری دارای اجزایی است که این اجزا با یکدیگر دارای رابطه می باشند).

• رفتار هریک از اجزاء، بخشی از معماری نرم افزار می باشد.

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

علاوه بر تعاریف ارائه شده در [Bass03] تعاریف گوناگون دیگری نیز برای معماری نرم افزار ارائه شده است که در اینجا به برخی از آنها اشاره خواهیم کرد : در [IEEE00]معماری نرم افزار به صورت زیر تعریف شده است : معماری نرم‌افزار، سازمان زیربنایی سیستم می‌باشد، که در قالب اجزا و روابط بین آنها و همچنین روابط آنها با محیط، بیان شده است و برای طراحی و تکامل آن اصولی وجود دارد.

در این نوع تعریف، فرایند تولید معماری، عضوی از معماری در نظر گرفته شده است.

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

معماری هر سیستم نرم‌افزاری می‌تواند بدون توجه به نحوه تولید آن مشخص و ارزیابی گردد.

در [Booch 98] معماری نرم افزار مجموعه‌ای از تصمیمات مهم درباره ساختار سیستم نرم‌افزاری ، انتخاب اجزاء ساختاری و ارتباطات بین آنها و همچنین مشخص نمودن نحوه همکاری این اجزاء با یکدیگر می‌باشد.

وقتی این اجزاء در کنار یکدیگر سیستم بزرگی را تشکیل دهند معماری نرم افزار به وجود خواهد آمد.

در [Garlan 93]، معماری نرم‌افزار سطحی از طراحی تعریف شده است که دارای ویژگی‌های زیر می‌باشد : • ورای الگوریتم و ساختمان داده طراحی شده باشد.

• شامل ساختار کلی سیستم، ساختار‌های کنترلی عمده، پروتکل‌های ارتباطی، اختصاص کارکرد‌ها به اجزاء، توزیع فیزیکی اجزاء باشد.

• ترکیبی از اجزاء طراحی باشد که از بین گزینه‌های طراحی موجود انتخاب شده است.

در تعاریف ارائه شده توسط [Booch 98] و [Garlan 93]، از معماری به عنوان ساختار کلی سیستم نام‌ برده شده است.

باید توجه داشت، ضعف این تعریف نسبت به تعریف ارائه شده توسط [Bass 03] در محدود کردن ساختار سیستم به تنها یک ساختار می‌باشد.

در حالی که سیستم برای مشخص کردن معماری، دارای ساختار‌های گوناگون باشد.

در [RUP 03] معماری نرم‌افزار سازمان یا ساختار اجزاء اصلی سیستم که از طریق واسط‌هایی با هم ارتباط برقرار می‌کنند؛ می‌باشد به طوری که هر یک از اجزاء از اجزاء کوچکتری تشکیل شده که این اجزاء کوچک نیز با یکدیگر ارتباط دارند.

در این تعریف نیز، به ساختار‌های گوناگون اشاره نشده است.

گرچه در [RUP 03] در مرحله طراحی معماری نرم‌افزار، ساختار‌ها یا دیدگاه های مختلفی برای معماری معرفی شده است.

دیدگاه ما نسبت به معماری، دیدگاه [Bass 03] می‌باشد.

یکی از نکات مهم در این تعریف، امکان ارائه ساختار‌های گوناگون برای معماری می‌باشد.

این ساختار‌ها نباید محدود به چندین ساختار پیش فرض باشند.

به عنوان مثال برای تولید معماری یک سیستم امن، می‌توان مدل امنیتی سیستم را نیز عضو معماری قرار داد.

زیر بررسی و ارزیابی آن قبل از مرحله پیاده سازی بسیار حیاتی می‌باشد.

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

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

الگو­های معماری یا سبک­های معماری الگوهای معماری[2] یا سبک ­های معماری[3] شامل شرحی از اجزاء و نوع روابط بین آنها می باشد به نحوی که تعدادی قانون برای معرفی اجزاء و نحوه ارتباط بین آنها، مشخص گردد.

[Bass 03] به عنوان مثال client-server یک الگوی معماری است که مشخص می کند سیستم دارای دو جزء می باشد و این دو جزء تحت پروتکل خاصی با یکدیگر ارتباط دارند.

هر الگوی معماری در برگیرنده تعدادی معیار کیفی[4] می باشد و معمار نرم افزار بر اساس نیازهای کیفیتی مورد نظر، الگوی معماری مناسب را انتخاب می نماید.

در بسیاری از موارد از سبک‌های معماری، به جای الگوهای معماری استفاده می گردد.

از دیدگاه ما الگو‌های طراحی باید بتوانند یک یا چند نیاز کیفی را برآورده نمایند.

زیرا درصورتی که تنها کارکرد مد نظر باشد بدون استفاده از الگوی خاصی می‌توان به آن دست یافت.

مدل مرجع[5] مدل مرجع، تقسیم بندی و تجزیه کارکردهای مختلف یک سیستم به همراه جریان داده های بین هریک از بخش‌ها می باشد.

در حقیقت مدل مرجع، تقسیم بندی یک مسئله مشخص به اجزاء می‌باشد به گونه ای که این اجزا توانایی حل مسئله را داشته باشند.

به عنوان مثال، مدل مرجع برای یک نرم افزار سیستم عامل، شامل بخش‌هایی نظیر : مدیریت حافظه، مدیریت دیسک، مدیریت فعالیت‌ها و ...

می‌باشد.

معماری مرجع [6] معماری مرجع، مدل مرجعی می باشد که به اجزای نرم افزاری نگاشت شده است.

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

هر جزء نرم افزار در این مدل ممکن است قسمتی از یک کارکرد یا چندین کارکرد را پیاده سازی نماید.

به عنوان مثال برای یک سیستم‌عامل، مدیریت حافظه توسط جزء هسته انجام شود.

مدیریت دیسک توسط جزء مدیر دیسک و هسته انجام شود و ...

مدل مرجع الگوی معماری معماری مرجع معماری نرم افزار ارتباط بین الگوی معماری، مدل مرجع و معماری مرجع دیدگاه های معماری سیستم های مدرن و امروزی به اندازه ای پیچیده هستند که یه ساختار و دیدگاه واحد، توانایی نمایش همه جنبه های آنها را ندارد.[Bass 03] بنابراین برای نمایش معماری یک سیستم نرم افزاری از دیدگاه های مختلف استفاده می کنیم.

یک ساختار یا دیدگاه معماری، نمایش مجموعه ای از اجزای معماری مرتبط با یکدیگر و ارتباط بین این اجزا می باشد.

(تصاویر در فایل اصلی موجود است) دیدگاه Bass بر اساس طبقه بندی ارائه شده در [Bass 03] ساختارهای معماری نرم افزار قابل دسته بندی از سه گروه عمده به شرح زیر می باشند: • ساختار ماژول‌ ها در این ساختار، اجزاء تشکیل دهنده ماژول ها هستند.

ماژول، یک واحد پیاده سازی شده از سیستم می‌باشد.

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

هر ماژول شامل طیفی از وظایف می‌باشد.

در ساختار ماژول‌ها، بیشترین تاکید بر نحوه پخش شدن وظایف مختلف بر روی ماژول‌ها و نحوه ارتباط ماژول‌ها با یکدیگر است.

در این ساختار تاکید خاصی روی ساختار‌های اجرایی نمی‌شود.

• ساختار اجزاء و رابط‌ها در این دیدگاه، اجزاء تشکیل دهنده واحد‌های در حال اجرا می باشند(واحد‌های محاسباتی).

همچنین رابط‌ها نحوه ارتباط و گفتگوی بین اجزاء را نشان خواهند داد.

این ساختار مشخص کننده اجزای مهم اجرایی و نحوه ارتباط آنها با یکدیگر است.

همچنین این ساختار مواردی نظیر : مهمترین محل‌های ذخیره اطلاعات، نحوه تکرار داده‌ها، اجزایی که به طور موازی اجرا می‌گردند، می‌باشد.

• ساختار تخصیص منابع این ساختار ارتباط بین اجزاء نرم افزاری و اجزائی که در محیط خارجی تولید و استقرار نرم افزار وجود دارند را نشان می دهد.

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

در این دیدگاه، از ابزار UML استفاده نشده ولی از لحاظ مفهومی قابلیت پیاده سازی با استفاده از UML‌ وجود دارد.

دیدگاه 4+1 این دیدگاه در [Kruchten 95] ارائه شده و امروزه به عنوان استاندارد در IEEE 1471 [IEEE 00] مطرح می‌باشد.

در این دیدگاه، ساختارهای معماری به صورت زیر طبقه بندی شده اند : • Logical View • Process View • Deployment View • Implementation View • Use-case View همچنین این دیدگاه در [RUP 03] نیز به عنوان استاندارد توسعه معماری نرم افزار معرفی گردیده است.

پایه این دیدگاه متدولوژی شیء گرا و ابزار استفاده از آن UML می باشد.

برای استفاده بهینه از این دیدگاه پیشنهاد می شود که مدل فرایند انتخابی به صورت تکراری و بر پایه RUP انتخاب گردد.

دیدگاه‌های دیگر از دیگر دیدگاه هایی که در [Garland 03] معرفی گردیده شده می توان به : • دیدگاه RM-ODP (استاندارد ISO ) • دیدگاه Hofmeister اشاره نمود.

برای جزئیات بیشتر به [Garland 03] مراجعه شود.

اشاره نمود.

طراحی معماری نرم افزار در این بخش به بررسی عوامل تاثیر گذار بر معماری نرم‌افزار و نحوه تولید معماری خواهیم پرداخت.

با توجه به تعاریف انجام شده، معماری نرمافزار هر سیستم، پس از به دست آوردن نیازهای آن سیستم باید تولید شود.

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

در ادامه هریک از دو ویژگی فوق را تعریف کرده و نقش آن را در طراحی معماری مورد بررسی قرار خواهیم داد.

کارکرد‌های سیستم و معماری نرم‌افزار کارکرد‌های سیستم، توانایی‌های سیستم در انجام کارهای مختلف می‌باشد[Bass 03].

برای دستیابی به کارکرد‌های مورد نظر در یک سیستم نرم افزاری می‌توان از ساختار‌های گوناگون استفاده نمود.

به بیانی دیگر در صورتی که در تولید نرم افزار تنها کارکرد مورد نظر می بود؛ امکان تولید نرم افزار در قالب یک واحد یکپارچه و مستقل امکان پذیر بود.

اما معمولاً کارکرد، تنها نیاز نرم افزار نمی باشد.

بنابراین برای برآورده کردن نیازهای دیگر که شامل نیازهای غیرکارکردی و کیفی میباشند؛ باید از ساختارهای خاصی در تولید نرم افزار استفاده نمود.

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

زیران کارکرد‌ها در قالب یک ماژول یکتا نیز قابل دستیابی است.

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

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

هدف از بیان سیستم نرم افزاری در قالب ساختار‌های گوناگون که با هم دارای رابطه هستند، برآورده کردن نیاز‌های کیفی مورد نظر در سیستم نرم‌افزار می‌باشد.

ویژگی‌های کیفی ویژگی‌های کیفی، نیاز‌هایی از سیستم هستند که جنبه غیر کارکردی دارند(نیازهای غیر کارکردی).

این نیاز‌ها در مراحل طراحی، پیاده سازی و استقرار سیستم باید مد نظر قرار گیرند[Bass 03].

در حقیقت، برآورده کردن این ویژگی‌های کیفی، مستلزم توجه به آنها در مرحله طراحی، پیاده سازی و استقرار است.

به عنوان مثال ویژگی کیفی قابلیت استفاده دارای جنبه‌های گوناگون است.

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

در حالی که قابلیت بازگرداندن تغییرات انجام شده، یا فراهم آوردن امکان Cancel کردن فعالیت‌های نرم افزار توسط کاربر از جنبه‌های مربوط به معماری این ویژگی کیفی محسوب می‌گردد.

با توجه به مطالب مطرح شده دو نکته مهم در زمینه ارتباط ویژگی‌های کیفی و معماری وجود دارد : • معماری نرم‌افزار یکی از اجزای حیاتی فرایند تولید نرم‌افزار برای برآورده نمودن ویژگی‌های کیفی می‌باشد.

معماری باید قابلیت بیان مهمترین ویژگی‌های کیفی نرم‌افزار را داشته باشد و امکان ارزیابی آنها را در سطح معماری فراهم سازد.

• معماری نرم‌افزار به تنهایی قادر به برآورده ساختن نیاز‌های کیفی نمی‌باشد، بلکه به عنوان بستری برای قرار دادن کیفیت در سیستم نرم‌افزار به کار می‌رود.

ویژگی‌های کیفی پس از معرفی در معماری نرم‌افزار، در مراحل بعدی توسعه نیز باید مد نظر قرار گیرند.

باید توجه داشت که برآورده ساختن یک نیاز کیفی، بر روی دیگر نیاز‌های کیفی اثرگذار است.

به عنوان مثال، سیستم‌ای که دارای ویژگی کیفی امنیت می‌باشد، معمولاً دارای ویژگی قابلیت اطمینان نیز است.

یا برای مثال سیستمی که دارای کارایی مناسبی می‌باشد، قابلیت تغییر پایین‌تری می‌باشد.

در [With 02] ارتباط بین ویژگی‌های کیفی گوناگون بیان شده است.

معیار‌های کیفی را می‌توان به دسته‌های گوناگون طبقه بندی نمود.

در [Bass 03] معیارهای کیفی که در توسعه معماری نرم افزار تاثیر گذاراند در سه دسته زیر طبقه بندی شده اند :‌ • کیفیت سیستم ( availability، modifiability، performance، security، testability و usability ) • معیارهای کیفی کسب و کار ( زمان تحویل به بازار و ...

) • معیارهای کیفی نظیر یکپارچگی منطقی معماری که مستقیماً متوجه خود معماری می‌باشد و به طور غیر مستقیم بر روی کیفیت سیستم تاثیرگذار است.

همچنین در [Garland 03] معیارهایی علاوه بر معیارهای فوق ارائه گردیده است : • قابلیت انطباق با فرهنگ‌های مختلف • یکپارچگی داده ای • قابلیت نگهداری بالا • قابلیت سلامت ( Safety )‌ • قابلیت مدیریت در [With 02] فهرست کاملی از ویژگی‌های کیفی گوناگون ارائه شده است.

معیار‌های کیفی مورد توجه ما، معیار‌های کیفی سیستم می‌باشد.

زیرا در این گزارش، هدف طراحی معماری نرم‌افزار بوده و برای آن معماری سیستم باید مورد ارزیابی قرار گیرد.

ویژگی‌های کیفی سیستم ویژگی‌های کیفی سیستم، نیاز‌های غیرکارکردی می‌باشند که بر روی کارکرد‌های سیستم اثرگذار خواهند بود.

تعریف ویژگی‌های کیفی به صورت کلی و در قالب نیاز‌های غیرکارکردی دارای مشکلات زیر می‌باشد : • تعریف ویژگی کیفی قابل استفاده عملی نمی‌باشد.

به عنوان مثال وقتی می‌گوییم سیستم باید قابلیت تغییر داشته باشد، این قابلیت تغییر می‌تواند شامل قسمت‌های مختلفی از سیستم گردد.

• در این تعریف، مشخص نیست که هر ویژگی کیفی چه زمینه‌هایی از سیستم را در بر می‌گیرد.

به عنوان مثال، قابلیت خراب نشدن عملیات سیستم می‌تواند در دسته ویژگی‌های قابلیت در دسترس‌بودن، امنیت و قابلیت اطمینان طبقه بندی شود.

• هریک از ویژگی‌های کیفی، دارای پارامتر‌های متفاوت می‌باشند.

به عنوان مثال، کارایی، دارای پارامتر‌هایی نظیر "پیغام" های وارد شده به سیستم دارد.

امنیت دارای حمله است و قابلیت استفاده دارای پارامتری نظیر ورودی کاربر می‌باشد.

همه این پارامتر‌ها بیانگر یک عمل بر روی سیستم می‌باشند ولی با لغات مختلف نشان داده شده اند.

برای حل این مشکلات [Bass 03] مفهومی به نام سناریو‌های ویژگی کیفی را ارائه داده است.

این سناریو‌ها راه حلی برای بیان دقیق ویژگی‌های کیفی یک سیستم نرم‌افزار ارائه می‌کنند.

سناریو‌های ویژگی‌کیفی سناریو‌های ویژگی‌ کیفی، یک نیاز غیر کارکردی می‌باشند.

این نیاز‌ها به طور دقیق بیان شده اند و هر نیاز مربوط به یک ویژگی کیفی خاص می‌باشد.

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

) که عملی را در قبال سیستم انجام می‌دهد.

در حقیقت سیستم را تحریک می‌نماید.

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

محیط : محیطی که محرک در آن رخ می‌دهد، بسته به شرایط سیستم می‌تواند متفاوت باشد.

به عنوان مثال سیستم می‌تواند در شرایط حداکثر بار و یا در شرایط اجرای معمولی باشد.

شرایط دیگر نیز می‌تواند وجود داشته باشد.

محصول نرم‌افزاری : این بخش بیانگر محصول نرم‌افزاری است که محرک بر روی آن اثر گذار است.

این محصول می‌تواند کل سیستم و یا بخشی از آن باشد.

پاسخ : پاسخ عملی است که سیستم در قبال تحریک انجام می‌دهد.

مقیاس پاسخ : وقتی سیستم پاسخی در قبال محرک نشان می‌دهد، این پاسخ باید قابل اندازه‌گیری باشد.

اندازه گیری این پاسخ، مشخص می‌نماید که آیا نیاز مربوط به سناریو برآورده شده است یا خیر.

در [Bass 03] سناریو‌های کیفی به دو دسته زیر طبقه بندی شده اند : • سناریو‌های عمومی : سناریو‌هایی که مستقل از نوع سیستم می‌باشند.

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

• سناریو‌های حقیقی : سناریو‌هایی هستند که به طور خاص بیانگر نیاز‌های سیستم تحت توسعه می‌باشند.

در شکل2 بخش‌های تشکیل دهنده یک سناریو ویژگی کیفی ارائه شده است.

شکل 2 - بخش‌های تشکیل دهنده سناریو ویژگی کیفی ویژگی‌های کیفی کسب و کار علاوه بر ویژگی‌های کیفی سیستم نرم‌افزاری، تعداد ویژگی کیفی مرتبط با کسب و کار نیز وجود دارد که بر شکل‌دهی معماری سیستم نرم‌افزاری اثر گذار است.

این ویژگی‌های کیفی شامل مواردی نظیر هزینه‌ها، زمان بندی، و ملاحظات مربوط به بازاریابی می‌باشد.

در [Bass 03] تعداد از ویژگی‌های کیفی کسب و کار به شرح زیر ارائه شده است : • زمان دستیابی به بازار : زمان مورد نیاز برای ارائه سیستم به بازار از عوامل تاثیر گذار بر معماری است.

به عنوان مثال برای سیستمی که باید به سرعت آماده ارائه به بازار شود، استفاده از بخش‌هایی هر سیستم‌های قبلی بسیار مهم است.

• هزینه و سود : باید برای انتخاب معماری مورد نظر برای هر سیستم نرم‌افزاری، تحلیل سود - هزینه انجام داد.

به عنوان مثال استفاده از معماری که قابلیت تغییر بالایی دارد، قطعاً هزینه بیشتری برای سازمان به همراه خواهد داشت.

بنابراین باید سود استفاده از هر معماری را در مقابل هزینه‌های آن بررسی نمود.

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

• بازار هدف : برای به دست گرفتن بازار و رقابت با دیگر محصولات باید ویژگی‌های کیفی نرم‌افزار را ارتقاء داد.

همچنین هر بازار، به یک ویژگی کیفی خاص توجه می‌کند.

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

• برنامه ارائه نرم‌افزار در فاز‌های متفاوت : در صورتی که نرم‌افزار باید در فاز‌های متفاوت و به صورت افزایشی توسعه داده شود، قابلیت تغییر و انعطاف معماری از اهمیت ویژه ای برخوردار است.

• یکپارچه سازی با سیستم‌های موجود : در صورتی که سیستم در حال توسعه می‌خواهد با سیستم‌های موروثی یکپارچه شود، باید مکانیزم‌های یکپارچه سازی در آن به کار برد.

ویژگی‌های کیفی معماری در [Bass 03] تعداد ویژگی کیفی ارائه شده که مرتبط با کیفیت کلی معماری نرم‌افزار می‌باشد.

این ویژگی‌ها عبارتند از : • یکپارچگی مفهومی : یکپارچگی مفهومی به معنای هماهنگ بودن و یکسان بودن روش‌ها به کاربرده شده در معماری نرم‌افزار می‌باشد.

به عنوان مثال سیستم نرم‌افزاری که برخی از بخش‌های آن با استفاده از تکنیک‌های شیء گرا و برخی دیگر از بخش‌های آن توسط تکنیک‌های غیرشیء گرا تولید شود، دارای یکپارچگی مفهومی نیست.

• صحیح بودن و کامل بودن : معماری نرم‌افزار باید کامل و صحیح باشد.

به این معنی که باید مدل‌های تولید شده از نظر نحوی و مفهومی دارای ویژگی‌های لازم باشند.

همچنین همه ساختار‌های لازم برای ارائه معماری کامل باشد.

یک طراحی معماری خوب باید دارای چه ویژگی‌هایی باشد؟‌ از نظر ما یک معماری خوب، معماری است که ویژگی‌های کیفی اشاره شده در فوق، در آنها برآورده شود.

باید توجه داشت که ویژگی‌های کیفی کسب و کار، در صورت برآورده شدن ویژگی‌های کیفی سیستم، برآورده خواهند شد.

همچنین بین برآورده شدن ویژگی‌های کیفی سیستم و ویژگی‌های کیفی معماری رابطه مستقیم برقرار است ولی دستیابی به ویژگی‌های کیفی سیستم به معنای دستیابی به ویژگی‌های کیفی معماری نمی‌باشد.

زیرا یک معماری می‌تواند ویژگی‌های کیفی سیستم نظیر کارایی، قابلیت تغییر و ...

را برآورده ساخته ولی از نظر مفهومی دارای یکپارچگی نباشد.

بنابراین معماری خوب، باید ویژگی‌های کیفی سیستم و معماری را برآورده نماید.

که در این بین پارامتر ویژگی‌های کیفی سیستم از اهمیت ویژه‌ای برخوردار است.

بنابراین برای طراحی معماری، یکی از ورودیهای ضروری ویژگیهای کیفی سیستم میباشد.

برای اندازه گیری میزان برآورده شدن ویژگیهای کیفی، تکنیکهای گوناگونی وجود دارد.

یکی از روشهای مرسوم، ارزیابی معماری نرم افزار میباشد.

همچنین در [Chastek 05] در مورد امکان معرفی تعدادی سنجه برای اندازه گیری ویژگیهای کیفی در معماری نرم افزار بحث شده است ولی هنوز سنجه دقیقی برای اندازه گیری معماری معرفی نشده است.

دستیابی به ویژگیهای کیفی برای دستیابی به ویژگیهای کیفی، روش ها و تکنیک گوناگونی وجود دارد.

دو تکنیک مطرح در این زمینه استفاده از تاکتیکها و الگوها (سبکها) معماری میباشد.

تاکتیکهای معماری برای دستیابی به ویژگی کیفی، باید تصمیماتی مربوط به نحوه طراحی معماری اتخاذ نمود.

به این تصمیمات پایه تاکتیک معماری نامیده میشوند.

در حقیقت تاکتیک یک تصمیم طراحی است که با اعمال آن بر روی معماری، میتوان پاسخ ویژگی کیفی را کنترل نمود و آن را به میزان مورد نظر تبدیل نمود [Bass03].

باید توجه داشت که تصمیمات معماری را میتوان به دو دسته تقسیم نمود.

برخی از تصمیمات طراحی برای دستیابی به کارکرد مورد نظر میباشد و برخی از تصمیمات برای کنترل پاسخ ویژگی کیفی.

در اینجا منظور از تاکتیک ها، مورد دوم میباشد.

به هر ویژگی کیفی میتوان تعدادی تاکتیک معماری نسبت داد و هنگام طراحی معماری با توجه به خاصیت تاکتیک مورد نظر از آن استفاده نمود.

به عنوان مثال برای ویژگی کیفی قابلیت تغییر و کارایی میتوان تاکتیکهای ارائه شده در شکل 3 و 4 را در نظر گرفت.

این تاکتیک ها با توجه به نوع کاربرد در سه دسته طبقه بندی شده اند.

شکل 3 – خلاصهای از تاکتیکهای قابلیت تغییر شکل 4 – خلاصهای از تاکتیکهای کارایی الگوهای معماری الگوهای معماری، یا سبکهای معماری دارای مفهومی مشابه با سبک های معماری در ساختمان میباشند.

به عنوان مثال در ساختمان سبکهای معماری نظیر : یونانی، ایتالیایی و ...

وجود دارد.

هر سبک معماری دارای یک یا چندین ویژگی کلیدی و قوانینی برای ترکیب آنها میباشد.

هر الگوی معماری با اجزای زیر تعریف میشود : مجموعه ای از اجزاء ( به عنوان مثال محل ذخیر سازی داده، اجزاء محاسباتی و ...

) توپولوژی ارتباطی اجزاء با یکدیگر شامل ارتباطها، پروتکل ارتباطی و ...

مجموعه ای از قیود منطقی ( به عنوان مثال در الگومعماری لوله و فیلتر لوله ها انتقال دهنده داده ها هستند و به طور افزایشی داده ورودی را به خروجی تبدیل میکنند.

همچنین جهت حرکت داده ها در لولهها نشان داده نمیشود.

) مجموعه ای از مکانیزمهای تبادل اطلاعات ( به عنوان مثال فراخوانی روتین، تخته سیاه و ...

) که مشخص کننده نحوه ایجاد هماهنگی بین اجزا در توپولوژی معرفی شده میباشد.

در [Shaw 96] مجموعه ای از مهمترین الگوها یا سبکهای معماری که میتواند در طراحی معماری نرم افزار سودمند باشد، معرفی شده است.

این مجموعه در شکل 5 نشان داده شده است.

شکل 5 - مجموعه ای از مهمترین الگوهای معماری ارتباط تاکتیکها و الگوهای معماری تاکتیک ها و الگوهای معماری دارای ارتباط مستقیمی با یکدیگر میباشند.

یک الگو یا سبک معماری، مجموعه ای از تاکتیک های مرتبط با یکدیگر را برای دستیابی به یک ویژگی خاص کنار هم جمع مینماید.

به عنوان مثال برای دستیابی به ویژگی کیفی در دسترس بودن، می توان از تاکتیک تکرار استفاده نمود.

اما باید توجه داشت استفاده از این تاکتیک به تنهایی کافی نمیباشد زیرا در صورت ارائه تکرار باید روشی برای همسان سازی نسخه های تکراری نیز معرفی نمود.

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

در [Bass 01] از الگوهای معماری به عنوان سازندههای ویژگیهای کیفی نام برده شده است.

باید توجه داشت که یکی از مسائل مرتبط با استفاده از الگوهای معماری این است که هر الگو علاوه بر تاثیرات مثبت بر ویژگیهای کیفی مورد نظر، ممکن است تاثیر منفی بر چند ویژگی کیفی داشته باشد.

با استفاده همزمان از این دو مفهوم میتوان به طراحی معماری نرمافزار پرداخت.

در بخش 4 روشهای گوناگونی برای طراحی معماری نرم افزار با استفاده از مفاهیم تاکتیکها و الگوها ارائه میگردد.

روشهای طراحی معماری نرم افزار در این بخش به بررسی روشهای طراحی معماری نرم افزار خواهیم پرداخت.

در این مرحله از فرایند تولید معماری سیستم فرض می شود که نیازهای سیستم به همراه ویژگی های کیفی مورد نظر تعیین شده اند و میخواهیم معماری سیستم را ایجاد کنیم.

برای این کار روشهای گوناگونی پیشنهاد شده است که در اینجا برخی از آنها را بررسی می کنیم.

طراحی مبتنی بر ویژگی طراحی مبتنی بر ویژگی [Bass 01]، به عنوان ورودی نیازهای سیستم (کارکردی و ویژگیهای کیفی) را دریافت کرده و خروجی آن طراحی منطقی (نه دقیق) معماری می باشد(شکل 6).

بنابراین این روش در فرایند توسعه سیستم میتواند پس از به دست آوردن نیازهای سیستم انجام شود.

شکل 6 – ورودیها و خروجیهای روش ADD در این روش طراحی معماری نرم افزار با طی مراحل زیر انجام می شود : 1 – یک عنصر طراحی برای تجزیه شدن انتخاب میشود.

این عنصر معمولاً در ابتدای فرایند طراحی، کل سیستم است.

در این حالت باید همه ورودیهای لازم برای انجام عمل طراحی (محدودیتها، نیازهای کارکردی و ویژگیهای کیفی) مشخص باشد.

2 – عنصر ایجاد شده با طی مراحل زیر پایش میشود : 2-1- ابتدا پیشبرندههای معماری از مجموعه سناریوهای ویژگیهای کیفی و نیازهای کارکردی انتخاب میشوند.

در حقیقت این مرحله مشخص میکند که برای انجام عمل تجزیه چه چیزی حائز اهمیت است.

2-2- الگوی معماری که برآورده کننده پیشبرندههای معماری مورد نظر است انتخاب میشوند.

این الگوها معمولاً با توجه به تاکتیکهای لازم برای برآورده کردن پیشبرنده مورد نظر، انتخاب یا ایجاد میشوند.

همچنین در این مرحله زیر ماژولهای لازم برای به کار بردن تاکتیکهای مورد نظر مشخص میشوند.

2-3- ماژولهای مورد نظر ایجاد شده و کارکردهای لازم برای هر ماژول با توجه به موارد کاربرد به آنها اختصاص داده میشوند.

2-4- برای زیر ماژولها، واسط هایی انتخاب میشود.

همچنین تجزیه انجام شده، محدودیتهایی را بر روی ارتباطات بین ماژولها ایجاد میکند.

این اطلاعات در این مرحله مستند میشوند.

2-5- در این مرحله زیر ماژولها با توجه به کارکردها و ویژگیهای کیفی مجدداً مورد بررسی قرار میگیرند تا اطمینان حاصل شود که برآورده کننده نیازهای مورد نظر میباشند.

3 – مراحل فوق را برای ماژولهای ایجاد شده تکرار نمایید.

طراحی به کمک سبک های معماری مبتنی بر ویژگی در روش طراحی مبتنی بر ویژگی، یک چارچوب کلی برای نحوه طراحی سیستم پیشنهاد گردید و در آن معماری نرم افزار به کمک عمل تجزیه و استفاده از الگوها یا سبکهای معماری طراحی گردید.

در طراحی به کمک سبکهای معماری مبتنی بر ویژگی، به جای استفاده از الگوها یا سبک های معماری، استفاده از مفهومی به نام سبکهای معماری مبتنی بر ویژگی [Klein 99] پیشنهاد شده است.

سبکهای معماری در حقیقت مجموعه ای از اجزاء و ارتباط دهنده ها بودند که کلاسهای طراحی را تشکیل میدادند.

این سبکها به همراه خود توصیفی غیر رسمی و غیر صریح از نقاط قوت و ضعف استفاده از سبک را نیز دارا بودند.

استفاده از این سبکها امکان استفاده از تجربیات گذشته را برای معماران نرمافزار فراهم میآورد.

در سبکهای معماری مبتنی بر ویژگی یا ABAS، هدف تبدیل سبک معماری به ابزاری است که بتوان به کمک آن در مورد طراحی انجام شده و کیفیت آن اظهار نظر نمود.

برای دستیابی به این هدف، در ABAS به هر سبک معماری یک چارچوب استدلال نسبت داده میشود که به کمک آن میتوان میزان در مورد طراحی مورد نظر استدلال انجام داد.

برای هر ویژگی کیفی میتوان یک چارچوب استدلال مبتنی بر مدلهای آن ویژگی کیفی اختصاص داد.

این مدلها عموماً برای هر ویژگی کیفی توسط متخصصین حوزه مربوطه ایجاد میشوند.

در ادامه به بررسی ساختار ABAS ها و نحوه استفاده از آنها میپردازیم.

در معرفی بخش های مختلف ABAS از یک ABAS به نام خط لوله همزمان استفاده میکنیم.

این ABAS نوعی از الگوی معماری لوله و فیلتر معرفی شده در [Shaw 96] می باشد که میتوان از آن در ساخت سیستمهای بلادرنگ استفاده نمود.

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

هر ABAS از چهار بخش زیر تشکیل میشود: توصیف مسئله : به طور غیر رسمی به توصیف مسئلهای که باید توسط ABAS حل شود شامل : ویژگی کیفی مورد نظر، حوزه مورد استفاده، محدودیت ها و نیازهای خاص مربوط به هر ویژگی کیفی میپردازد.