همروندی و تخصیص زیرسیستم
بررسی مدل رفتار شئ از نظر پویایی از وجود نوعی همروندی میان کلاس ها (یا زیر سیستم ها) نشان می دهد . اگر چند کلاس (یا زیر سیستم ) در یک زمان فعال نباشند، نیازی به پردازش همروند درسیستم نیست. و این بدین معناست که کلاس ها ( یا زیر سیستم ها ) را می توان بر روی یک پردازنده سخت افزاری پیاده سازی کرد. از طرف دیگر اگر کلاسها (ویا زیر سیستمها ) باید به صورت آسنکرون بر روی رویدادها دریک زمان عمل کنند، همروندی وجود دارد. هنگامی که زیر سیستم ها بصورت همروند فعال می شوند دو انتخاب تخصیصی وجود دارد: (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. توصیف رویه هر عمل.

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