: مفاهیم شیء گرایی
مقدمه
شئ گرایی برای توسعه نرم افزار اولین بار در سال 1960 پیشنهاد شد، این روش پس از 20 سال به طور گسترده مورد استفاده جامعه نرم افزاری قرار گرفت.
توسعه دهندگان نرم افزار در دهه 1980 توجه جدی خو د را روی شئ گرایی معطوف کردند.
تکنولوژی شئ، قابلیت استفاده مجدد را برای مؤلفه های نرم افزاری به ارمغان آورد و این نیز به نوبه خود در تسریع توسعه نرم افزار و تولید محصول با کارایی بالا تاثیر بسزایی دارد؛ بعلاوه سیستمهای شئ گرا، براحتی قابل توسعه و به سهولت با محیط سازگار- از نظر تعامل با سیستمهای موجود در محیط استفاده از نرم افزار- می شوند .
دیدگاه شئ گرایی یک سیر تکاملی دارد؛ همچنانکه در بخشهای بعدی خواهیم دید، تعیین همه کلاسهای لازم برای یک سیستم دریک تکرار تا اندازه ای غیرممکن است و به محض تکمیل مدلهای تحلیل و طراحی نیاز به کلاسهای جدید در سیستم نمایان می شود.
درک سیستمهای پیچیده وتولید نرم افزار برای چنین سیستمهایی توسط افرادی که در این زمینه تجربه کافی ندارند، کاری بس مشکل است .
همچنین محصولی که این افراد تولید می کنند کارایی لازم را نخواهد داشت، در اینجا مهندسی نرم افزار به کمک افراد آمده و با مطالعه روشها و فنون مختلف مسیر توسعه و تولید نرم افزار را هموار می- سازد.
تجربیات بدست آمده در این زمینه، متدها و فرآیندهای متنوعی را برای توسعه نرم افزار در اختیار توسعه دهندگان قرار داده و ابزارهای مناسبی نیز این روشها را پشتیبانی می کنند.
درتوسعه یا ساخت نرم افزار برای یک سیستم، مشتری باید تعریف دقیقی از سیستم را در اختیار توسعه دهنده قرار دهد.
در توصیف سیستم، زبان طبیعی تا آن اندازه دقیق نیست که بتوان همه نیازمندیها، ساختار و رفتار سیستم را با آن بیان کرد و کد نویسی نیز چنان وارد جزئیات می شود که به یکباره نمی توان سیستم را در این سطح تشریح کرد.
لذا برای درک سیستم دست به مدل سازی می زنیم و مؤلفه های سیستم ، زیر سیستمها و رفتار سیستم را به صورت نمودارهای گرافیکی ترسیم می نماییم تا موارد قابل کاربرد و مهم به صورت برجسته به چشم بخورد و هیچ موردی در حوزه سیستم از قلم نیافتد .
در متد شئ گرا از زبان مدلسازی استانداردUML که در فصل چهارم به تفصیل خواهدآمد، استفاده می شود.
این زبان به وسیله ابزارهای مختلفی نظیر Rational Rose ، visio و … پشتیبانی می شود، میتوان ازUML در فرآیندهای مختلف استفاده کرد.
مفاهیم اساسی
در این بخش مفاهیم اساسی توسعه نرم افزار شئ گرا را معرفی می کنیم.
در بالا به متد و فرآیند اشاره شد اما هیچ تعریفی از آنها ارائه نشد، حال این دو مفهوم کلی را بصورت زیر تعریف می کنیم.
متد، متدلوژی و اشیاء
متد مجموعه ای از وظایف را جهت تعیین نیازمندیها، تحلیل، طراحی، برنامه ریزی، تست و پشتیبانی مشخص می کند.
از نظر فنی فرآیند توسعه نرم افزار- متدلوژی- یک قالب کاری برای وظایف لازم جهت ساختن یک نرم افزار با کیفیت بالاست.
در واقع متدلوژی، فرآیندی ساختارمند جهت توسعه نرم افزار است که به وسیله فنون و ابزارها حمایت می شود.
متد شئ گرا برپایه شئ استوار است، دیدگاه شئ گرا دنیای واقعی مسئله را بصورت مجموعه ای از اشیاء مرتبط به هم می بیند.
شئ یک موجودیت است که در دامنه مسئله نقش تعریف شده ای دارد و دارای حالت، رفتار و شناسه خاص خودش است.
شئ می تواند یک ساختار ، نقش ، مکان و ...
باشد؛ شئ داده و رفتار را در خود کپسوله میکند و از دسترسی اشیاء دیگر به داده های خود جلوگیری و همچنین تا ثیر تغییرات محیطی بر این داده ها را کاهش می دهد و تنها راه دسترسی به این داده ها استفاده از اعمال یا سرویس های خود شئ می باشد.
کلاس نوع اشیاء را نشان می دهد و شامل ویژگی های مشترک مجموعه ای از اشیاء می باشد، شئ نمونه ای از کلاس است .
داده های شئ تحت عنوان صفات در کلاس شناخته می شوند و مقادیر این صفات است که شئ را از دیگر اشیای همنوع متمایز می نمایند.
اعمال به دستکاری تعداد محدودی از صفات می پردازند و ارتباط بین کلاس ها و دیگر عناصرسیستم نیز از طریق همین سرویسها- اعمال – صورت می گیرد.
به عبارت دیگر کلاس یک مشخصه کلی (قالب ، الگو یا طرح اولیه )است که مجموعه ای ازاشیاء مشابه را نشان می- دهد.نماد گرافیکی کلاس در شکل زیر نشان داده شده است، این نماد شامل سه قسمت است که بترتیب نام کلاس ، لیست صفات و لیست اعمال را نشان می دهند.
متد شئ گرا برپایه شئ استوار است، دیدگاه شئ گرا دنیای واقعی مسئله را بصورت مجموعه ای از اشیاء مرتبط به هم می بیند.
به عبارت دیگر کلاس یک مشخصه کلی (قالب ، الگو یا طرح اولیه )است که مجموعه ای ازاشیاء مشابه را نشان می- دهد.نماد گرافیکی کلاس در شکل زیر نشان داده شده است، این نماد شامل سه قسمت است که بترتیب نام کلاس ، لیست صفات و لیست اعمال را نشان می دهند.
------------------------ نام کلاس ------------------------ لیست صفات ------------------------ لیست اعمال ------------------------ با تعریف کردن اشیاء موجود در سیستم از نوع یک کلاس خاص، این اشیاء همه صفات، اعمال و روابط کلاس مربوطه را به ارث می برند.
یک فوق کلاس شامل ویژگی های مشترک صفات و اعمال جمعی از کلاسهاست و زیرکلاس یک حالت خاص ازفوق کلاس است که به آن تخصیص نیزگفته می شود.
این تعاریف از وجود یک سلسله مراتب نشان می دهد که در آن کلاسهای تعمیم(فوق کلاس) توسط کلاسهای تخصیص به ارث برده می شوند، ممکن است که هر کدام ازکلاس های تخصیص دارای یکسری صفات و اعمال اختصاصی اضافی باشند.
مجموعه مقادیر موجود برای یک صفت در یک کلاس، دامنه مقادیر آن صفت را نشان می دهد.
پیامها وسیله برقراری ارتباط و تعامل بین اشیاء می باشند ، این پیامها شئ مقصد را تحریک می کنند تا یک کار خاص را انجام دهد.
سرویسی که در شیء فرستنده پیام تولید می کند، یک پیام با قالب message:[destination, operation, parameters] ارسال میکند که در آن destination شیء گیرنده و operation سرویسی از شیء گیرنده است که پیام را دریافت می کند و parameters شامل اطلاعات لازم جهت انجام موفق سرویس خواسته شده است.
شکل 1-2 مثالی از کلاسهای تعمیم و تخصیص را نشان می دهد که در آن برای دانشجو یک فوق کلاس دانشجو داریم که شامل داده ها و اعمال مشترک بین دانشجویان دوره لیسانس و فوق لیسانس است، همچنین دو زیر کلاس تخصیص جداگانه برای دانشجویان لیسانس و فوق لیسانس نشان داده شده است که حالات خاصی از کلاس دانشجو هستند.
در عمل ما شیئی از نوع فوق کلاس دانشجو نخواهیم داشت، در این حالت به کلاسstudent یک کلاس مجرد گفته می- شود .
کلاس مجرد کلاسی است که هیچ شیئی از آن نوع نداشته باشیم.
کپسوله سازی، ارث بری و چند ریختی با توجه به مطالب ذکر شده در بالا، شیء گرایی به واسطه سه خاصیت مهم کپسوله سازی، ارث بری و چند ریختی یک روش منحصر بفرد است .
بطور کلی کپسوله سازی تکنیکی است که جزئیات پیاده سازی داخلی شئ را از دید سایر اشیاء و مؤلفه های سیستم پنهان می کند(مخفی سازی اطلاعات ).
عمل، تابعی است که در تمام نمونه های یک نوع وجود دارد و سایر اشیاء تنها از طریق اعمال موجود در یک شئ می توانند به اطلاعات این شئ دسترسی داشته باشند، بنابراین اعمال یک واسط برای کلاس بشمار می روند.
واسط رویه بیرونی کلاس را بدون اینکه ساختار درونی وچگونگی پیاده سازی اعمال را نشان دهد ، نمایان می سازد.
خاصیت کپسوله سازی داده و عمل دریک کلاس بطور عمده مزایای زیررا دارد.
جزئیات پیاده سازی داخلی داده و روتین ها از دنیای خارج قابل مشاهده نیست (مخفی سازی اطلاعات ).
این خاصیت تاثیر تغییرات محیطی بر شیء را کاهش می-دهد.
ساختمان داده ها و اعمالی که برای دستکاری داده ها در نظر گرفته شده با هم ادغام شده و تحت یک نام (اسم کلاس) شناخته می شود و این اساس مؤلفه قابل استفاده مجدد را فراهم می نماید.
واسطه های ما بین اشیاء کپسوله شده ساده اند، لزومی ندارد که شئ فرستنده پیام از جزئیات ساختمان داده درونی شئ مقصد اطلاع داشته باشد.
خاصیت کلیدی بعدی که روش شیءگرا را از سایر روشها متمایز می دارد، ارث بری است.
در شکل بالا زیر کلاس Graduate student همه صفات و اعمال متناظر شده با فوق کلاسش(Student) را به ارث می برد، بدین معنی که تمام ساختمان داده و الگوریتمهایی که برای فوق کلاسstudent طراحی و پیاده سازی شده برای کلاس تخصیص نیز در دسترس می باشد و هیچ کار اضافی لازم نیست انجام بگیرد .
و عملاً از قابلیت استفاده مجدد استفاده می کند.
اگر تغییری در داده ها و اعمال فوق کلاس انجام داده شود بلافاصله توسط تمام زیر کلاس های آن فوق کلاس به ارث برده می شود.
لذا از مکانیزم سلسله مراتبی برای انتشار تغییرات در سیستم استفاده می شود و این مهم است که در هر سطح از سلسله مراتب صفات یا اعمال به آنچه که توسط سطح بعدی به ارث برده می شود، اضافه می- شود.
بنابراین وقتی که لازم است کلاسی جدید ایجاد شود، مهندس نرم افزار می تواند به یکی از راه کارهای زیر عمل کند: می توان بدون استفاده از ارث بری کلاس را بطور مستقل طراحی نمود.
بررسی ساختار سلسله مراتبی کلاس های موجود و یافتن سطحی از ارث بری که بیشترین صفات و اعمال کلاس جدید را داراست، سپس کلاس جدید در سطح بالاتر قرار داده می شود و صفات و اعمال موجود در سطح پایین تر را به ارث می برد.
سلسله مراتب را ساختاربندی مجدد می نماییم تا کلاس جدید بتواند صفات و اعمال لازم را به ارث ببرد.
چند ریختی مشخصه ای دیگر از شئ گرا است که تا حد زیادی از کارهای لازم جهت توسعه سیستم موجود می کاهد.
در واقع چند ریختی بمعنای انجام چند کار مختلف توسط یک چیز است؛ بعنوان مثال برای یک روتین که چهار شکل گرافیکی مختلف، بیضی ، دایره ، مربع و لوزی را رسم کند در حالت عادی برای هر نوع باید متد مخصوص نوشته شده و برای نوع جدیدتر نیز باید متد خاص خود را اضافه نماییم.
برای پاسخ گویی به این مشکل در شئ گرایی از چند ریختی استفاده می کنیم، در اینجا همه این انواع به عنوان زیر کلاسهایی از کلاس عمومی Graphقرار می گیرند .
هر زیر کلاس یک عمل بنامdraw تعریف می کند، شئ می تواند یک پیامdraw را به هر یک از اشیاء نمونه از یک زیر کلاس بفرستد، شئ گیرنده پیام از تابع draw ی خود می خواهد که رسم مناسب را تولید کند.
وقتی که یک رسم الخط دیگر اضافه شود، یک زیر کلاس با تابع draw ی خاص خودش ایجاد می شود و بدین ترتیب کار طراحی ساده تر و از انجام کارهای تکراری جلوگیری می شود.
بطور خلاصه، چند ریختی این توانایی را به ما می دهد که چند عمل مختلف را تحت یک نام واحد داشته باشیم.
شناسایی عناصر مدل شئ در زیر مواردی را مطرح می نماییم که با استفاده از آنها شناسایی عناصر مدل شئ که که شامل کلاس، شئ ، صفات ، اعمال و پیامها است، راحتتر صورت می گیرد.
شناسایی کلاسها و اشیاء هنگامی که محیط اطراف خود را نگاه می کنیم براحتی اشیاء فیزیکی زیادی را می- توان شناسایی و تعریف (صفات واعمال) نمود، اما وقتی که فضای مسئله یک نرم افزار را بنگریم، ملاحظه می کنیم که کار مشکلتراست.
برای شناسایی اشیاء روی متنی که با زبان طبیعی سیستم را توصیف کرده یک پارس انجام می دهیم و تمام اسمها یا عبارات اسمی رادر یک جدول قرار می دهیم سپس مترادفها را از جدول حذف می نماییم، حال از این اسمها یا عبارات اسمی، آنهایی شئ هستندکه در یکی از موارد زیر صدق کنند: موجودیتهای خارجی (سیستمهای دیگر ، ابزارها و افراد) که تولیدکننده یا مصرف کننده اطلاعات در سیستم کامپیوتری هستند.
اشیائی ( گزارش ، علائم ، سیگنال )که قسمتی از دامنه های اطلاعاتی مسئله هستند.
رویدادهایی ( مانند ارسال اطلاعات برای تصمیم گیری یک ربات ) که در بطن عملیات سیستم نهفته است.
نقشهایی ( مدیر ، مهندس ، فروشنده ) که افراد در این نقشها با سیستم تعامل دارند.
واحد سازمانی (تقسیمات، گروه ، تیم) که مربوط به برنامه کاربردی است.
اماکن ( کف اتاق، جای خالی در سیستم رزرواسیون ) که عملکرد سیستم به آن وابسته است.
ساختارها (حسگرها، کامپیوترها) که نوع نقاط انتهایی یا کلاسهای مرتبط با سایر اشیاء را تعیین می نمایند.
شناسایی صفات شئ شیئی که در مرحله قبل مشخص شده بوسیله مجموعه صفاتش تعریف می شود ، صفات تصویر واضحی از شئ در خلال مسئله به ما می دهند.
برای توسعه یک مجموعه با معنا از صفات یک شئ، آنالیست باید متن پروسه را دوباره مطالعه کند و آنچه که درباره یک شئ معین است، مشخص بنماید.
شناسایی اعمال شئ اعمال، رفتار شئ را تعریف می کنند و صفات شئ را با برخی روشها تغییر می دهند.
بطور مشخص یک عمل مقدار یک یا چند صفت را که در شئ قرار دارد ، تغییر می- دهد .
بنابراین اعمال باید از طبیعت صفات شئ و ساختمان داده اشتقاقی از آنها اطلاع داشته و با روشهایی پیاده سازی شوند که قادر به دستکاری این ساختمان داده باشند.
اگر چه انواع مختلفی از اعمال وجود دارد اما عموما به سه دسته تقسیم می شوند: اعمالی که داده ها را با برخی روشها ( اضافه کردن، قالب بندی مجدد، انتخاب ) دستکاری می کنند.
اعمالی که محاسبات را انجام می دهند .
اعمالی که شئ را برای وقوع رویدادهای کنترلی نمایش می دهند.
بطور مشابه شناسایی اعمال با پارس دوباره متن زبان طبیعی و مشخص کردن افعال یا عبارات فعلی انجام می گیرد، همچنین اعمال اضافی می تواند با درنظر گرفتن چرخه زندگی شئ در پیامهایی که با سایر اشیاء سیستم رد و بدل می کند ، معین شود.
تعیین اعمال آخرین مرحله مشخص سازی شئ است .
چرخه زندگی یک شئ با مشخص کردن آنچه که موجب ایجاد شئ ، تغییر دادن، دستکاری کردن ، خواندن شئ و احتمالاً حذف شئ، معین می شود.
در قسمت بعدی مدیریت پروژه نرم افزاری را برای پروژه- های شئ گرا را توضیح می دهیم.
چارچوب یک فرآیند معمولی برای پروژه های شئ گرا چارچوب یک فرآیند معمولی روشهایی سازمان یافته را برای مهندسی نرم افزار تعریف می کند.
این روش ها به ساخت و نگهداری نرم افزار، وظایف، تفکیک مراحل مختلف توسعه (نقطه بررسی مرحله کاری پروژه ) و محصولاتی که درهر مرحله لازم است، می پردازد.
مهندس شئ گرا یک فرآیند تکراری را در توسعه نرم افزار طی می کند، به عبارت دیگر نرم افزار شئ گرا با طی کردن سیکلهایی کامل می شود و یک فرآیند توسعه شئ گرا باید ذات تکاملی داشته باشد تا آنجا که برخی از صاحبنظران در این زمینه یک مدل بازگشتی/ موازی را برای این کارپیشنهاد می کنندکه در اساس بصورت زیر عمل می کند: تحلیل مسئله را تا جایی که کلاسهای اصلی مسئله و ارتباطات بین کلاسها مشخص شود، ادامه می دهیم .
با طراحی یک طرح اولیه تعیین می کنیم که آیا کلاسها و ارتباطات تعیین شده در مرحله قبل در عمل قابل پیاده سازی است یا نه؟
اشیائی که مجدداً می توانند مورد استفاده قرار بگیرند از کتابخانه اشیاء استخراج می- کنیم تا به وسیله آن یک الگوی سطح بالا از پروژه بسازیم.
طرح آزمایشهایی جهت کشف خطاهای الگو گرفتن فیدبک از مشتری در رابطه با الگوی ساخته شده تغییر و تحلیل دوباره مدل براساس آنچه که از الگو، طراحی و فیدبک مشتری عاید شده است.
اصلاح مدل طراحی جهت وفق دادن تغییرات.
تولید کد برای برخی از اشیاء ( آنهایی که از قبل قابل دسترسی نیستند) اسمبل کردن یک الگوی جدید با استفاده از اشیاء کتابخانه ای و اشیائی که اخیراً ساخته ایم.
طرح آزمایشات جهت کشف خطاها در الگوی جدید.
گرفتن فید بک از مشتری در رابطه با الگوی جدید.
با تجزیه کردن سیستم به مؤلفه های کاملاً مستقل، این کار را تا جایی که الگوی هر مؤلفه کامل شود، تکرار می کنیم.
تکرار کردن فرآیند بازگشتی / موازی نیاز به برنامه ریزی، مهندسی(تحلیل ، طراحی ، استخراج کلاس، الگوسازی و تست کردن ) و فعالیتهای تکاملی دارد.
سیکل توسعه شئ گرا چرخه عمر توسعه شئ گرا که در شکل 1-3 نشان داده شده است، شامل پیشرفت موازی نمایان ساختن اشیاء در سه فاز تحلیل، طراحی و پیاده سازی است که در مراحل اولیه توسعه یک مدل انتزاعی بر پارامتر های خارجی- کیفیت سیستم کاربردی - تاکید دارد، با تغییر مدل بیشتر وارد جزئیات می شویم بطوریکه بیشتر به چگونگی ساخت سیستم و چگونگی عملکرد آن می اندیشیم - معماری ، ساختمان داده و الگوریتمها .
سرانجام مانند هر سیستم اطلاعاتی، توسعه دهنده سیستم باید به تولید کد و روتینهای دسترسی به پایگاه داده بپردازد.
شکل 1-3 : فازهای سیکل توسعه سیستمهای شئ گرا فصل دوم - تحلیل و طراحی شئ گرا فرآیند تحلیل و طراحی شئ گرا در این فصل به روندکاری تحلیل و طراحی شئ گرای سیستم می پردازیم.
در فاز تحلیل، مدلی از دنیای واقعی نرم افزار در حال توسعه که خواص مهم آن را نشان می- دهد، ساخته می شود.
این مدل مفاهیم موجود در دامنه سیستم را بصورت انتزاعی نشان می دهد و بیانگر این است که سیستم چه کاری را باید انجام دهد و به چگونگی انجام (از دید فنی)آنها نمی پردازد.
مدل تحلیلی رفتار عملی سیستم را مستقل از محیطی که نهایتا با آن در ارتباط خواهد بود، مشخص می کند.
آنالیست باید زمانی را برای کشف نیازمندیهای سیستم صرف کند و مدل باید تمام این نیازها را پاسخگو باشد.
توجه شود که ایجاد تغیرات در طول فاز تحلیل بسی آسانتر و با هزینه کمتری نسبت به فازهای بعدی قابل انجام است.
در فاز طراحی چگونگی برآورده کردن نیازهای کشف شده در مدل تحلیلی از مسئله، در محیط پیاده سازی بررسی می شود.
Rumbaugh عملیات فاز طراحی را به دو مرحله تقسیم کرده است: مرحله طراحی سیستم مرحله طراحی شئ طراح سیستم یک دید کلی از معماری سیستم را در نظر می گیرد و سیستم را در اجزایی کوچکتر که زیرسیستم نامیده می شود، سازماندهی می کند.
این دید مبنای تصمیم گیری در شناسایی همروندیها، تخصیص فرآیندها به پردازه ها، دسترسی به منابع و ...
قرار می گیرد.
در طراحی شئ یک مدل طراحی با جزئیات پیاده سازی بیشتری ساخته می شود؛ مانند ساختار بندی دوباره کلاسها برای بهبود کارایی، ساختمان داده های درونی ، پیاده سازی کنترل سیستم، الگوریتم پیاده سازی هر کلاس، پیاده سازی روابط و بسته بندی کردن در ماژولهای فیزیکی .
برای مدل آنالیز شده، فاز طراحی با فاز پیاده سازی دنبال می شود که مدل طراحی شده به کد در زبان برنامه نویسی ترجمه شده و از DBMS برای پایگاه داده های موجود استفاده می کند.
تحلیل شیءگرا OOA هنگامی که می خواهیم یک محصول یا سیستم جدید بسازیم چگونه آن را توصیف کنیم تا با تکنیک های مهندسی نرم افزار شئ گرا بتوانیم یک سیستم مطمئن تولید نماییم؟
آیا سوالهای خاصی در این زمینه وجود دارد که باید از مشتری بپرسیم ؟
اشیاءمربوط به سیستم کدامند؟
اشیاء موجود در سیستم چه ارتباطی باهم دارند ؟
چگونه مسائل را مشخص یا مدل کنیم تا یک طراحی موثر داشته باشیم؟
هرکدام از این سوالها در بطن تحلیل شئ گرا جواب داده می شود.
تحلیل شی گرا اولین مرحله فنی است که به عنوان قسمتی از مهندسی نرم افزار شئ گرا انجام داده می شود.
جهت ایجاد یک مدل تحلیلی ازسیستم اصول پایه ای زیر بکار برده می شود.
دامنه اطلاعات باید مدلسازی شود.
کارکرد سیستم توصیف شود.
رفتار سیستم ارائه گردد.
مدلهای داده ای، عملی و رفتاری تقسیم بندی شود تا جزئیات بیشتری از مسئله ارائه شود.
مدلهای اولیه ماهیت مسئله را نشان می دهند در حالیکه مدلهای پایانی جزئیات پیاده سازی را ارائه می کنند.
منظور از تحلیل شیءگرا تعریف تمام کلاس های مربوط به مسئله ای است که باید جواب داده شود - اعمال و صفات متناظر با آنها ، رابطه بین این کلاسها و رفتاری که از خود نشان می دهند.
جهت انجام این کار باید وظایف زیر انجام داده شود.
نیاز های اساسی کاربر که باید از طریق مصاحبه با کاربر به اطلاع مهندس نرم افزار برسد .
کلاسها باید شناسایی شوند.
سلسله مراتب کلاس باید مشخص شود.
رابطه شیء به شیء باید نشان داده شود.
رفتار شیء باید مدلسازی شود.
وظایف 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، دید های مدل کاربر و مدل ساختاری حاصل از تحلیل سیستم به تفصیل بررسی شده و نمایشی پیرامون این دیدها بطور دقیق در فاز طراحی ارائه می شود.
فرآیند طراحی سیستم طراحی سیستم جزئیات معماری مورد نیاز برای ساختن سیستم را توضیح می دهد، این فرآیند شامل فعالیت های زیر است: تقسیم مدل تحلیلی به زیر سیستمها شناسایی همروندهایی که درتعریف مسئله قید شده است تخصیص زیر سیستم ها به پردازه ها و وظایف توسعه طرح برای واسط کاربری انتخاب یک استراتژی اساسی برای پیاده سازی مدیریت داده ها شناسایی منابع عمومی و درنظر گرفتن یک مکانیزم کنترلی برای دسترسی به آنها طراحی یک مکانیزم کنترلی مناسب برای سیستم برای مدیریت وظایف تعیین چگونگی برخورد با شرایط مرزی درزیر روال طراحی هریک از مراحل فوق الذکر را با جزئیات بیشتری می آوریم.
افراز مدل تحلیلی در طراحی سیستم شئ گرا، افرازی از مدل تحلیلی انجام می دهیم بطوریکه مدل را به مجموعه هایی از کلاس های مرتبط- از نظر تعامل با هم و رفتار- افراز می کنیم.
هر یک از این مجموعه ها یک زیر سیستم بشمار می روند.
بطور کلی تمام عناصر زیر سیستم برخی از ویژگی ها را به بصورت مشترک در خود دارند.
همه این عناصر ممکن است در انجام یک عمل دخیل باشند، یا اینکه همه در یک محصول سخت افزاری مقیم باشند ویا ممکن است همه عناصر، یک کلاس ازمنابع را مدیریت کنند.
زیرسیستم ها به وسیله مسؤلیتهایشان مشخص می شوند، یعنی یک زیر سیستم را می- توان بوسیله سرویسهایی که فراهم می کند، شناسایی کرد.
در طراحی سیستم شئ گرا، سرویس به معنای جمعی از اعمال است که یک عمل مشخص را انجام می دهند(مانند مدیریت یک پردازشگر لغت، تبدیل یک سیگنال آنالوگ به دیجیتال و...) .
در این مرحله زیر سیستم هایی که تعریف و طراحی شده اند باید با معیارهای طراحی زیر مطابقت داشته باشند.
زیر سیستم باید واسط کاربری تعریف شده ای داشته باشد تا ارتباط با بقیه سیستم بتواند از طریق این واسط انجام شود.
بجز تعداد کمی از کلاس های ارتباطی بقیه کلاس های زیرسیستم فقط می- توانند باکلاس های آن زیر سیستم همکاری داشته باشند.
باید تلاش شود که تعداد زیر سیستمها کمترین مقدار ممکن داشته باشند.
یک زیر سیستم می تواند بمنظور کاهش پیچیدگی به زیر سیستم های داخلی افراز شود.
وقتی دو زیر سیستم با هم در ارتباط باشند آنها می توانند رابطه سرویس دهنده /مشتری یا اتصال نقطه به نقطه باهم داشته باشند.
درحالت سرویس دهنده / مشتری هر سیستم در یکی از این دو نقش - سرویس دهنده یا مشتری - عمل می کند و جریان ارائه سرویس یکطرفه و از سرویس دهنده به مشتری می باشد.
درحالت نقطه به نقطه جریان ارائه سیستم ممکن است دو طرفه باشد.