طراحی سیستم شی گرا

طراحی سیستم شی گرا

تحلیل سیستم به کمک روشهای شی گرا (Object- Oriented Analysis and Design) کمک می کند تا تحلیل گران سیستم بتوانند سیستم های سریع و منطقی را در شرایط در حال تغییر فضای کسب و کار طراحی نمایند. در این مقاله ما زبان UML یا Unified Modeling Language را که راهی برای تحلیل سیستم های شی گرا است، معرفی خواهیم کرد. UML یکی از قویترین ابزارهای طراحی و تحلیل سیستم است و می تواند کیفیت تحلیل های انجام شده را به مقدار زیادی بالا ببرد. این متد شامل نمودارهایی است که ساختار سیستم های شی گرا را به تصویر می کشند.

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

اشیا:

اشیا مجموعه ای از افراد، مکان ها و چیزهایی هستند که با سیستم تحلیلی ما در ارتباط هستند. مثالهایی از اشیاء می توانند شامل مشتری ها، اقلام، سفارشات و غیره باشند.

کلاسها:

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

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

یک مشخصه یا Attribute بعضی از خصوصیاتی را نشان می دهد که در همه ی اشیا یک کلاس یافت می شود. برای مثال هر خودرویی که در کلاس خودروهای اجاره ای وجود دارد، دارای مشخصه ی اندازه، رنگ، سازنده و مدل است ولی مقدار هر مشخصه ممکن است برای هر خودروی یک کلاس متقاوت باشد.

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

وراثت:

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

نمودارها و مفاهیم UML

UML مجموعه ای وسیع از ابزارها را برای مستندسازی، طراحی و تحلیل سیستم های نرم افزاری در اختیار تحلیلگران قرار می دهد. UML چندین نوع از نمودارها را در اختیار تحلیلگر قرار می دهد. این نمودارها عبارتند از:

• نمودارهای اجزاء (Component Diagrams)
• نمودارهای استقرار (Deployment Diagrams)
• نمودارهای درخواستهای سیستم یا موردهای استفاده (Use Case Diagrams): این نمودار چگونگی استفاده از سیستم را نشان می دهد. تحلیلگران از این نمودار برای شروع کار استفاده می کنند.
• سناریوهای Use Case: این ابزارها به صورت نموداری نیستند ولی از آنها برای بیان شفاهی استثنائات نسبت به رفتار اصلی که در Use Case تشریح شده است، استفاده می شود.
• نمودارهای فعالیت (Activity Diagrams): این نمودارهاجریان کلی فعالیت ها را نشان می دهد. هر UseCase ممکن است دارای یک نمودار فعالیت باشد.
• نمودارهای توالی (Sequence Diagrams): برای نمایش توالی فعالیت ها از این نمودار استفاده می شود. هر Use Case می تواند یک یا چند نمودار توالی داشته باشد.
• نمودارهای ارتباطات (Comminucation Diagrams): این نمودار می تواند جایگزین نمودار فعالیت باشد، با این تفاوت که این نمودار به جای زمانبندی ها بیشتر به ارتباطات تاکید دارد.
• نمودارهای کلاس (Class Diagrams): این نمودار برای نمایش کلاس ها و روابط بین آنها رسم می شود. برای رسم این نمودار، از نمودارهای توالی استفاده می شود.
• نمودارهای حالت (StateChart Diagrams): برای نمایش تغییرات حالت ها از این نمودار استفاده می شود. هر کلاس می تواند یک نمودار حالت داشته باشد.

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

مدلسازی Use Case

اساسا UML بر پایه ی یکی از تکنیک های شی گرا به نام Use Case استوار است. در اینجا UML برای تحلیل مدل Use Case و برای مشتق کردن اشیاء سیستم و تعاملات آنها با همدیگر استفاده می شود. در اینجا برای درک بهتر موضوع ابتدا باید با تکنیک Use Case بیشتر آشنا بشویم.

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

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

نمودارهای Use Case دارای 4 نوع رابطه هستند که به نوعی روابط رفتاری عناصر مدل با همدیگر را نشان می دهند. شکل زیر روابط مذکور و همچنین علائم آن را نشان می دهد:

