پروژه مفهوم معماری نرم افزار و مقایسه ای تحلیلی انواع آنها



موضوع : مفهوم معماری نرم افزار
و مقایسه ای تحلیلی انواع آنها

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

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

عنوان
شماره صفحه
چکیده Error! Bookmark not defined.
فهرست مطالب 4
فهرست جدول ها 10
فهرست شکل ها 11

مقدمه 14

فصل اول

مفهوم و دسته بندی معماری ها و جایگاه معماری نرم افزار در آن 20
1-1 مقدمه …20
1-2 تاریخچه معماری 20
1-3 مفهوم و تعریف معماری 21
1-4 چارچوبهای معماری 22
1-4-1 چارچوب معماری Zachman 22
1-4-2 چارچوب معماری FEAF ….23
1-4-3 چارچوب معماری C4ISR 23
1-5 چارچوب ها و متدولوژی ها 23
1-6 دسته بندی معماری ها 25
1-6-1 معماری سیستم، معماری نرم افزار 25
1-6-2 معماری سازمان 26
1-6-3 معماری کسب و کار 26
1-6-4 معماری اطلاعات 27
1-6-5 معماری سیستمهای کاربردی 27
1-6-6 معماری داده 28
1-6-7 معماری تکنولوژی 28
1-7 معماریهای دیگر 30

فصل دوم

مفهوم معماری نرم افزار و مقایسه ای تحلیلی بر تعاریف آنها 32
2-1 مقدمه 32
2-2 مفهوم معماری نرم افزار 32
2-3 تعاریف معماری نرم افزار 33
2-4 دلایل وجود تعاریف مختلف برای معماری نرم افزار 35
2-4-1 وجود دیدگاهها و رویکردهای متفاوت 35
2-4-2 کیفی بودن شناسه "سطح بالا بودن" در مفهوم معماری 36
2-4-3 تفاوت در کلمات مورد استفاده در تعاریف 36
2-5 ارائه جدول اجزاء تشکیل دهنده تعاریف 36
2-5-1 اجزاء معماری نرم افزار و منطق انتخاب اجزاء 37
2-5-2 ارتباط های بین اجزاء معماری نرم افزار 38
2-5-3 مجموعه اجزاء معماری نرم افزار و ارتباط بین آنها 39
2-6 تعریف و مقایسه پارمترهای متناظر در چارچوب 40
2-6-1 رابطه، ارتباط، تعامل، اتصال 41
2-6-2 اجزاء نرم افزاری، موئلفه، زیرسیستم 42
2-6-3 خصوصیت، واسط، رفتار 44
2-6-4 ساختار، سازماندهی، چارچوب 45

فصل سوم

مفهوم، تعریف و سنجش مشخصه های کیفی در معماری نرم افزار 47
3-1 مقدمه 47
3-2 مفهوم کیفیت نرم افزار و مشخصه های کیفی 47
3-3 تعریف کیفیت در نرم افزار و مشخصه های کیفی 49
3-4 Observable via Execution Error! Bookmark not defined.
3-5 Not Observable via Execution Error! Bookmark not defined.
3-6 معرفی برخی از صفات کیفی نرم افزار بر اساس دسته بندی [Bass 03] Error! Bookmark not defined.
3-7 صفات دسته اول: صفات کیفی سیستمی Error! Bookmark not defined.
3-7-1 Availability Error! Bookmark not defined.
3-7-2 Performance Error! Bookmark not defined.
3-7-3 Security Error! Bookmark not defined.
3-7-4 Functionality Error! Bookmark not defined.
3-7-5 Usability Error! Bookmark not defined.
3-7-6 Modifiability Error! Bookmark not defined.
3-7-7 Portability Error! Bookmark not defined.
3-7-8 Reusability Error! Bookmark not defined.
3-7-9 Integrability Error! Bookmark not defined.
3-7-10 Testability Error! Bookmark not defined.
3-8 صفات دسته دوم: صفات کیفی کسب و کار Error! Bookmark not defined.
3-8-1 Time to Market Error! Bookmark not defined.
3-8-2 Cost and benefit Error! Bookmark not defined.
3-8-3 Projected lifetime of the system Error! Bookmark not defined.
3-8-4 Targeted Market Error! Bookmark not defined.
3-8-5 Rollout schedule Error! Bookmark not defined.
3-8-6 Integration with legacy systems Error! Bookmark not defined.
3-9 صفات دسته سوم: صفات کیفی معماری Error! Bookmark not defined.
3-9-1 Conceptual Integration Error! Bookmark not defined.
3-9-2 Correctness and Completeness Error! Bookmark not defined.
3-9-3 Buildability Error! Bookmark not defined.
3-10 Trade-Off موجود بین صفات کیفی Error! Bookmark not defined.

فصل چهارم

سبک ها و الگوهای معماری نرم افزار و نحوه ارزیابی و انتخاب آنها 50
4-1 مقدمه و تاریخچه 50
4-2 تعریف سبک معماری 51
4-2-1 تعاریف مختلف سبک معماری نرم افزار 51
4-3 معرفی برخی سبک های متداول 51
4-3-1 سبک های متمرکز روی داده 52
4-3-2 سبک های جریان داده 53
4-3-3 سبک های ماشین مجازی 54
4-3-4 سبک های فراخوانی و بازگشت 55
4-3-5 سبک های موئلفه های مستقل 57
4-3-6 سبک های چند ریختی 58
4-4 الگوهای معماری نرم افزار 59
4-5 سازماندهی الگوها 59
4-5-1 الگوهای پیاده سازی 61
4-5-2 الگوهای طراحی 61
4-5-3 الگوهای معماری 61
4-6 الگوها و سبک ها 63
4-7 ارزیابی و انتخاب یک سبک معماری نرم افزار 63
4-7-1 پارامترهای ارزیابی سبکها 63
4-7-2 جدول ارزیابی سبکها 63
4-7-3 تکمیل جدول ارزیابی سبکها 64
4-7-4 ارائه الگوریتم استفاده از جدول 64
4-7-5 مشکلات موجود 66

فصل پنجم

طرح مشکل موجود، سوابق، راهکارها و کارهای انجام شده 68
5-1 مقدمه 68
5-2 طرح مشکل موجود در سبکهای معماری نرم افزار 68
5-3 دسته بندی های سبکهای معماری 70
5-3-1 دسته بندی های موضوعی Error! Bookmark not defined.
5-3-2 دسته بندی سبکهای معماری بر اساس [Clements 02-1] Error! Bookmark not defined.
5-3-3 دسته بندی های سیستمی Error! Bookmark not defined.

فصل ششم

ارائه یک استاندارد برای سازماندهی سبکهای معماری نرم افزار 71
6-1 مقدمه 71
6-2 ورودی و خروجی های یک استاندارد سازماندهی سبکها Error! Bookmark not defined.
6-3 بررسی جنبه های موجود برای ارائه یک استاندارد سازماندهی Error! Bookmark not defined.
6-3-1 دسته بندی های سیستمی Error! Bookmark not defined.
6-3-2 دسته بندی های موضوعی Error! Bookmark not defined.
6-3-3 روشهای ارزیابی سبکهای معماری نرم افزار Error! Bookmark not defined.
6-3-4 روشهایی استاندارد برای مستند کردن و جمع بندی سبکها Error! Bookmark not defined.
6-4 اجزاء استاندارد سازماندهی سبکها Error! Bookmark not defined.
6-4-1 دسته بندی پیشنهادی برای کلیه سبکهای معماری نرم افزار Error! Bookmark not defined.
6-4-2 کاتالوگ مستند سازی کلیه سبکهای معماری نرم افزار Error! Bookmark not defined.
6-5 معرفی فرایند ایجاد استاندارد سازماندهی سبکها Error! Bookmark not defined.
6-6 فاز اول: تهیه استانداردهای مورد نیاز Error! Bookmark not defined.
6-6-1 قدم اول: ارائه یک استاندارد برای دسته بندی انواع سیستم های نرم افزاری Error! Bookmark not defined.
6-6-2 قدم دوم: ارائه یک استاندارد برای دسته بندی انواع سبکهای معماری نرم افزار Error! Bookmark not defined.
6-6-3 قدم سوم: ارائه یک استاندارد برای مستند کردن هر سبک معماری نرم افزار Error! Bookmark not defined.
6-6-4 قدم چهارم: ارائه یک استاندارد برای دسته بندی انواع مشخصه های کیفی Error! Bookmark not defined.
6-7 فاز دوم: تهیه دسته بندی استاندارد و قالب استانداردِ کاتالوگ سبکها Error! Bookmark not defined.
6-7-1 قدم اول: ارائه یک قالب دسته بندی استاندارد برای سبکهای معماری نرم افزار Error! Bookmark not defined.
6-7-2 قدم دوم: ارائه یک قالب استاندارد برای کاتالوگ کلیه سبکهای معماری نرم افزار Error! Bookmark not defined.
6-8 فاز سوم: جمع آوری و مستند کردن سبکهای موجود و ارائه روشهای ارزیابی Error! Bookmark not defined.
6-8-1 قدم اول: اضافه کردن سبکهای دسته بندی های موضوعی به استاندارد Error! Bookmark not defined.
6-8-2 قدم دوم: اضافه کردن سبکهای دسته بندی های سیستمی به استاندارد Error! Bookmark not defined.
6-8-3 قدم سوم: تهیه یا ارائه مدل ارزیابی برای سبکهای هر نوع سبک/نوع سیستم Error! Bookmark not defined.
6-9 فاز چهارم: ارائه طرحهای کاربرد، توسعه و سازگاری استاندارد Error! Bookmark not defined.
6-9-1 قدم اول: ارائه طرح استانداردِ ارائه سبکهای جدید Error! Bookmark not defined.
6-9-2 قدم دوم: ارائه طرحها و قوانین توسعه استانداردهای موجود Error! Bookmark not defined.
6-10 جمع بندی کلی استاندارد ارائه شده Error! Bookmark not defined.

فصل هفتم

مدلسازی فرایندهای استاندارد ارائه شده، بر اساس UML 74
7-1 مقدمه 74
7-2 فرایند مدلسازی فرایند 74
7-3 مدل کردن منابع کسب وکار Error! Bookmark not defined.
7-4 مدل کردن اهداف کسب وکار Error! Bookmark not defined.
7-5 تعیین Actorهای کسب وکار Error! Bookmark not defined.
7-6 مدل جریانهای کاری موجود در استاندارد Error! Bookmark not defined.
7-7 جریانهای کاری فاز اول Error! Bookmark not defined.
7-7-1 فاز اول – قدم اول Error! Bookmark not defined.
7-7-2 فاز اول- قدم دوم Error! Bookmark not defined.
7-7-3 فاز اول – قدم سوم Error! Bookmark not defined.
7-7-4 فاز اول – قدم چهارم Error! Bookmark not defined.
7-8 جریانهای کاری فاز دوم Error! Bookmark not defined.
7-8-1 فاز دوم – قدم اول Error! Bookmark not defined.
7-8-2 فاز دوم – قدم دوم Error! Bookmark not defined.
7-9 جریانهای کاری فاز سوم Error! Bookmark not defined.
7-9-1 فاز سوم – قدم اول Error! Bookmark not defined.
7-9-2 فاز سوم – قدم دوم Error! Bookmark not defined.
7-9-3 فاز سوم – قدم سوم Error! Bookmark not defined.
7-10 جریانهای کاری فاز چهارم Error! Bookmark not defined.
7-10-1 فاز چهارم – قدم اول Error! Bookmark not defined.
7-10-2 فاز چهارم – قدم دوم Error! Bookmark not defined.
7-11 مدل خروجی های کسب وکار Error! Bookmark not defined.

فصل هشتم

خلاصه، نتیجه گیری و کارهای آینده 76
8-1 مقدمه 76
8-2 خلاصه و نتیجه گیری 76
8-3 کارهای آینده 77
8-4 در نهایت 79

منابع و مراجع 80

فهرست جدول ها

شماره جدول
شماره صفحه
جدول ‏1-1 : چارچوب های مهم معماری 23

جدول ‏2-1 : یک چارچوب برای تعاریف معماری نرم افزار 40
جدول ‏2-2 : پارامترهای متناظر در چارچوب 41

جدول ‏4-1: الگوهای معماری نرم افزار ارائه شده در [Buschmann 96] 62
جدول ‏4-2: یک مثال برای سبکها و اعداد مربوط به هر یک از مشخصه های کیفی آنها 65
جدول ‏4-3: مقادیر مشخصه های کیفی که کاربر درخواست نموده است. 66
جدول ‏4-4: مجموع قدر مطلق تفاضلات محاسبه شده برای هر سبک 66
جدول ‏4-5: مجموع مربعات تفاضلات محاسبه شده برای سبکهایی که مقدار SAD یکسانی دارند 66

جدول ‏5-1 : دسته بندی سبکهای معماری نرم افزار در [Shaw 96] Error! Bookmark not defined.
جدول ‏5-2 : دسته بندی [Fielding 00] Error! Bookmark not defined.
جدول ‏5-3 : دسته بندی سبکهای معماری نرم افزار بر اساس [Clements 02-1] Error! Bookmark not defined.
جدول ‏5-4 : دسته بندی [Buschmann 96] Error! Bookmark not defined.
جدول ‏5-5: سبکهای ارائه شده برای سیستمهای پردازش توزیع شده از [Morisawa 02] Error! Bookmark not defined.
جدول ‏5-6: سبکهای ارائه شده برای سیستمهای اطلاعاتی سازمان از [Kolp 01] Error! Bookmark not defined.
جدول ‏5-7: سبکهای ارائه شده در [Hawthorne 05] Error! Bookmark not defined.
جدول ‏5-8: سبکهای ارائه شده برای سیستمهای تجارت الکترونیک از [Widhani 02] Error! Bookmark not defined.
جدول ‏5-9: سبکهای ارائه شده برای سیستمهای مدیریت منابع از [Kircher 04] Error! Bookmark not defined.

جدول ‏6-1: انواع سیستمهایی که تاکنون برای آنها سبک معماری ارائه شده است. Error! Bookmark not defined.
جدول ‏6-2: استانداردی برای مستند کردن هر سبک بر اساس استاندارد [Clements 02-1] Error! Bookmark not defined.
جدول ‏6-3: عبارات اختصاری استفاده شده در جدول Error! Bookmark not defined.

فهرست شکل ها

