فرآیند تحلیل و طراحی شئ گرا

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

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

1. مرحله طراحی سیستم

2. مرحله طراحی شئ

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

در طراحی شئ یک مدل طراحی با جزئیات پیاده سازی بیشتری ساخته می شود؛ مانند ساختار بندی دوبارة کلاسها برای بهبود کارایی، ساختمان داده های درونی ، پیاده سازی کنترل سیستم، الگوریتم پیاده سازی هر کلاس، پیاده سازی روابط و بسته بندی کردن در ماژولهای فیزیکی . برای مدل آنالیز شده، فاز طراحی با فاز پیاده سازی دنبال می شود که مدل طراحی شده به کد در زبان برنامه نویسی ترجمه شده و از DBMS برای پایگاه داده های موجود استفاده می کند.

تحلیل شیءگرا OOA

هنگامی که می خواهیم یک محصول یا سیستم جدید بسازیم چگونه آن را توصیف کنیم تا با تکنیک های مهندسی نرم افزار شئ گرا بتوانیم یک سیستم مطمئن تولید نماییم؟ آیا سوالهای خاصی در این زمینه وجود دارد که باید از مشتری بپرسیم ؟ اشیاءمربوط به سیستم کدامند؟ اشیاء موجود در سیستم چه ارتباطی باهم دارند ؟ چگونه مسائل را مشخص یا مدل کنیم تا یک طراحی موثر داشته باشیم؟

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

1. دامنه اطلاعات باید مدلسازی شود.

2. کارکرد سیستم توصیف شود.

3. رفتار سیستم ارائه گردد.

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

5. مدلهای اولیه ماهیت مسئله را نشان می دهند در حالیکه مدلهای پایانی جزئیات پیاده سازی را ارائه می کنند.

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

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

2. کلاسها باید شناسایی شوند.

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

4. رابطه شیء به شیء باید نشان داده شود.

5. رفتار شیء باید مدلسازی شود.

6. وظایف 1تا 5 باید آنقدر تکرار شود تا مدل تحلیلی کامل شود.

هدف تحلیل شیء گرا توسعه مدلی است که یک نرم افزار کامپیوتری را - جهت بیان نیاز های تعریف شده توسط کاربر - توصیف می کند.دردهه اخیر آقایان Booch,Raubaugh,Jacobson با ترکیب بهترین ویژگی های روش های شخصی و برخی از روشهای موجود تحلیل و طراحی شیءگرا روشUnified را معرفی کردند که بصورت گسترده ای در صنعت استفاده می شود. در روش Unified از زبان مدلسازی یکپارچه که در فصل بعد به تفصیل خواهد آمد، استفاده می شود . این زبان به مهندس نرم افزار اجازه می دهد تا با استفاده از علائم مدلسازیی که به وسیله مجموعه ای از قواعد نحوی و معنایی کنترل می شود، یک مدل تحلیلی ازسیستم نشان دهد.

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

-  دید مدل کاربر: دید مدل کاربر سیستم را از چشم انداز کاربر نمایش می دهد. مورد قابل کاربرد روشی برای مدلسازی این دیدگاه است . این نمایش تحلیلی، سناریو های مورد استفاده از چشم انداز کاربر نهایی را توصیف می کند.

-  دید مدلسازی ساختاری: در این دید داده و عملکرد درونی سیستم نمایش داده می- شود که ساختار ایستای سیستم(کلاسها،اشیاء و روابط بین آنها) را مدلسازی می کند.

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

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

- دید مدل محیط پیاده سازی: چشم اندازهای ساختاری و رفتاری محیطی که سیستم باید در آن پیاده سازی شود، ارائه می شود.بطور کلی مدلسازی تحلیلی UML روی دید های کاربر و ساختاری سیستم متمرکز می شود و مدلسازی فاز طراحی درUML شامل دید های رفتاری، پیاده سازی و محیط پیاده سازی می شود.

تحلیل مدل شئ گرا می تواند در سطوح مختلف انتزاعی انجام شود . مدل کردن کار تلاشی است جهت تعریف و شناسایی کلاسها ،اشیاء روابط و رفتارها که کل کار را مدل می کند. مدل شیء در سطح کار روند کاری سیستم تحت مطالعه را نشان میدهد، اما مدل شیء در سطح نرم افزار کاربردی روی نیازمندیهای مشتری ـ نیازمندیهایی که نحوة ساخت سیستم را تحت تاثیر قرار می دهدـ متمرکز می شود.

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

