پایان نامه استفاده از کارت های CRC در معماری کلان

تعداد صفحات: 145 فرمت فایل: word کد فایل: 10001988
سال: 1385 مقطع: مشخص نشده دسته بندی: پایان نامه مهندسی کامپیوتر
قیمت قدیم:۲۱,۱۰۰ تومان
قیمت: ۱۹,۰۰۰ تومان
دانلود فایل
  • خلاصه
  • فهرست و منابع
  • خلاصه پایان نامه استفاده از کارت های CRC در معماری کلان

    پایان نامه کارشناسی ارشد

    رشته مهندسی کامپیوتر- نرم افزارM.Sc))

    چکیده 

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

    سیستمهای نرم افزاری بزرگ و حجیم امری ضروری محسوب می شود. با افزایش حجم برنامه های

    کاربردی و با پیچیده تر شدن آنها, مشکلات طراحی و ساخت , بخصوص توسعه و نگهداشت پیش می

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

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

    جای تمرکز روی کد, میدان  دید وسیع و سطح تجرید بالاتر رفته و طراحی روی  ساختار سطح بالای

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

    از سوی دیگر تولید نرم افزار کاری است که هزینه و زمان زیادی را می طلبد پس بنابراین

    باید قبل از صرف هزینه و زمان اضافی از مطلوب بودن معماری اطمینان حاصل نمود. این کار نیز از

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

    یکی از مشکلات و معضلاتی که در زمینه روشهای ارزیابی براساس سناریو وجود دارد فقدان

    ابزاری برای یافتن سناریو و تمرکز بیشتر در این زمینه است. در این تحقیق این موضوع مورد توجه

    قرار گرفته است. راه حل ارائه شده مبتنی بر ایده استفاده از ابزار ساده ای بنام کارتهای [1]CRC است

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

    این کارتها با افزایش تعامل بین ذینفعان باعث بالا رفتن دقت و سرعت آنها در بدست آوردن

    سناریوهای ارزیابی شده و علاوه براین با توجه به افزایش تعامل ذینفعان باعث تفهیم بیشتر معماری و در

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

    در راه حل ارائه شده در این پایان نامه ابتدا معماری و مستندات اولیه آن مورد مطالعه قرار

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

    بدست آوردن سناریوهای ارزیابی سیستم ارائه می شود. در بدست آوردن سناریوها از ابزاری بنام

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

    حل با مدلسازی کارتهای سناریو  هر ذینفعی سناریوی مورد نظر خود را در کارتها نوشته و طبق قالب

    پیشنهادی این کارتها, اطلاعات مربوط به کارتها را پر می کند و سپس از طریق کارتهای جمع آوری

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

    یابد. 

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

    است. اما علیرغم این مطالعات هنوز جای انجام کارهای زیادی در زمینه استفاده از ابزارهای ساده

    مانند کارتهای شاخص در زمینه معماری نرم افزار وجود دارد که بعنوان راههای آینده در انتهای پایان

    نامه پیشنهاد شدهاند. 

    فصل اول

    معرفی 

    1-1-  مقدمه 

    با وجود اینکه مدت زمان زیادی از همگانی شدن استفاده از کامپیوتر نمی گذرد ولی شاهد این

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

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

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

    طراحی آنها نمی توان روش سنتی را بکار برد و به مسئله معماری توجه نکرد. بعبارتی دیگر برای اینکه

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

     در اوایل, بکارگیری کامپیوترها در تولید نرم افزارهای مورد تقاضا, کار مشکلی نبود ولی به مرور

    زمان و پیشرفت فرهنگ بکارگیری کامپیوتر, سیستمهای نرم افزاری مورد تقاضا حجیم تر و پیچیده تر شد

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

    روشن است که روز به روز تقاضای تولید نرم افزار بیشتر می شود و در این میان این تقاضاها به

    سمت کارهای پیچیده تر می رود. بعبارتی پس از گذشت چند دهه پیچیدگی نرم افزار بصورت افزایشی

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

    دارند و همانطور که Booch در سال 1999 و Kruchten در سال 2000در [14] اشاره کردند

    همچنانکه که ما نمی توانیم همان روشهای استفاده شده در ساخت خانه های معمولی را برای ساخت

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

    بطور کلی با پیچیده شدن سیستم ها نیاز به معماری احساس می شود. در این مورد Garlan نیز می

    گوید : همانطور که اندازه و پیچیدگی سیستم های نرم افزاری افزایش پیدا می کند مسئله طراحی ماوراء

    ساختمان داده ها و الگوریتم ها حرکت می کند و طراحی و تعیین ساختار کلی سیستم بعنوان نوع

    جدیدی از مسئله  آشکار می شود که به آن  معماری نرم افزار می گویند [8]. در  واقع می توان گفت که

    معماری همانند یک پل مهم و اصلی بین نیازمندیها و طراحی می باشد[19و8]. 

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

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

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

    واضح است که پیچیدگی یک قضیه و مسئله کلیدی در سیستمهای امروزی  است که ما دوست

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

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

    1 – تمردپذیری فکری یا پیچیدگیهای ذاتی نرم افزار به این معنی است که در نرم افزار با نوعی پیچیدگی

    به نام پیچیدگی ذاتی روبه رو هستیم که در ابعاد مختلف از جمله در تعریف نرم افزار و  مراحل تحلیل و

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

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

    کاری انجام داد و همچنین نمی توان آن را از بین برد، چون این پیچیدگی ذاتی است و اکتسابی نیست،

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

    معماری نرم افزار باید از طریق ایجاد سطوح تجرید , یکسان سازی و ساده نمودن مفاهیم ,تجزیه مناسب

    سیستم, سیستم را قابل فهم نموده و مدیریت فکری روی آن داشته باشد [15]. 

    2-  تمرد پذیری مدیریتی یا پیچیدگی کنترل عوامل تولید کننده نرم افزار  ناشی از اندازه پروژه , تعداد

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

    افزار قابل کنترل نیستند. غیر قابل کنترل بودن عوامل به این دلیل است که عوامل آن انسانی هستند ، پس

    کنترل آن مشکل بوده و می توان گفت که به سمت کنترل  ناپذیری میل می کند. پس می گوییم که در

    اینجا عوامل انسانی نقش کلیدی را دارند و سرمایه گذاری در آن از نوع مواد و ماشین آلات و دستگاه و

    پول نقد نیست و یک سری عوامل انسانی هستند که تحت کنترل مدیریت قرار می گیرند و این مسئله

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

    تیمهایی که از نظر جغرافیایی پراکنده هستند, پیچیدگی را افزایش می دهند. معماری نرم افزار می تواند

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

    کردن وابستگیها و غیره آسان نماید[15]. 

    با توجه به مواردی که بیان شد می بینیم که معماری با خصوصیاتی که دارد هر دو پیچیدگی (تمردپذیری فکری، تمردپذیری مدیریتی) را از بین می برد، چون معماری سیستم را به مولفه ها تجزیه

    می کند که این باعث ایجاد یک سطح تجرید و پنهان ماندن جزئیات غیر ضروری در موارد لازم می

    شود. معماری باعث یکسان شدن مفاهیم می شود، چون مولفه ها مانند IC ها عمل می کنند و باعث

    یکسانی و سادگی می شوند و چون سیستم به اجزاء کوچکتر تجزیه می شود، پیچیدگی این اجزا کمتر

    می شود و قابل فهم تر می شوند.  

    معماری وابستگی به نیروی انسانی را کاهش می دهد چون کل مراحل کار از ابتدا به صورت

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

    کار کند. 

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

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

    در یک جمع بندی می توان گفت که علاوه بر نیاز به معماری در سیستمهای پیچیده, بطور کلی در

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

    حجم بزرگ 

    پیچیدگی

    تقاضای پروژه از طرف مشتری و انجام کار به سفارش مشتری

    انعطاف پذیری

    تعامل با سیستمهای دیگر 

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

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

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

    است[38]. 

    با دانستن نیازهای کامل یک سیستم می توان معماری آن را بوجود آورد. اما لازم است بدانیم که

    با این نیازها نمی توان معماری یکسان را از طریق معماران متفاوت, انتظار داشت. بعبارتی نیازهای یک

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

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

    درپیاده سازی معماری بدست آمده , روشی وجود داشته باشد تا محصول (معماری)ارزیابی شود. 

    ارزیابی معماری بستگی به این دارد که تصمیمات کلیدی معمار, روی ویژگیهای کیفیتی درست

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

    قبل از ساخت محصول نرم افزاری  ارزیابی نمود. 

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

    است که ارزیابی معماری از نظر هزینه و زمان اهمیت داشته و باید روشی و ابزاری برای ارزیابی انتخاب

    شود تا نتیجه مطلوبی را به دنبال داشته و سیستم را  دچار ضرر و زیان نکند. 

    ارزیابی معماری یک چالش مهمی است که باید هر چه زودتر انجام گیرد تا از اتلاف زمان و

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

    همیشه بدنبال راههایی هستند که پیش از تولید نرم افزار و قبل از پرداخت هر گونه هزینه تولید, سیستم را

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

     

    2-1 تعریف مسئله 

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

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

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

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

    هزینه و زمان صرف شده برای آن سیستم هدر خواهد رفت و در نتیجه رضایت ذینفعان را نیز درپی

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

    در واقع مسئله اصلی اینستکه چگونه می توان پیش از تولید یک سیستم نرم افزاری و از طریق

    مستندات و اطلاعات اولیه, آن را ارزیابی و تحلیل نمود و مسئله مهم تر اینستکه در امر ارزیابی براساس

    سناریو از چه روشی استفاده شود که سناریوها با سرعت و دقت بیشتر فراهم شود و طوری باشد که با

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

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

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

    پیشبرد موفقیت آمیز یک پروژه معماری نرم افزار خواهد نمود. در این بین چالشهای خاصی وجود دارد

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

    کارتها, هنوز  جایگاهی در معماری نیافته است. 

    در این تحقیق به ارائه کاربرد کارتهای شاخص در امر ارزیابی معماری نرم افزار پرداخته شده

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

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

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

    نرم افزار براساس سناریوها به ارمغان می آورند.  

     

    Abstract:

     

       Software architecture is an important step of software engineering process which is necessary to produce in huge software project. By increasing application size and complexity, some problem might appear in design, construction, and especially in development and maintenance, of these applications, so one method to solve this problem use software architecture.    Systems which are based on architecture no longer use traditional methods and instead of concentrating on codes concentrate more on designs, and abstraction is on higher level of system structure. In other word software architecture concentrate on high level structure and large part of system, connectors and interacts and also it ignore details, then system abstraction level increase and developer will be release of  thinking to details so they can think more on components, interfaces and connectors to have acceptable and better software design.

       Software architecture is a process which needs lots of time and cost so we should be confident about the quality of architecture before developing the software to not to pay any extra time or cost and this affair become in truth by methods of evaluating of architecture. One of the architecture evaluation method is evaluation based on scenario; however these methods are not error prone.

       A kind of problem in software evaluation methods is lake of tools in scenario finding and is lake of concentration on this field which will discuss in detail in this paper. The solution is based on simple tools idea that is called CRC cards or index cards.

       These cards increases interaction between stakeholders and in result they can achieve scenarios evaluation with high speed and focus and also they can understand architecture and the software much better.

       To prove the theory of index cards some research has done but it has steel lots of place to do more research on these simple tools which presented at the end of this paper.   

  • فهرست و منابع پایان نامه استفاده از کارت های CRC در معماری کلان

    فهرست:                                                                                                      

    چکیده .....................................................................................................................1 

    فصل اول – معرفی .................................................................................................. 3 

    1 مقدمه ................................................................................................................... 4  

    تعریف مسئله ........................................................................................................ 9 

    سابقه تحقیق .........................................................................................................10 

    خروجی ها .......................................................................................................... 13 

    1-5ساختار پایان نامه ................................................................................................. 14

    فصل دوم – آشنایی با ادبیات تحقیق ...................................................................... 15

    1-2مفاهیم پایه معماری ............................................................................................. 16

    1-1-2 معماری ................................................................................................... 17

    2-1-2 معماری نرم افزار .................................................................................... 18

    2-2 ویژگیهای کیفیتی نرم افزار ................................................................................  22

    1-2-2 ویژگی کارایی ........................................................................................ 25

    2-2-2 ویژگی امنیت ......................................................................................... 26

    3-2-2 ویژگی در دسترس بودن ....................................................................... 27

    4-2-2 ویژگی قابلیت عملکرد ........................................................................ 28

    5-2-2 ویژگی قابلیت استفاده ......................................................................... 28

    6-2-2 ویژگی قابلیت اصلاح ......................................................................... 29

    7-2-2 ویژگی قابلیت حمل ............................................................................ 31

    8-2-2 ویژگی قابلیت استفاده مجدد................................................................ 31 

    9-2-2 ویژگی قابلیت تجمیع.............................................................................32

    10-2-2ویژگی قابلیت آزمایش..........................................................................32

    3-2 بررسی ویژگیهای کیفیتی معماری نرم افزار از نگاهی دیگر ............................. 33 

    3- 2-1 مثال: سناریو دسترس پذیری...................................................................36

    4 ارزیابی و تحلیل معماری ..................................................................................38

    2- 4-1 تکنیکهای اندازه گیری .......................................................................... 42

    2- 4-2 تکنیکهای پرسشی...................................................................................43 

    2- 4-3 روشهای ارزیابی معماری مبتنی بر سناریوها.......................................... 46

    و

    2- 5 کارتهای CRC....................................................................................................50

    2- 5-1 قابلیت رسمیت دادن به کارتهای CRC...................................................53

    2- 5-2 بیان مسیر................................................................................................. 54

    2- 5-3 کارتهای رسمیت یافته................................................................................55

    2- 6 کارتهای CRC در معماری نرم افزار  .................................................................57 

    2- 6-1 نقش مورد کاربری در معماری  ................................................................59 

    2- 6-2 کارتهای CRC و استفاده از ایده آن در مورد کاربری ..............................59. 

    2- 6-3 استفاده از کارتها برای مولفه های معماری ................................................62

    2- 7 خلاصه  ...........................................................................................................64

    فصل سوم- اهمیت سناریوها .................................................................................67 

    1-3 مدل دید 4+1 (مدلkruchten  ) ..........................................................................67 

    2 انواع سناریوها در معماری.........................................................................................73 

    3- 3 سناریوها در روشهای تحلیل معماری........................................................................75 

    4 خلاصه  ................................................................................................................... 77 

    فصل چهارم-  کاربرد کارتهای شاخص(سناریو) در استخراج  سناریوها..................... 79 

    1 کارتهای شاخص یا کارتهای سناریو سناریو...............................................................82

    4- 2 استفاده از کارتهای شاخص (سناریو)در استخراج سناریوها......................................82 

    4- 3 مدلسازی کارتهای شاخص و مراحل آن....................................................................84

    4- 4 خلاصه  .....................................................................................................................89 

    فصل پنجم-  مطالعه مورد .... .....................................................................................................92 

    ز

    1-5سیستم مورد مطالعه  .....................................................................................................92

    2-5بررسی سیستمی دیگر  .................................................................................................98 

     99................................................  Subordinate Agent توصیف مولفه های 1-2-5

     101 ...................................................  Maneger Agent توصیف مولفه های 2-2-5

    3-5 بررسی سیستم کنترل تجدید نظر ..............................................................................108 

    1-3-5 تعیین معماری و سناریوها ...................................................................................108 

    5- 4 خلاصه  ....................................................................................................................113 

    فصل ششم – نتیجه گیری ................................................................................................... 114 

    1-6 آیا سناریوها در روشهای ارزیابی تکنیک مناسبی هستند؟ .......................................116

    2-6 کارتهای CRC چه میزان در مهندسی و معماری نرم افزار مفید می باشند؟............118 

    3-6 جایگاه کارتهای شاخص در روشهای ارزیابی براساس سناریو چیست؟ ..... ...........119

    4-6 مقایسه روش پیشنهادی با روشهای موجود ............................................................ 120 

     6- 5 مزایای روش پیشنهادی ...........................................................................................122

    6- 6 معایب روش پیشنهادی ............................................................................................123

    6- 7 فرصتهای آینده .........................................................................................................125 

    فهرست منابع و مراجع .........................................................................................................125

     

    منبع:

      

    [1]        Akogrimo consortium . 2005 . Architecture evaluation and assessment , Dissemination level: public 2005

    [2]        Arnold , K. AND Gray  AND  Guzdial ,M. AND Rugaber ,S.2002 . extending CRC

    Cards into a Complete Design Process

    [3]        Baba, M.A. AND Gorton,I. AND Jeffery,R. 2005 . Toward a Framework for Capturing and using Architecture Design knowledge , National ICT AustraliaLtd, (June)

    [4]        Bahsoon ,R. AND Emmerich ,W. 2003 . evaluating software   architectures:

    development, stability, and evolution

    [5]        Baker, Donna L. AND Bufkin, M. AND Carson , H. Tom .2005. architecture , engineering and construction  

    [6]        Barbacci, M. AND Clements, P. AND Lattanze,A. AND Northrop,L. , Wood,W. 2003 . Using Architecture Trade off Analysis Method(ATAM) to Evaluate the Software

    Architecture for a product line of Avionics Systems A case study ,( July)

    [7]        Barbacci , M. R. 2002 . SEI Architecture Analysis Techniques and when to use them

    ,Carnegie Mellon Software Architecture Institute  

    [8]        Bass,L., AND Clements, P. AND Kazman, R. 2003 . Software Architecture in Practice , second edition

    [9]        Bass,L. AND Kazman, R. .1999 . Architecture-based Development , Technical Report

    ,(April )

    [10]    Bass,L. AND Kazman,R. AND Abowd,G. AND Clements,P. 1999 Scenario-Based

    Analysis of Software Architecture

    [11]    Biddle ,R. AND Noble ,J. AND Tempero ,E. 2001 . Reflection on CRC Cards for OO

    Design ,Technical Report, (Auguest)

    [12]    Biddle ,R. AND Noble ,J. AND Tempero ,E. 2002 .  From Essential use cases to objects

    [13]    Borstler ,J. AND Umea university AND Sweden . 2004 . Classes or Objects? CRC-

    Cards Considered Harmfull

    [14]    Bredemeyer Consulting .2002. Architecture Resources for Enterprise Advantage. white paper

    [15]    Bredemeyer ,D. AND Malan,R. 2002 . Software Architecture: Central         Concerns key decisions . (MAY)

    (http://www.bredemeyer.com/pdf_files/ArchitectureDefinition.PDF)

    [16]    Carnegie Mellon Software Architecture Institute . 2003 .  Cost Benefit Analysis

    Methods(CBAM)

    [17]    chilcott , D. 2001 . 7-Steps for Building an Information System” , Outformations , Inc

            [18]Clement,P.    AND    Kazman,R.    AND    Klein    .    2002    .     Evaluating    Software

    architectures:methods and case studies , Adison Wesely

    [19] Craig AND Damon , A. 2005 . Software Engineering Course Notes. ,Fall 

    [30]Dobrica,L. AND Niemelae, E. 2002 .  A Survey on Software Architecture Analysis

    Methods ,  IEEE Computer Society, (July) 

    [21]    Garlan,D. 2002 . software Architecture: a Roadmap , school of computer scince carniegie Mellon university

    [22]    Houari,N. AND Ekaette,E. AND Wu,W. AND H.far,B. AND Rochefort, S. 2003 .

    Architectural Evaluation of a Distributed Agent System for Network fault

    Management ,2nd ASERC Workshop on software architecture

     

    [24]     Jacobson,I. AND Booch,G. AND Rumbaugh,J. .1999 . the Unified Software

    Development Process , Rational software Corporation, first edition

    [25]     Kazman,R. 1999 . Using Scenario in architecture evaluation

    [26]     Kazman,R. AND Klein,M. AND Clements,P. 2000 , ATAM:Method of architecture evaluation , Technical report in carnegie Mellon Software Achitecture Institude ,

    (August )

    [27]     Kruchten,P. 1995 . The 4+1 view Model of Achitecture , IEEE

    [28]     Object Oriented Design . Study book, faculty of Sciences, 2002  

    [29]     Perry , D. AND Wolf,A. . 1992 . Foundation for the Study of Software Architecture , 

    SIGSOFT Software Eng. Notes

    [30]     Rank , S. 2005 . Architectural Reaction for Software Evolution Department of

    Computing and Informatics, University of Lincoln ,(30th June)

    [31]     Rees ,O. 1993 .Using Path Expressions as Concurrency Guards

    [32]     Roach, S. AND Vasquez ,J. 2004 . A Tool to Support the CRC Design Method  ,

    International Conference on Engineering Education , (21 October)

    [33]     Ronald , A. Grace AND Coleman,D. AND Ogush,M.A. AND Rhodes,  S. ,  AND

    Hewlett-Packard Product Generation Consulting . 2000 . Experience with

    Documentation of Software Architectures

    [34]     Scott  AND Ambler ,W.  1999 . Modeling Bridging the Communication Gap Between

    [35]     Shams Aliee ,F. 1996 . Modelling The Behaviour of Processes Using Collaborating

    Objects , a thesis , (may )

    [36]     Sun,CH. 2003 . QOS COMPOSITON AND DECOMPOSITON MODEL IN

    UNIFRAME .  a Thesis , Submitted to the Faculty of  Purdue University, In Partial

    Fulfillment of the Requirements for the Degree of  Master of Science, (August)

    [37]     Tekinerdogan,B. 2003 . ASAAM: Aspectual Software Architecture Analysis Method ,

    Department of Computer Engineering, Bilkent University, Bilkent 06800, Ankara,

    Turkey

    [38]     www.sei.cmu.edu/ata/products_services/cbam.html

ثبت سفارش
عنوان محصول
قیمت