شماره شکل
شماره صفحه
شکل ‏1-1: مفهوم معماری تدبیرات و نقشه های قبل از ساخت سیستمها است. ]ایزایران 81[ 21
شکل ‏1-2 : نحوه بیان متدولوژی ها با چارچوب ها ]ایزایران 81[ 24
شکل ‏1-3 : معماری سازمان و زیرمعماری های مربوطه از ]ایزایران 81[ 26

شکل ‏2-1 : مفهوم معماری نرم افزار، طراحی سطح بالا می باشد 33
شکل ‏2-2 : جزء معماری به ناظر و منظر معمار بستگی دارد 37
شکل ‏2-3 : R یک رابطه بیرونی و R1 یک رابطه درونی است 38
شکل ‏2-4: فرامدل پیشنهادی برای رابطه، ارتباط، تعامل، اتصال 42
شکل ‏2-5: فرامدل ارائه شده برای جزء، موئلفه، سیستم و… 43
شکل ‏2-6: فرامدل پیشنهادی برای رفتار، خصوصیت، واسط 45

شکل ‏3-1: فرامدل ارتباط مشخصه های کیفی با دیگر مفاهیم موجود در معماری از [Albin 03] Error! Bookmark not defined.
شکل ‏3-2: تاکتیک های ارائه شده برای دستیابی به حد مطلوب Availability در [Bass 03] Error! Bookmark not defined.
شکل ‏3-3: دسته بندی مشخصه های کیفی بر اساس [Bass 03] Error! Bookmark not defined.
شکل ‏3-4: Trade-Offهای موجود بین مشخصه های کیفی و حد مطلوب آنها از [Barbacci 95] Error! Bookmark not defined.
شکل ‏3-5: ارتباط صفات کیفی و وابستگی آنها به یکدیگر از [Fitzpatrik 96] Error! Bookmark not defined.

شکل ‏4-1: دسته بندی Garlan و Shaw برای سبک های معماری نرم افزار از [Shaw 96] 52
شکل ‏4-2 : مدل سبک های متمرکز روی داده از [Shaw 96] 53
شکل ‏4-3 : سبک Pipe and Filter از [Shaw 96] 54
شکل ‏4-4 : سبک برنامه اصلی و زیرروال از [Shaw 96] 55
شکل ‏4-5: سبک معماری Object Oriented از [Shaw 96] 56
شکل ‏4-6 : نمونه ای از سبک لایه ای مورد استفاده در استاندارد ارتباطی ISO از [Shaw 96] 57
شکل ‏4-7: مجموعه از الگوها از [Trowbridge 03] 60
شکل ‏4-8: نمایش روابط الگوها با خطوط از [Trowbridge 03] 60
شکل ‏4-9: سطوح انتزاع الگوها از ]زاداحمد 85[ 61
شکل ‏4-10: الگوی لایه ای از ]زاداحمد 85[ 62
شکل ‏4-11 : جدول ارزیابی سبکهای معماری نرم افزار بر اساس پارامترِ مشخصه های کیفی 64

شکل ‏5-1: قسمتی از دسته بندی سبکهای معماری نرم افزار از [Shaw 97] Error! Bookmark not defined.
شکل ‏5-2 : ارتباط بین نوعِ دید معماری، سبک معماری، دید معماری از [Clements 02-1] Error! Bookmark not defined.

شکل ‏6-1: ورودی و خروجی های سیستم استاندارد سازماندهی سبکهای معماری نرم افزار Error! Bookmark not defined.
شکل ‏6-2: جنبه هایی که باید برای ارائه استاندارد سازماندهی سبکها در نظر بگیریم. Error! Bookmark not defined.
شکل ‏6-3 : منظرها و ناظرهای هر سبک معماری نرم افزار Error! Bookmark not defined.
شکل ‏6-4: اجزاء اصلی استاندارد سازماندهی سبکهای معماری نرم افزار Error! Bookmark not defined.
شکل ‏6-5: دسته بندی اولیه برای سبک های معماری نرم افزار از [Ryoo 05] Error! Bookmark not defined.
شکل ‏6-6: یک دسته بندی قابل توسعه برای سبک های معماری نرم افزار از [Ryoo 05] Error! Bookmark not defined.
شکل ‏6-7: مدل کیفیت McCall از [Astudillo 04] Error! Bookmark not defined.
شکل ‏6-8: مدل کیفیت ISO/9126 از [Astudillo 04] Error! Bookmark not defined.
شکل ‏6-9: نمونه یک دسته بندی انواع سیستمها برای سیستمهای اطلاعاتی Error! Bookmark not defined.
شکل ‏6-10: قالب دسته بندی پیشنهادی برای سیستمهای اطلاعاتی Error! Bookmark not defined.
شکل ‏6-11: فرایند ارائه قالب استاندارد برای تهیه کاتالوگ سبکها Error! Bookmark not defined.
شکل ‏6-12: فرایند ایجاد یک استاندارد برای سازماندهی سبکهای معماری نرم افزار 73

شکل ‏7-1: منابع کسب وکار مورد استفاده در کل فرایند Error! Bookmark not defined.
شکل ‏7-2: سلسله مراتب اهداف در فرایند معرفی شده Error! Bookmark not defined.
شکل ‏7-3: Actorهای کسب وکار موجود در فرایند ارائه شده Error! Bookmark not defined.
شکل ‏7-4: فازهای فرایند ارائه استاندارد Error! Bookmark not defined.
شکل ‏7-5: مدل قدمهای ارائه شده برای فاز اول Error! Bookmark not defined.
شکل ‏7-6: مدل فرایند ارائه شده برای قدم اول از فاز اول Error! Bookmark not defined.
شکل ‏7-7: مدل فرایند ارائه شده برای قدم دوم از فاز اول Error! Bookmark not defined.
شکل ‏7-8: مدل فرایند ارائه شده برای قدم سوم از فاز اول Error! Bookmark not defined.
شکل ‏7-9: مدل فرایند ارائه شده برای قدم چهارم از فاز اول Error! Bookmark not defined.
شکل ‏7-10: مدل قدمهای ارائه شده برای فاز دوم Error! Bookmark not defined.
شکل ‏7-11: مدل فرایند ارائه شده برای قدم اول از فاز دوم Error! Bookmark not defined.
شکل ‏7-12: مدل فرایند ارائه شده برای قدم دوم از فاز دوم Error! Bookmark not defined.
شکل ‏7-13: مدل قدمهای ارائه شده برای فاز سوم Error! Bookmark not defined.
شکل ‏7-14: مدل فرایند ارائه شده برای قدم اول از فاز سوم Error! Bookmark not defined.
شکل ‏7-15: مدل فرایند ارائه شده برای قدم دوم از فاز سوم Error! Bookmark not defined.
شکل ‏7-16: مدل فرایند ارائه شده برای قدم سوم از فاز سوم Error! Bookmark not defined.
شکل ‏7-17: مدل قدمهای ارائه شده برای فاز چهارم Error! Bookmark not defined.
شکل ‏7-18: مدل فرایند ارائه شده برای قدم اول از فاز چهارم Error! Bookmark not defined.
شکل ‏7-19: مدل فرایند ارائه شده برای قدم دوم از فاز چهارم Error! Bookmark not defined.
شکل ‏7-20: خروجی های هر یک از مراحل که منجر به استاندارد نهایی خواهد شد. Error! Bookmark not defined.

مقدمه

پیشرفت و بزرگتر شدن جامعه بشری در دنیای امروزی و پیچیده تر شدن روابط بین آنها، باعث بوجود آمدن سیستمهای بزرگ و پیچیده در زندگی بشر امروزی شده است. با پیشرفت علم کامپیوتر و وارد شدن آن به بطن زندگی بشر، اکثر سیستمهایی که بشر امروزی با آنها سروکار دارد، به صورت کامپیوتری پیاده سازی می شوند.
زندگی بشر امروزی وابسته به سیستمهای نرم افزاری بزرگ و پیچیده موجود می باشد. سیستمهای شرکتهای هواپیمایی و مسافربری، سیستمهای ارتباطی توزیع شده همانند تلویزیون، تلفنهای معمولی و همراه، سیستمهای بانکداری، سیستمهای مدیریت بورس، سیستمهای عمل جراحی راه دور، سیستمهای کنترل ماهواره های مختلف، سیستمهای معاملات راه دور و هزاران سیستم نرم افزاری دیگر که وجود خلل و نقصی در آنها تاثیرات جبران ناپذیری بر زندگی بشر امروزی خواهد داشت.
در نتیجه یکی از نیازهای حیاتی بشر امروزی اینست که سیستمهای بزرگ و پیچیده موجود، بدون خطا، سریع، با امنیت و کارایی بالا و… در اختیار آنها گیرد. در نتیجه توسعه دهندگان سیستمهای نرم افزاری بزرگ و پیچیده، باید سیستمهایی با چنین ویژگیهایی، در اختیار کاربران قرار دهند.
در نتیجه ارائه سیستمهایی در مقیاس بزرگ که دارای برخی ویژگی ها همچون کارایی بالا، بدون خطا و بدون عیب، سریع و امن و…، نیاز توسعه دهندگان سیستمهای نرم افزاری مقیاس بزرگ می باشد. به این مشخصه ها در حوزه مهندسی نرم افزار نیازهای غیرعملیاتی یا مشخصه های کیفی می گویند.
مهمترین مسئله در توسعه سیستمهای نرم افزاری مقیاس بزرگ، مبحث معماری آن می باشد. معماری، ساختارهای موئلفه ها و زیرسیستمهای یک سیستم مقیاس بزرگ و ارتباط بین آنها می باشد. معماری نرم افزار، یکی از مهمترین حوزه ها در مهندسی نرم افزار است و دلیل آن تاثیر حیاتی معماری در موفقیتِ توسعه سیستمهای نرم افزاری است.
توسعه یک سیستم نرم افزاری مقیاس بزرگ با ویژگی های مذکور، نیازمند ارائه یک معماری مناسب و کامل برای سیستم نرم افزاری مورد نظر می باشد. در نتیجه ارائه یک معماری درست و مناسب برای چنین سیستمهایی از اهمیت حیاتی برخوردار است.
همیشه بشر از تجربیات قبلی خود یا دیگران در انجام کارهای فعلی بهره جسته است. در زمینه معماری نرم افزار نیز معماران نرم افزار برای ارائه یک معماری مناسب می توانند از تجربیات معماران گذشته و ماهر برای ارائه معماری خود بهره گیرند. امروزه برای سیستمهای گوناگون، معماریهای مختلفی توسط معماران ماهر ارائه شده است. این معماریها به کررات در سیستمهای مختلف مورد آزمایش قرار گرفته و اعتبار و صحت آنها برای استفاده در برخی از سیستمهای نرم افزاری اثبات شده است. به این معماری ها، الگوها یا سبکهای معماری نرم افزار می گویند.
در نتیجه یک معمار نرم افزار برای ارائه یک معماری مناسب، باید به سبکهای معماری موجود در حوزه سیستمی خود آشنایی داشته باشد تا بتواند از آنها برای ارائه یک معماری مناسب استفاده کند. یعنی معمار یک سیستم نرم افزاری برای ارائه یک معماری برای یک سیستم، باید تسلط کافی بر سبکهای معماری نرم افزار و مزایا، معایب و کاربردهای هر یک از آنها داشته باشد.
سبکهای معماری نرم افزار همه روزه توسط افراد و گروههای مختلف ارائه می شوند و هر گروه در حوزه سیستمی خود، به معرفی سبکهای جدید معماری نرم افزار می پردازد. درنتیجه یک معمار نرم افزار برای آشنایی به سبکهای معماری مربوط به حوزه خود، باید در یک دوره تناوب خاص مثلاً هر ماه، سبکهای معماری جدید را جمع آوری، بررسی و تحلیل کند. تا بتواند یک معماری درست و مناسب برای سیستم مورد نظر خود ارائه کند.
از طرفی با وجود سبکهای معماری مختلف برای حوزه های موجود، ممکن است برای یک کاربرد خاص، سبکهای زیادی پیشنهاد شده باشد. در برخی موارد ارائه کنندگان سبکها، روشهایی برای انتخاب یک سبک از بین سبکهای مختلف که توسط خودشان معرفی شده، ارائه می کنند. ولی همیشه این طور نیست و برای سبکهای مختلف که توسط افراد مختلف برای یک حوزه خاص ارائه شده است، روشی برای انتخاب یک سبک وجود ندارد.
از طرفی دیگر، همه روزه بر تعداد سبکهای معماری نرم افزار افزوده می شود و تعداد آنها در حال افزایش می باشد و هیچ کنترل مرکزی و واحد بر آنها وجود ندارد. این امر معماران سیستمهای نرم افزاری را در شناخت و استفاده از سبکها، دچار مشکل می کند یعنی با انباشته شدن سبکهای معماری نرم افزار، کار معماران نرم افزار در انتخاب یک سبک، خیلی مشکل خواهد شد.
در نتیجه می توان مشکلات موجود برای ارائه یک معماری را به صورت زیر بیان کرد:
1- با افزایش روز افزون سبکهای معماری نرم افزار، هیچ کنترل مرکزی و واحد برای آنها وجود ندارد. و در ارائه سبکهای نوعی پراکندگی وجود دارد.
2- برای سبکهای ارائه شده توسط گروههای مختلف، روشهای انتخاب و ارزیابی واحدی وجود ندارد.
3- برای ارائه یک سبک معماری نرم افزار به صورت یک مستند، روشی استاندارد وجود ندارد که همه از این استاندارد تبعیت کنند.
4- عدم وجود یک سری از مشخصه های کیفی استاندارد که همه ارائه کنندگان سبکها از آنها برای ارائه روشهای ارزیابی خود استفاده کنند.
5- به دلیل وجود سبکهای مختلف، یک معمار نرم افزار در انتخاب یک سبک معماری دچار سردرگمی خواهد شد.
و دهها مشکل دیگر که با ارائه روز افزون سبکهای معماری نرم افزار به صورت پراکنده و عدم کنترل مرکزی، معماران نرم افزار در استفاده از سبکهای معماری، امروزه و در آینده به آن دچار خواهند شد.
برای حل مشکلات ذکر شده تلاشهایی توسط گروههای مختلف انجام گرفته است و مبحث دسته بندی سبکهای معماری بوجود آمده است. برای دسته بندی سبکهای معماری نرم افزار روشهای مختلفی تاکنون ارائه شده است. دسته ای از روشها، سبکهای معماری نرم افزار را بر اساس نوع سبک آنها دسته بندی می کنند. یعنی ابتدا یک دسته بندی از انواع سبکهای معماری ارائه کرده سپس سبکهای معماری را در این دسته بندی قرار می دهند. ما به این نوع دسته بندی ها، دسته بندی موضوعی می گوییم. برخی دیگر، سبکها را بر اساس نوع سیستم مورد کاربرد آن سبک، دسته بندی می کنند. یعنی ابتدا یک دسته بندی از انواع سیستمهای نرم افزاری ارائه کرده، سپس سبکهای معماری را در این دسته بندی قرار می دهند. ما به این نوع دسته بندی، دسته بندی سیستمی می گوییم. سوالی که در این زمینه مطرح می شوند، اینست که آیا این روشها، مشکلات موجود را حل می کنند. یعنی با دسته بندی سبکها می توان مشکل معماران و پراکندگی سبکهای ارائه شده را حل کرد.
آنچه مسلم است، صرف دسته بندی سبکها به روش موضوعی یا سیستمی مشکلات موجود به طور کامل رفع نخواهد شد. به عنوان مثال مشکلاتی مانند ارائه پراکنده سبکها بدون کنترل مرکزی، عدم مستند سازی استاندارد سبکها، عدم وجود نحوه ارزیابی و انتخاب سبکهای همنوع و… هنوز پا برجا هستند.
در نتیجه عوامل دیگری نیز باید در این دسته بندی ها لحاظ گردند. به عنوان مثال نحوه ارزیابی سبکها که باید برای تمامی سبکها، روشهای ارزیابی با سبکهای همنوع خود ارائه شود یا روشی استاندارد برای مستند کردن سبکها در این دسته بندی ها وجود داشته باشد.
در نتیجه برای رفع مشکلات موجود، نیاز به یک استاندارد سازماندهی برای کلیه سبکها داریم که بر اساس این استاندارد بتوانیم کلیه سبکهای موجود و سبکهایی را که در آینده ارائه خواهد شد، سازماندهی کنیم. درنتیجه اگر توسعه چنین استانداردی را به عنوان یک سیستم در نظر بگیریم، می توانیم از روشهای توسعه سیستمها همانند مدلهای موازی یا فازبندی شده مثل RUP1، برای توسعه و تکمیل این استاندارد استفاده کنیم.
برای توسعه چنین استانداری می توان مراحل زیر را بر اساس متدولوژی RUP جنین تعریف کرد.
1- فاز اول – شناخت (Inception): در این فاز به بررسی و شناخت مسئله موجود پرداخته و کلیه مفاهیم مورد نیاز برای آن را مورد بررسی قرار می دهیم. به طوری که دید درستی از مسئله و آنچه می خواهد داشته باشیم. در حقیقت مسئله مورد نظر، تعریف و مورد بررسی قرار می گیرد و مفاهیم مورد استفاده در مسئله شناخته می شوند.
با توجه به مسئله مورد نظر که توسعه یک استاندارد برای سازماندهی سبکهای معماری نرم افزار می باشد، در این فاز باید کلیه مفاهیم مورد نیاز برای توسعه این استاندارد شناخته شود. مفاهیمی که باید شناخته شود، به صورت زیر خواهد بود.
1-1- بررسی مفهوم معماری و دسته بندی های آن: در این مرحله به بررسی مفهوم معماری در حالت کلی پرداخته و بعد از آشنایی با مفهوم آن به بررسی انواع معماری های موجود می پردازیم. در ادامه جایگاه معماری نرم افزار در این دسته بندی را مشخص می نماییم.
1-2- بررسی مفهوم و تعریف معماری نرم افزار: در این مرحله به بررسی مفهوم معماری نرم افزار می پردازیم و با اشاره به تعریف معماری نرم افزار، سعی می کنیم درکی واضح و بدون ابهام از معماری داشته باشیم.
1-3- بررسی مشخصه های کیفی در معماری نرم افزار: با توجه به اهمیت مشخصه های کیفی در معماری نرم افزار و اینکه هدف اصلی معماری، دستیابی به میزان مطلوبی از این مشخصه ها است، در نتیجه باید مفهوم، تعریف و نحوه اندازه گیری هر یک از مشخصه های کیفی مورد بررسی قرار گیرد.
1-4- بررسی سبکها و الگوهای معماری نرم افزار: با توجه به مسئله مورد بررسی که توسعه یک استاندارد برای سازماندهی سبکهای معماری نرم افزار می باشد، باید مفهوم و تعریف سبک معماری مورد بررسی قرار گرفته و برای آشنایی بیشتر با آنها، برخی از سبکهای معماری نرم افزار را مطالعه و مورد بررسی قرار دهیم.
2- فاز دوم – تکوین (Elaboration): در این فاز باید نیازمندیهای سیستم مورد نظر به صورت کامل شناخته شده و مورد تحلیل قرار گیرند. برای تحلیل نیازمندیها ابتدا باید فرایندهای توسعه سیستم را پیدا یا معرفی کرده سپس آنها را به موردهای کاربرد شکسته و با معرفی سناریو برای هر یک از آنها، گروههای کاری تشکیل شده و موردهای کاربرد را مورد تحلیل قرار دهند.
برای سیستم مورد نظر یعنی ارائه یک استاندارد برای سازماندهی سبکهای معماری نرم افزار مراحل زیر را پیشنهاد می دهیم.
2-1- تحلیل نیازمندی های مسئله: در این مرحله بر اساس شناختی که در فاز قبل از مفاهیم مرتبط با موضوع بدست آمده است، نیازمندیهای مورد نیاز مسئله مطرح می شود. در این مرحله روشهای قبلی نیز مورد بررسی قرار خواهد گرفت و بر اساس روشهای قبل، ایده ای برای توسعه این سیستم ارائه می شود.
2-2- بدست آوردن فرایندهای مورد نیاز سیستم: در این مرحله باید فرایندهای مورد نیاز برای توسعه سیستم و سازماندهی مذکور ارائه شود. هر یک از فرایندها تفضیل شده و برای هر یک پیشنهاداتی ارائه شود.
2-3- تفضیل فرایندهای ارائه شده: در این برای هر یک از فرایندهای موجود باید روش توسعه آنها ارائه شود. برای هر فرایند دو حالت وجود دارد. اول اینکه این فرایند قبلاً توسط گروههای دیگر مورد بررسی و تحلیل قرار گرفته و پیاده سازی شده است. دوم اینکه برای فرایند، کارهای قبلی یا وجود ندارد و یا اینکه ناقص بوده و پیاده سازی مطلوب ما انجام نشده است. که باید روشی جدید برای توسعه فرایند ارائه شود.
3- فاز سوم – ساخت (Construction): در این مرحله بر اساس فرایندها و موردهای کاربرد بوجود آمده، باید بر اساس مدیریت انجام شده و تقسیم کار بین گروههای کاری مختلف، هر فرایند توسعه یابد و پیاده سازی گردد. مراحل این فاز بر اساس فرایندهای بدست آمده از فاز قبل تنظیم خواهد شد. در این مرحله می توان از تکنیکهای موازی سازی عملیات، تکرار عملیات و… استفاده کرد.
4- فاز چهارم – انتقال (Transition): در این مرحله با اتمام توسعه سیستم، باید سیستم مورد نظر به سیستم واقعی موجود انتقال یابد. برای این فاز مراحل زیر را پیشنهاد می کنیم:
4-1- تشکیل سازمان استانداردسازی سبکها: باید برای پیاده سازی واقعی استاندارد سازماندهی بدست آمده، یک سازمان تشکیل گردد و با معرفی استاندارد مذکور، باعث گردد سبکهای معماری نرم افزار از این به بعد در قالب استاندارد این سازمان ارائه گردد.
4-2- معرفی روشهای نگهداری و توسعه استاندارد: در این مرحله باید روشهایی برای نگهداری و توسعه استاندارد ارائه شده معرفی گردد که با اضافه شدن سبکهای مختلف به آن سازگاری استاندارد حفظ شود.
4-3- معرفی روشهای استفاده از استاندارد: در این مرحله باید روشهای استفاده از استاندارد شامل استفاده از سبکهای موجود در استاندارد و نحوه اضافه کردن سبکها به آن معرفی شود.

در این پایان نامه فازهای اول و دوم یعنی شناخت و تکوین از مراحل توسعه استاندارد سازماندهی سبکهای معماری نرم افزار، انجام گرفته است. فصلهای پایان نامه نیز بر همین اساس طرح ریزی شده اند.
برای انجام هر مرحله از فاز اول، یک فصل در نظر گرفته شده است.
در فصل اول به بررسی مفهوم معماری و دسته بندی آنها پرداخته ایم.
در فصل دوم به بررسی مفهوم معماری نرم افزار پرداخته و کلیه مفاهیم موجود در حوزه معماری نرم افزار را تعریف کرده و تحلیلی بر تعاریف موجود معماری نرم افزار آورده ایم.
در فصل سوم به بررسی برخی از مشخصه های کیفی مهم موجود در معماری نرم افزار پرداخته و مفهوم، تعریف و نحوه سنجش آنها را مورد بررسی قرار داده ایم.
در فصل چهارم به بررسی سبکهای معماری نرم افزار پرداخته و برخی از سبکهای مهم موجود را بررسی کرده و مشخصه های کیفی هر سبک را تشریح کرده ایم. در ادامه همین فصل به بررسی الگوهای نرم افزار و بخصوص الگوهای معماری پرداخته و ارتباط آن را با سبکهای معماری نرم افزار ذکر کرده ایم.
فصلهای بعدی برای انجام فاز دوم ارائه شده است.
در فصل پنجم به بررسی انواع دسته بندی های سبکهای معماری نرم افزار پرداخته و کارهای انجام شده قبلی در این رابطه را ارائه نموده ایم.
در فصل ششم فرایند پیشنهادی خود را برای توسعه این استاندارد ارائه کرده ایم. سپس تک تک مراحل فرایند ارائه شده را تشریح کرده و برای هر یک، کارهای انجام شده قبلی را آورده و برای برخی نیز روشهایی جدید ارائه نموده ایم.
در فصل هفتم فرایند ارائه شده را با استفاده از UML مدل کرده و فرایند پیشنهادی را در قالب دیاگرامهای UML ارائه نمودیم. برای مدل کردن فرایندها از روش Eriksson و Penker که جدیدترین روش مدل کردن فرایندها در UML است استفاده کردیم و دیاگرامها را در نرم افزار شرکت Sparx بنام Enterprise Architect 6.1 کشیده و در این فصل آورده ایم.
در فصل آخر نیز بعد از بیان خلاصه ای از کل پایان نامه و نتیجه گیریهای انجام شده، کارهای آینده که در ادامه این پایان نامه می توان انجام داد، به عنوان کارهای آینده ذکر نموده ایم.

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

1-1 مقدمه
در این فصل مفهوم معماری، تاریخچه معماری، اصطلاحات و تعاریف بنیادی مورد نیاز در این شاخه را مورد بررسی قرار می دهیم. سپس اشاره ای مختصر به چارچوبهای معماری نرم افزار خواهیم داشت. بعد دسته بندی های معماری را از جهات مختلف بررسی کرده و جایگاه معماری نرم افزار را در این دسته بندی مشخص می کنیم. خواننده آشنا به اصول معماری می تواند از این فصل صرف نظر نماید.
1-2 تاریخچه معماری
معماری دارای ریشه لاتین "APXITEKTΩN" به معنای "استادی در ساختن" می باشد ]امربر 82[. در لغت نامه Cambridge، معماری به معنای "هنر و استادی در طراحی و ساخت" و "سبک طراحی و ایجاد" است.
شاید اولین جایی که بشریت از معماری استفاده کرده است به زمانهای ساخت ساختمانهای بزرگ برمی گردد. مفهوم معماری به طور حتم از زمانهای قدیم در ذهن بشریت بوده و از آن استفاده می کرده است. به طورحتم، ساختن بناهای عظیم، بدون تفکر معماری امکان پذیر نبوده است. اگر بناهایی مثل اهرام مصر یا تخت جمشید را بررسی کنیم، به این نتیجه می رسیم که ساخت چنین بناهایی بدون نقشه اولیه و تدبیرات قبل از ساخت، امکان پذیر نبوده است و این همان مفهوم معماری است.
اکثراً برای عدم وجود معماری در منابع مختلف، عمارت وینچستر را مثال می زنند، عمارتی بزرگ و عظیم، ولی بدون معماری. به عنوان مثال، از مجموع 1417 درِ آن، 950 در، بجایی باز نمی شود ]ایزایران 81[. پس بدون معماری می توان عمارات و ساختمانها یا هر چیزی در مقیاس بزرگ ساخت. ولی در این حالت نیازمندی های واقعی ذی نفعان1 برآورده نمی شود و بعد از ساخت، هزاران مشکل دیگر پدیدار می گردد.

شکل ‏1-1: مفهوم معماری تدبیرات و نقشه های قبل از ساخت سیستمها است. ]ایزایران 81[
1-3 مفهوم و تعریف معماری
در [Klir 91] سیستم، مجموعه ای از اجزاء2 مرتبط تعریف می شود. دو جزء و یک رابطه بین آنها، تشکیل یک سیستم می دهند. برای ایجاد یک سیستم، ابتدا باید آنرا شناخت و تحلیل کرد. تعریف تحلیل، تعیین سطح مند3 اجزاء و روابط بین آنها می باشد. بعد از تحلیل هر سیستم، برای ایجاد سیستم، اجزاء و روابط بدست آمده از تحلیل را باهم ترکیب می کنند تا سیستم مورد نظر ایجاد شود. به ترکیب اجزاء بدست آمده از تحلیل برای ایجاد سیستم جدید، طراحی می گویند [Klir 91].
با گذشت زمان سیستمها در حال بزرگ شدن هستند. در نتیجه سیستمها و طراحی آنها به یک عامل پیچیده تبدیل شده است. تعریف ساده پیچیدگی در [Klir 91]، تعداد و تنوع اجزاء و روابط بین آنها می باشد. در نظریه سیستمی4، روشهای مختلفی برای غلبه بر پیچیدگی ها وجود دارد. یکی از روشهای غلبه بر پیچیدگی، سطح مند کردن اجزاء و روابط می باشد؛ به طوریکه بتوان از جزئیات دوری کرد. یعنی بتوان طراحی این سیستمها را به دو سطح، طراحی سطح بالا و طراحی با جزئیات شکست.
بنابراین به ایده بزرگی بنام "معماری" می رسیم. در [IEEE 1471-00] معماری سیستم، "بالاترین مفهوم از طراحی یک سیستم" معنا می شود. مفهوم معماری، یک راه حل برای غلبه بر پیچیدگی طراحی سیستمها می باشد. اگر یک ساختمان را یک سیستم در نظر بگیریم، معماری آن می تواند نقشه اولیه ساختمان روی کاغذ باشد. یا اگر سیستم را یک سد در نظر بگیریم، یک ماکت اولیه از آن سد می تواند معماری آن باشد. در حالت کلی در معماری از جزئیات فاصله گرفته و سعی می کنیم به یک مفهوم بالاتری از سیستم برسیم.
ساختار، نمایش و چیدمانی منطقی از اجزاء و روابط بین آنها می باشد [Klir 91]. در حقیقت معماری سیستم، ساختار یا ساختارهای سطح بالا، در طراحی یک سیستم می باشد. در [IEEE 1471-00] معماری را اینگونه تعریف می کند: معماری، ساختارِ موئلفه ها، ارتباط بین آنها و اصول و قواعد حاکم بر طراحی و تکامل آنها در گذر زمان می باشد.
1-4 چارچوبهای معماری5
چارچوب های معماری، روشهایی برای فکر کردن سازماندهی شده درباره سیستمهای پیچیده ارائه می کنند. چارچوب های معماری از این حقیقت منشاء گرفته اند که هر سیستم از دیدگاه مهندسی دارای جنبه های گوناگونی است.
بعنوان مثال اگر یک ساختمان را در نظر بگیریم، کاربری، توزیع فضا، نحوه ارتباط فضاهای مختلف، نمای بیرونی، اسکلت بندی، معماری داخلی، نقشه تاسیسات و… جنبه های مختلفی هستند که یک معمار ساختمان می تواند به آنها توجه نماید. در سیستمهای اطلاعاتی می توانیم به اجزاء سیستم، نحوه انجام فرایندها، نحوه توزیع اجزاء، کاربران، ترتیب انجام کارها و غیره اشاره نمائیم.
بعبارت دیگر، معمار سیستمهای اطلاعاتی برای حل یا تشریح راه حل مسئله می تواند به سوالاتی نظیر، سیستم از چه چیزهائی تشکیل شده است؟ نحوه کار سیستم چگونه است؟ اجزاء تشکیل دهنده سیستم باید در کجا نصب شوند؟ ترتیب زمانی انجام کارها چگونه است؟ و دلیل و هدف از انجام فعالیتها چیست و… توجه نماید. همانطور که مشاهده می کنید، در سوالات فوق به شش جنبه اصلی چه چیز، چگونه، کجا، چه کسی، کی و چرا توجه شده است که می توان گفت نگرشی جامع را فراهم می سازند.
از طرف دیگر، نگرش معمار به سیستم می تواند بُعد دیگری نیز داشته باشد و آن اینکه سوالات فوق از چه کسانی پرسیده شده یا از منظر چه کسانی پاسخ داده شود. هر یک از منظرهای مختلف، پاسخهای مختلفی خواهند داشت. بعنوان مثال در مورد یک ساختمان، صاحب ساختمان، طراح ساختمان و مهندسی که برای ساخت آن در نظر گرفته شده است، دیدگاههای مختلفی خواهند داشت. این موضوع در مورد سیستمهای اطلاعاتی نیز صدق می کند. پاسخ افرادی نظیر صاحب سیستم، طراح سیستم، سازنده سیستم و… با هم متفاوت خواهند بود.
برای معماری سیستمهای اطلاعاتی یا معماری سازمان، چارچوبهای مختلفی ارائه شده است که به برخی از آنها به صورت گذرا اشاره می کنیم.
1-4-1 چارچوب معماری Zachman
مدل Zachman عبارتست از مجموعه تمام توصیفات ممکن از یک شی پیچیده که به منظور تعریف کامل آن بکارگرفته می شوند. چارچوب زکمن، چارچوبی است متشکل از اجزاء مختلف که از طریق دیاگرام ها و مستندات استاندارد، به توصیف کامل سیستم نائل می شود. این چارچوب دارای دیدگاهها و سطوح چکیده سازی مختلفی است که مطابق با سطوح مختلف سازمانی و فرایندهای توسعه سیستمهای اطلاعاتی ایجاد شده اند.
1-4-2 چارچوب معماری FEAF
چارچوب معماریFEAF توسط شورای مدیران ارشد اطلاعاتی دولت فدرال ایالات متحده آمریکا تهیه و تنظیم شد. این چارچوب معماری شامل رهنمودهایی برای توصیف ماموریتهای چند سازمانی در دولت فدرال ، برای معماران سیستمهای اطلاعاتی می باشد. ماموریت چند سازمانی به ماموریتهایی اطلاق می شود که در اجرای آن چندین سازمان به صورت مشترک فعالیت می نمایند.
1-4-3 چارچوب معماری C4ISR
انگیزه اصلی از ارائه چارچوب معماری در وزارت دفاع آمریکا، ارائه یک راهنمای معماری جامع در کلیه بخشهای وزارت دفاع بوده تا توسط آن تعامل پذیری و کارائی در اجرای ماموریت ها تضمین شود. نسخه اول معماری C4ISR در ژون 1996 و نسخه دوم معماری C4ISR در دسامبر 1997 ارائه شد.
در زیر لیست برخی از چارچوبهای مهم معماری آورده شده اند. برای هر یک از چارچوبهای موجود در جدول می توانید اطلاعات کاملتر را از آدرس ارائه شده مشاهده کنید.
ردیف
نام چارچوب
ارائه کننده
تاریخ ارائه
اطلاعات کاملتر
1
Zachman
John A. Zachman
1987-1999
www.ZIFA.com
2
FEAF6
سازمان مدیریت ارشد فناوری اطلاعات دولت آمریکا
1999
www.CIO.gov
3
C4ISR/DoDAF7
وزارت دفاع آمریکا
1996
www.c3i.osd.mil
4
TEAF8
خزانه داری آمریکا
2000
www.treas.gov
5
TOGAF9
Open Group
1995
www.opengroup.org
جدول ‏1-1 : چارچوب های مهم معماری
1-5 چارچوب ها و متدولوژی ها
نکته خیلی مهم و قابل توجه اینست که چه شباهت و چه تفاوتی بین چارچوبهایی مثل Zachman و متدولوژیهایی همانند RUP وجود دارد و چگونه باهم مقایسه می شوند.
چارچوبهای معماری، همانطور که از اسم آنها برمی آید تنها یک چارچوب10 هستند. یعنی تمام اشیائی که در یک سیستم می تواند باشد، در این چارچوب جای می گیرد. چارچوبها می توان به عنوان یک ابر داده11 یا ابرشیء نیز معرفی کرد که تنها یک چارچوب کامل برای اشیاء سیستم می باشد. در حالی که هیچ اشاره ای به نحوه ایجاد یا بدست آوردن این اشیاء نمی کند. با توجه به اینکه چارچوب ها تمامی ساختارهای یک سیستم را شامل هستند، درنتیجه از چارچوبهای معماری می توان برای ایجاد، یا ارزیابی متدولوژی ها مختلف استفاده کرد. درنتیجه همه متدولوژیهای موجود را می توان در چارچوبهای معماری مثل چارچوب زکمن قرار داد و کمبودهای آنرا کشف کرد.
رابطه چارچوبها با متدولوژی ها همانند رابطه UML با RUP می باشد. همانطور که UML فقط یک زبان مدلسازی کامل (یا در حال تکامل) می باشد و یک سری دیاگرامها، برای استفاده معرفی کرده است، در حالی که هیچ اشاره ای به روند و فرایند استفاده از دیاگرامها ندارد، در حالی که RUP یک فرایند بوده و از دیاگرامهای UML در زمانهای مختلف فرایند خود استفاده می کند. به همین ترتیب چارچوبها فقط یک سری ساختارها معرفی می کنند و به چگونگی و زمان و… ایجاد و بدست آوردن آنها اشاره ای نمی کنند و این متدولوژی ها هستند که با استفاده از چارچوبها، ساختارهای سیستم را طی فرایندی بدست می آورند. در حقیقت متدولوژی ها نشان دهنده یک حرکت در روی چارچوب هستند، بعنوان مثال خط پررنگ یک متدولوژی "فرایند محور"12 نظیر روش Clive Finkelstein را نشان می دهد و خط نقطه چین یک متدولوژی داده محور13 نظیر James Martin را نشان می دهد.

شکل ‏1-2 : نحوه بیان متدولوژی ها با چارچوب ها ]ایزایران 81[
1-6 دسته بندی معماری ها
معماری را می توان از جنبه های مختلف مورد بررسی قرار داد. یک طراح پایگاه داده، همیشه از معماری داده صحبت می کند، طراح نرم افزار، از معماری نرم افزار و مدیر ارشد IT سازمان، از معماری اطلاعات سخن می گویند.
برای معماری، دسته بندی خاصی در مراجع وجود ندارد ولی در برخی منابع مانند [McGovern 03]، برخی معماریهای موجود را تشریح کرده است. در ادامه به معرفی عمده معماریهای موجود همانند دسته بندی [McGovern 03] می پردازیم که به صورت زیر می باشد.
* معماری سیستم (System Architecture)
* معماری نرم افزار (Software Architecture)
* معماری سازمان (Enterprise Architecture)
* معماری کسب و کار (Business Architecture)
* معماری اطلاعات (Information Architecture)
* معماری کاربرد (Application Architecture)
* معماری داده (Data Architecture)
* معماری تکنولوژی (Technology/Infrastructure Architecture)
* معماری مرجع (Reference Architecture)
* معماری خط تولید (Product-Line Architecture)
1-6-1 معماری سیستم، معماری نرم افزار
بالاترین مفهوم در دسته بندی های معماری، معماری سیستم می باشد. مفهوم معماری و معماری سیستم تقریباً یکسان است. به این دلیل که در بیان تعربف معماری در اصل معماری یک سیستم را تعریف می کنیم که این سیستم می تواند هر چیزی باشد. تعریف معماری سیستم را [IEEE 1471-00] ارائه می کنیم. معماری سیستم، مجموعه ای است از موجودیت14 های یک سیستم، خصوصیات هر یک از آنها و رابطه15 بین آنها که یک ساختار برای سیستم تعریف می کنند.
اگر بخواهیم یک تعریف برای معماری نرم افزار (معماری سیستمهای نرم افزاری) یا معماری سیستمهای دیگر (مثل معماری سیستمهای تولیدی) ارائه کنیم، کافی است در تعریف معماری سیستم، بجای "موجودیتها"، موجودیتهای سیستم مورد نظر را قرار دهیم. ولی آنچه از مفهوم معماری برمی آید اینست که معماری، ساختارهای سطح بالای یک سیستم را شامل می شود. درنتیجه اگر بخواهیم تعریف معماری سیستم را برای سیستمهای دیگری مثل سیستمهای نرم افزاری بیان کنیم، باید موجودیتهای سطح بالای آنرا بیان کنیم و در قسمت خصوصیات، چون به صورت Black Box به اجزاء نگاه می کند، فقط خصوصیات بیرونی16 آنها را در نظر می گیریم. موجودیتهای سطح بالای سیستمهای نرم افزاری، موئلفه های نرم افزاری و زیرسیستمهای آن می باشند. درنتیجه تعریف معماری نرم افزار، بر اساس معماری سیستم، بدین صورت باید باشد: معماری نرم افزار، مجموعه زیرسیستمها و موئلفه ها، خصوصیات بیرونی هر یک از آنها و ارتباطات بین آنها است که یک ساختار برای نرم افزار تعریف می کند.
1-6-2 معماری سازمان
ابتدا تعریف معماری سازمان را از ]ایزایران 81[ (به استناد از IEEE) می آوریم: معماری سازمانی عبارتست از تنظیم قوانین و مقرراتی برای تعریف یک ساختار واحد و منسجم، که شاملِ اجزاء، روابط بین آنها، و چگونگی تعامل اجزاء فوق با یکدیگر می شود.
همانطور که از تعریف مشخص است، معماری سازمان نیز همچون معماری نرم افزار شامل یک سری اجزاء (ولی در این تعریف اشاره ای به نوع اجزاء نکرده است) و تعاملات بین آنها می باشد. هر سازمانی ممکن است از طرف یک سری عوامل بیرونی و درونی تحت فشار قرار گیرد. اهمیت و لزوم معماری سازمانی را می توان در انعطاف پذیری در برابر فشارهای بیرونی و درونی ذکر کرد.
خود معماری سازمان به نوبه خود از معماری های زیر تشکیل شده است:

شکل ‏1-3 : معماری سازمان و زیرمعماری های مربوطه از ]ایزایران 81[
1-6-3 معماری کسب و کار
نوک هرم معماری فناوری اطلاعات جنبه های مربوط به کسب وکار و تجارت سازمان را تشریح می کند. در این سطح مباحثی چون استراتژی های کسب و کار و فناوری سازمان خط مشی ها دامنه و تصمیم گیری درمورد پارادایم های تجاری فناوری اطلاعات مانند کسب و کار الکترونیک و… از فعالیتهایی است که در این سطح انجام می شود. همچنین در این لایه مواردی چون ساختار سازمانی فرایندهای کسب و کار سیستم های برنامه ریزی و کنترل و همچنین مکانیسم های اداری و مدیریتی برای حصول به استراتژی ها و اهداف سازمانی تشریح و ارتباط میان آنها مدل سازی می شود.
در کل، شامل مستندات جامع از ساختار سازمان، ماموریت ها، اهداف کاری، وظایف، فرآیندها، فعالیت ها و اطلاعات مرتبط با نیازهای فعلی و آتی سازمان که در دو نقشه مجزا تحت عناوین نقشه وضع موجود و نقشه وضع مطلوب ارائه خواهد شد. دراین قسمت نسبت به ارائه شرح وظائف اقدام خواهد شد.
1-6-4 معماری اطلاعات
با ظهور سیستم های رایانه ای و گسترش استفاده از آنها در سازمانها به مرور زمان مشخص شد که مکانیزاسیون فرایندها و عملیات الزاماً صحت و کارایی آنها را تضمین نمی کند. به عبارت دیگر اینکه فرایندهای ناقص و غیربهینه باشد مکانیزاسیون آن تنها سبب تسریع در انجام "یک کار اشتباه" می شود لذا برای کاربرد بهینه فناوری اطلاعات باید اطلاعات مورد نیاز و در جریان فرایندهای سازمان بهینه سازی و مدل سازی شود. سپس برمبنای خوشه بندی اطلاعات و ارتباطات گروههای اطلاعاتی با فرایندهای کاری سیستم های موردنیاز سازمان مشخص می شوند. در این لایه مباحثی چون مهندسی مجدد فرایندها17 برای اصلاح و بهینه سازی گردش کار و اطلاعات مطرح می گردد.
اطلاعات اصلی مورد نیاز برای انجام وظایف سازمانی در لایه معماری اطلاعات شناسایی می شوند. در این لایه مدلهای منطقی اطلاعات دسته های داده مخازن داده و ارتباط آنها با وظایف سازمان و سیستم های برنامه های کاربردی شناسایی و تعریف می گردند. ابتدا نواحی موضوعی سازمان شناسایی و دسته بندی شده و از طریق آن مدل اطلاعاتی تهیه می شود. در ادامه بانکهای اطلاعاتی منطقی و ارتباط بین نواحی موضوعی و وظایف سازمانی در غالب نمودارهای مختلف مدل سازی می شوند. مباحثی چون مکانیسم ها و رویه های مدیریت دانش نیز در این لایه مطرح می شود.
1-6-5 معماری سیستمهای کاربردی
این لایه دربرگیرنده سیستم های کاربردی است که برای دستیابی به کارکردهای تعریف شده در لایه های بالایی لازم می آیند. سیستم هایی چون برنامه ریزی منابع سازمان18 مدیریت ارتباطات با مشتری19 سیستم های اطلاعاتی مدیریت20، سیستم های مدیریت زنجیره عرضه21 و… در این لایه لحاظ شده اند.
شناسایی و توصیف برنامه های کاربردی و ماژولها و ارتباط آنها با فرایندهای سازمان و سایر برنامه های کاربردی در لایه معماری برنامه های کاربردی انجام می شود. ارتباط بین برنامه های کاربردی با وظایف سازمان و همچنین با نواحی وظیفه ای سازمان از موارد دیگری است که در ادامه طراحی این لایه از معماری تدوین می شوند.
1-6-6 معماری داده
مجموعه ای از موجودیتها به منظور ایجاد واحدهایی که وظیفه ذخیره سازی فیزیکی داده ها را برعهده گیرند اعم از دستی یا الکترونیکی مانند فایل، صفحه گسترده، پایگاه داده ها و…
1-6-7 معماری تکنولوژی
این لایه در حقیقت پیکره ظاهری فناوری اطلاعات و آن چیزی است که در اذهان عموم از فناوری اطلاعات متصور است. این سطح از فناوری اطلاعات دربرگیرنده فناوریهای سخت افزاری و نرم افزاری ازجمله ریزپردازنده ها، رایانه های شخصی، شبکه های رایانه ای، زیرساختهای مخابراتی و الکترونیکی، بسترهای نرم افزاری و… می شود. درحقیقت استقرار سیستم های اطلاعاتی سازمان بر محمل این لایه انجام می گردد. در لایه معماری زیرساختها فناوریهای سخت افزاری نرم افزاری و شبکه های مخابراتی موردنیاز برای استقرار سیستم های کاربردی سازمان شناسایی و تبیین می گردند. نیازمندیها و موجودیهای تکنولوژیکی سازمان براساس چهار ناحیه تکنولوژیکی اصلی (بستر نرم افزاری مدیریت داده ها و سیستم های عامل سخت افزارهای پردازش اطلاعات فناوریهای مخابراتی و میان افزارها) طبقه بندی می گردند.
1-6-8 معماری مرجع
برای تعریف معماری مرجع ابتدا باید مدل مرجع را تعریف کنیم.
مدل مرجع، یک طبقه بندی از نیازهای عملیاتی به همراه جریان داده میان قطعات است. مدل مرجع یک شیوه استاندارد و شناخته شده برای مسائل می باشد که توانسته است بین قطعات حل کننده آن مساله تفکیک قائل گردد. بنابراین مدل مرجع حاوی تعدادی راه حل استاندارد برای حل یک مساله خاص است. مثلاً در طراحی سیستم های بانکی یا طراحی سیستم فروش برنامه های کاربردی بسیاری تولید شده است و در صورتی که در یک حوزه خاص تعداد بسیاری برنامه کاربردی تولید شده باشد می توان به یک مدل مرجع دست پیدا نمود. در این مدل مرجع الگوهایی برای حل مسائل وجود دارد که هنگام مواجه با یک مساله جدید مشابه با همان مسائل می توان به آنها مراجعه نمود و از آنها در مساله جدید استفاده کرد مدل مرجع موضوعی است. هر موضوعی برای خود مدل مرجع دارد. معماری مرجع مبتنی بر مدل مرجع است. اگر مدل مرجع را به موئلفه های نرم افزاری نگاشت نماییم بگونه ای که گردش اطلاعات بین این موئلفه ها را بتوان نشان داد معماری مرجع بوجود آورده ایم. طبیعتاً این موئلفه های نرم افزاری عامل پیاده سازی نیازمندی های عملیاتی تعریف شده در مدل مرجع می باشند.
به بیان دیگر در مدل مرجع موئلفه های مورد نیاز و تعریف آنها مشخص گردیده است. همچنین وظیفه این موئلفه ها و ارتباط آنها تعیین گردیده است. در صورتیکه بتوان یک نگاشت نرم افزاری میان این موئلفه ها و موئلفه های نرم افزاری برقرار نمود یا به عبارت دیگر برای این موئلفه ها نرم افزار طراحی کرد و ارتباط میان این موئلفه ها و موئلفه های نرم افزاری را تعیین نمود آنگاه به یک معماری مرجع دست خواهیم یافت.
بنابراین نقش مدل مرجع تقسیم نیازمندی ها و شناسائی موئلفه هایی با وظایف مشخص می باشد، در حالی که نقش معماری مرجع انطباق این موئلفه ها با بخش های نرم افزاری و برقراری نگاشتی مابین آنها است. این نگاشت الزاماً یک به یک نیست. بنابراین می توان گفت معماری مرجع ابزاری است که در اختیار فراهم کنندگان راهکار می تواند قرار داشته باشد تا بتوانند با کمک و بکارگیری آن برای هر صورت مسئله مشابه ای در حوزه معماری مرجع راهکاری مناسب با آن ارائه نمایند.
باید توجه داشت که معماری مرجع کاملاً وابسته به یک حوزه خاص می باشد و تنها برای یک مساله خاص مطرح خواهد بود. از این رو معماری مرجع یک معماری برای حوزه خاص است و با توجه به همان حوزه و بر اساس مدل مرجع موجود برای آن حوزه می توان نگاشتی بین نیازمندیها و موئلفه های نرم افزاری بوجود آورد. از معماری مرجع می توان در خط تولید بهره برد. به عبارت دیگر معماری مرجع پایه ای برای ایجاد یک خط تولید نرم افزار است. در صورتیکه بر اساس معماری مرجع بتوان نمونه هایی از یک نرم افزار را پیاده سازی نمود و از آنها در تولید نرم افزار استفاده مجدد نمود می توان یک خط تولید نرم افزار داشت. البته معمولا خط تولید نرم افزار برای مجموع های از محصولات مشابه بکار خواهد رفت و می توان بر همین اساس یک معماری خط تولید نیز در نظر گرفت.
1-6-9 معماری خط تولید
برای تعریف مجموعه ای از محصولات که توسط شرکتها و سازمانها در داخل شرکت به کار می رود. برای به اشتراک گذاشتن طراحی و پیاده سازی و تبادل اطلاعات بین تیمهای مختلف به کار می رود. در محدوده ها و دامنه های کاری یکسان، نرم افزارهای مورد نیاز و مورد استفاده به هم بسیار شبیه هستند و در واقع با تغییرات اندک در نقاطی که مدنظر مشتریان است، شاید بتوان یک نرم افزار را که برای محیطی مشابه نوشته شده است برای محیط جدید مورد استفاده قرار داد. این حقیقت طراحان را به روش خط تولید رهنمون کرده است.
در خطوط تولید با توجه به دامنه کاربرد مربوطه و محیط عملیاتی مورد نظر یک معماری برای مساله در نظر گرفته شده و اجزای اولیه مساله به نحوی طراحی می شوند که در نقاط کلیدی خود (که وابسته به مساله است) قابل تطبیق و تغییر باشند. این اجزا می توانند بسته به مسایل مختلف رفتار متفاوتی نشان داده و مطابق محیط مورد نظر به کار گرفته شوند. در واقع در این روش قابلیت استفاده مجدد از معماری فراهم آمده و با طراحی یک معماری کلان با توجه به مساله و محیط عملیاتی مربوطه و در نظرگرفتن اجزای اولیه برای پاسخگویی نیازها، آن اجزای اولیه به نحوی طراحی می گردند که در نقاط خاصی که در محیط مساله دارای اهمیت است قابلیت تغییر داشته باشند (به سادگی) و این معماری و اجزا، در مسایل بعدی و محیط های عملیاتی بعدی به سادگی قابل استفاده بوده و قابلیت تطابق دارند.
این روش می تواند در عین حال شامل مواردی چون طراحی ها، مستندات، راهنماهای کاربران، مسایل مرتبط با کنترل پروژه، و موارد تست نیز باشد. در این روش برای ساخت سیستم جدید تنها کافیست اجزا مورد لزوم از بانک اجزا انتخاب شده، متناسب سازی شده و در نهایت با توجه به معماری در کنار یکدیگر قرار گیرند. برای مثال در یک شرکت سازنده تلفن همراه، با طراحی یک معماری کلان برای گوشی های خود و ارائه اجزای اولیه سازنده آن، می تواند برای ارائه محصولات بعدی خود تنها با عوض کردن شاخص ها و فاکتورها و پارامترهای مدنظر برای محصول جدید نوع دیگری از تلفن های همراه را تولید نموده و در عین حال مواردی چون تسریع در تولید، کم شدن هزینه، سرعت پیاده سازی و … را به دست آورد.
اکثر شرکتهایی که نرم افزار تولید می کنند، نرم افزارهای زیادی توسعه داده اند که برخی مشخصه های آنها باهم یکسان بوده است. دسته ای از نرم افزارها در موارد زیر یکسان هستند:
* معماری یکسانی دارند.
* روی یک Platform با مشخصات یکسانی اجرا می شوند.
* قسمتهای زیادی از Business آنها باهم مشابه می باشد.
* مدیریت و سازماندهی اجزاء نرم افزاری آنها یکسان می باشد.
* و موارد زیاد دیگر

قسمتهای مشابه در این دسته از نرم افزارها را Core Assets می گویند. Core Assetها خاصیت قابل استفاده مجدد دارند و می توانند موارد زیر باشند:
Component, Framework, Library, Tools, A development or execution Platform
برای هر یک از Core Assetها یک معماری در نظر گرفته می شود، به طوریکه تمامی محصولات در این دسته، بتواند در آن معماری قرار گرفته و از آن استفاده کنند. به این معماری، معماری خط تولید می گویند.
1-7 معماریهای دیگر
علاوه بر معماری هایی که در قسمت قبلی معرفی کردیم، برخی معماری های دیگر نیز در برخی از مراجع آورده شده است و امروزه اسامی آنها را به کرات می شنویم. در حقیقت بسیاری از معماری هایی که نام برده می شوند، سبک معماری نرم افزار هستند. (در فصلهای چهارم توضیح داده خواهد شد.) ولی آنها را به نام معماری معرفی می کنند. مثلاً معماری Client/Server در حقیقت یک سبک معماری نرم افزار می باشد. یا در حقیقت می توان آنها را به عنوان زیرمعماری های نرم افزار معرفی کرد. معماری سرویس گرا22 و معماری مبتنی بر مدل23 نیز به عنوان نوعی سبک معماری در سیستمهای نرم افزاری مطرح می باشند.

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

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

2-1 مقدمه
در این فصل مفهوم معماری نرم افزار به تفصیل بیان خواهد شد. سپس تعاریف معماری نرم افزار آورده می شود. برای معماری نرم افزار تعاریف مختلفی ارائه شده است درحالی که تعریف استاندارد و مورد پذیرش همه1، وجود ندارد. هدف اصلی در این فصل مقایسه تعاریف موجود برای معماری نرم افزار بر اساس تحلیل اجزاء بکار رفته در تعاریف آنها می باشد. برای اینکار ابتدا تعاریف موجود را برای معماری نرم افزار جمع آوری کرده، سپس تعاریف را تحلیل می کنیم. یعنی تعاریف را به اجزاء تشکیل دهنده و روابط بین آنها می شکنیم و اجزاء و روابط بدست آمده را بررسی و مقایسه می کنیم.
2-2 مفهوم معماری نرم افزار
با گذشت زمان سیستمها در حال بزرگ تر شدن هستند. ساده ترین تعریف از سیستم، مجموعه اجزاء و رابطه های بین آنها می باشد. با بزرگتر و پیچیده تر شدن سیستمها، طراحی آنها نیز به یک عامل پیچیده تبدیل شده است. در تئوری سیستمی روشهای مختلفی برای غلبه بر پیچیدگی سیستمها وجود دارد. یکی از روشهای غلبه بر پیچیدگی، سطح مند کردن اجزاء و روابط بین آنها می باشد. بر اساس همین روش، طراحی سیستمها پیچیده را به دو سطح طراحی سطح بالا و طراحی با جزئیات می شکنند. بنابراین به ایده بزرگی بنام معماری می رسیم. مفهوم معماری، یک راه حل تقسیم و غلبه برای غلبه بر پیچیدگی طراحی سیستمهای پیچیده می باشد [Kaisler 05].
معماری نرم افزار یکی از زیر شاخه های مهم و اصلی در مهندسی نرم افزار به شمار می رود. معماری باعث تقسیم بندی یک کل به بخشها، و ارتباط بین بخشها می شود که باعث بوجود آمدن گروههایی از افراد، یا گروههایی از گروهها، به صورت سازمانی، جغرافیایی یا در حدود و اندازه های مختلف می شود که به صورت مشترک برای حل یک مسئله بزرگ، تلاش می کنند. معماری یک راه حل تقسیم و غلبه2 برای حل مسائل می باشد، به طوری که یک کل را به بخشها شکسته و بعد از حل هر یک از بخشها، با استفاده از ارتباط بین بخشها، باعث حل مسئله اصلی می شود.
مفهوم معماری نرم افزار، طراحی سطح بالا می باشد. یعنی فاز طراحی را به دو سطح، طراحی سطح بالا و طراحی با جزئیات تقسیم می کنیم. در حقیقت هدف از این نوشته مشخص کردن دقیق تر حد فاصل این دو سطح می باشد به طوریکه بتوان هر عامل در فاز طراحی را در یکی از این دو سطح قرار داد.

شکل ‏2-1 : مفهوم معماری نرم افزار، طراحی سطح بالا می باشد
2-3 تعاریف معماری نرم افزار
تعریف، قرارداد در مورد یک موضوع بین طرفین است. تعریف موضوع، تعیین مرز آن می باشد. موضوع معماری نرم افزار، از دیدگاههای مختلف شناخته شده و تعاریف، از مکتب های فکری مختلف ارائه می شود و هنوز توافقی برای یک تعریف استاندارد صورت نگرفته و موضوع در حال شناخته تر شدن و تعاریف در حال تکامل می باشند.
برای معماری نرم افزار تا کنون بیش از 150 تعریف معتبر از افراد و گروههای مختلف ارائه شده است؛ در حالی که تعریفی استاندارد و کامل، تا کنون ارائه نشده است و همیشه تعاریف در حال تکامل می باشند.
در ادامه برخی تعاریف معماری نرم افزار از [SEI 05] آورده می شود. انتخاب این تعاریف، به دلیل اعتبار ارائه دهندگان این تعاریف می باشد. اگر با همین روش مقایسه ای، مجموعه دیگری از تعاریف انتخاب شود، به همین پارمترهای مقایسه ای منجر خواهد شد و به همین نتیجه خواهیم رسید.
تعریف 1 [Bass 03]: معماری نرم افزار برای یک برنامه یا یک سیستم محاسباتی، ساختار یا ساختارهای آن سیستم است که شامل اجزاء نرم افزاری، خصوصیات "Externally Visible" هر یک از اجزاء و ارتباط بین آنها می باشد.
تعریف 2 [IEEE 1471-00]: سازماندهی اساسی یک سیستم که شامل موئلفه ها، ارتباط بین هر یک از آنها و ارتباط آن با محیط سیستم و اصولی حاکم بر طراحی و تکامل آن می باشد.
تعریف 3 [RUP 03]: معماری مجموعه ای از تصمیمات مهم در مورد سازماندهی یک سیستم نرم افزاری می باشد و شامل انتخاب اجزاء ساختاری، واسط هر یک از آنها که سیستم را تشکیل داده اند، به همراه رفتارهایی از اجزاء که توسط آنها با اجزاء دیگر همکاری3 می کنند، ترکیب اجزاء ساختاری و رفتاری.
تعریف 4 در [SEI 05] از Perry در سال 1992: معماری مجموعه ای از اجزاء معماری است که شکل خاصی دارند. این افراد اجزاء را به 3 نوع، اجزاء فرایندی، اجزاء داده ای و اجزاء اتصالی طبقه بندی می کنند. معماری نرم افزار ساختار موئلفه های یک سیستم (یا برنامه) و ارتباطات بین آنها و یک سری اصول و راهنمایی های حاکم بر طراحی و تکامل آن می باشد.
تعریف 5 در [SEI 05] از Garlan در 2003: مجموعه ای از موئلفه های نرم افزاری، زیرسیستم ها، ارتباطات، تعاملات، خصوصیات هر یک اجزاء (گفته شده) و مجموعه ای از اصول هدایت کننده که هر دو (مجموعه) باهم یک سری خصوصیات اساسی و قیدهایی برای یک سیستم نرم افزاری تشکیل می دهند.
تعریف 6 در [SEI 05] از Hayes در 1994: مشخصه های یک سیستم Abstract که شامل موئلفه های تابعی و رفتاری است و رفتارها و واسطهای هر موئلفه و اتصالات4 موئلفه- موئلفه را توصیف می کند.
تعریف 7 در [SEI 05] از Boehm در 1995: یک معماری سیستم نرم افزاری شامل :
* مجموعه ای از موئلفه ها، اتصالات و قیدهای یک سیستم یا نرم افزار می باشد.
* مجموعه ای از درخواستهای Stakeholderهای سیستم
* منطق و اصولی را برای موئلفه ها، اتصالات و قیدهای سیستمی که می خواهیم پیاده سازی کنیم و مطابق مجموعه درخواستهای Stakeholderها باشد، تعریف می کند.
تعریف 8 [McGovern 03]: یک معماری نرم افزار برای یک سیستم یا مجموعه سیستمها، شامل تصمیمات مهم طراحی در مورد ساختارهای نرم افزار و تعاملات بین این ساختارها که سیستم مورد نظر را تشکیل می دهند، می باشد. این تصمیمات طراحی مجموعه ای از کیفیتهایی را حمایت5 می کنند که باید توسط سیستم حمایت شوند تا موفقیت حاصل شود. تصمیمات طراحی یک سری اصول مفهومی پایه برای توسعه و حمایت و نگهداری سیستم ارائه می دهند.
تعریف 9 در [SEI 05] از U.S. Army در 2000: معماری نرم افزار یک چارچوب ایستا6 یا یک اسکلت می باشد که شکل و فرم یک سیستم نرم افزاری را ارائه می کنند و قراردادها، مکانیزمهایی برای ترکیب زیرسیستمها و بخشهای موئلفه 7 که بتوان معماری را تشکیل داد. معماری نحوه ارتباط بخشها با همدیگر را تعریف می کند و شامل قید8هایی حاکم بر نحوه ارتباط آنها است.
تعریف 10 در [SEI 05] از Bhagtani در 2003: یک چارچوب پایه یا یک ابزار ساخت که فرایندهای طراحی را ساده می کند. یک سیستم Abstract می باشد که موئلفه های عملیاتی و رابطه بیرونی این موئلفه ها، قیدهایی بر روی این موئلفه ها و منطقی9 برای انتخاب آنها می باشد.
لیست کلیه تعاریف موجود برای معماری نرم افزار را می توانید در [SEI 05] مشاهده کنید.
2-4 دلایل وجود تعاریف مختلف برای معماری نرم افزار
با بررسی تعاریف می توان دلایل عمده وجود تعاریف مختلف را پیدا کرده و با بررسی هر یک از آنها، به تعاریف کاملتری رسید.
2-4-1 وجود دیدگاهها و رویکردهای متفاوت
برای تحلیل و طراحی سیستمها، تاکنون رویکردهای زیادی ارائه شده است. از دسته متدولوژی های ساخت یافته تا شیءگرا و…، همه این رویکردها سعی در سطح مند کردن عوامل و روابط دارند، طوریکه بتوانند بر پیچیدگی سیستمها غلبه کرده و آنها را توسعه دهند. به عنوان مثال در دسته متدولوژی های ساخت یافته، از پیمانه ها10 و موئلفه های پیمانه ای11 صحبت می کنیم در حالی که در متدولوژی های شیءگرا با کلاسها و موئلفه ها سر و کار داریم. مثلا اگر تعریف 4 را در نظر بگیریم، اجزاء معماری12 را به 3 دسته فرایندی، داده ای، اتصالی تقسیم بندی می کند و واضح است که این تعریف بر اساس رویکرد ساخت یافته بوده است. یا در تعریف 6 که تنها از موئلفه های تابعی و رفتاری نام می برد. در نتیجه اگر بخواهیم تعریفی کاملتر و جامعتر ارائه دهیم نباید از دیدگاه و رویکرد خاص موضوع را تعریف کنیم، بلکه باید از دیدگاه بالاتری به موضوع نگاه کنیم. تعریف معماری نرم افزار باید به گونه ای مستقل از یک رویکرد و متدولوژی خاص ارائه شود.
2-4-2 کیفی بودن شناسه "سطح بالا بودن" در مفهوم معماری
با توجه به مفهوم معماری که ساختارهای سطح بالای سیستم می باشد، بدیهی است که "سطح بالا بودن" یک شناسه کیفی می باشد. یعنی اندازه و مقدار آن از یک ناظر13 به یک ناظر دیگر فرق خواهد کرد. در نتیجه به طور حتم شاهد برداشتهای مختلفی از معماری خواهیم بود. پس کاری که بنابه نظریه سیستمی باید انجام دهیم، مشخص کردن مرز موضوع برای معماری می باشد و باید روشی ارائه دهیم که شناسه "سطح بالا بودن" را از حالت کیفی به حالت کمی تبدیل شود. برای تبدیل شناسه "سطح بالا بودن" از حالت کیفی به حالت کمی به یک منطق (مجموعه قواعد و تعاریف) در مورد عوامل طراحی نیارمندیم تا بتوانیم عوامل و اجزاء موجود در طراحی را شناخته و بر اساس منطق موجود سطح بندی کنیم و به هر سطح مشخصه ای اختصاص دهیم.
سطح بندی کردن عوامل و روابط موجود در سیستم به صورت گسترده ای بر اساس رویکردهای مختلف انجام می شود. مثلاً در متدولوژی های ساخت یافته، فعالیتهای یک سیستم به صورت سطح مند در قالب نمودار جریان داده14 ارائه می شود و یا در متدولوژی های شئ گرا، اشیاء یا کلاسهای موجود در سیستم را به صورت سطح مند تعریف می کنیم. نحوه سطح بندی عوامل و روابط در متدولوژی های مختلف، باهم فرق دارند.
2-4-3 تفاوت در کلمات مورد استفاده در تعاریف
در تعاریف، اکثراً از کلماتی متفاوت ولی تقریباً با یک مفهوم استفاده شده است. مثلاً از ساختار، سازماندهی، چارچوب و اسکلت و یا از ارتباط و تعامل استفاده شده است. البته معانی دقیق هر یک از آنها با همدیگر فرق دارد ولی اکثراً به یک مفهوم استفاده می شوند. این طرز استفاده از کلمات متفاوت نشان می دهد هنوز موضوع معماری نرم افزار، دارای فرهنگ لغت استاندارد نیست.
2-5 ارائه جدول اجزاء تشکیل دهنده تعاریف
ساده ترین تعریف سیستم، مجموعه ای از اجزاء و رابطه های بین آنها است. اگر تعریف معماری نرم افزار را یک سیستم بگیریم، ساده ترین چارچوب برای آن شامل اجزاء تعریف، رابطه های موجود بین اجزاء تعریف و مجموعه این اجزاء خواهد بود. بر همین اساس می توان هر تعریف را به سه قسمت شکست. با توجه به تعاریف موجود برای معماری نرم افزار، می توان قسمتهای زیر را برای ارائه چارچوب در نظر گرفت.
* تعریف ارائه شده چه اجزائی برای معماری نرم افزار آورده است. یعنی معماری نرم افزار در آن تعریف شامل چه اجزائی می باشد.
* انتخاب این اجزاء از چه منطقی تبعیت می کند.
* هر تعریف برای اجزائی که معرفی کرده چه خصوصیات و رفتارهایی در نظر گرفته است.
* چه نوع رابطه هایی بین این اجزاء وجود دارد.
* در انتها مجموعه اجزاء و رابطه های تشکیل شده، چه چیزی برای توسعه سیستم نرم افزاری ارائه می دهند.
پس هر تعریف برای معماری نرم افزار از پنج قسمت تشکیل خواهد شد: مجموعه اجزاء و رابطه های معماری نرم افزار، اجزاء معماری نرم افزار، خصوصیات و رفتارهای هر جزء، رابطه بین اجزاء معماری نرم افزار، منطق انتخاب اجزاء.
2-5-1 اجزاء معماری نرم افزار و منطق انتخاب اجزاء
اولین سوالی که مطرح می شود اینست که چه اجزائی در معماری نرم افزار قرار دارند. یا اجزاء معماری15 کدامند و انتخاب این اجزاء از چه منطقی تبعیت می کند.
ابتدا یک مثال برای اجزاء غیر معماری می آوریم: فرض کنید هدف پیاده سازی یک الگوریتم می باشد. یعنی می خواهیم برنامه ای بنویسیم و یک الگوریتم خاصی را پیاده سازی کنیم. در پیاده سازی این الگوریتم باید برخی از داده ها، ذخیره یا بازیابی شوند. ما می توانیم در پیاده سازی آن از آرایه، لیست پیوندی یا پشته و… یا هر راه حل دیگری استفاده کنیم. در این حالت نحوه پیاده سازی این ساختمان داده، یک جزء غیر معماری برای ما می باشد. چون از دید ما غیر قابل رویت16 است.
در حالت کلی برای تشخیص اینکه یک جزء در معماری قرار دارد یا نه، به منظرِ ناظر بستگی دارد. یعنی اگر رفتارهای بیرونی یک جزء برای ناظر قابل رویت17 باشد، آن جزء در معماری آن ناظر قرار دارد. یعنی برای آن ناظر جزء معماری محسوب می شود. یک مثال واضح تر می آوریم [Bass 03] فرض کنید در یک سیستمی، معمار سیستم به گروه پیاده سازی دستور می دهد تا یک ماژول توسعه دهند. حال معمار سیستم را A1 و ماژولی که گروه پیاده سازی باید توسعه دهند را M1 می گیریم. گروه پیاده سازی برای پیاده سازی M1 به این نتیجه می رسند که باید ماژولی بنام M2 نیز داخل M1 برای پیاده سازی M1، پیاده سازی کنند. حال فرض کنید گروه پیاده سازی نیز یک معمار بنام A2 دارند در این حالت M2 برای A1 قابل رویت نیست پس M2 برای A1 جزء معماری محسوب نمی شود. درحالی که برای A2 جزء معماری می باشد.

شکل ‏2-2 : جزء معماری به ناظر و منظر معمار بستگی دارد
پس جزء معماری به ناظر و منظر معمار بستگی دارد. درنتیجه برای انتخاب معماری کافی است اجزاء سطح بالای طراحی یا همان اجزاء معماری را از دید معمار سطح بالا یا بالاترین سطح، انتخاب کنیم. اجزاء سطح بالای طراحی در سیستمهای نرم افزاری شامل اجزائی می شوند که سیستم از آنها تشکیل می شود. یعنی زیرسیستم ها و موئلفه ها و… .
2-5-2 ارتباط های بین اجزاء معماری نرم افزار
اجزاء معماری می توانند شامل خصوصیات18 و رفتارهایی19 باشند. این خصوصیات و رفتارها باعث ارتباط بین اجزاء معماری می شود. سوالی که مطرح می شود اینست که چه خصوصیات و رفتارهایی از این اجزاء باید در معماری نرم افزار آورده شوند.
در حالت کلی ارتباط20 را می توان به دو نوع ارتباط بیرونی21 و ارتباط درونی22 تقسیم کرد. فرض کنید دو جزء A و B داریم و این دو جزء باهم رابطه R دارند. حال فرض کنید جزء A نیز از دو جزء A1 و A2 با رابطه R1 تشکیل شده است. در این حالت برای یک ناظر مثل O1 که خارج از A و B قرار دارد، R یک رابطه بیرونی و R1 یک رابطه درونی محسوب می شود. حال خصوصیات و رفتارهای یک جزء معماری را می توان به دو دسته درونی و بیرونی تقسیم کرد. آن دسته از خصوصیات و رفتارهایی از اجزاء که باعث ارتباط بیرونی با اجزاء دیگر می شود را خصوصیات و رفتارهای بیرونی و بقیه را درونی می گوییم.

شکل ‏2-3 : R یک رابطه بیرونی و R1 یک رابطه درونی است
یا اگر به دید شیءگرایی به موضوع نگاه کنیم، اگر خصوصیات و رفتارهای یک جزء به صورت Private تعریف شود، برای دیگر اجزاء قابل رویت نیست. ولی اگر به صورت Public تعریف گردد برای دیگر اجزاء قابل رویت خواهد بود. پس معماری اجزاء را تعریف می کند و اطلاعاتی در مورد چگونگی ارتباط اجزاء با همدیگر را ارائه می کند. بدین معنی که بعضی از اطلاعات که مربوط به ارتباط های داخل هر جزء است را حذف می کند. بنابراین یک معماری قبل از هر چیز یک Abstraction از یک سیستم می باشد که مانع پرداختن در جزئیات اجزاء می شود. در نتیجه معماری فقط به قسمتهای Public اجزاء نگاه می کند و قسمتهای Private اجزاء یعنی جزئیات هر جزء و پیاده سازی داخلی آنها به معماری مربوط نمی باشد.
رفتار هر جزء بخشی از معماری می باشد. تا حدی که از دیدگاه یک جزء دیگر قابل تشخیص باشد. این رفتار اجازه می دهد تا اجزاء با همدیگر در ارتباط باشند و این بخش واضحی از معماری می باشد. این بدین معنی نیست که هر رفتار از جزء باید در معماری آورده شود. رفتارهای هر جزء تا جایی در معماری آورده می شوند که اجزاء دیگر بتوانند با آن در ارتباط باشند. این رفتارها بخشی از معماری نرم افزار محسوب می شوند.
در نهایت، معماری به اجزاء، از بیرون می نگرد در نتیجه فقط خصوصیات و رفتارهای بیرونی یا فقط واسط های اجزاء را در نظر می گیرد. یا به عبارت دیگر فقط خصوصیات و رفتارهایی که باعث ارتباط با اجزاء دیگر می شوند، در معماری قرار دارند.
2-5-3 مجموعه اجزاء معماری نرم افزار و ارتباط بین آنها
حال معماری نرم افزار، مجموعه ای از اجزاء معماری و خصوصیات و رفتارهای بیرونی آنها و ارتباط بیرونی بین آنها است. نکته بعدی که در شناخت و تحلیل معماری نرم افزار وجود دارد اینست که این اجزاء باید سطح مند23 باشند. یعنی تشکیل یک ساختار سطح مند از اجزاء و روابط، می دهند. ولی ممکن است چندین نوع ساختار ارائه دهیم. به عنوان مثال در پروژه های مقیاس بزرگ24، اجزاء مختلف بین تیمهای مختلف تقسیم می شود. فرض کنید برای چنین کاری یکبار سیستم را به صورت عملیاتی (تابعی) بین تیم تقسیم کنیم و بار دیگر به صورت داده ای بین تیمهای دیگر تقسیم کنیم. در نتیجه ساختارهای متفاوتی برای توصیف یک سیستم مورد نظر خواهیم داشت. در نهایت معماری ساختارهایی از سیستم مورد نظر می باشد که این ساختارها اجزاء معماری و فقط خصوصیات و رفتارهای بیرونی هر جزء و ارتباط بیرونی بین آنها خواهد بود.

پس می توان همه تعاریف را در یک جدول به صورت زیر جمع آوری کرد:

ردیف
ساختار
معماری نرم افزار
اجزاء
معماری نرم افزار
خصوصیات و
رفتارهای هر جزء
ارتباط بین اجزاء
معماری نرم افزار
منطقی برای
انتخاب اجزاء
1
ساختار یا ساختارهای سیستم
اجزاء نرم افزاری
خصوصیات بیرونی اجزاء نرم افزاری
ارتباط بین اجزاء نرم افزاری

2
سازماندهی اساسی یک سیستم
موئلفه ها

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

ارتباط بین موئلفه ها
اصولی حاکم بر طراحی و تکامل
5

موئلفه های نرم افزاری – زیرسیستمها
خصوصیات اجزاء
ارتباط و تعاملات بین موئلفه ها و زیرسیستم ها
اصول و قیدهایی برای سیستم
6
یک سیستم Abstract
موئلفه های تابعی و رفتاری –
رفتارهای هر موئلفه- واسط های هر موئلفه
اتصالات بین موئلفه ها

7

موئلفه ها – درخواستهای ذی نفعان 25 سیستم

اتصالات بین موئلفه ها
منطق و اصولی برای سیستم
8
تصمیمات مهم طراحی در مورد ساختارهای نرم افزار
ساختارهای نرم افزار

تعاملات بین ساختارهای نرم افزار
اصول و راهنمایی هایی برای توسعه و نگهداری سیستم
9
چارچوب ایستا – یک اسکلت
زیرسیستمها و موئلفه ها
مکانیزمهای ترکیب زیرسیستمها و موئلفه ها
ارتباط موئلفه ها و زیرسیستمها
قراردادها – سیاست ها – قیدهایی حاکم بر نحوه ارتباط آنها
10
چارچوب پایه – یک سیستم Abstract
موئلفه های عملیاتی

رابطه های بیرونی بین موئلفه ها
قیدهایی بر روی موئلفه ها – منطقی برای انتخاب آنها
جدول ‏2-1 : یک چارچوب برای تعاریف معماری نرم افزار
2-6 تعریف و مقایسه پارمترهای متناظر در چارچوب
در این قسمت می خواهیم سلولهایی از جدول 3 که در یک ستون قرار دارند را باهم مقایسه کرده و دلیل وجود تعاریف مختلف را بیشتر مورد بررسی قرار دهیم. در ستون آخر از جدول 3 اکثراً از کلمات مشابه استفاده کرده اند که نیازی به بررسی عمیق ندارد.

اگر به ستونهای چارچوب دقت کنیم اجزاء به کار رفته در ستونهای مشابه به صورت زیر می باشند.
ستون اول
ستون دوم
ستون سوم
ستون چهارم
ساختار (Structure)
جزء (Element)
خصوصیت (Property)
رابطه، ارتباط
سازماندهی (Organization)
موئلفه (Component)
واسط (Interface)
تعامل (Interaction)
چارچوب (Framework)
زیرسیستم (Subsystem)
رفتار (Behavior)
اتصال (Connector)
جدول ‏2-2 : پارامترهای متناظر در چارچوب
برای مقایسه هر یک از پارامترها، باید مفهوم و تعریف هر یک از آنها را ارائه کرده و آنها را باهم مقایسه کنیم. تعاریف مختلفی برای هر یک از عناصر موجود در جدول، توسط گروههای مختلف ارائه شده است. مثلاً IEEE تعاریفی برای ساختار و موئلفه و… ارائه کرده است. ولی خود IEEE یا گروههای دیگر، در مورد معماری نرم افزار تعریف ارائه کرده است. باید به دنبال استاندارد بالاتری برای تعاریف باشیم. برای همین اکثر تعاریف را در حوزه سیستم بررسی کرده، سپس تعریف آنها را در حوزه سیستمهای نرم افزاری آورده و باهم مقایسه می کنیم.
2-6-1 رابطه، ارتباط، تعامل، اتصال
برای دو مجموعه A,B، حاصل ضرب دکارتیاینگونه تعریف می شود:. رابطه R از A به B ()، هر زیرمجموعه از خواهد بود. اگر یک رابطه از A به B باشد و یک رابطه از B به A نیز داشته باشیم، آنگاه A با B (یا B با A) ارتباط دارد. ارتباط IR بین A و B را می توان به صورت ریاضی تعریف کرد: . اگر در رابطه R از A به B چیزی از A به B فرستاده شود، رابطه را تعامل یک طرفه یا عمل26 گویند. اگر در یک ارتباط چیزی بین دو طرف رد و بدل شود، تعامل گویند. برای رد و بدل کردن هر چیز در کامپیوتر نیاز به یک مسیر یا راه ارتباطی بین دو جزء داریم. اتصال در [Fielding 00] به عنوان یک ماشین مجرد27 تعریف می شود که برای Communication, Coordination, Cooperation بین موئلفه ها بکار می رود. در [Clements 02] به عنوان گذرگاه یا مسیر زمان اجرا برای تعامل بین موئلفه ها تعریف می شود. برای تعاریف و توضیحات بالا با استفاده زبان مدلسازی یکپارچه و دیاگرام کلاس، یک فرامدل28 ارائه می کنیم. به عنوان مثال تعریف ریاضی رابطه را در نظر بگیرید. A و B دو جزء محسوب می شوند که رابطه R از جزء A توسط یک اتصال (X,Y) به جزء B برقرار است و می توان آنرا با یک کلاس نمایش داد که دارای سه خصوصیت منبع (A)، مقصد (B)، اتصال ((X,Y)) می باشد که در انتها مدل ارائه شده ما به صورت زیر خواهد بود.

شکل ‏2-4: فرامدل پیشنهادی برای رابطه، ارتباط، تعامل، اتصال
در تعاریف معماری نرم افزار از عبارات رابطه، ارتباط، تعامل و اتصال استفاده شده است. سوالی که مطرح می شود اینست که کدامیک از این عبارات برای معماری نرم افزار درست تر است؟ رابطه یک واژه کلی است. عباراتInteraction, Coupling, Cohesion, Constraint, Function, Organization, Structure, … همگی نوعی رابطه می باشند[Klir 91] . در حالی که عمل و تعامل علاوه بر اتصال ساده، در مورد اشیائی که باید رد و بدل شود نیز بحث می کنند. آنچه مسلم است در مبحث معماری، اجزاء را به صورت Black Box در نظر می گیرند. در حالی که نحوه تعامل بین آنها باید کاملاً مشخص گردد. یعنی باید ساختار اشیائی که رد و بدل می شود نیز مشخص باشد و با انواع دیگر ارتباط های ذکر شده قابل تفکیک باشد.
2-6-2 اجزاء نرم افزاری، موئلفه، زیرسیستم
موضوع29 آن بخش از واقعیت30 که مورد تحقیق یا مطالعه است. زیرموضوع بخشی از موضوع است. ناظر کسی است که به موضوع توجه می کند. عامل31 جزئی از موضوع که به خودی خود وجود دارد و بر موضوع اثر معنی دار می گذارد. جزء، زیرموضوعی است که فقط یک عامل داشته باشد. موئلفه زیرموضوعی است که دارای حداقل دو عامل و یک رابطه باشد. سیستم، موضوعی که حداقل یک موئلفه داشته باشد. زیرسیستم، بخشی از سیستم که حداقل یک موئلفه داشته باشد [Klir 91]. یک فرامدل برای تعاریف بالا به صورت شکل زیر ارائه می کنیم:

شکل ‏2-5: فرامدل ارائه شده برای جزء، موئلفه، سیستم و…
در سیستمهای نرم افزاری، جزء نرم افزاری می تواند ماژول، کلاس، موئلفه، زیرسیستم و… باشد. با توجه به تعاریف، تفاوتی که بین یک موئلفه و زیرسیستم وجود دارد اینست که یک موئلفه در حوزه موضوع تعریف می شود در حالی که یک زیرسیستم در حوزه سیستم تعریف می شود. یعنی موئلفه ها می توانند به صورت مستقل توسعه داده شوند و مستقل از سیستم ها وجود داشته باشند. در [Crnkovic 02] می توانید بیش از ده تعریف و مقایسه برای موئلفه را پیدا کنید. به عنوان مثال در [Souza 99] موئلفه اینگونه تعریف می شود، یک بخش قابل استفاده مجدد از نرم افزار که به صورت مستقل توسعه داده می شود و برای ساختن بخشهای بزرگتر با موئلفه های دیگر قابل ترکیب است. هر موئلفه باید اولاً شامل مجموعه ای از واسط ها برای تعامل با موئلفه های دیگر باشد و دوماً کد قابل اجرا باشد [Crnkovic 02]. با این تعریف بسیاری از اجزاء دیگر همانند کلاس های کامپایل شده، توابع کتابخانه ای و… را که دارای واسط باشند، می توان به عنوان موئلفه نام برد. حال سوالی که مطرح می شود اینست که کدام عبارت برای تعریف معماری نرم افزار درست تر می باشد؟ نکته مهم اینست که سیستم ها بر اساس موئلفه ها و زیرسیستمها توسعه داده می شوند. ولی با توجه به مفهوم موئلفه در سیستمهای نرم افزاری ممکن است برای توسعه یک سیستم نرم افزاری از موئلفه ها استفاده نکنیم و از روشهایی غیر از مبتنی بر موئلفه استفاده کنیم.
2-6-3 خصوصیت، واسط، رفتار
رفتار، رخدادهای معنی دار حاصل از موضوع و یا موئلفه های آن می باشد[Klir 91]. در [Booch 94] رفتار اینگونه تعریف می شود، چگونگی عمل و عکس العمل32 (یا کنش و واکنش) یک شیء، در تغییرات حالت یا ارسال/دریافت پیغام. به عبارت دیگر رفتار، فعالیتهای ظاهری قابل مشاهده و قابل تست یک شئ است. چند نکته در مورد این تعاریف وجود دارد. اول اینکه شئ، در متدولوژی شیءگرا هر چیزی می تواند باشد. برای مقایسه شئ و موئلفه (شباهتها و تفاوتها) به [Crnkovic 02] نگاه کنید. دوم اینکه موئلفه یا شئ نمی تواند در یک محیط ایزوله قرار داشته باشد، یعنی اینکه موئلفه ها و اشیاء حتماً دارای رفتار هستند. سوم اینکه رفتارها، فعالیت های ظاهری و قابل مشاهده هستند، در نتیجه از دیدگاه یک ناظر، رفتارهای داخلی یا رفتارهای خارجی معنی نخواهند داشت.
خصوصیت، کیفیت های دورنی33 (ذاتی) یا برونی34 یک شئ. یک خصوصیت، مشخصه های یک شئ را تعریف می کند و باعث تمایز یک شئ از اشیاء دیگر می شود. شناسه35، یک خصوصیت نام گذاری شده یک شئ می باشد [Souza 99]. اکثر موارد خصوصیت و شناسه بجای همدیگر استفاده می شوند. در برنامه نویسی شئ گرا خصوصیت با شناسه فرق دارد. خصوصیت ها، شناسه هایی هستند که باید برای آنها متدهای Get و Set نوشته شود یعنی نحوه دستیابی و تغییر آنها توسط برنامه نویس کنترل می شود. برای اطلاعات بیشتر به [Souza 99] مراجعه کنید.
در تعاریف، خصوصیت برای اجزاء استفاده شده است. ولی برای موئلفه ها همیشه از واسط استفاده می شود. واسط ها به عنوان نقطه دسترسی به رفتارها و خصوصیات یک موئلفه می باشند. در حقیقت واسط ها پروتکلها و قوانین دسترسی به رفتارها و خصوصیت های یک موئلفه را تعریف می کنند که موئلفه های دیگر از این طریق با آن ارتباط برقرار کنند. واسط ها مستقل از پیاده سازی یک موئلفه توسعه داده می شوند که این امکان را فراهم می آورد که بدون تغییر در واسط های یک موئلفه، پیاده سازی های آن تغییر کند. اطلاعات کاملتر را در [Crnkovic 02] نگاه کنید.
حال سوال اینست که کدام عبارت مناسب تر می باشد. واضح است که برای موئلفه ها، واسط ها تنها بخش قابل رویت می باشد و تنها معرفی واسط ها کفایت می کند. ولی برای اشیاء باید رفتارها و خصوصیت های بیرونی و قابل رویت را ذکر کنیم که شناسه ها و خصوصیات و متدهای عمومی36 می باشد.
برای کلیه تعاریف ذکر شده، همانند قسمتهای قبل، یک فرامدل به صورت شکل زیر پیشنهاد می دهیم:

شکل ‏2-6: فرامدل پیشنهادی برای رفتار، خصوصیت، واسط
2-6-4 ساختار، سازماندهی، چارچوب
ساده ترین تعریف سیستم، مجموعه ای است از اجزاء و رابطه بین آنها که به صورت S= (E, R) نمایش می دهند که در آن E مجموعه ناتهی از اجزاء می باشد. جزء یک واژه عمومی بوده و می تواند موئلفه، زیرسیستم و… باشد. با افزایش تعداد و تنوع اجزاء و روابط سیستم (پیچیده شدن سیستم)، برای فهم سیستم، مجموعه اجزاء و روابط سیستم را بر اساس یک منطق خاصی، نمایش می دهند و چینشی منطقی به آن مجموعه می دهند.
سطح37، آستانه ای در یک سیستم است که در آن موئلفه های یک موضوع به زیرموئلفه ها و روابط بین آنها تفصیل می شود. سطح مندی یا سلسله مراتب38، مجموع سطوح مربوط به یک موضوع است. ساختار، نمایش سطح مند مجموعه اجزاء و روابط بین آنها می باشد [Klir 91].
اگر چینشی منطقی برای مجموعه اجزاء و روابط یک سیستم، طوری ارائه دهیم که همه اجزاء و روابط موجود در سیستم بتوانند در این چینش، قرار بگیرند به این چیدمان چارچوب می گویند. در حقیقت یک چارچوب یک افراز برای مجموعه اجزاء و روابط یک سیستم می باشد و بستری برای قرار گرفتن تمامی اجزاء و روابط یک سیستم می باشد. در سیستمهای نرم افزاری نیز یک چارچوب به مجموعه ای کامل از اشیاء گفته می شود که باهم برای انجام دسته ای از مسئولیتها، دور هم گرد آمده اند. برای اطلاعات بیشتر در مورد چارچوب های نرم افزاری و دسته های مختلف آنها به [Kaisler 05] مراجعه کنید. از چارچوب های معروف می توان به چارچوب مندلیف برای عناصر طبیعی و چارچوب Zachman برای سازمان ها نام ببریم. چند نکته مهم در توضیحات و تعاریف بالا وجود دارد. اول یک چارچوب می تواند از چندین ساختار استفاده کند. دوم، یک چارچوب باید بستر و جایگاهی برای تمامی اجزاء و رابطه های یک سیستم باشد. یعنی باید بیشترین شمول را دارا باشد. درنتیجه در ارائه یک چارچوب باید از کمترین واژه ها، قیدها و محدویتها استفاده کرد تا بیشترین شمول را دارا باشد.
سازماندهی، فرایندی است که در آن تقسیم کار میان افراد و گروههای کاری و هماهنگی میان آنها، به منظور کسب هدف(ها) صورت می گیرد و از وظایف مدیر محسوب می شود. روشهای متعددی همانند فرایندگرا و شئ گرا و… برای سازماندهی ارائه شده است. برای سازماندهی سیستم ها ممکن است از چارچوب ها یا ساختارها نیز استفاده کنیم.
حال سوالی که مطرح می شود، اینست که در معماری آیا به غیر از ارائه ساختار یا چارچوب برای اجزاء، سازماندهی نیز انجام می دهیم. یعنی تقسیم کار میان افراد و گروههای کاری و هماهنگی میان آنها، در معماری قرار دارد یا نه؟

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

3-1 مقدمه
در این فصل با توجه به اهمیت مهم مشخصه های کیفی در معماری نرم افزار و تاثیر حیاتی معماری نرم افزار بر میزان مشخصه های کیفی، ابتدا به بررسی مفهوم کیفیت و مشخصه های کیفی پرداخته، سپس برای تک تک آنها، مفهوم و تعریف هر یک را ارائه کرده و نحوه سنجش آنها را بیان می کنیم. در نهایت تاثیر مشخصه های کیفی بر همدیگر را تشریح می کنیم.
3-2 مفهوم کیفیت نرم افزار و مشخصه های کیفی
سیستمهای کامپیوتری در بسیاری از برنامه های کاربردهای بحرانی1 مورد استفاده قرار می گیرد. در این برنامه ها یک نقص2 می تواند عواقب زیادی را به دنبال داشته باشد. برنامه های کاربردی بحرانی دارای مشخصه های زیر می باشند:
1. برنامه کاربردی چرخه عمر طولانی دارد (شاید چندین سال) و نیازمند ارتقاء تکاملی3 هستند.
2. برنامه کاربردی باید به صورت مداوم و بدون توقف اجرا شوند.
3. برنامه کاربردی باید با ابزار سخت افزاری در تعامل باشد.
4. این برنامه ها باید شامل برخی مشخصه های کیفی باشند. نظیر Timeliness, Reliability, Safety, Interoperability و…
توسعه دهندگان این سیستمها، مسئول تشخیص و تعیین نیازمندیهای این برنامه های کاربردی و ایجاد سیستم برای محقق سازی این نیازمندیها هستند. توسعه دهندگان سیستمهای بحرانی، ابتدا نیازمندی های برنامه مورد نظر را شناسایی می کنند، نرم افزار مورد نظر را طوری توسعه می دهند که نیازمندی های مورد نظر را با منابع مقتضی پوشش دهند.
سیستمهای بحرانی در حالت کلی نیازمند برخی مشخصه های دیگر نیز هستند که می توان به کارایی، وابستگی، امنیت، سلامتی و برخی نیازهای مشابه اشاره کرد. نیازمندیها در حالت کلی به دو دسته نیازمندیهای عملیاتی4 و نیازمندیهای غیرعملیاتی 5 تقسیم می شوند. نیازمندیهای عملیاتی، عبارتست از توانایی سیستم در انجام کاری که برای آن ایجاد شده است. نیازمندیهای غیرعملیاتی که تحت عنوان مشخصه های کیفی6 از آنها یاد می شود، هر آنچه که غیر از نیازمندیهای عملیاتی سیستم باشد، در این دسته قرار می گیرند. مانند کارایی، امنیت، هزینه ساخت و… .
کیفیت نرم افزار به صورت مستقیم با توانایی یک سیستم در قبال نحوه انجام نیازمندی های عملیاتی و غیرعملیاتی آن در ارتباط می باشد. یک سیستم می تواند شامل مشخصه های زیادی همچون کارایی، قابلیت نگهداری، امنیت و… باشد. کیفیت هر یک از مشخصه های موجود، بر کیفیت کل سیستم تاثیر دارد. یعنی کیفیت کل سیستم تابعی از کیفیت تک تک این مشخصه ها می باشد. همیشه کیفیت این مشخصه ها قابل اندازه گیری نیست. هر مشخصه می تواند به عنوان یک خصوصیت برای سیستم باشد. به مجموعه خصوصیات قابل اندازه گیری یا قابل مشاهده (غیر قابل اندازه گیری) که در کیفیت کل سیستم تاثیر می گذارد، مشخصه های کیفی آن سیستم می گویند. به عنوان مثال، کارایی، قابلیت نگهداری، قابلیت استفاده مجدد، امنیت و… مشخصه های کیفی برای سیستم های نرم افزاری می باشند.
دو نکته در رابطه با صفات کیفی از اهمیت زیادی برخوردار است:
1. معماری برای تحقق بسیاری از صفات کیفی مهم و بحرانی در سیستم قابل بهره برداری بوده و این کیفیت های مورد نظر می بایستی در سطح معماری، طراحی و ارزیابی شوند.
2. برخی از این صفات کیفی وابسته به معماری نیستند و تحقق در زمینه دستیابی به این کیفیتها در معماری کار درستی نیست و نتیجه قابل استفاده ای ارائه نمی کند. به همین علت می گوییم که یکسری ویژگیها در زمان معماری و طراحی قابل ارزیابی هستند و برای بعضی از صفات کیفی معماری، باید معماری را اجرا نمود، یعنی آزمایش آنها به بعد موکول می شود. به عنوان مثال مشخصه User Friend بودن یک نرم افزار در قسمت معماری مورد بررسی قرار نمی گیرد.
اصولاً رسیدن به یک کیفیت بر روی کیفیت دیگر تاثیر گذار است. مثلاً ممکن است وقتی که کارایی یک سیستم را بالا ببریم، امنیت آن کاهش یابد. یعنی ممکن است که همه صفات کیفیتی را نتوانیم با هم در حد عالی، برآورده سازیم. اندازه و مقدار یک مشخصه کیفی، ممکن است به اندازه دیگر مشخصه های کیفی وابسته باشد. دستیابی به یک کیفیت، اغلب در کیفیت های دیگر اثر دارد، که این اثر مثبت یا منفی است. مثلاً امنیت و تحمل خطا7 به صورت انحصاری قابل دستیابی اند. سیستم با حداکثر امنیت، کمترین قدرت تحمل خطا را می تواند داشته باشد و برعکس. مثال دیگر اندازه کارایی به اندازه مشخصه های کیفی دیگر مثل امنیت بستگی دارد. با افزایش میزان امنیت یک سیستم، ممکن است سرعت سیستم کاهش یافته و از کارایی آن سیستم کاسته شود.
3-3 تعریف کیفیت در نرم افزار و مشخصه های کیفی
در لغت نامه Cambridge کیفیت "چگونگی خوب یا بد بودن هر چیز" معنی می شود. برای کیفیت تعاریف مختلفی ارائه شده است که در زیر به نمونه هایی از آنها را از [Fitzpatrik 96] می آوریم:
تعریف اول از German Industry Standard DIN 55350 Part 11:

…..

توجه به جدول ارائه توسط McCall، می توان کلیه ارتباطات بین صفات کیفی را درک کرد. به عنوان مثال Usability با Efficiency رابطه معکوس دارد. یعنی با افزایش یک از آنها در سیستم، دیگری کاهش خواهد یافت. در نتیجه وظیفه معمار نرم افزار می باشد که Trade-Off موجود بین این دو را حل کرده تا به یک سطح مطلوبی از آنها برسیم. در [Fitzpatrik 96] این مفاهیم به صورت کامل مورد بررسی و تحلیل قرار گرفته است.
در [Berander 05] می توانید توضیحات و تحلیل هایی کامل بر Trade-Offهای بین مشخصه های کیفی مشاهده کنید.

در این فصل، ابتدا به مفهوم کیفیت در نرم افزار پرداخته و در ادامه تعریف مشخصه های کیفی را ارائه کردیم. سپس مشخصه های کیفی را تک به تک مورد بررسی قرار دادیم و نحوه ارزیابی هر یک را بیان کردیم. مهمترین مسئله در مشخصه های کیفی یعنی Trade-Off بین آنها را بیان کردیم.
در کل هدف این فصل پرداختن به ویژگی های کیفی مورد بحث در معماری بود. در فصل های بعد، مسئله ارتباط مشخصه های کیفی با سبک های معماری نرم افزار و نحوه ارزیابی سبکهای معماری نرم افزار بر اساس مشخصه های کیفی آنها مورد بررسی قرار خواهد گرفت.

4. فصل چهارم ی
سبک ها و الگوهای معماری نرم افزار و نحوه ارزیابی و انتخاب آنها

4-1 مقدمه و تاریخچه
هر سیستم، از موئلفه های مختلفی تشکیل شده است. هر سیستم را می توان به روشهای مختلف به موئلفه ها و روابط بین آنها شکست. در حقیقت سیستمها را می توان به مجموعه های مختلفی از موئلفه ها و روابط بین آنها، افراز کرد. برای سیستمهای نرم افزاری، روشهای مختلفی برای شکستن سیستم به اجزاء و روابط، وجود دارد که هر کدام از این روشها در سطوح بالا، یک معماری برای سیستم مورد نظر خواهند بود.
برخی از این روشها یا معماری ها، توسط معماران نرم افزار بارها برای سیستمهای خاص ارائه شده اند و به مراتب مورد استفاده قرار گرفته اند و کاربردها و توانایی های آنها تائید شده است و مجموعه ای از معماری ها و الگوهای معماری1 تشکیل شده است که معماران را در ارائه معماری ها، یاری می کنند. یعنی معماران، برای ارائه یک معماری، می توانند از این مجموعه از معماری ها، استفاده کنند. هر یک از معماری های این مجموعه را یک سبک معماری می گویند.
لغت سبک معماری برای اولین بار توسط Perry و Wolf [Perry 92] در سال 1992 معرفی شد و در سال 1994، Garlan و Shaw [Garlan 94] در نوشته ای سبکهای معماری نرم افزار را معرفی کرده و همراه با مثالهایی، آنها را مقایسه کردند.
انگیزه اصلی در انتخاب نوعی از معماری در شرایط خاص، با توجه به استدلالها و مشخصه های کیفی شکل می گیرد ولی سبکها، دانش و خرد معماران ماهر را بازنمایی کرده و معماران کم تجربه را برای طراحی معماری هایشان راهنمایی می کنند.
4-2 تعریف سبک معماری
برای سبک معماری نیز همانند تعریف خود معماری، تعاریف زیادی ارائه شده است. در این قسمت برخی از تعاریف سبک معماری نرم افزار را ارائه می کنیم.
4-2-1 تعاریف مختلف سبک معماری نرم افزار
تعریف اول را از [Perry 92] می آوریم: یک خانواده از سیستمهای نرم افزاری، بر حسب سازماندهی ساختاری آنها تعریف می کند. یک سبک معماری، موئلفه ها و ارتباطات بین آنها، همراه با قید های استفاده و کاربرد آنها و قوانین ترکیب و طراحی در ساخت آنها را بیان می کند.
تعریف دوم از [Shaw 96]: یک سبک معماری توصیفی است از انواع موئلفه ها و نحوه چیدمان2 آنها و توصیفی از الگوی تعامل داده و کنترل، بین موئلفه ها و توصیفی رسمی از مزایا و محاسن هر یک، در بکارگیری آنها.
تعریف سوم از [Clements 02-1]: یک تبحرگری3 از انواع جزء و ارتباط، به همراه مجموعه ای از قیدهایی برای نحوه کاربرد آنها می باشد.
تعریف چهارم از [Albin 03]: یک نوع از ابرداده که مجموعه ای از اجزاء و ارتباطات بین آنها را تعیین می کند. که یک سیستم را بر اساس سبک، توصیف می کند. این اجزاء عموماً، موئلفه ها، اتصالها هستند که ارتباط های بین آنها، قیدهایی بر نحوه ترکیب موئلفه ها و اتصالها می باشد.

سبک های مختلف معماری، اختلاف بین کلاس های مختلف طراحی را نشان می دهند و اینکار با ارائه شواهدی تجربی از بکارگیری هر کلاس، باتوجه به استدلالهای کیفی آن و داشتن خواص مربوط به آن کلاس، انجام می شود. سبک را می توان مانند مجموعه ای از قواعد حاکم روی یک معماری فرض کرد. سبک معماری مجموعه ای از قواعد برای طراحی است که انواع موئلفه ها و اتصالهایی که می توانند برای ایجاد یک سیستم (یا زیر سیستم) بکار روند، همراه با محدودیتهای داخلی یا خارجی در مورد نحوه ترکیب بندی آنها را نشان می دهد.
4-3 معرفی برخی سبک های متداول
در این قسمت به معرفی برخی از سبکهای متداول تر و مشخصه های کیفی آنها می پردازیم.
سبک های زیادی تاکنون ارائه شده اند و برای همین نیاز به دسته بندی آنها یک امر ضروری می باشد. اولین نوع دسته بندی های سبکهای معماری توسط Garlan و Shaw در [Shaw 96] به صورت زیر انجام دادند که شامل سبک های زیر می باشد که در این قسمت، سبک های معماری نرم افزار را بر اساس این دسته بندی توضیح می دهیم.

شکل ‏4-1: دسته بندی Garlan و Shaw برای سبک های معماری نرم افزار از [Shaw 96]
4-3-1 سبک های متمرکز روی داده4
هدف این سبک معماری، رسیدن به کیفیت برقراری یکپارچگی5 می باشد. کلمه "متمرکز روی داده" اشاره به سیستم هایی دارد که در آنها دستیابی و بهنگام سازی داده ها، توصیفی مناسب از عملکرد سیستم است. یک مشتری6، روی مجموعه رشته کنترلی مستقلی اجرا می شود و داده مشترکی که توسط تمام مشتری ها دستیابی می شود، می تواند به صورت Passive Repository (مثل یک فایل) یا Active Repository (مثل Blackboard) باشد.

شکل ‏4-2 : مدل سبک های متمرکز روی داده از [Shaw 96]
مفهوم ارتباط در اینجا می تواند به دو دسته اشاره کند: Repository و Blackboard. یک Blackboard، برای مشتری ها در زمان تغییرات در داده ها، ابلاغ می فرستد و بنابراین Active است.
با داشتن Blackboard در این سبک، شکل معرف، شامل پیکان هایی خواهد بود که بتوانند از سمت داده مشترک منشعب شوند. این سبک معماری، همواره در حال گسترش و ارتقاء اهمیت است و این بخاطر وجود راه حلی ساختاری برای رسیدن به برقراری یکپارچگی است.
در بسیاری از سیستم ها – بخصوص سیستم های متشکل از موئلفه هایی از پیش ساخته شده – یکپارچگی داده ها با مکانیزم Blackboard فراهم می شود. در این سیستم یک مزیت عمده این است که مشتری ها به صورت مستقل از هم موجود می باشند و همچنین داده مشترک نیز بخشی از مستقل از مشتری ها است و بنابراین این سبک مقیاس پذیر7 است و مشتری های جدید می توانند به راحتی اضافه شوند. همچنین این سبک خاصیت تغییرپذیری8 بالایی دارد و این بخاطر امکان تغییر عملکرد هر یک از مشتری ها بدون داشتن اثراتی روی بقیه مشتری ها می باشد. البته Coupling بین مشتری ها این خاصیت را کم می کند ولی کارایی9 را بالا می برد.
4-3-2 سبک های جریان داده10
هدف در این سبک، رسیدن به استفاده مجدد11 و تغییرپذیری است. در این سبک، به سیستم به این دید نگاه می شود که یک سری از تبدیلات روی قطعاتی متوالی از داده های ورودی انجام می شود. داده، به سیستم وارد می شود و در میان موئلفه ها جریان می یابد. تا زمانی که به مقصد نهایی برسد.
این سبک شامل دو زیر سبک است، Batch Sequential و Pipe & Filter. در سبک Batch Sequential، گامهای پردازش یا همان موئلفه ها، برنامه های مستقلی هستند و فرض بر این است که هر گام قبل از شروع گام بعد، اجرایش به تکامل می رسد. هر دسته ای از داده ها، کلاً بین گام ها، انتقال داده می شود. فرم کلی برنامه در این سبک، فرم کلاسیک پردازش داده است.
سبک Pipe & Filter تاکید روی تبدیل و پردازش تدریجی داده، بوسیله موئلفه های متوالی دارد. این سبک یک سبک متداول در خانواده سیستم های عامل UNIX است. فیلترها، transducer های روی Streamها هستند. فیلترها، داده ها را بطور تدریجی تبدیل می کنند. Pipeها، حالتی به خود نمی گیرند و فقط برای حرکت دادن بین فیلترها قرار می گیرند. قواعد حاکم روی این سبک ، چگونگی بستن Pipeها و فیلترها به هم را مشخص می کنند. یک Pipe، یک Source End دارد که به پورت خروجی یک فیلتر متصل است و یک Sink End که به پورت ورودی یک فیلتر متصل است.

شکل ‏4-3 : سبک Pipe and Filter از [Shaw 96]
4-3-3 سبک های ماشین مجازی12
در این سبک معماری، هدف اصلی رسیدن به قابلیت جابجایی13 بالا است. این سبک، عملکردی را که برای سخت افزار یا نرم افزاری که برنامه روی آن اجرا می شود، شبیه سازی می کند. اینکار به روشهای مختلفی انجام می شود. این سبک می تواند سکو14هایی که هنوز ساخته نشده اند را شبیه سازی کند، (مثل سخت افزاری جدید) و می تواند حالتهای بدی که ممکن است در عمل بسیار پیچیده، پر هزینه و خطرناک باشند شبیه سازی نماید (مثل سیستم های بحرانی/امنیت یا سیستم های پرواز). مثالهای متداول از این سبک شامل مفسرها15، سیستم های قاعده مند16 و پردازشگرهای زبانهای فرمانی می باشند. مثلاً زبان جاوا، روی ماشین مجازی جاوا اجرا می شود که اجازه می دهد که زبان جاوا مستقل از سکو باشد.
4-3-4 سبک های فراخوانی و بازگشت17
هدفی که در این سبک دنبال می شود، رسیدن به قابلیت تغییر و مقیاس پذیری18 است. این سبک، معماری غالب سیستم های نرم افزاری بزرگ در 30 سال گذشته بود، ولی از این سبک، زیر سبک هایی با خصوصیات ارزشمند، پدید آمدند که در ادامه تعدادی از آنها بررسی می شوند.
4-3-4-1 سبک برنامه اصلی و زیر روال19
این سبک همان پارادایم برنامه سازی به روش کلاسیک را نشان می دهد. هدف، تکه کردن برنامه به قطعات کوچکتر، برای رسیدن به قابلیت تغییر بالاتر است. یک برنامه به صورت سلسله مراتبی تقسیم می شود و یک رشته واحد از کنترل است و هر موئلفه در این سلسله مراتب، این کنترل را از پدر خود بدست می آورد و به فرزندان خود می دهد. جریان کنترل می تواند همراه با جریان داده هم باشد. شکل زیر شمای کلی این سبک را نشان می دهد.

شکل ‏4-4 : سبک برنامه اصلی و زیرروال از [Shaw 96]
4-3-4-2 سبک سیستمهای فراخوانی روالهای خارجی20
سیستم های مبتنی بر این سبک، همان سبک "برنامه اصلی و زیر روال" هستند که به تکه هایی تقسیم می شوند که آن تکه ها روی کامپیوتر هایی که از طریق شبکه ای به هم متصل شده اند، قرار می گیرند. هدف در این سبک، بالا بردن کارایی بوسیله توزیع محاسبات و استفاده از چندین پردازشگر است. در این سیستم ها، انتساب واقعی بخشها به پردازشگرها تا زمان اجرا به تاخیر می افتد و این بدان معناست که انتساب ها در جهت بالا بردن کارایی براحتی می توانند تغییراتی داشته باشند. می توان گفت این سبک هیچ فرقی با سبک برنامه اصلی و زیر روال استاندارد ندارد مگر اینکه فراخوانی زیر روال ها و انجام عملیات آنها – در صورتی که آن تابع روی یک ماشین خارجی باشد – زمان بیشتری صرف خواهد کرد.
4-3-4-3 سبک سیستم های شی گرا21
این سبک، نسخه مدرنی از معماری های فراخوانی و بازگشت می باشد. پارادایم شی گرا، تکیه بر بسته بندی داده و دانشی در مورد چگونگی انجام عملیات و دستیابی بر داده ها دارد. بسته بندی شامل محصورسازی داده ها و پنهان سازی رموز داخلی داده ها از محیط است. دستیابی به شیء، فقط از طریق عملیاتی خاص، موسوم به متد، مقدور است. محصورسازی قابلیت استفاده مجدد و قابلیت تغییر را بالا می برد و این بخاطر این است که طی این مسیر مقوله ها از هم جداسازی می شوند. مثلاً کاربر یک سرویس نیاز به دانستن اینکه سرویس چگونه کار می کند، ندارد. خاصیت اصلی که در واقع وجه تمایز پارادایم شی گرا و انواع داده های مجرد است، وراثت22 و چندریختی23 است. هنگامی که تجریدهایی از شی ء، یک موئلفه می سازند که سرویسهای Black Box را تامین کند و باقی موئلفه ها از آن دسته اول استفاده کنند، سبک Call-Based Client-Server بوجود می آید.

شکل ‏4-5: سبک معماری Object Oriented از [Shaw 96]
4-3-4-4 سبک سیستم های لایه ای24
در این سبک، موئلفه ها هر یک به لایه ای انتساب داده می شوند تا محاورات بین موئلفه ها کنترل شود. در مدل محض از این زیر سبک، هر لایه فقط با لایه های مجاور خود ارتباط دارد. هدف در این سبک رسیدن به قابلیت تغییر و قابلیت جابجایی است. پایین ترین لایه، عملیات مرکزی (مثل سخت افزار یا Kernel سیستم عامل) را فراهم می کند. هر لایه بالاتر روی لایه قبلی ساخته می شود و لایه پایینی اش را پنهان می سازد و سرویسهایی را که توسط لایه های بالاتر مورد استفاده اند، فراهم می کند. در عمل، اغلب سیستم های لایه ای، محض نیستند و عملیات در یک لایه امکان ایجاد ارتباط با عملیات هر لایه ای را دارند. این امکان Layer Bridging نامیده می شود و زمانی مورد استفاده قرار می گیرد که مساله کارایی در زمان اجرا مورد نظر باشد. نمونه های ساده و پیچیده آن در شکل آورده شده است.

شکل ‏4-6 : نمونه ای از سبک لایه ای مورد استفاده در استاندارد ارتباطی ISO از [Shaw 96]
4-3-5 سبک های موئلفه های مستقل25
این معماری، برای رسیدن به قابلیت تغییر، بوسیله جداسازی بخشهای مختلف محاسباتی است. این معماری از فرایندهای مختلف که با ارسال پیام به هم، کار می کنند، تشکیل شده است. این فرایندها به هم داده می فرستند، ولی یکدیگر مستقیماً را کنترل نمی کنند. پیامها می توانند به یک مشترک مشخص فرستاده شوند یا در حالت استفاده از سیستم بر پایه رخداد که از پارادایم Publish/Subscribe استفاده می کند، می تواند بین مشترکهای غیر مشخص مبادله شود. سیستم های بر پایه رخداد، زیر سبک هایی هستند که در آنها، کنترل بخشی از مدل است. هر موئلفه ای، داده هایی را که می خواهد با محیطش تسهیم کند، اعلام می دارد (عمل Publish) و بقیه موئلفه ها می توانند در این کلاس داده، مقداری را ثبت کنند (عمل Subscribe). اگر اینکار را بکنند هر زمان که داده ای ظاهر شد، فراخوانی می شوند و داده را دریافت می کنند. در این روش مدیریت پیام ممکن است موئلفه هایی که به آنها پیام ارسال می کند، کنترل نکند. موئلفه ها مقادیری را ثبت می کنند که می خواهند دریافتشان کنند و سپس پیام را به مدیریت پیام می دهند تا پیام و یا مرجع شیء را به بقیه مشترکین متقاضی بدهد.
این زیر سبک برای این مهم است که هر موئلفه را از شناسایی موئلفه های دیگر بی نیاز می کند. همچنین موئلفه ها می توانند بطور موازی کار کنند و فقط در زمان نیاز با هم مقادیری از داده را رد و بدل کنند. این Decoupling، یکپارچگی موئلفه ها را ساده می کند. فرایندهای مرتبط در سیستم های چند پردازنده ای کلاسیک، مثل Client/Server زیر سبک دیگری از سبک اصلی، مطرح شده است که در آن هدف اصلی رسیدن به مقیاس پذیری بالا است. سرور می تواند داده را به یک یا بیشتر مشتری بدهد. مشتری به سرور تقاضا می دهد. اگر سرور، سنکرون عمل کند، در همان زمان که داده را می دهد، کنترل را به مشتری برمی گرداند و اگر آسنکرون عمل کند فقط داده را به مشتری می دهد.
4-3-6 سبک های چند ریختی26
در اغلب سیستم ها، نمی توان گفت که از یک سبک منفرد برای ساخت استفاده شده و معمولاً سیستم ها چندریختی اند. این چندریختی را می توان در انواع زیر بررسی کرد:
4-3-6-1 چند ریختی از نظر مکانی27
یعنی با داشتن شکل ساختار اجرایی، الگوهایی از سبک های مختلف در مکان های مختلف به چشم می خورند. مثلاً شاخه هایی از سیستم "برنامه اصلی و زیر روال" می توانند دارای داده مشترک (Repository) باشند.
4-3-6-2 چند ریختی سلسله مراتبی28
یعنی یک موئلفه از یک سبک با تقسیم شدن، طبق قواعد سبک های مختلفی ساخته شود. شکل پایین، این موضوع را نشان می دهد.
4-3-6-3 چندریختی همزمان29
یعنی هر یک از انواع مختلف سبک ها را بتوان با تعریفی از سیستم منطبق ساخت. این نوع آخر چند ریختی در واقع بازگو می کند که سبک ها، انواع معماری های نرم افزار را نمی توانند به دسته های کاملاً مجزا و بدون همپوشانی تقسیم کند. مثلاً سبک متمرکز روی داده را می توان به نوعی شبیه به سبک معماری موئلفه های مستقل دانست. لایه های موجود در یک سیستم لایه ای می توانند نمایشگر شیء یا موئلفه های مستقل یا حتی زیر روالهای مربوط به سیستم برنامه اصلی و زیر روال، باشند. موئلفه ها در یک سبکPipe & Filter معمولاً پردازشگرهایی هستند که مستقل از هم عمل می کنند و تا وقتی که ورودی روی پورت آنها حاضر شود، صبر می کنند و این باز هم شبیه به سیستم های با موئلفه های مستقل است که ترتیب اجرایشان از قبل مشخص شده است.
4-4 الگوهای معماری نرم افزار
مفهوم الگو ابتدا در معماری ساختمان در سال 1964 توسط Christopher Alexader مطرح شد ]زاداحمد 85[. وی کتابهایی را در رابطه با معماری ساختمان و طراحی شهری عرضه کرد. او یک کیفیت بی نامی را در میان معماری پیدا کرد و پی برد راه حلهای متفاوت خوب، در معماری، چیزهای مشترکی را با توجه به مشکل خاص دارند که او آنها را الگو30 نامید. سپس یک زبان الگو فراهم شد که یک مجموعه ای از الگوها برای محدوده مشکلی خاص در یک ترتیب مشخص بکار گرفته شد. به این ترتیب یک روش ساخت و ساز مستقل از زمان بوجود آمد.
یک الگو یک مدل یا تقلیدی از یک کار یا چیز واقعی است که توانایی ساخت مجدد موجودیتها را به کرات به ما می دهد. هر الگو یک مشکلی که چندین بار در محیط رخ داده است را شرح می دهد و سپس هسته راه حل مشکل را به روشی که شما می توانید استفاده کنید توضیح می دهد و این راه حل، میلیونها بار بدون اینکه هیچ دو باری مثل هم باشد بکار گرفته می شود.
مهندسین نرم افزار برای بسیاری از مسائل تحلیل، طراحی، پیاده سازی و…، راه حلهایی دارند. الگوها این راه حلهای آزموده شده و تست شده را بصورت بسیار قابل دسترس و در فرمی نوشتاری عالی در اختیار قرار می دهند. از اینرو الگوها کمک می کنند تا مبتدیها بتوانند بدون اینکه سالها تجربه کسب کنند در پروژه های متوسط بصورت خبره عمل نمایند و همچنین خبره ها را در طراحی سیستمهای نرم افزاری پیچیده و در مقیاس بزرگ پشتیبانی می کند.
برای تمامی مراحل دوره عمر توسعه یک نرم افزار31 الگوهایی ارائه شده است. به عنوان مثال در مرحله تحلیل سیستمهای نرم افزار، الگوهای تحلیل و در قسمت طراحی آن، الگوهای طراحی ارائه شده است. علم الگوها باعث بوجود آمدن یک روش در توسعه سیستمهای نرم افزاری بنام تحلیل و طراحی مبتنی بر الگو32 شده است. برای اطلاعات بیشتر در این زمینه به [Yacoub 03] مراجعه کنید.
4-5 سازماندهی الگوها
الگوها که در ابتدا برای ساختن ساختمانها و معماری شهرها بکار برده شده بودند به سرعت توسط کمیته توسعه نرم افزار به منظور توصیف پیچیدگی سیستمهای نرم افزاری مورد پذیرش قرار گرفت.
هرالگویی معمولا توصیفگر دسته ای از ماژولها، جلوه گر روابط و کنش و واکنش میان آنها است. از این رو، الگوها، دریایی از ماژولها را به مجموعه ای بسیار مدیریت پذیر از الگوها بدل می کنند. با توجه به تعداد زیاد الگوها، کلید اصلی شناسای الگوهای مرتبط با کار شما، رابطه بین الگوها است. به عنوان مثال، برخی از الگوها پالایشی از کلاسهای دیگرند. برای شروع سازماندهی الگوها برحسب روابط، مجموعه ای از الگوها را بوسیله دایره های کوچک نمایش می دهیم.

شکل ‏4-7: مجموعه از الگوها از [Trowbridge 03]
اگر خطی بین یک جفت از الگوها کشیده شود رابطه ای را نشان می دهد، برای مثال شکل زیر نمونه ای از روابط بین الگو ها را نمایش می دهد.

شکل ‏4-8: نمایش روابط الگوها با خطوط از [Trowbridge 03]
تقسیم الگوها به خوشه ها آنها را بسیار مدیریت پذیر نموده است. سطوح تجرد، روشی مفید برای طبقه بندی الگوها برای گروههای کاربری بمنظور یافتن الگوهای متناظر با حوزه علاقه شان است. تقسم الگوها از حالت کل به توصیف کامل به تصمیم گیری درمورد اینکه کدام الگو را بایستی مورد توجه قرار داد، کمک می نماید.
یک روش برای گروه بندی الگوها، تقسیم گراف الگو به سه لایه بصورت زیر می باشد:

شکل ‏4-9: سطوح انتزاع الگوها از ]زاداحمد 85[
4-5-1 الگوهای پیاده سازی
الگو پیاده سازی، الگو سطح پایین مخصوص پلات فرم خاصی است. الگو پیاده سازی توصیفگر چگونگی پیاده سازی جنبه های خاص موئلفه ها یا روابط میان آنها با استفاده از ویژگی های پلات فرم معین است.
4-5-2 الگوهای طراحی
یک الگو طراحی شمایی را برای پالایش زیرسیستمها یا موئلفه های یک سیستم نرم افزاری یا روابط بین آنها فراهم می نماید. توصیفگر ساختمان موئلفه های ارتباطی است که مساله طراحی عمومی را در زمینه ای خاص حل می نمایند.
4-5-3 الگوهای معماری
الگوی معماری بیانگر شمای سازمانی ساختاری پایه برای سیستم نرم افزاری است. مجموعه ای از زیر سیستمهای از پیش تعریف شده را فراهم می نماید، مسئولیتهایشان را مشخص می کند، و قوانین و رهنمودهایی را برای سازمان دهی روابط بین آنها برمی شمارد. این الگوها توصیف می کنند که یک برنامه کاربردی را چگونه در بالاترین سطح ساختمان دهی و سازماندهی نماییم.
برای معماری نرم افزار نیز همانند مراحل دیگر توسعه سیستم های نرم افزار، الگوهایی ارائه شده است. در [Buschmann 96] یک الگوی معماری اینگونه تعریف شده است: یک شَمای سازمانیِ اصولیِ ساختاری برای سیستمهای نرم افزاری بیان می کند.
یک الگوی معماری یک مجموعه از قبل تعریف شده از زیرسیستم ها و مسئولیتهای خاص آنها را فراهم می آورد و شامل قوانین و راهنمایی هایی برای سازماندهی ارتباطات بین آنها است.

الگوهایی که در [Buschmann 96] از آنها به نام الگوهای معماری نرم افزار یاد می کند، به صورت زیر دسته بندی شده است.
Interactive Systems
* Model-View-Controller (MVC)
* Presentation-Abstraction-Control (PAC)
Adaptable Systems
* Microkernel
* Reflection
From Mud to Structure
* Layers
* Pipes and Filters
* Blackboard
Distributed Systems
* Broker
* Pipes and Filters
* Microkernel
جدول ‏4-1: الگوهای معماری نرم افزار ارائه شده در [Buschmann 96]
هر الگو شامل سه قسمت اصلی می باشد. معرفی الگو، بیان مشکل موجود و ارائه راه حل. به عنوان مثال الگوی لایه ای به صورت زیر توصیف می شود:
معرفی الگو: شما با سیستمی بزرگ و پیچیده سروکار دارید و می خواهید پیچیدگی را با تجزیه مدیریت نمایید.
بیان مساله: چگونه برنامه کاربردی برای پشتیبانی نیازمندیهای اجرایی بعنوان مثال قابلیت نگهداری، استفاده مجدد، توسعه پذیری، مقیاس پذیری، نیرومندی و امنیت بسازیم؟
راه حل: راه حل را در قالب مجموعه ای از لایه ها ارائه می دهیم. لایه ها بایستی به هم پیوسته33 و در سطح انتزاع یکسانی باشد. هر لایه ای بایستی چسبندگی ضعیفی به لایه های زیرین داشته باشد..

شکل ‏4-10: الگوی لایه ای از ]زاداحمد 85[
4-6 الگوها و سبک ها
همانطور که از مفهوم، تعاریف و دسته بندی، سبک ها و الگوها دیدیم، الگوها شباهت زیادی به سبک ها دارند. الگوها در سطح معماری، همان سبک ها می باشند. یا به عبارتی دیگر الگوها در سطح معماری را سبک معماری می گویند. در [Bass 03]، الگوهای معماری را همان سبک های معماری معرفی می کند و آنها را یک مفهوم می داند.
4-7 ارزیابی و انتخاب یک سبک معماری نرم افزار
با توجه به اینکه هر روز سبکهای زیادی برای حوزه های مختلف ارائه می شود، به طور حتم برای یک حوزه مشخص، بیش از یک سبک معماری نرم افزار وجود خواهد داشت. در نتیجه باید روشهایی برای مقایسه، ارزیابی و انتخاب یک سبک معماری نرم افزار وجود داشته باشند.
ارزیابی و انتخاب یک سبک معماری نرم افزار را نباید با روشهای ارزیابی معماری نرم افزار اشتباه گرفت. ارزیابی معماری نرم افزار بعد از ارائه معماری برای یک سیستم، برای اطمینان از صحت و پوشش تمامی نیازمندیهای ذی نفعان سیستم انجام می شود. در حالی که ارزیابی سبکهای معماری نرم افزار برای انتخاب یک سبک معماری از بین چندین سبک می باشد.
روشهای مختلفی برای ارزیابی معماری نرم افزار ارائه شده است که می توانید به [Clements 02] مراجعه کنید. در ]پورکمالی 82[ نیز این روشها توضیح داده شده اند و در ]جافریان 82 [می توانید یک چارچوب برای مقایسه ای بر این روشها را ببینید.
4-7-1 پارامترهای ارزیابی سبکها
برای انجام مقایسه نیاز به پارامترهای مقایسه داریم. حال سوالی که مطرح می شود اینست که در یک حوزه مشخص، سبکهای معماری نرم افزار، بر اساس چه پارامترها و ویژگی هایی باهم تفاوت خواهند داشت. آنچه مسلم است، مشخصه های کیفی هر سبک باعث تمایز آن سبک با دیگر سبکها (در همان حوزه) خواهد بود.
به عنوان مثال در حوزه سبکهای Data-Centered دو سبک Repository و Blackboard را داریم که تمایز این سبکهای در حالی که از یک چیدمان استفاده می کنند، تفاوت در مشخصه های کیفی آنها خواهد بود. و یا در دسته سبکهای Communicating Processes دو سبک Client/Server و سبک Peer-to-Peer نیز همین وضعیت را دارند.
4-7-2 جدول ارزیابی سبکها
برای انتخاب و ارزیابی سبکهای معماری نرم افزار در یک حوزه مشخص، می توان سبکها و پارامترهای موجود را در یک جدول نمایش داد. به طوری که در سطرهای جدول، سبکهای معماری نرم افزار و در ستونهای مشخصه های کیفی را قرار داد.

شکل ‏4-11 : جدول ارزیابی سبکهای معماری نرم افزار بر اساس پارامترِ مشخصه های کیفی
باید دقت کرد که این جدول برای کلیه سبکهای معماری نرم افزار کشیده نمی شود و فقط سبکهایی که در یک حوزه قرار دارند، در یک جدول قرار می گیرند. در نتیجه به ازای هر یک از حوزه های موجود، باید یک جدول همانند جدول بالا کشیده شود.
4-7-3 تکمیل جدول ارزیابی سبکها
بعد تهیه چنین جدولی باید خانه های جدول موجود را پر کنیم. برای این کار می توانیم از یک سری از اعداد استفاده کنیم. به عنوان مثال برای سبک S1 و ویژگی کیفی Q1 عددی بین 0 تا 100 در نظر بگیریم. البته تخصیص این اعداد (کمی کردن مقدار مشخصه های کیفی) کار ساده ای نیست و متخصصان آن حوزه بر اساس مشخصه های هر یک از سبکها و مقایسه هر یک از آنها با دیگر سبکهای آن حوزه می توانند چنین اعدادی را تخصیص دهند. از روشهای دیگری نیز می توان استفاده کرد.
4-7-4 ارائه الگوریتم استفاده از جدول
بعد از تکمیل این جدول باید یک الگوریتم برای انتخاب سبک مطلوب از جدول مورد نظر معرفی شود. که معماران دیگر بر اساس این الگوریتم بتوانند سبک دلخواه خود را انتخاب کنند.
برای مشخص تر شدن موضوع ارزیابی سبکهای معماری نرم افزار یک مثال ساده شده به روش ارزیابی ارائه شده در [Mahmoud 05] می آوریم.
به عنوان مثال، فرض کنید برای یک حوزه خاص، سبکهای S1، S2 و S3 ارائه شده است. فرض کنید مشخصه های کیفی آنها با نامهای QA1 تا QA6 می باشد و ارائه کننده این سبکها جدول کمی زیر را برای آنها ارائه می کند.

QA6
QA5
QA4
QA3
QA2
QA1

2
3
2
3
2
3
S1
2
3
3
3
2
2
S2
3
3
2
3
3
1
S3
جدول ‏4-2: یک مثال برای سبکها و اعداد مربوط به هر یک از مشخصه های کیفی آنها
فرض کنیم چنین الگوریتمی برای انتخاب سبک مناسب کرده است:
1- ابتدا باید تحلیلی در مورد صفات کیفی صورت گیرد و مقادیر کمی به آن ویژگیها، با توجه به نیاز و اولویت خواسته های سهامداران و دیگر عوامل مرتبط نسبت داده شود.
2- مجموع قدر مطلق تفاضلات34 بین مقادیر صفات کیفی سیستم مورد نظر و مقادیر صفات کیفی هر سبک را به صورت مقابل بدست می آوریم. (SAD) i =
که در j تعداد صفات کیفی و i تعداد سبکها وSij درایه سطر iام و ستون jام جدول و Aj، jامین مقدار صفت کیفی است.
3- کوچکترین مقدار مجموع قدر مطلق تفاضلات، سبک مناسب را تعیین می کند.
4- اگر تنها یک سبک کوچکترین مقدار مجموع قدر مطلق تفاضلات را داشته باشد سبک مورد نظر همان است در غیر این صورت با وجود بیش از دو مقدار مساوی به صورت زیر ادامه می دهیم.
5-مجموع مربعات تفاضلات35 بین مقادیر صفات کیفی سیستم مورد نظر و مقادیر صفات کیفی هر سبک را به صورت مقابل محاسبه می نمائیم. (SSD) =
6- ضریب همبستگی بین مقادیر صفات کیفی و مقادیر صفات کیفی هر سبک که مقدار SSD آن کمترین شده است را بدست می آوریم. فرض کنید Di2 بدین صورت تعریف شود. Di2=
در این صورت ضریب همبستگی به صورت مقابل محاسبه می شود. Ri=
7- سبکی را انتخاب می کنیم که بیشترین ضریب همبستگی را با مقادیر صفات کیفی داشته باشد.
8- اگر بیشتر از یک سبک بیشترین ضریب همبستگی را داشتند، سبکی را انتخاب می نمائیم که مقدار صفت کیفی آن با صفات کیفی مهم سیستم مورد نظر یکسان باشد، به عبارت دیگر با مقایسه میان مقادیر صفات کیفی سیستم مورد نظر با سبکهایی که بیشترین ضریب همبستگی را دارند سبک مورد نظر را انتخاب می نمائیم.
حال فرض کنید مقادیر کمی صفات کیفی یک کاربر که بیان کننده میزان اهمیت آنها است به صورت جدول زیر باشد.

QA6
QA5
QA4
QA3
QA2
QA1
2
3
3
3
2
3
جدول ‏4-3: مقادیر مشخصه های کیفی که کاربر درخواست نموده است.
مقدار SAD را برای هر سبک به صورت زیر بدست می آوریم.

SAD
Style
1
S1
1
S2
5
S3
جدول ‏4-4: مجموع قدر مطلق تفاضلات محاسبه شده برای هر سبک
همانطور که در جدول بالا بدست آمد SAD برای دو سبک S1 و S2 کمترین مقدار را دارد.
در ادامه مجموع مربعات تفاضلات را برای دو سبک S1 و S2 که مقادیر SAD یکسانی پیدا کرده اند محاسبه می نمائیم، که به صورت زیر خواهد بود.

Di2
Style
1
S1
1
S2
جدول ‏4-5: مجموع مربعات تفاضلات محاسبه شده برای سبکهایی که مقدار SAD یکسانی دارند
سپس ضریب همبستگی را برای دو سبک که کوچکترین D2 مساوی را دارند محاسبه می کنیم.
R(S1,A)= R(S2,A)=
با توجه به اینکه مقدار ضریب همبستگی در هر دو مورد یکسان شد باید با توجه به اهمیت صفات کیفی و اینکه کدام یک از آنها مهم ترند و با کدام سبک همخوانی بیشتری دارند، سبک مناسب را انتخاب نمائیم. فرض کنید که ویژگی QA4 برای ما بسیار مهم است ولی QA1 چندان اهمیتی ندارد و چون سبک S2 این ویژگی را بخوبی برآورده می کند پس سبک S2 را از میان دو سبک انتخاب می کنیم.
4-7-5 مشکلات موجود
البته سوالاتی نیز در این رابطه مطرح می شود که به صورت زیر می آوریم:
1- آیا استانداردی برای حوزه ها و دسته سبکها وجود دارد. که برای ارزیابی و انتخاب سبکهای هر یک از آن حوزه، یک جدول تهیه کنیم.
2- آیا استانداردی برای مشخصه های کیفی وجود دارد. که از آنها برای ستونهای جدول استفاده کنیم.
3- آیا روشهای استانداردی برای تکمیل خانه های جدول یا برای کمی کردن مقدار مشخصه های کیفی وجود دارد.
این سوالات و سوالات دیگر، ایده ارائه یک استاندارد برای سازماندهی سبکهای معماری نرم افزار می باشد که در فصلهای آینده بیشتر به آنها خواهیم پرداخت. به این سوالات در فصلهای بعد پاسخ داده خواهد شد.

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

5. فصل پنجم ی
طرح مشکل موجود، سوابق، راهکارها و کارهای انجام شده

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

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

در نتیجه می توان مشکلات موجود را به صورت زیر بیان کرد:
1- با افزایش روز افزون سبکهای معماری نرم افزار، هیچ کنترل مرکزی و واحد برای آنها وجود ندارد. و در ارائه سبکهای نوعی پراکندگی وجود دارد.
2- عدم وجود یک کاتالوگ کامل برای سبکهای معماری نرم افزار که کلیه سبکهای معماری نرم افزار در این کاتالوگ ذخیره گردد و معماران سیستمهای نرم افزار بر اساس این کاتالوگ به سبک مورد نظر خود دست یابند.
3- برای سبکهای ارائه شده توسط گروههای مختلف، روشهای انتخاب و ارزیابی واحدی وجود ندارد.
4- برای ارائه یک سبک معماری نرم افزار به صورت یک مستند، روشی استاندارد وجود ندارد که همه از این استاندارد تبعیت کنند.
5- عدم وجود یک سری از مشخصه های کیفی استاندارد که همه ارائه کنندگان سبکها از آنها برای ارائه روشهای ارزیابی خود استفاده کنند.
و دهها مشکل دیگر که با ارائه روز افزون سبکهای معماری نرم افزار به صورت پراکنده و عدم کنترل مرکزی، معماران نرم افزار در استفاده از سبکهای معماری، امروزه و در آینده به آن دچار خواهند شد.

برای حل مشکلات ذکر شده تلاشهایی توسط گروههای مختلف انجام گرفته است و مبحث دسته بندی سبکهای معماری بوجود آمده است. برای دسته بندی سبکهای معماری نرم افزار روشهای مختلفی تاکنون ارائه شده است. که در ادامه کلیه دسته بندی های موجود، جمع آوری شده و هر یک مورد بررسی قرار می گیرد.
5-3 دسته بندی های سبکهای معماری
سبک معماری، کلاسی از معماری مختلف را نشان می دهد و در واقع تجریدی برای مجموعه ای از معماری های متناظر با آن است. Mary Shaw و David Garlan در [Shaw 96]، مستندسازی مجموعه ای از انواع سبک های دیده شده را بر عهده داشته اند و عقیده داشتند که اینکار از جهات زیر سودمند باشد:
* مستندات سبک ها، یک قالب کاری برای رسمیت بخشیدن به سبکهای معماری جدید ایجاد می کند. در واقع این مستندات سبکها را قالب دار و قانون مند و در نتیجه قابل تعریف می سازد.
* معیارهای واحدی را برای تعریف و یکپارچه سازی یک سبک فراهم می کنند.
* با ایجاد یک زمینه منطقی، راه را برای مقایسه و انتخاب بین دو یا چند سبک باز می کند.
شناخت از سبک های معماری در مراحل طراحی و آنالیز بسیار مفید می باشد. در مرحله طراحی، معمار نرم افزار می تواند سبکی را براساس ادراکی که از اهداف کیفی مطلوب از سیستم مورد ساخت دارد، انتخاب کند، تا جائیکه هدف از مستندسازی سبک های معماری، یک کتابچه راهنما خواهد بود که معمار نرم افزار می تواند از آن بعنوان مرجع (حاوی انتخاب های مختلف) جهت طراحی استفاده کند. به عنوان مثال زمانی که دو یا چند سبک معماری مشابه باشند، با مراجعه به این مرجع می توان اختلاف آنها را دریافت.

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

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

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

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

شکل ‏6-1: فرایند ایجاد یک استاندارد برای سازماندهی سبکهای معماری نرم افزار

7. فصل هفتم ی
مدلسازی فرایندهای استاندارد ارائه شده، بر اساس UML

7-1 مقدمه
در این فصل فرایند ارائه شده در فصل قبل برای استاندارد سازماندهی سبکهای معماری نرم افزار را با استفاده از روش توسعه یافته در UML، ارائه شده توسط Eriksson و Penker، مدلسازی می کنیم. اطلاعات بیشتر در مورد این روش مدلسازی را می توانید در [Eriksson 00] مشاهده کنید. از پرداختن به مفاهیم اولیه مدلسازی فرایند پرهیز می کنیم. آنها را می توانید در [Eriksson 00] ببینید.
مدلها در نرم افزار Enterprise Architect 6.1 کشیده شده اند. که این نرم افزار را به صورت Trial می توانید از www.SparxSystems.com بگیرید.
7-2 فرایند مدلسازی فرایند
مدلسازی فرایند ارائه شده برای استاندارد سازماندهی سبکها، را بر اساس فرایند زیر انجام می دهیم.
1- مدل کردن منابع کسب وکار1 مورد استفاده: در این مرحله منابع مورد نیاز برای ارائه استاندارد را جمع آوری کرده و بعد از دسته بندی بر استفاده از Object Diagram مدل کرده ایم.
2- مدل کردن اهداف کسب وکار2 : در این مرحله مدل سلسله مراتبی اهداف فرایند ارائه شده را در قالب Object Diagram ارائه کرده ایم.
3- مدل کردن Actorهای کسب وکار: Actorهای موجود را در قالب Use Case Diagram ارائه کرده ایم.
4- مدل کردن جریانهای کاری کسب وکار3 (یا فرایندهای موجود): در این مرحله فازها و قدمهای ارائه شده را در قالب جریانهای کاری با استفاده از Activity Diagram مدل کرده ایم.
5- مدل کردن خروجی های کسب وکار4 : خروجی های بدست آمده از جریانهای کاری را به صورت سلسله مراتبی در قالب Object Diagram مدل کرده ایم.
در این فصل فرایند ارائه شده در فصل ششم را با استفاده از توسعه ای که Eriksson و Penker برای مدل کردن فرایندها در UML ارائه کرده اند، مدل کردیم. برای رسم مدلهای موجود از دیاگرامهای UML و نرم افزار Enterprise Architecture 6.1 استفاده کردیم.

فصل هشتم
خلاصه، نتیجه گیری و کارهای آینده

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

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

سپس فازها و قدمهای ارائه شده را تشریح کرده و برای هر یک، کارهای انجام شده قبلی را ارائه کرده و پیشنهاداتی ارائه نموده ایم.
در فصل هفتم فرایند ارائه شده را بر اساس دیگرامهای UML مدل کردیم. مدلهای ارائه شده می تواند شروعی برای یک پروژه بزرگ توسعه استاندارد سازماندهی سبکهای معماری نرم افزار باشد. در نتیجه در ارائه مدلها از جدیدترین روش مدلسازی فرایند استفاده شده وسعی شده با بیشترین دقت انجام شود.
8-3 کارهای آینده
در این قسمت کارهای آینده، در ادامه این پایان نامه را برای هر یک از فصلهای پایان نامه ذکر می کنیم و در نهایت مهمترین کار آینده را که توسعه استاندارد ارائه شده است، توضیح می دهیم.
1- در فصل اول با توجه به بررسی انواع معماری های مختلف، می توان یک دسته بندی استاندارد برای انواع معماری های دیده شده در حوزه سیستمها ارائه کرد. که معماری نرم افزار یکی از آنها باشد و نحوه ارتباط هر یک از آنها و تاثیر هر یک بر دیگری را مورد بررسی قرار داد و در نهایت کاتالوگ آنرا به استاندارد ارائه شده اضافه کرد.
2- در فصل دوم مقایسه ای جامع بر برخی تعاریف معماری نرم افزار ارائه کردیم. روش مقایسه بر اساس تحلیل اجزاء مورد استفاده در تعاریف بود. با توجه به اینکه تعاریف بر پایه تفکر فکری و رویکرد گروههای ارائه می شوند، می توان مقایسه تعاریف را بر مبنای تفکرات فکری و رویکردهای مختلف انجام داد. اگر مقایسه ها به صورت کامل انجام شود، می توان چارچوبی برای ارائه یک تعریف کامل تر ارائه نمود و تعریف یا تعاریف آنها را به عنوان کاتالوگی استاندارد به استاندارد ارائه شده اضافه کرد.
3- در فصل سوم به بررسی مشخصه های کیفی موجود در معماری نرم افزار پرداخته، تعریف و نحوه اندازه گیری آنها را بررسی کردیم. در ادامه این فصل می توان یک روش استاندارد برای مستند کردن یک مشخصه کیفی ارائه کرد، به طوری که بتوان با استفاده از آن هر مشخصه کیفی را مستند کرده و تمامی ویژگی های یک مشخصه کیفی مانند نام، تعریف، نحوه اندازه گیری، ارتباط با دیگر مشخصه های کیفی و… را در این مستند بیاوریم. سپس با جمع آوری مستندات برای کلیه مشخصه های کیفی موجود، با استفاده از یکی از مدلهای کیفی استاندارد، یک کاتالوگ استاندارد برای مشخصه های کیفی ایجاد کرد و در نهایت کاتالوگ آن را به عنوان یک مرجع کامل به استاندارد ارائه شده افزود.
4- در فصل چهارم، بعد از معرفی سبکهای معماری نرم افزار یکی از روشهای ارزیابی سبکهای معماری نرم افزار را تشریح کردیم. می توان با مراجعه به کتابها و مقالات مختلف، کلیه روشهای ارزیابی سبکهای معماری نرم افزار را جمع آوری کرده و بعد از مقایسه آنها، کاتالوگ کامل آنرا به عنوان راهنمایی برای ارائه روشهای ارزیابی جدید به استاندارد ارائه شده اضافه کرد.
5- در فصل پنجم تنها به بررسی مشکل موجود و کارهای انجام شده قبلی پرداخته ایم.
6- در فصل ششم، یک فرایند برای ایجاد یک استاندارد برای سازماندهی سبکهای معماری نرم افزار ارائه نمودیم و در فصل هفتم فرایند ارائه شده را بر اساس UML مدل کردیم. این فرایند در چهار فاز ارائه شده است که هر یک شامل چندین قدم می باشد. در کل 11 مرحله برای ایجاد این استاندارد ارائه کردیم و تک تک آنها را مورد بررسی قرار داده و کارهای قبلی انجام شده را آورده و برای برخی موارد پیشنهاداتی ارائه کردیم. در کل، توسعه کامل این استاندارد را می توان به عنوان کارهای آینده این پایان نامه ذکر کرد. هر یک از تک تک 11 مرحله می تواند به عنوان یک کار آینده مطرح گردد. به عنوان مثال تک تک 11 مرحله می توانند به عنوان پایان نامه کارشناسی یا کارشناسی ارشد مطرح گردند. تک تک 11 مرحله معرفی شده را می توان به روشهای دیگر نیز انجام داد. به عنوان مثال، برای مستند کردن سبکهای معماری نرم افزار روش [Clements 02-1] را پیشنهاد دادیم. می توان از زبانهای توصیف معماری (ADL1ها) نیز در این زمینه استفاده کرد.
7- برخی دیگر از فیلدها در زمینه معماری نرم افزار مانند روشهای رسمی2، وجود دارد که از آنها در فرایند ایجاد استاندارد، استفاده ای نکردیم. می توان ارتباط استاندارد ایجاد شده را با دیگر مفاهیم موجود در معماری نرم افزار بیشتر مورد بررسی قرار داد، تا استاندارد تکمیل تر شود.
8- از دیگر کارهای آینده مربوط به این پایان نامه، می توان به معرفی یک استاندارد مشابه برای دیگر الگوهای موجود در مهندسی نرم افزار اشاره کرد. به عنوان مثال همین وضعیت موجود برای الگوهای معماری (یا سبکهای معماری نرم افزار)، در الگوهای طراحی نیز داریم. می توان از این استاندارد ایده گرفته و برای سازماندهی الگوهای طراحی (یا الگوهای دیگر) نیز استانداردی مشابه تعریف کرد.
9- سوالی که در رابطه با مستند کردن هر سبک معماری نرم افزار مطرح می شود اینست که آیا ارائه یک روش واحد مستند کردن سبک برای کل سبکها مناسب است؟ این موضوع را می توان بر اساس انواع سبکهای ارائه شده در استاندارد مورد بررسی قرار داد و استاندارد مستند کردن هر سبک را تکمیل یا تصحیح نمود.
10- سوالی دیگری در رابطه با مدلهای کیفی معماری نرم افزار مطرح می شود اینست که آیا ارائه یک مدل کیفی واحد برای کل استاندارد مناسب است؟ این موضوع را نیز می توان برای انواع سیستمهای ارائه شده مورد بررسی قرار داد. ممکن است ارائه مدل کیفی واحد برای کل استاندارد مناسب نباشد و مثلاً برای هر نوع سیستم خاص مدل کیفی مجزاء مناسبتر باشد.

در کل برای توسعه و پیاده سازی کامل استاندارد ارائه شده، تاسیس یک سازمان به همراه تیمهای مختلف از حوزه های مختلفی از انواع سیستمهای نرم افزاری، پیشنهاد می شود.
8-4 در نهایت
عامل موفقیت، در کار گروهی و هدفمند می باشد. در این پایان نامه فرایندی برای توسعه یک استاندارد برای سازماندهی کلیه سبکهای معماری نرم افزار ارائه شد. امید است با تشکیل یک گروه شامل تیمهای مختلف، این استاندارد در کشور عزیزمان ارائه، توسعه، بهبود و پشتیبانی گردد.

منابع و مراجع

[Abowd 97] G. Abowd, L. Bass, P. Clements, R. Kazman, L. Northop, and A. Zaremski, "Recommended Best Industrial Practice for Software Architecture Evaluation", Technical Report, CMU/SEI-96-TR-025, 1997.

[ACM 06] The ACM Computing Classification System, Publications Dept., ACM, Inc , 2006, see http://www.acm.org/class/1998/ccs98.html

[Albin 03] S.T. Albin, the Art of Software Architecture: Design Methods and Techniques, 2003.

[Arlow 03] J. Arlow, I. Neustadt, Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, 2003.

[Astudillo 04] H. Astudillo, Five Ontological Levels to Describe and Evaluate Software Architectures, Departamento de Informática, Universidad Técnica Federico Santa María
Avda.España 1680, Valparaíso, Chile, 2004

[Barbacci 95] M. Barbacci, M.H. Klein, T.A. Longstaff, C.B. Weinstock, Quality Attributes, Technical Report, CMU/SEI-95-TR-021 ESC-TR-95-021, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1995

[Bass 03] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition, Addison-Wesley, 2003.

[Berander 05] P. Berander, L.O. Damm, J. Eriksson, T. Gorschek, K. Henningsson, P. Jönsson, S. Kågström, D. Milicic, F. Mårtensson, K. Rönkkö, P. Tomaszewski, Software Quality Attributes and Trade-Offs, Blekinge Institute of Technology, June 2005

[Booch 98] G. Booch, J. Rumbaugh, and I. Jacobson, UML User Guide, Addison-Wesley Longman, 1998.

[Buschmann 96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern Oriented Software Architecture: A system of Patters, Wiley Press, 1996

[Buschmann 00] F. Bachmann, L. Bass, J. Carriere, P. Clements, D. Garlan, J. Ivers, R. Nord, R. Little, Software Architecture Documentation in Practice: Documenting Architectural Layers, SPECIAL REPORT, CMU/SEI-2000-SR-004, March 2000

[Clements 02] P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2002.

[Clements 02-1] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford, Documenting Software Architecture, Addison Wesley, 2002.

[Crnkovic 02] I. Crnkovic, M. Larsson, Building Reliable Component-Based Software Systems, Artech House, 2002

[Eriksson 00] H.E. Eriksson, M. Penker, Business Modeling with UML: Business Patterns at Work, John Wiley & Sons, 2000

[Fielding 00] R.T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, 2000

[Fitzpatrik 96] R. Fitzpatrik, Software Quality: Definitions and Strategic Issues, Staffordshire University, School of Computing Report, April 1996

[Fowler 02] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002.

[Garlan 94] D. Garlan, and M. Shaw. An Introduction to Software Architecture, Technical Report, CMU/SEI-94-TR-21, 1994.

[Garland 03] J. Garland, R. Anthony, Large-Scale Software Architecture, Wiley Press, 2003.

[Hawthorne 05] M.J. Hawthorne, D.E. Perry, Architectural Styles for Adaptable Self-Healing Dependable Systems, 2005

[IEEE 1044-02] IEEE Standard Classification for Software Anomalies. Technical Report IEEE P1044-1993 R2002, IEEE Standards Department, Software Engineering Standards Committee, September 2002.

[IEEE 1471-00] Recommended Practice for Architectural Description of Software Intensive Systems. Technical Report IEEE P1471-2000, IEEE Standards Department, The Architecture Working Group of the Software Engineering Committee, September 2000.

[Jahnke 02] J.H. Jahnke, D.M. German, J.P. Wadsack, Architectural Patterns for Data Mediation in Web-centric Information Systems, Department of Computer Science University of Victoria, 2002

[Kaisler 05] S.H. Kaisler, Software Paradigms, John Wiley & Sons, 2005

[Kircher 04] M. Kircher, P. Jain, Pattern Oriented Software Architecture: Patterns for Resource Management, Volume 3, John Wiley & Sons, 2004

[Klir 91] G. Klir, Facets of System Science, Plenum Press, 1991.

[Kolp 01] M. Kolp, J. Mylopoulos, Architectural Styles for Information Systems: An Organizational Perspective, 2001

[Land 01] R. Land, Architectural Solutions in PAM, Master thesis, Computer Science, NAVI-PAM Project Group, 2001

[Langdon 03] C.S. Langdon, Information Systems Architecture Styles and Business Interaction Patterns: Toward theoretic correspondence, Information Systems and e-Business Management, Springer Verlag, 2003

[Mahmoud 05] M.S. Mahmoud, M.M. Shaban, A Framework of Architectural Styles for Distributed Business Information Systems, IJICIS, Vol. 5, No. 1, July 2005

[McGovern 03] J. McGovern, S.W. Ambler, M.E. Stevens, J. Linn, V. Sharan, E.K. Jo, Practical Guide to Enterprise Architecture, 2003

[Mellor 04] J.S. Mellor, K. Scott, A. Uhl, D. Weise, MDA Distilled: Principles of Model-Driven Architecture, 2004

[Morisawa 02] Y. Morisawa, K. Inoue, K. Torii, Architectural Styles for Distributed Processing Systems and Practical Selection Method, 2002

[Perry 92] D.E. Perry, A.L. Wolf, Fundations of the study of Software Architecture, ACM Sigsoft, Software Engineering Notes vol 17 no 4, Oct 1992.

[Petrasch 99] R. Petrasch, The Definition of ‚Software Quality': A Practical Approach, FastAbstract ISSRE, 1999

[Pressman 01] R.S. Pressman, Software Engineering – A Practitioner's Approach, McGraw-Hill, 2001.

[RUP 03] P. Kruchten, the Rational Unified Process: An Introduction, Third Edition, Addison-Wesley, 2003.

[Ryoo 05] J. Ryoo, H. Saiedian, A Sramework for classifying and Developing Extensible Architectural Views, Article in Press, Elsevier, 2005

[SEI 05] Software Engineering Institute (SEI), Carnegie Mellon University, How Do You Define Software Architecture, from www.sei.cmu.edu/architecture/definitions.html

[Sessions 03] R. Sessions, J. Van Sickler, Software Fortresses: Modeling Enterprise Architectures, 2003

[Shaw 96] M. Shaw, D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996.

[Shaw 97] M. Shaw, P. Clements, Toward Boxology: Preliminary Classification of Architectural Styles, Carnegie Mellon University, Pittsburgh, PA 15213, 1996

[Souza 99] D.F.D. Souza, A.C. Wills, Objects, Components, Frameworks with UML: the Catalysis Approach, Addison-Wesley, 1999.

[Trowbridge 03] D. Trowbridge, D. Mancini, D. Quick, G. Hohpe, J. Newkirk, D. Lavigne, Enterprise Solution Patterns Using Microsoft .NET, Microsoft Corporation, 2003

[Widhani 02] A. Widhani, S. Böge, A. Bartelt, W. Lamersdorf, Software Architectures and Patterns for Electronic Commerce Systems, University of Hamburg, Department of Computer Science, 2002

[Yacoub 03] S.M. Yacoub, H.H. Amar, Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems, Addison-Wesley, 2003

]امربر 82[ ر. امربر، پایان نامه کارشناسی ارشد، دانشگاه آزاد اسلامی، ارائه مدلی برای معماری مرجع راهکار، 1382

]ایزایران 81[ سمینارهای آموزشی معماری سازمان، C4ISR به روش ساخت یافته، شرکت ایزایران، 1381

]پورکمالی 82[ م. پورکمالی انارکی، سمینار کارشناسی ارشد، دانشگاه آزاد اسلامی، روشهای ارزیابی معماری نرم افزار، 1382

]جافریان 82[ ا. جافریان، پایان نامه کارشناسی، دانشگاه امیرکبیر تهران، ارائه چارچوب AES-AKU برای روشهای ارزیابی معماری نرم افزار، 1382

]فتح اللهی 81[ ع. فتح اللهی، سمینار کارشناسی ارشد، دانشگاه شهید بهشتی، انطباق چارچوب معماری سازمانی فدرال با امکانات نرم افزار System Architect ، 1381

]زاداحمد 85[ م. زاداحمد، سمینار کارشناسی ارشد، دانشگاه آزاد اسلامی واحد جنوب، الگوهای راه حل پیاده سازی نرم افزارهای سازمان ، 1385
1 Rational Unified Process (RUP)
1 Stakeholders
2 Elements
3 Hierarchical
4 System Theory
5 Architecture Frameworks
6 Federal Enterprise Architecture Framework (FEAF)
7 Command Control Communication Computing Intelligence Surveillance Reconnaissance (C4ISR)
8 Treasury Enterprise Architecture Framework ( TEAF)
9 The Open Group Architecture Framework (TOGAF)
10 Framework
11 Metadata
12 Process Centered
13 Data Centered
14 Entities
15 Relationship
16 Public
17 Business Process Reengineering (BPR)
18 Enterprise Resource planning (ERP)
19 Custom Relation Management (CRM)
20 Management Information Systems (MIS)
21 Supply Chain Management (SCM)
22 Service Oriented Architecture (SOA)
23 Model Driven Architecture (MDA)
1 Universally Accepted
2 Divide and Conquer
3 Collaboration
4 Connectors
5 Support
6 Static Framework
7 Component Parts
8 Constraint
9 Rationale
10 Modules
11 Module Components
12 Architectural Elements
13 Observer
14 DFD, Data Flow Diagram
15 Architectural Elements
16 Invisible
17 Visible
18 Properties
19 Behaviors
20 Relationship
21 Inter-Relationship
22 Intra-Relationship
23 Hierarchical
24 Large-Scale
25 Stakeholder
26 Action
27 Abstract Machine
28 Meta Model
29 Subject
30 Reality
31 Factor
32 Act and React
33 Intrinsic
34 Extrinsic
35 Attribute
36 Public Methods
37 Level
38 Hierarchy
1 Critical Applications
2 Failure
3 Evolutionary Upgrade
4 Functional Requirements
5 Non-Functional Requirements
6 Quality Attributes
7 Fault Tolerance
1 Architectural Patterns
2 Topology
3 Specialization
4 Data Centered
5 Ability of Integration
6 Client
7 Scalable
8 Modifiability
9 Performance
10 Data Flow
11 Reusability
12 Virtual Machine
13 Portability
14 Platform
15 Interpreter
16 Rule-Based
17 Call & Return
18 Scalability
19 Main Program and Subroutine
20 Remote procedure call
21 Object Oriented
22 Inheritance
23 Polymorphism
24 Layered
25 Independent Components
26 Heterogeneous
27 Lacationally
28 Herarchically
29 Simultaneously
30 Pattern
31 Software Development Life Cycle (SDLC)
32 Pattern Oriented Analysis and Design
33 Cohesive
34 – Sum Of Absolute Differences (SAD)
35 – Sum Of Squares Of Differences (SSD)
1 Business Resources
2 Business Goals
3 Business Workflows
4 Business Outcomes
1 Architecture Description Languages (ADL)
2 Formal Methods
—————

————————————————————

—————

————————————————————