فرمت فایل:word
تعداد صفحات:90
چکیده
با گسترش روز افزون استفاده از مدلهای فرایند مبتنی بر معماری، طراحی معماری نرم افزار اهمیت ویژهای یافته است. یک طراحی معماری خوب، طراحی است که نیازهای کیفی مورد انتظار مشتری را برآورده نماید. در این گزارش روش های گوناگون طراحی معماری نرم افزار مورد بررسی قرار خواهد گرفت. سپس ویژگی کیفی قابلیت تغییر به طور دقیق و جزئیات معرفی خواهد شد و سپس معماری یک سیستم مطالعه موردی با دیدگاه دستیابی به قابلیت تغییر طراحی خواهد شد.
فهرست مطالب
2-1 تعاریف پایه در معماری نرم افزار. 6
الگوهای معماری یا سبکهای معماری.. 6
3-1 کارکرد‌های سیستم و معماری نرمافزار. 9
3-5 ویژگیهای کیفی کسب و کار. 11
3-6 ویژگیهای کیفی معماری.. 12
3-7 یک طراحی معماری خوب باید دارای چه ویژگی‌هایی باشد؟. 12
3-8 دستیابی به ویژگیهای کیفی. 12
ارتباط تاکتیکها و الگوهای معماری.. 15
4 روشهای طراحی معماری نرم افزار. 16
4-2 طراحی به کمک سبک های معماری مبتنی بر ویژگی 17
4-3 طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه. 19
5-2 مشخص نمودن نیازهای قابلیت تغییر با استفاده از سناریو‌های کیفی 23
5-3 مدل سازی قابلیت تغییر در سطح معماری نرم افزار 24
5-4 تاکتیکهای قابلیت تغییر. 24
5-5 تاکتیک‌هایی که تغییرات را محلی می‌کنند. 25
5-6 تاکتیک‌هایی که میدان دید وظایف را کاهش می دهند. 26
5-7 تاکتیک‌هایی که از پخش شدن تغییرات جلوگیری می‌کنند. 26
ارزیابی نحوه اختصاص وظایف.. 27
ارزیابی وابستگی بین ماژول‌ها 27
استفاده از روشهای بهینه سازی.. 30
5-9 تصمیم گیری نهایی در مورد طراحی ویژگی کیفی قابلیت تغییر. 30
6-1 مرحله 1 - انتخاب یک سناریو حقیقی. 31
6-2 مرحله 2 - بررسی نوع سناریو حقیقی 31
6-3 مرحله 3 - انتخاب چهارچوب استدلال مناسب.. 32
6-4 مرحله 4 - مشخص نمودن پارامترهای محدود و آزاد 34
6-5 مرحله 5 - مشخص کردن تاکتیکهای وابسته به پارامترهای آزاد 35
6-6 مرحله 6 - اختصاص مقادیر اولیه به پارامترهای آزاد 36
6-7 مرحله 7 - انتخاب تاکتیکها و به کاربردن آنها برای دستیابی به پاسخ مناسب 36
استفاده از کامپایلر به عنوان واسط. 38
استفاده از سیستم‌عامل به عنوان واسط. 38
6-8 مرحله 8 : اختصاص مسئولیت‌ها به عناصر معماری.. 38
فهرست مطالب
شکل 1 - ارتباط بین الگوی معماری، مدل مرجع و معماری مرجع. 7
شکل 2 - بخشهای تشکیل دهنده سناریو ویژگی کیفی. 11
شکل 3 – خلاصهای از تاکتیکهای قابلیت تغییر. 11
شکل 4 – خلاصهای از تاکتیکهای کارایی. 13
شکل 5 - مجموعه ای از مهمترین الگوهای معماری.. 14
شکل 6 – ورودیها و خروجیهای روش ADD.. 16
شکل 7 – الگوی معماری خط لوله همزمان. 18
جدول 1 – پارامترهای الگوی خط لوله همزمان. 18
جدول 2 – خروجی فاز اول روش CBAM... 20
شکل 8 - نمودار مقایسه میزان کاربرد هر راهبرد در مقابل هزینه. 20
شکل 9 - انواع نمودار‌های ممکن برای سودمندی براساس پاسخ. 21
جدول 3 - نحوه بازنمایی وابستگی بین دو ماژول. 29
شکل 11 - نمودار جریان داده ( تغییرات به طور غیر مستقیم از A به B منتقل میشود) 30
جدول 4- سناریو حقیقی قابلیت تغییر برای سیستم مورد مطالعه. 31
جدول 5 - سناریو عمومی قابلیت تغییر برای مسئله مورد بررسی. 32
شکل 12 - نمایش سیستم به صورت دو ماژول وابسته. 32
جدول 6 - چهارچوب استدلال برای ویژگی کیفی قابلیت تغییر. 33
شکل 13 - پارامترهای اثر گذار بر روی هزینه تغییرات.. 34
جدول 7 - پارامترهای قابلیت تغییر و تاکتیکهای اثر گذار بر روی آنها 35
جدول 8 - قانون‌هایی که نحوه استفاده از تاکتیکها را مشخص.... 36
شکل 14 - تکه طراحی تاکتیک شکستن زنجیره وابستگی. 38
شکل 15 - اختصاص وظایف با توجه به تاکتیکهای اعمال شده 39
- مقدمه
امروزه یکی از مهمترین ویژگیهای هر سیستم نرم‌افزاری، کیفیت میباشد. با پیشرفت‌های انجام شده و گسترش ابزار‌های گوناگون برای توسعه نرمافزار، توسعه نرم‌افزار‌هایی که کارکرد‌های مورد نظر مشتریان را برآورده سازند، امری آسان و سریع گشته است. در حال حاضر، تفاوت بین دو نرمافزار را توانایی نرم‌افزار‌ها در برآورده ساختن ویژگیهای کیفی مورد انتظار تعیین می‌کند.
معماری نرم افزارِ یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد[Bass 03] . معماری نرمافزار شامل اولین تصمیمات طراحی سیستم میباشد و این تصمیمات زیربنای فعالیت‌های طراحی، پیاده‌سازی، استقرار و نگهداری سیستم میباشد. همچنین معماری نرمافزار، اولین عنصر قابل ارزیابی در فرایند توسعه نرمافزار میباشد[Bass 03] . بنابراین برای طراحی سیستمی که نیازهای کیفی مورد نظر را برآورده سازد، تولید معماری نرمافزار اولین گام در دستیابی به کیفیت در نرمافزار و همچنین ارزیابی ویژگیهای کیفی است.
در مدلهای فرایند توسعه نرمافزار مبتنی بر معماری[1] معمولاً ابتدا نیازهای کیفی سیستم تعیین شده و سپس معماری نرمافزار مربوطه طراحی میگردد. پس از طراحی معماری، میتوان به ارزیابی آن پرداخت و تغییرات لازم را در طراحی مورد نظر ایجاد داد. بنابراین دو بخش اساسی در مدلهای فرایند توسعه نرمافزار مبتنی بر معماری، بخشهای طراحی و ارزیابی معماری نرم افزار میباشند. این دو بخش در ارتباط مستقیم با یکدیگر میباشند و هر یک مکمل دیگری میباشد. بنابراین فرایند طراحی معماری را میتوان شامل ساخت معماری نرمافزار، ارزیابی آن و اصلاح معماری پیشنهادی دانست.
در این گزارش، هدف بررسی روشهای موجود در طراحی معماری نرمافزار بر اساس ویژگیهای کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزارهایی برای این منظور میباشد. ادامه مطالب گزارش به این صورت طبقه بندی شده اند. در بخش 2 توضیح مختصری در ارتباط با معماری نرمافزار و مفاهیم مرتبط با آن ارائه میشود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش 3 طراحی معماری نرمافزار، ویژگیهای یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش 4 روشهای طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. در بخش 5 خلاصه و نتیجه گیری ارائه خواهد شد. در بخش 6 مراجع مورد استفاده در این گزارش معرفی میگردد.
- معماری نرم افزار چیست ؟
برای معماری نرمافزار، تعریفی که به طور عمومی پذیرفته شده باشد، وجود ندارد. افراد مختلف، معماری نرمافزار را به اشکال گوناگون تعریف کرده‌اند. این تعاریف، از لحاظ ظاهری متفاوتند ولی به مفهوم مشترکی اشاره می‌کنند.
در [Bass 03] معماری نرم افزار به صورت زیر تعریف شده است :
معماری نرم افزار یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد.
از تعریف فوق می توان به نتایج زیر دست یافت :
- معماری، اجزای نرم افزار را تعریف می نماید. همچنین در این تعریف، از جزئیاتی از اجزا، که در نحوه استفاده و ارتباط با اجزای دیگر کاربردی ندارند؛ صرف نظر می گردد.
- هر سیستم نرم افزار شامل چندین ساختار می باشد؛ و هیچ یک از این ساختارها، به تنهایی معماری نرم افزار نمیباشد. بلکه این ساختارها در کنار یکدیگر معماری نرم افزار را تشکیل می دهند.
- هر سیستم نرم افزاری دارای یک معماری می باشد. (زیرا هر سیستم نرم افزاری دارای اجزایی است که این اجزا با یکدیگر دارای رابطه می باشند).
- رفتار هریک از اجزاء، بخشی از معماری نرم افزار می باشد. (زیرا این رفتار در نحوه ارتباط بین اجزا تاثیرگذار است.)
- معماری نرم افزار باید قابل ارزیابی باشد تا بتوان از روی آن تشخیص داد سیستم مورد نظر بر پایه معماری انتخاب شده نیازهای خود را برآورده خواهد کرد یا خیر.
علاوه بر تعاریف ارائه شده در [Bass03] تعاریف گوناگون دیگری نیز برای معماری نرم افزار ارائه شده است که در اینجا به برخی از آنها اشاره خواهیم کرد :
در [IEEE00]معماری نرم افزار به صورت زیر تعریف شده است :
معماری نرمافزار، سازمان زیربنایی سیستم میباشد، که در قالب اجزا و روابط بین آنها و همچنین روابط آنها با محیط، بیان شده است و برای طراحی و تکامل آن اصولی وجود دارد.
در این نوع تعریف، فرایند تولید معماری، عضوی از معماری در نظر گرفته شده است. ( زیرا قوائد و اصول طراحی و تکامل نیز عضوی از معماری در نظر گرفته شده اند.) در حالی که این موارد جزء معماری محسوب نمی‌گردند. معماری هر سیستم نرم‌افزاری می‌تواند بدون توجه به نحوه تولید آن مشخص و ارزیابی گردد.
در [Booch 98] معماری نرم افزار مجموعه‌ای از تصمیمات مهم درباره ساختار سیستم نرم‌افزاری ، انتخاب اجزاء ساختاری و ارتباطات بین آنها و همچنین مشخص نمودن نحوه همکاری این اجزاء با یکدیگر میباشد. وقتی این اجزاء در کنار یکدیگر سیستم بزرگی را تشکیل دهند معماری نرم افزار به وجود خواهد آمد.
در [Garlan 93]، معماری نرمافزار سطحی از طراحی تعریف شده است که دارای ویژگیهای زیر میباشد :
- ورای الگوریتم و ساختمان داده طراحی شده باشد.
[1] Architecture Centric
تحقیق در مورد معماری نرم افزار