• ارتباط برقرار می کند (Comminucates): یک عامل یا Actor توسط این رابطه با Use Case ارتباط برقرار می کند. باید توجه داشت که این ارتباطات همیشه باید برای عامل ها سودمند باشند.
• شامل می شود (Includes): این رابطه زمانی استفاده می شود که یک Use Case رفتاری را دارا باشد که در سایر Use Case ها هم وجود داشته باشد. به عبارت دیگر یک Use Case عمومی در سایر Use Case ها شامل می شود (اصل وراثت در شی گرایی). یک مثال از این نوع رابطه می تواند این چنین باشد: “پرداخت هزینه های دانش آموزی” توسط دو Use Case دیگر یعنی “ثبت نام در کلاس” و “ثبت نام در فوق برنامه ها” شامل شود.
• بسط می دهد (Extends): اگر use Case شامل سلسله ای از رفتارهایی باشد که در شرایط خاص و به صورت اضافه انجام شود، و Actor دیگری در انجام آن نقش داشته باشد، آن را با Extends بسط می دهیم. به عنوان مثال “بیمه سلامت دانش آموز” Use Case پایه ای “پرداخت هزینه های دانش آموزی” را بسط می دهد. به عبارت دیگر، بعضی از دانش آموزان در زمان پرداخت هزینه ها، ممکن است در بیمه ی سلامت نیز ثبت نام کنند. جهت رابطه از سمت Use Case بسط داده شده به سمت Use Case پایه ای رسم می شود.
• تعمیم می دهد (generalizes): اگر یک چیزی در مدل بیشتر از دیگری متداول و عمومی باشد، از رابطه ی تعمیم برای اتصال آنها استفاده می کنیم. این نوع رابطه می تواند بین دو عامل یا دو Use Case استفاده شود. برای مثالی از این نوع رابطه، یک “دانش آموز پاره وقت” یک “دانش آموز” را تعمیم می دهد. برای مثال دیگر، بعضی از کارمندان دانشگاه، استاد نیز هستند. این رابطه به سمت “شیء” کلی رسم می شود.

شکل زیر مثالی از یک نمودار Use Case برای یک سیستم برنامه ریزی کنفرانس را نشان می دهد. Actor ها شامل مدیر کنفرانس (مسئول مدیریت و برنامه ریزی کنفرانس)، شرکت کننده، سخنرانان، سخنران کلیدی، رزرو کننده هتل و مسئول پذیرایی می باشند. این Actor ها کاربرانی هستند که که در سیستم نقش های متفاوتی بر عهده ی ایشان است. هر دو عامل “مدیر کنفرانس” و “مسئول پذیرایی”، در برنامه ریزی غذاها و ضیافت ها نقش دارند. همچنین مدیر کنفرانس مسئول برنامه ریزی سخنرانی ها نیز می باشد. در طرف دیگر این مدل،  شرکت کننده ها در کنفرانس ثبت نام می کنند. باید توجه داشت که use Case مربوط به “رزرو اتاق” در هر دو Use Case “سازماندهی سخنران ها” و “ثبت نام برای کنفرانس” از طریق رابطه ی Include، شامل شده است. به عبارت دیگر باید به هر دو عامل “سخنرانان” و “ثبت نام کنندگان”، اتاق تخصیص داده شود. Use Case مربوط به “تخصیص مترجم”، Use Case مربوط به “ثبت نام برای کنفرانس را بسط می دهد. دلیل این امر این است که همه ی شرکت کنندگان نیاز به تخصیص مترجم نداشته و مستقیما می توانند در کنفرانس ثبت نام کنند. در نهایت، عامل سخنران تعمیمی از سخنران کلیدی می باشد.

باید توجه داشت که تنها رسم نمودار Use Case برای تحلیل و مدلسازی سیستم با این روش کافی نمی باشد و باید برای هر Use Case توضیحاتی در قالب یک سناریو تدوین نماییم. این سناریوها فرمت مشخصی نداشته و هر کسی می تواند بنابر نیاز خودش یک فرمت خاصی را توسعه دهد. یک سناریوی نوعی می تواند دارای سه بخش باشد:

1. یک بخش در بالا شامل مشخصات و اطلاعات شناسایی Case
2. قدمهای اجرایی
3. یک بخش در پایین شامل پیش فرضها، فرضیات، سوالها و اطلاعات بیشتر

شکل زیر نمونه ای از این نوع سناریوها را نشان می دهد.

نمودارهای Use Case پایه ای برای رسم سایر نمودارهای UML مانند نمودارهای کلاس و نمودارهای فعالیت ها،ایجاد می کنند. در کنار این نمودار، سناریوی Use Case نیز برای رسم نمودارهای توالی مورد استفاده قرار می گیرند. در کل این دو نمودار Use Case و سناریوی مربوطه دو ابزار قوی برای فهم کاکرد سیستم می باشند.

نمودارهای فعالیت

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