اجزای کلی یک مدل آنالیز شده شئ گرا

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

- یک دید ایستا از کلاسهای معنایی
- دید ایستا از صفات
- دید ایستا از روابط بین کلاسها
- دید ایستا از رفتار ( این رفتار با تعریف یک ترتیب از اعمال ، تعیین می شود.)
- دید پویا از تعامل بین کلاسها و زیر سیستم ها
- دید پویا از کنترل زمانی سیستم

طراحی شئ گرا OOD

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

طبیعت منحصر به فرد طراحی شئ گرا در توانایی آن در طراحی نرم افزار بر اساس چهار مفهوم زیر می باشد:

- مجرد سازی( Abstraction)
- مخفی سازی اطلاعات ( Information hiding)
- استقلال تابعی( Functional independency )
- پیمانه ای (Modularity)

بطور کلی فعالیتهای ساخت یک سیستم شئ گرا عبارتند از: طراحی شئ گرا، برنامه نویسی شئ گرا و تست شئ گرا. در شکل 2-1 یک هرم چهار لایه ای برای طراحی شئ گرا نشان داده شده است.

 

لایه های طراحی شئ گرا

لایة زیر سیستم ( subsystem layer): این لایه هر یک از زیر سیستم ها را نشان می دهد که نرم افزار را قادر به برآوردن نیازهای تعریف شده - توسط کاربر - می نماید و همچنین با استفاده از این لایه نرم افزار، فراساختارهای تکنیکی که نیازهای کاربر را پشتیبانی می کند،پیاده سازی می نماید.

لایة شئ و کلاس ( class and object layer ): این شامل کلاسهای سلسله مراتبی است که سیستم را قادر به استفاده از تعمیم و تخصیص می سازد، این لایه همچنین شامل نمایشی از هر شیء است.

لایه پیام ( message layer ): لایة پیام شامل جزئیات طراحی است و شئ را قادر می- سازد تا با دیگر اشیاء تعامل داشته باشد. این لایه بر واسط های نرم افزاری داخلی و خارجی سیستم استوار است.

لایة مسؤلیتها (responsibility layer ): این لایه شامل طراحی داده ساختارها و الگوریتم ها برای تمام صفات و اعمال موجود در هر شئ می باشد.

شکل 2-2 رابطه بین مدل تحلیلی شی گرا و مدل طراحی که از آن مشتق شده را نشان می دهد. طراحی زیرسیستم از توصیف نیازهای کلی مشتری در قالب موارد قابل کاربرد، رویدادها و حالاتی که از دید یک بیننده غیر تکنیکی که توسط مدلهای رفتاری - برای اطلاعات بیشتر در مورد نمودار های رفتار و موارد قابل کاربرد به فصل چهارم مراجعه شود - تصویر شده ، اشتقاق می شود. طراحی کلاس و اشیاء از توصیف صفات، اعمال و همکاری های موجود در مدلCRC نگاشت می شود، طراحی پیامها از مدل رابطه بین اشیاء و سرانجام طراحی مسؤلیتهای شئ ازصفات، اعمال و همکاری های توصیف شده در مدلCRC مشتق می شود.

روش Unified در طراحی شیءگرا

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


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


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

فرآیند طراحی سیستم

طراحی سیستم جزئیات معماری مورد نیاز برای ساختن سیستم را توضیح می دهد، این فرآیند شامل فعالیت های زیر است:

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

درزیر روال طراحی هریک از مراحل فوق الذکر را با جزئیات بیشتری می آوریم.

افراز مدل تحلیلی

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

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

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

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

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

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

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

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

1. لایه ارائهpresentation layer (زیر سیستم های متناظر با واسط کاربری)

2. لایه کاربردی application layer (زیر سیستم هایی که پردازش های مربوط به برنامه کاربردی را انجام می دهند)

3. لایه قالب بندی داده ها data formatting layer (زیر سیستم هایی که داده را برای پردازش آماده می کنند.)

4. لایه پایگاه داده ای data base layer (زیرسیستم های مربوط به مدیریت دادها)

بطور کلی روش زیر برای لایه بندی توصیه می شود

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

