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

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

لینک پرداخت و دانلود *پایین مطلب*

فرمت فایل: Word (قابل ویرایش و آماده پرینت)

تعداد صفحه :71

بخشی از متن مقاله

پیچیدگی در نرم افزار

بدلیل تفاوت ذاتی بین نرم افزار و سخت افزار پیچیدگی خاصی در ابعاد مختلف از جمله تعریف نرم افزار، طراحی و پیاده‌سازی، تست و نگهداری آن وجود دارد که:

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

یک خاصیت ذاتی سیستمهای نرم افزاری بزرگ

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

انواع پیچیدگی:

intelleictually intractivility (تمردپذیری و اجازه پذیرفتن برای آشفتگی):

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

Management intractivility (تمرد پذیری مدیریتی):

پیچیدگی در سازمان و فرآیند بکار گرفته شده در ساخت سیستم، ممکن است از اندازة پروژه (تعداد افردی که در تمام جهات ساخت سیستم درگیر هستند)، وابستگیهای پروژه، فاصله جغرافیایی سیستمها و . . .  بعبارتی عوامل تولید کننده نرم افزار غیر قابل کنترل هستند چون سازمان، افراد و فرآیند هستند و ماشین نیستند که کنترل شوند و سرمایه‌های اولیه برای تولید نرم افزار الزاماً ماشین، سرمایه و پول نیست بلکه یکسری عوامل انسانی متغیری هستند که تحت مدیریت قرار می‌گیرند.

راهکارهای معماری

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

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

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

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

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

آیا این قطعات با هم بدرسیت کار می‌کنند؟ این موضوع واسط و رابطه‌های بین قطعات می‌باشد. اما تطابق خوبی که جامعیت سیستم را مدیریت می کند و همچنین با شرایط سیستم کار کند زمانیکه این قطعات ترکیب می‌شود خصوصیات خوب داشته باشند. مورد لزوم است.

شکل  زیر وسعت تصمیم و تأثیرات مستقیم را معین می‌کند. بخشیی از تصمیمات در حوزه محدود به توسعه‌های محلی (Local) است و اثری روی معماری ندارد و در سطح تک تک مؤلفه‌ها است و از نوع غیر معماری می‌باشد.

بخش دیگر Local نیست ولی تأثیر زیادی ندارد. از خود تقسیم‌بندی سیستماتیک و Local می‌باشد. خود سیستماتیک شامل Highimpaet می‌باشد که ما بدنبال Highimpnet می‌باشیم (اولویت بالا برای ما مهم است).

و بدلیل اینکه تصمیمات معماری روی جنبه‌های مختلفی از جمله 1- Sysstempriority (قراردادهای اولویت: مثلاً آیا Perdormance اولویت بیشتری دارد یا Security):

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

مدل لایه‌بندی و تصمیمات معماری:

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

1- سطح بالاتر از معماری (Meta- Architecture): dictionary معماری می‌باشد مجموعه‌ای از تصمیمات  سطح بالا است که ساختاری، تجزیه و مجموعه‌ای از تصمیمات سطح بالا را شامل می‌شود. دورنمای معماری ، اصول- لیک‌ها- مفاهیم کلیدی و مکانیزمها را شامل می‌شود.

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

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

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

2-1: معماری ادراکی: شامل دیاگرامهای معماری و  CRC-R کارنها می‌باشد.

تمرکز بر روی تعیین مؤلفه ها و انتساب وظایف به مؤلفه‌ها دارد.

2-2: معماری منطق: شامل را به روز کردن و دیاگرامهای معماری (نشان دادن واسطها)، تعیین واسط، تعیین مؤلفه‌ها و راهنماییهای کاربردی آنها می‌باشد.

تمرکز بر روی طراحی واسطه‌های مؤلفه‌ها ، پروتین‌ها و مکانیزم‌ اتصال و طراحی واسط  و تعیین آن مهیا کردن تعریف ضمن از اطلاعات برای کار برای مؤلفه‌ها، دارد.

2-3 خطوط راهنمایی و سیاستهای معماری:

شامل کاربرد مدلها و خطوط راهنمای، الگوها طراحی و مکانیزمها؛ چهارچوبهای کاری، استانداردها و ساختارهای زیرین می‌باشد.

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

2-3 معماری اجرایی:

ایده‌های فرآیند (نشان داده شده د ر دیاگرامهای همکاری) می‌باشد بر روی، انتخاب و آدرس دهی فضاها؛ چگونه آنها با هم تبادل می‌کنند و هماهنگ می‌شوند، چگونه منابع فیزیکی به آنها انتساب داده می‌شوند، تمرکز دارد.

دیدهای معماری: 1- هر دو دید ساختاری و رفتاری برای تفکر و ارائه معماری مهم می‌باشند:

دید ساختاری: اگر ما بپذیریم که «معماری بالاترین سطح ساختار سیستم شامل مؤلفه‌ها، روابط مابین آنها ، و خصوصیات قابل روئیت از خارج آنها می‌باشد، دید ساختاری محوری است . دید  ساختار شامل: دیاگرام معماری(مقوله‌بندی دیاگرام کودسLUML ، و تعیین مؤلفه و واسط آنها می‌باشد.

دید رفتاری: در تجزیه سیستم به مؤلفه‌ها و طراحی و اسطه‌هایشان؛ و طراحی مکانیزمهای برای آدرس دهی به تهدیدهای میانبر مربوطه مساحتی بایست به سؤال:

این چگونه کار می‌کند؟ همچنین، در تفهیم و کاربرد معماری، ما می‌بایست قادر به جواب دادن به همان سؤال پاسصخ دهیم. این نقش دید رفتاری، با دیاگرامهای توالی یا همکاری (مقوله‌بندی دیاگرامهای همکاری و توالی در UML ) می‌باشد.

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

Archi tecture Views:

در چارچوب کاری تصمیمات معماری

1- metanrchiteetune

2- Archilecture

2-1 conceputual

2-2 Logicalony

2-3 Execution Ar

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

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

در معماری نرم افزار بسته به خروجهای سطح بالا توجه داریم و اینکه چگونه قبل از Derelope کرده نرم افزار می‌توان آنرا ارزیابی کرد این ارزیابی یک معماری قابل اجرا است. مثلاً prototype مهندس نرم افزار یک نوع معماری قابل اجرا است معماری قابل اجرای سیستم های توزیع شده و همروند ایجاد می‌شوند نگاشت مؤلفه‌های به فرآیندهایی سیستم فیزیکی با توجه به تمرین بر روی مفاهیمی از قبیل گذردهی و scalability deplogmentriew کد نوع معماری قابل اجرا می‌باشد.

Nrchirecture Business cycle:

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

چرخه را نمایش می‌دهد.

1- معماری بر ساختار سازمان در حال توسعه اثر می‌گذارد. یک معماری یک ساختاری برای یک سیستم تجویزی می‌کند.

2- معماری می تواند بر اهداف سازمان در حال توسعه تأثیرگذار باشد. یک سیستم موفق ساخته شده از معماری می‌تواند یک شرکت را به مهیا کردن جای پای در نواحی مشخص قادر سازد.

3- معماری می تواند بر نیازمندیهای مشتریان برای سیستم بعدی از  طریق فرصت دادن به مشتریان برای دریافت یک سیستم (بر اساس همان معماری) در اطمینان بشتر، بموقع‌تر و حالت مقدمه به صرفه‌تر از اینکه اگر سیستم بدوی از چرک نویس (سیستم قدیمی دارای اشکال)

4- فرآیند ساخت سیستم می تواند تجربه معمار را برای با سیستم بعدی از طریق اضافه کردن اساس همکاری تجربه تحت تأثیر قرار دهد.

5- تعدادی از سیستمهای تأثیر و تغییر واقعی بر فرهنگ مهندس نرم افزاری می‌گذارند، آن فرهنگی که محیط تکنیکی از آهن که سازندگان سیستم عمل کردن و زیاد می‌گیرند.

 Desighing the Architecture

برای یک روش طراحی معماری برای برآورده کردن هردو نیازمندیهای کیفی و نیازمندیهای  وظیفه مندی طراحی مبتنی بر معماری (ADD) می باشد. ADD یک مجموعه ای از سناریوهای صفات کیفی را بعنوان ورودی گرفته و دانش مربوط به روابط صفات کیفی قابل دستیابی و معماری را بخاطر طراحی معماری بکار می گیرد. روش ADD می تواند بعنوان یک توسعه ای از دیگر روشهای استقرار از قبیل RUP، دیده شود. RUP چندین مرحله دارد که نتیجه در سطح بالای طراحی یک معماری است اما با طراحی همراه با جزئیات و پیاده سازی پردازش می کند. ولی ADD تغییر دهد مراحل RUP را با طراحی سطح بالای معماری تغییر داده و فرآیند Rational را دنبال می کند.

Architecture Description Langnague.(ADL(:

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

مثال: C22  Wright . Darcvin . Rapiol و …

مثلاً: Rapid بر روی رخدادهای سیستم، رفتار دینامیکی سیستم بکار برای الگوهای رخدادی تمرکز دارد.

یا Wright بر روی کانکتورها، رفت زیر سیستمهای دینامیکی تمرکز دارد.

Product Lines:

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

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

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

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

مثلاً طراحی یک DB در مدل مرجع تا این حد می دانیم که هدف چیست و مولفه هایی که باید حضور داشته باشند و ارتباط و وظایف این مولفه ها را می دانیم.

Reference Architecture:

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

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

مثلاً: در طراحی DB قبل، مسئولیت انطباق وظایف مشخص شده در مدل مرجع به مولفه های نرم افزاری بر عهده معماری مرجع می باشد.

Migration Plane :

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

تعریف دیگر:

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

Enterprise Architectec tuve Planning (EAP( :

برنامه ریزی معماری سازمانی

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

تعریف دیگر

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

Eind user:

رفتار، کارآیی، امنیت، قابلیت اطمینان، قابلیت کاربرد

رفتار از قبیل سازگار، با بستر، قابلیت کار با دیگر سیستم ها)

Customer ( مشتری):

هزینه پایین، خیلی وقتها تغییر نکردن، زمان سریع عرضه به بازار

Marketer( بازاریاب):

ویژگیهای خالص، زمان کوتاه بازاریابی، هزینه پایین، رقابت بیشتر با محصولات هم رده

Maintainerنگهداری کننده نرم افزار:

قابلیت تغییر

Developer( تولید کننده نرم افزار):

هزینه پایین، نگهداری افراد استخدام شده

Derelopment Manager (مدیر تولید نرم افزار ):

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

System Administratio( مدیر سیستم ):

Architect:

معمار در مورد استراتژیهای فکر می کند که به تمام این  این اهداف  ( یا مصاعدمبین آنها ) دست یابد.

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

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

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

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

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

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

- یکسری از سیستمها تاثیر می گذارند و واقعاً فرهنگ مهندسی نرم افزار را تغییر می دهند، آن محیطی تکنیکی است که در آن سازندگان سیستم فعالیت کرده و یاد می گیرند. اولین DB های رابطه ای، تولید کنندگان کمپانی، و OS های مبتنی بر جدول این تاثیر را در OS 196 و سریعتر در OS 197 داشته اند، صفحه گستره جهانی (www) یک مثالی است برای OS 199. EE2 ( ممکن است یک مثالی باشد برای اوسالیانه دهه قرن 21.

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

قابلثیت تغییر را که ویژگی مورد انتظار Maintainer نگهداری کننده نرم افزاری می باشد می توان از سبک Call Sneturn استفاده نمود.

تحوه نمایش توسط UML:

UML یک نوعی از ساختارها را برای نهمایش انواع مختلفی از Modnie ها فراهم می کند. UML یک ساختار CLASS وارد که توصیف شئی گراری از یک Module می باشد. Pack age ها می توانند در مواردی که گروهبندی عمکردها ( وظیفه مندیها) مهم می باشد، مثل زمانی که می خواهند لایه ها (Layers) و کلاسها را نمایش دهند. ساختار System Sub می تواند بکار گرفته شود اگر یک توصیفی از واسط و رفتار مورد نیاز باشد.

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

Module Deromposition بوسیله رابطه Is - Pare - of  (Aggregation) برآورده  می شود. USes Module توسط رابطه dependency بدست می آید. و ایده
Module Class  توسط Generalization ، یا رابطه Is-a  ( که Inhertance نامیده می شود) تامین می شود.

Aggregation : در UML، ساختار Sabayatem برای نمایش Module هایی که شامل دیگر Module ها  می باشند می تواند بکار رود، Class box معمولآً برای برگهای Decomposition بکار می رود.

Subsytem هم بطور Package ها و هم بطور Classiher ها ( کلاس بندی ) بکار برده می شوند. بعنوان Package آنها می توانند تجزیه (Decom pere) شوند و از این رو برای Module Aggregation مناسب می باشند. بعنوان کلاس بندی، آنها محتویاتشان را محصور می کنند و می توانند یک واسط صریح مهیا کنند.

Aggegation به یکی از سه روش زیر خودش را نشان می دهد.

- Module ها ممکن است تو در تو باشند

- نتیجه ای ( رابطه قبل و بعدی) از دو تا دیاگرام ( در حد امکان متصل) می تواند نشان داده شود، جائیکه دومی یک Depe از محتویات یک Module نشان داده شده در اول می باشد.

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

در UML6 Composition یک شکلی از Aggregation با رابطه  غیر صریح مالکیت می باشد که رابطه بین قسمتهای زنده و همراه با کل (Whole) می باشند. اگر Module ، A ترکیبی از ماژولهای B و C می باشد B بنابراین B یا C نمی توانند بدون A  موجود باشند، اگر A در زمان اجرا خراب شود، B و C خراب می شوند.  بنابراین رابطه Composition مربوط به UML یک غیر صراحتی تحت ساختار پیاده سازی Unit ( واحدها) دارد. رابطه همچنین Endows عناصر را باریک ویژگی زمان اجرا. بعنوان یک معمار باید مطمئن شد که با این خاصیت قبل از بکارگیری رابطه Composition مربوطه UML را راحت هستید.

Generalizatian : این رابطه قلب UML هست در حالیه Module ها توسط
Class ها ( یا بوسیله Sub System ها ) نشان داده می شوند. شکل زیر نمادگذاری او سالیه (پایه) موجود در UML را نشان می دهد.

هر دوتا دیاگرام از لحاظ مفهومی یکسان می باشند. UML اجازه می دهد کی بیضی (…) در عوض یک Sub Module بکار برده شود. تا نشان دهد که یک Module می تواند فرزندی بیشتری از نشان داده شده دارد و بیشتر از یکی مشابه هستند. Module شکل (Shap) پدر ماژول های Polygon، Circle، و Spline می باشد که هر کدام یک زیر کلاسی (Sub clacc)، بچه (Child) ، یا ( Sdescen daw) از Shap می باشند. Shap خیلی کمی است، در حالیکه بچه هایش نسخه های خاص تری می باشند.

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

دانلود فایل