دانلود مقاله پیچیدگی در نرم افزار

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

مشخصات این فایل
عنوان: پیچیدگی در نرم افزار
فرمت فایل : word( قابل ویرایش)
تعداد صفحات: 71

این مقاله درمورد پیچیدگی در نرم افزار می باشد.

خلاصه آنچه در مقاله پیچیدگی در نرم افزار می خوانید :

توصیف اشکال برجسب درجه گویایی:
Option 1 : نمایش غیر صریح: این منجر به ساده ترین دیاگرامها می شود اما اجازه به یک مشکل آشکاری که هیچ روشی جهت ویژگی بندی نامها یا ویژگیهای و اسطهادر نمایش اولیه نمی شود. این روش قابل قبول است اگر مولفه فقط یک واسط داشته باشد، اگر واسطها بتوانند از سیستم با توپوثری استتاج شوند یا اگر دیاگرام جای دیگری پالایش شود.
Ptio 2 : واسطها بعنوان حاشیه ( یادداشت): یک مهر برای اطلاعات در مورد واسطها مهیا می کند، گر چه حاشیه ها  هیچ مقیاسی در UML ندارند از این رو نمی توانند یک واسط مرتبط نباشند، این روش معقول می باشد.
Option 3 : واسطها بعنوان صفات Class/ Obiect ها واسطها را بعنوان قسمتی از مدل ساختاری فرمال می کند، اما آنها می توانند فقط یک نمایش ساده در یک Class Diagram داشته باشند، اساساً یک Name و یک Type.
Option 4 : Interface ها بصورت Ineface های UmL نشان O – در UML یک توصیف سرجودی ازیک واسط دریکClassdiagram بستگی به نوع یک Compenent، مهیا می کند. در یک Instance diagram یک نفش مربوط UML، مرتباً با یک نمونه واسط می شود و با نام نوع واسط توصیف می شود و یک روش فشرده با نشادن اینکه می نمونه مولفه طریق یک نمونه واسط ویژه در حال تعامل می باشد را نشان می دهد.
این روش بصورت ویژوال سیستم و جداگانه ای از Component ها و Interface مهیا می کند، در واسطهایی که بطور واضح و مفید دیده شوند.
بهر حال، این استراتژی هیچ وسیله ای جهت ترسیم سرویسهای مواد درخواست شده از طرف محیط Componet یک قسمت کلیدی از یک Interface می باشد، فراهم نمی کند. برخلاف Class ها، واسطهای UML صفات یا زیر ساختار ندارند.
Option 5:  Interface بعنوان کلاسها: که واسطها را بصورت کلاسهایی شامل یک Compoent غالب بر فقدان گویایی و آسترنایتو ذکر شده قبلی می باشد. ( حالا می توان زیر ساختار واسط را نمایش داد و می توان بیان کرد که یک Component teppe چندین واسط از همان Type دارد. یک نمونه ای Component بصورت یک Obiect‌ی شامل یک مجموعه ای از Interfaceobject  ها مدل می شود. بهر حال با نمایش Interface ها بصورت کلاس ها، مانه فقط دیاگرام را پازایت دارد می کنیم بلکه روشنی تشخیص ویژوال بین Interface ها و Componet ها را از دست می دهیم. ما می توانیم یک نمادگذاری مختلف دیگری بکار ببریم که در آن واسطها Interface ها شامل Class باشند، همانطوری که قسمت پاینی Option 5 نشان داده شده است.
تعیین نقاط تعامل دور از عقل می باشد، بهرحال بعنوان محدودیت که معمولاً مشخص می کند که یک کلاس شامل دیگر کلاسهایی است که نمونه هایشان ممکن است قابل دستیابی از طریق نمونه های کلاس پدر باشند یا نباشند.
Connectors : سه مورد مستدل در مورد نمایش Connector ها وجود دارد. این انتخاب بین گویایی و تطابق معنایی در یک است و پیچیدگی در دست دیگر مقابل هم قرار می گیرند.

Optionl : Type اتصالات بعنوان Assoca tion ها و Instance اتصالات بعنوان Linkها:
در یک دیاگرام Box & line معماری یک سیستم خطوط بین مولفه ها Connector ها می باشند. یک حالت نمایش Connector ها در UML، Association بین کلاسها یا Link های بین Object ها می باشد. این روش معمولاً بصورت ویژوال ساده می باشد، یک فاصله واصخی بین Component ها و Connecdor ها ایجاد می کند، و معروفترین رابطه در دیاگرامهای کلاس UML یعنی Association را بکار می برد. بعلاوه Association ها می توانند برچسب گذار می شوند، و یک Association جهت دار با Conncector می تواند با یک فلش معین شود. متاسفانه، Connector ها و Affociation ها معانی مختلفی دارند. یک سیستم در یک توصیف معماری بوسیله انتخاب مولفه ها با رفتار نمایش داده شده از طریق واسطهایش ساخته می شود و آنها را با Commector هایی که رفتارشان را هماهنگ می کند بهم متصل می کند. ( فشار یک سیستم بصورت رفتار جامع یک مجموعه ای از مولفه هایی که تعامل تعریف شده و بوسیله اتصالات بین آنها محدود می شود، تعریف می شود.
در مقابل، گر چه یک Association یا Link در UML یک توانایی را جهت تعامل بین عناصر مرتبط را نشان می دهد، مکانیزم Association اصولاً یک روشی است جهت توصیف رابطه ادراکی بین دو عنصر، بعلاوه یک Association یک رابطه ای است بین عناصر UML، از اینرو خودش بتنهایی نمی تواند در یک مدل UML باشد. نتیجتاً، یک Connector type بطور مجزا نمی تواند رد Uml نشان داده شود. در عرض شما می بایست دوباره قرار دادهای نامگذاری یا مقوسه بندی کردن معانی بدست آمده توسط توصیف را در زبان محدودیت شئی UML، طبقه بندی کنید، ثانیاً این روش اجازه تعیین واسطهای اتصالات  Connetor’s interfacesرا نمی دهد.
زبان محدودیت شیء UML، طبقه بندی کنید ، ثانیاً این روش اجازه تعین واسطهای اتصالات را نمی دهد.
option2 :
Connecter type as assoction class
یک راه حلی با فقدان گویایی واجد شرایط ‌assocation با یک کلاسی است که connector type را نمایش می دهد. در این شور connector type یا connector attributes  می تواند از طریق صفات یک کلاس یا شیء بدست آید. متأسفانه،‌این تکنیک هنوز هیچ روشی از نمایش صریح واسطهای connector فراهم نکرده است.
otion3 :
connector type as class & connector instance as bojects
یک روش برای دادن حالت به connecter های first-class در UML نمایش connector type از طریق کلاسها و connector instance ها از طریق اشیاء می باشد. کاربردن کلاسها و اشیاء همان چهار option برای نمایش  که برای interface ها داشتیم می باشد. نه در همه آنها، بعنوان تفاسیر و واسطها بوسیله یک کلاس عینیت می یابد یا بعنوان کلاسهای فرزند، با یک کلاس cennecter شامل می شود. یک طرحی برای نمایش interface ها داده شده ، یک پیوستگی بین یک interface مؤلفه و یک interface اتصال ممکن است بصورت یک association یا یک dependency نمایش داده شود.

System ها:
جهت نمایش مؤلفه های ویژه و اتصالات و type هایشان نیاز است تا گرافهایی از مؤلفه ها و اتصالات یعنی system ها محصور شوند.
otpion1 :
system as UML Subsystems
مکانیزم اولیه UML برای گروهبندی عناصر مرتبط package ها می باشد. در حقیقت، UML یک package stereotype استاندارد که subsystem نامیده می شود، تعریف می شود که مدلهایی UML که بیانگر قسمت منطقی یک سیستم می باشند را گروهبندی می کند. انتخاب subsystem ها جهت هر نگاشتی از مؤلفه ها و اتصالات مناسب می باشد، و بطور خاص جهت گروهبندی کلاسها خوب کار می کند. یکی از مشکلاتی در ارتباط با بکاربردن subsystem ها که در UML 10 تعریف شد عبارت است از گر چه آنها یک classifier و یک package معنا کاملاً واضح نیست.
یکسری         که می بایست قادر بود با یک subsystem بعنوان یک کلاس واحد شبیه موجودیت در مراحل معین فرآیند تولید رفتار کرد و بعداً قادر بود آنرا در ترمهایی از یک substructere خیلی جزئی شده پالایش کرد. داشتن این قابلیت انجام دادن اینکار subsystem را برای مدسازی مؤلفه های معماری بطور مناسب می سازد.
option2 : system as conaned objects : محتوی شیء می تواند جهت نمایش سیستمها بکار گرفته شود. مؤلفه ها بعنوان نمونه هایی از کلاسهای حاوی ، و connector ها با بکاربردن یکی از option های بررسی شده ، ‌مسئول می شوند. اشیاء یک مرز محصور قوی ایجاد کرده و از طریق آنها نشان گذاری که هر نمونه ای از کلاس substructure associated خودش را دارد حمل می شود. بهر حال، این روش مشکلاتی دارد، مهمترین آن association می باشد  که جهت مدل کردن connector های بین کلاسهای حامل از طریق کلاس محدود نمی شوند، مشکل آنست که ممکن نیست که بگوییم یک زوجی از کلاسها از طریق یک connector خاص تعامل می یابند، و بصورت association مدل می شوند. بنابراین، برای مثال، تعیین دو نوع کلاس حامل که از طریق یک association تعامل دارند برای نمونه هایی از کلاسهای بکارگرفته از هر جا صحیح نیست در غیر اینصورت در مدل
system as collaborations: option3
یک مجموعه ای از اشیاء در حال تبادل متصل از طریق likne های در UML با بکاربردن یک collaboration توصیف می شوند. اگر component ها بصورت object ها نمایش داده شوند، می توان collaboration ها را برای نمایش system ها بکار برده یک collaboration یک مجموعه ای از شرکاء و روابطی که برای یک هدف داده شده با معنی می باشند را تعریف می کند، در این مورد جهت توصیف ساختار زمان اجرای سیستم می باشد. شریک نقشهای دستبدی کننده ای که اشیاء بازی می کنند یا زمان تعامل با یکدیگر ‌می کنند را تعریف می کند. بطور مشابه، روابط نقشهای association ی که اتصالات می بایست تطابق دهند را تعریف می کنند.
نمودارهای coliaboration می توانند جهت نمایش collaboration ها در ‌مشخصات و سطح instance بکار روند. سطح مشخصات یک نمودار collaboration نقشهایی را نمایش می دهد که در collaboration تعریف می شود در یک الگو جهت توصیف کردن زیرساختارهای سیستم مرتب می شود.
یک سطح instance نمودار collaboration اشیاء و اتصالات شکل دهنده نقشها با نقشها در سطح مشخصات و تعامل  این هدف را نشان می دهد.
بنابراین یک collaboration نمایش داده شده در سطح instance بهتر است جهت نمایش ساختار زمان اجرای یک سیستم بکار گرفته شود.
شکل زیر این روش را نمایش می دهد.
type معماری filter قبلا نمایش داده شد، Instance های فیلترها و pipe ها بصورت نقشهای دستبدی کننده مربوطه نمایش داده می شوند - برای مثال، splitter / نقش splitter را و نقشهای مرتبط را معین می کند.
اشیاء و اتصالات مطابق با آن نقشهای نمایش داده شده در دیاگرامهای collaboration در سطح instance بوسیله نامهای زیر خطی معین می شوند.
گر چه این روش طبیعی جهت توصیف ساختارهای زمان اجرا می باشد، اشتباه است که بگوییم هیچ روشی جهت نمایش صریح ویژگیهای سطح سیستم وجود ندارد.
همچنین یک عدم تطابق معنایی وجود دارد: یک c ollaboration یک تعامل قابل ارائه ای بین اشیاء توصیف کرده و یک توصیف جزئی در جائیکه یک پیکربندی معماری جهت بدست آوردن یک توصیف کامل لازم می باشد مهیا می کند.

دیدهای Allocation
در UML یک نمودار deploment یک گرافی از گرههای متصل شده از طریق association های متبادل می باشد. شکل زیر یک مثالی برای این موضوع می باشد.
گره ها ممکن است شامل نمونه های component می باشد که معین می کنند که مؤلفه زنده است یا در گره اجرا می شود. مؤلفه ها ممکن است حاوی اشیائی باشند که معین می کنندن که شیء یک قسمتی از مؤلفه می باشد. مؤلفه ها با یکدیگر از طریق خطوط نقطه چین dependency متصل می شوند (در حد امکان از طریق واسطها) این بیان می کند که یک مؤلفه سرویس های مؤلفه دیگری را بکار می برد: یک stereotype ممکن است جهت تعیین کردن dependency دقیق اگر نیاز باشد بکار گرفته شود.
دیاگرام نوع depleyment ممکن است جهت نمایش مؤلفه هایی که ممکن است بر روی گره ها (nedes) اجرا شوند، بکار رود که این کار با بکاربردن خطوط نقطه چین با تضمین های مقوله بندی بکار رود.
یک گروه یک شیء فیزیکی زمان اجرا است که یک منبع پردازش را نمایش می دهد. گرهها شامل وسایل محاسباتی هستند همچنین شامل منابع پردازش مکانیکی یا اشیائی می باشند. گره ها ممکن است type هایی از نمونه های instance را نمایش دهند. نمونه هایی محاسباتی زمان اجرا، هر دوی اشیاء و مؤلفه ها ممکن است در نمونه های گره باقی بمانند (قرار گیرند). گرهها ممکن است توسط association ها به دیگر گرهها متصل شوند. یک association بیان کننده یک مسیر تبادلی بین گرهها می باشد. یک association ممکن است یک stereotype جهت تعیین طبیعیت مسیر تبادلی (برای مثال، نوع کانال یا نوع شبکه) داشته باشد.
تودرتو بودن سیمبول های در سیمبول  دلالت بر یک association ترکیبی بین یک کلاس گره و کلاسهای متشکل یا یک اتصال ترکیبی بین یک شی ء گره و اشیاء تشکیل دهنده آن، ‌می کند.
....

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

انواع پیچیدگی:
راهکارهای معماری
مدل لایه‌بندی و تصمیمات معماری:
2-3 معماری اجرایی:
 Desighing the Architecture
Architecture Description Langnague.(ADL(:
Product Lines:
Reference Architecture:
Migration Plane :
Enterprise Architectec tuve Planning (EAP( :
برنامه ریزی معماری سازمانی
System Administratio( مدیر سیستم ):
تحوه نمایش توسط UML:
توصیف اشکال برجسب درجه گویایی:
Optionl : Type اتصالات بعنوان Assoca tion ها و Instance اتصالات بعنوان Linkها:
دیدهای Allocation
عملیات واحد
4- اشتراک منابع
الگوی MVC :