2. تعین تعداد لایه ها :تعداد خیلی زیاد لایه ها (بیشتر از حدلازم) لزوماً از پیچیدگی سیستم نمی کاهد از طرف دیگر تعداد خیلی کم لایه ها ممکن است به استقلال عملیاتی زیر سیستم ها صدمه وارد کند.

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

4. طراحی واسط برای هر لایه

5. بررسی زیر سیستمها به منظور بهینه کردن ساختار کلاس های هر لایه

6. تعریف یک مدل پیام رسانی برای تعامل لایه ها

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

8. تکرار کردن این مراحل جهت بهینه کردن لایه بندی .(تصفیه کردن معماری لایه ای)

همروندی و تخصیص زیرسیستم

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

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

مؤلفه مدیریت وظیفه Task management component

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

- تعیین ویژگیهای وظیفه
- تعریف وظیفه ناظر و اشیاء متناظر با آن
- مجتمع سازی وظیفه ناظر و وظایف دیگر.

مؤلفه واسط کاربری user interface component

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

مؤلفه مدیریت داده Data management coumponent

مؤلفة مدیریت داده شامل دو قسمت جدا ازهم می باشد: (‍1)مدیریت کردن داده ها که قسمت بحرانی نرم افزار کاربردی هستند و(‌2) ساختن فراساختاری برای ذخیره و بازیابی اشیاء. بطور کلی مدیریت داده به صورت لایه ای طراحی می شود و ایدة آن این است که نیازهای سطح پایین برای دستکاری ساختارهای داده را از نیازهای سطح بالا برای دستگیری از صفات سیستم جدا نماییم. این کار در عمل با استفاده از یک DBMS برای تمام زیر سیستمها انجام می شود، اشیائی که برای دستکاری پایگاه داده لازم است عضو همان کلاسهایی است که در هنگام تحلیل دامنه مشخص شده اند.

مولفه مدیریت منابع Recourse management coumponent

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

ارتباط بین زیر سیستم ها Intersubsystem communication

پس ازاینکه هر زیر سیستم مشخص شد، لازم است که همکاریهای موجود میان زیرسیستمها بصورت سیستماتیک تعریف شود. بصورت کلی مدلی که برای همکاری شئ- به- شئ استفاده می شود را می توان برای زیرسیستمها نیز توسعه داد. هنچنانکه قبلاً ذکر شد، ارتباط می تواند بصورت اتصال سرویس دهنده/ مشتری یا نقطه به نقطه باشد. شکل 2-4 این ارتباط را نشان می دهد، باتوجه به شکل باید قراردادهایی بین زیرسیستمها مشخص شود. قرارداد نشان می دهد که چگونه یک زیرسیستم می تواند با یک زیر سیستم دیگر تعامل داشته باشد.

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

مشخصات شئ

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

توصیف پیاده سازی ترکیبی از اطلاعات زیر است؛

1. مشخص سازی نام شئ و ارجاع آن به یک کلاس.

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

3. توصیف رویه هر عمل.

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

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

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

مؤلفه های برنامه و واسط ها

یک نمود مهم در کیفیت طراحی نرم افزار پیمانه ای بودن آن است، بطوری که شامل مشخصات مؤلفه ای برنامه (پیمانه) است که برای تشکیل یک برنامة کامل با هم ترکیب می شوند، روش شئ گرا، شئ را به عنوان یک مؤلفه برنامه تعریف می کنند که می- تواند به مؤلفه های دیگر متصل شود. اما تعریف شئ و اعمال کافی نیست، در طول فاز طراحی باید واسط های بین اشیاء و ساختاری کلی را برای اشیاء فراهم کنیم. اگرچه مؤلفة برنامه طراحی مجردات است ولی این مؤلفه ها باید در یک زبان برنامه نویسی که برای پیاده سازی استفاده می شود ارائه شود.

طراحی الگو

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

توصیف طراحی الگو

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

1. نام الگو

2. هدف الگو

3. طراحی مواردی که الگو را تحریک می کنند

4. پاسخ های مربوط به هر محرک

5. کلاس های لازم برای پیاده سازی جواب

6. مسؤلیتها و همکاریهای بین کلاس های جواب

7. راهنمایی هایی جهت پیاده سازی مؤثر

8. کد منبع نمونه یا قالبهای کد منبع

9. مراجعه متقابل الگوهای طراحی مرتبط

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

استفاده از الگو در طراحی

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

 
منبع : iiend.com