فعالیت ها (Activity) می توانند شامل عملیات خود سیستم یا فعالیت های دستی کاربران مانند “امضا کردن یک سند” باشند. رویدادها (Events) شامل چیزهایی است که در یک زمان و مکان خاص اتفاق می افتند. شرطها (Conditions) شامل یک فلش به سمت لوزی و چندین فلش خروجی از آن می باشند. همگام سازی (Synchronization) برای دو مورد چندشاخه سازی (Fork) یا تلفیق (Join) استفاده می شود. رویدادهای چندشاخه آندسته از رویدادها هستند که می توانند به صورت موازی پیش بروند. چند رویداد موازی توسط یک همگام سازی از نوع تلفیق، با همدیگر ترکیب شده و به یک رویداد تبدیل شوند. نمودارهای فعالیت دارای دو نوع علامت دیگر نیز برای شروع و پایان فعالیت ها می باشد که در شکل فوق وجود دارند. فعالیت ها با توجه به محیطی که در آن اجرا می شوند، داخل یک مستطیل دسته بندی می شوند. یک مثال عملی از نمودارهای فعالیت در شکل زیر نشان داده شده است. این نمودار مربوط به Use Case تغییر اطلاعات دانش آموزان در یک سیستم آموزشی می باشند. این کار با ورود اطلاعات ورود به سیستم توسط دانش آموز و فشار دادن دکمه ی Submit شروع می شود. اطلاعات وارد شده به سرور سیستم ارسال شده و سرور با بررسی اطلاعات دانش آموز در سرور، یک پیغام خطا منبی بر عدم یافتن دانش اموز مربوطه یا اطلاعات دانش آموز (در صورت یافتن اطلاعات) به سرور مربوط به وب بازمی گرداند. لوزی مربوطه بعد از دریافت رکورد دانش آموز، تصمیم مربوط به یافتن یا نیافتن دانش آموز از دیتابیس را نشان می دهد.

نمودارهای کلاس

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

کلاس ها بوسیله ی یک مستطیل نشان داده شده و شامل اسم کلاس، صفات و عملگرهای مربوط به خود می باشد. صفات یا Attributes خصوصیات اشیا را نشان داده و عملگرها یا Methods به شناخت کلاس از چگونگی انجام کارها مربوط می شود. شکل زیر یک نمونه از نمودار کلاس را نشان می دهد. همانطور که از شکل نیز برمی آید، اسم کلاس در بالای مستطیل ظاهر شده و صفات و عملگرها به ترتیب در پایین آن می آیند. صفت  ها معمولا به صورت Private (موجود در داخل شی) تعریف شده و با علامت منفی نشان داده می شوند. در حالت دوم، یک صفت می تواند به صورت Protected تعریف شده و فقط در داخل زیر کلاسها قابل شناسایی باشد (صفت هایProtected با علامت # نشان داده می شوند). به غیر از این دو حالت، در شرایط خاصی می توان صفت ها را به صورت Public تعریف نمود تا در همه ی اشیاء خارج از یک کلاس قابل نمایش باشند.

یکی از راه های ارتقاء کیفیت نمودارهای کلاس، نمایش روابط بین آنها می باشد. دو نوع رابطه بین نمودارهای کلاس قابل تعریف است:

• وابستگی ها (Association)
• روابط جزء / کل (Whole / Part)

وابستگی ها

ساده ترین نوع ارتباط بین کلاس ها، رابطه ی وابستگی یا ارتباطات ساختاری می باشد. وابستگی ها به صورت خط ساده نشان داده شده و دو طرف آن با یک علامت که نشان دهنده ی تعدد (Multiplicity) نوع رابطه است، علامت گذاری می شود. در اینجا، صفر نشان دهنده ی “صفر”، یک نشان دهنده ی “یک (و فقط یک)” و ستاره نشان دهنده ی “چندین” است. همچنین علامت 0..1 نشان دهنده ی “از صفر تا یک” و علامت 1..* نشان دهنده ی “از یک تا چندین” می باشد.

به عنوان مثال هایی از این روابط، در شکل زیر هر دانشجوی تحصیلات تکمیلی یک پایان نامه دارد.

هر دانشجو می تواند در “از یک تا چندین” دوره یا کلاس درسی شرکت کند:

یک دانشجو به “از صفر تا چندین اتاق خوابگاه” تخصیص پیدا کرده است (بعضی از دانشجویان در هیچ اتاقی نبوده و اسم برخی از دانشجویان در یک یا چندین اتاق ثبت شده است):

یک دانشجو می تواند در چندین دوره ی داوطلبانه شرکت کند (این رابطه تفاوتی با رابطه ی *..0 ندارد):

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

روابط جزء / کل:

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

یک رابطه ی جزء / کل ممکن است برای اشیایی استفاده شود که شامل چندین بخش مجزا هستند. برای مثال یک سیستم کامپیوتری شامل کامپیوتر، پرینتر، نمایشگر و غیره می شود. در کل این نوع رابطه دارای دو دسته بندی کلی می باشد:

• ادغام (Aggregation)
• ترکیب (Composition)

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

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

استفاده از نمودارهای UML

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

گردآورنده مطالب و مولف: بهمن منافی              ویراستار:  سارا رهبر