UML چیست؟ مفاهیم آن در طراحی نرم افزار

اهمیت مدلسازی نرم افزار تا آنجاست که اگر شما روی یک نرم افزار ساده Hello World کار میکنید، باید UMl رو به عنوان یه ابزار مهم در جعبه لوازم خود داشته باشید. در این مقاله من مهدی محمدی شما رو با فرآیند مدل سازی توسط Uml در فرایند طراحی نرم افزار، توسعه آن و استقرار نرم افزار آشنا خواهم کرد.

uml و مدل سازی نرم افزار توسط یو ام ال در چند قدم

در این مقاله برای آشنایی با UML در مورد موارد زیر صحبت خواهم کرد:

• مروری کوتاه بر اینکه چرا مدل سازی سیستم نرم افزاری مهم است
• نحوه مدلسازی نیازمندی های سطح بالای نرم افزار High-Level Requirement در مدل طراحی شده برای آنکه مطمئن شویم چیزی که قرار است تولید شود همه نیازهای مشتری را برآورده میکند.
• چگونگی مدلسازی بخش های مختلف نرم افزار که قرار است با هم کل سیستم را بسازند
• چگونگی مدلسازی رفتار هر بخش از نرم افزار که قرار است با هم رفتار کلی سیستم را بسازند و مدل کردن نحوه تعامل این بخش ها با یکدیگر
• حرکت از مدل ساخته شده به سمت دنیای واقعی و شبیه سازی آن چیزی که قرار است در استقرار Deployment اتفاق بیفتد
• ایجاد یک پروفایل اختصاصی UML ای برای مدلسازی سایر دومین Domain های نرم افزار

برای یادگیری Uml بهتر است ابتدا کمی مفاهیم شی گرایی Object Oriented و کمی برنامه نویسی مثلا جاوا Java بلد باشید. البته من در این مقاله سعی خواهم کرد مفاهیم شی گرایی را در حد امکان پوشش دهم.

UML چیست؟ معرفی یو ام ال

uml یا همان unified modeling language یک زبان استاندارد مدلسازی برای سیستم های نرم افزاری و توسعه ای است. همین جمله نشان دهنده این است که uml بخشی از ساختار نرم افزار شما باید باشد ولی خوب کماکان بعضی سوالات در همین تعریف پاسخ داده نشده: چرا از کلمه Unified به معنی یکپارچه استفاده کردیم؟ چرا میگیم uml یکپارچه است؟ اصلا چی قراره که مدلسازی بشه باهاش؟uml یک زبان Language هست، یعنی چی؟و یه سوال خیلی مهمتر از همه اینکه اصلا چرا من باید به این uml و به مدلسازی اهمیتی بدم؟

طراحی سیستم ها System Design در هر مقیاس بزرگی که باشد کلا کاری دشوار است. هرچیزی از یک برنامه ساده دسکتاپی و ویندوزی گرفته تا یک سیستم Enterprise و دارای مقیاس سازمانی که بصورت چند لایه Multi-Tier، همه اینها میتوانند از صدها یا هزاران زیر نرم افزار و ماژول کوچک و اجزای سخت افزاری و نرم افزاری تشکیل بشوند. خوب در این شرایط شما و تیم تان چگونه میتونید تک تک اجزا و کامپوننت های ریز و درشت نرم افزار را در صورت نیاز، مسیریابی Track کنید؟ اصلا کار و وظیفه هر جزء چی هست؟ و اینکه اصلا هر جزیی چطوری نیازهای مشتری شما رو قراره برآورده کنند؟ علاوه بر اینها، شما چطوری قراره طراحی یک جزء را با هم تیمی هاتون به اشتراک بگذارید تا بدونن این بخش قراره چطوری کار کنه؟ هزاران مورد ریز وجود داره که در موقع طراحی و ارائه نرم افزار ممکنه فراموش بشن یا بد توضیح داده بشن یا بد فهمیده بشن، اگر شما راهنما و ابزار درستی برای این فهم و طراحی و انتقال نداشته باشید. دقیقا اینجا جاییه که ابزار مدلسازی UML وارد بازی میشه.

در سیستم دیزاین و طراحی سیستم System Design شما به به دلیل خیلی مهم باید حتما مدل سازی کنید: برای مدیریت پیچیدگی ها Manage Complexity.مدل سازی به شما کمک میکنه یه جنکل رو با همه درختهاش بتونید ببینید. به شما اجازه میده روی اجزاها تمرکز کنید، اونها رو در دست و کنترل داشته باشید، اجزا رو داکیومنت و نوشته کنید و مهمتر از همه بتونید در مورد همه اجزا با دیگران ارتباط Communication برقرار کنید.

یک مدل یک برداشت، یک فهم Abstraction از یک شی واقعیه.هنگامی که شما یک سیستم را مدلسازی میکنید، همه موارد غیرمترقبه Irrelevant و موارد گیج کننده Confusing را از سیستم حذف میکنید اصطلاحا Abstract Away میکنید. قراره که مدل شما نسخه ساده شده Simplified سیستم در دنیای واقعی باشه و همین کمک میکنه سیستم شما طراحی شده باشه مثل ماکت سیستم و قابل فهم باشه، حتی قبل اجزا بتونه ارزیابی Evaluate بشه و یا بشه به سیستمی که قراره تولید بشه انتقاد Critisized کرد، قبل از اینکه سیستم ساخته باشه و شما در گودال عمیق اشتباهات سیستم گیر کنید.حتی یه اتفاق بهتر، وقتی شما با یک زبان رسمی Formal Language مدل سازی کنید، شما یک زبان شبه زبان برنامه نویسی دارید که این مدلسازی حتی میتونه انتزاعی(برداشت و فهمی) از آنچه که در برنامه نویسی قراره اتفاق بیفته باشه.این سطح از دقت و درستی Precision کمک میکنه که مدل ما قابل فهم و خواندن توسط ماشین و کامپیوتر باشه، به همین دلیل میتونه توسط ماشین ترجمه بشه، اجرا بشه و بین سیستم های مختلف توزیع بشه. برای مدلسازی با کیفیت یک سیستم شما به یک چیز مهم نیاز دارید: زبانی که قراره مدل با اون توصیف بشه و اینجاست که UML ظاهر میشه.

زبان مدلسازی دقیقا چیه؟ Modeling anguage

زبان مدلسازی میتونه از شبه کدها Pseudo Code ساخته بشه یا از کد واقعی ساخته بشه، تصاویر یا دیاگرام ها یا حتی پاراگراف های طولانی از متن ها ساخته بشه. در واقع همه آن چیز هایی که کمک کنند شما بهتر بتونید سیستم رو توصیف و ماکت سازی کنید. المان هایی که قراره این سیستم رو توصیف کنید بهشون نوتیشن Notation میگیم. در واقع به این بخش توضیحات متنی روی notation ها که پروفایل Profile اون نوتیشن هست رو uml meta model میگیم. uml متامدل در واقع شرح و توضیح همه المان هایی هست که توی مدل Uml داریم براساس دامنینی که پروژه در اون domain قرار داره مثلا دامین بانکی، است.

اگرچه که Notation همه ماجرا نیست. بدون توضیح دادن اون المان یا Notation کسی قادر نخواهد بود بفهمه اون باکس یا اون علامت یعنی چی؟ یا شایدم باید بتونه حدس بزنه که اون شکلی که ما تو مدل گذاشتیم چیه؟ توضیح دقیقا هر المانی که توی مدل گذاشتیم یعنی دقیقا Semantic اون المان و مفهوم اون المان رو و چیزی که قراره از اون شکل و Notation درک بشه رو بهش Meta-Model میگیم.

زبان مدل سازی نرم افزار میتونه هر چیزی را از Notation ها شامل بشه و توضیحات هر مدل که همون متامدل هست. ولی سوال اینه که وقتی کلی راه و روش برای مدل سازی هست چرا ما باید از uml استفاده کنیم؟ اصلا مگه ما نمیتونیم زبان مدل سازی خودمونو درست کنیم؟ یعنی هم المان ها رو بکشیم و هم توضیحشون بدیم که برای بقیه قابل درک باشه؟ باید بگم هر روشی برای مدلسازی داشته باشیم برای خودش مزایا Advantage و ضررها و ایرادات Disadvantage هایی رو داره. ولی uml خودش 6 تا مزیت مهم داره:

6 مزیت اصلی Uml نسبت به سایر روش های مدلسازی نرم افزار

زبان مدلسازی UML به نسبت سایر روش های مدلسازی نرم افزار و سیستم،شش تا مزیت مهم و اصلی داره که عبارتند از:

• uml یک زبان رسمیه: هر کدام از المان های این زبان مدلسازی به درستی تعریف شده اند و خیلی ها معانی اون المان را میدانند و شما خیالتون راحته وقتی مدلتونو به کسی میدین اون آدم میتونه بفهمه این المان معنیش چیه؟
• یو ام ال مختصر و مفیده Consice: کل زبان با یک سری المان محدود ساخته شده و طراحی میشه یعنی Notation هاش زیاد نیست
• یو ام ال جامع و کامله Comprehensive است: یو ام ال با همین نوتیشن های محدودش میتونه هر نوع سیستمی رو با هر شکلی و بصورت کامل توصیف کنه
• قابل توسعه Scalable است: این uml اونقدر رسمی و کامل هست که هر جا لازم باشه ما یه نرم افزار خیلی بزرگ و توصیف کنیم بتونیم اینکارو بکنیم و برای نرم افزارهای کوچک هم همین uml به سادگی میتونه مدلسازی کنه. یعنی از نرم افزارهای ریز تا بزرگ میتونه خودشو Scale کنه
• UML براساس آموخته ها و تجربیات ساخته شده: یو ام ال براساس بهترین تجربیات و اعلی ترین اتفاقات در نرم افزارهای شی گرا Object Oriented Softwares در طی 15-20 سال گذشته ساخته شده و بهبود داده شده.
• Uml  استاندارده: uml توسط گروهی کنترل و مدیریت میشه که تعامل فعالی با حوزه های دانشگاهی و پروژه ها در سرتاسر دنیا دارندکه به اینها گروه استاندارد UML میگن و این تیم استاندارد مطمئن میشه که این زبان مدلسازی همواره و در همه نوع پروژه ای قابلیت همکاری و استفاده رو داشته باشه و به این معنی هست که uml یک محصول خاص برای مدل سازی محسوب میشه

مدل سازی با کد نوشته شده Modeling By Code بدون استفاده از UML

کدهای نرم افزار خودشون یه نمونه از مدلسازی دنیای واقعی هستند که در این مدلسازی هیچ مورد غیراضافی و غیرمهمی حذف نشده، یعنی همه آن چیزی که باید در عمل در نرم افزار نهایی وجود داشته باشه، توی کدنویسی و کدهای نرم افزار هم طبیعتا وجود دارند. هر سطر از کد نرم افزار برای ی بخشی از نرم افزار مهمه. ما توی کدهای نرم افزار ارث بری، کلاس ها، ارتباط بین کلاس ها، متغیرها و تمام جزییات نرم افزار نهایی رو پیاده سازی میکنیم. خوب چه ایرادی هست اگر خود این کدها رو به عنوان مدل نرم افزار در نظر بگیریم و کلا سراغ uml نریم؟ همه جزییات توش وجود دارن و همه اجزایی که نوشتیم برای کامپایلر معنی و مفهوم دارند و حتی اگر توی کدهامون کامنت نویسی Commenting خوبی داشته باشیم که این کدها برای هر کسی میتونه قابل درک باشه، اینطور نیست؟ خوب واقعیت اینه الان شما قبل اینکه نرم افزارو بنویسی هیچ چیزوی مدل نکردی و مستقیم رفتین نرم افزار رو نوشتین! سورس کد روی خود نرم افزار فقط تمرکز میکنه و متاسفانه کل سیستم رو نمیتونه ببینه، حتی فرض کنیم همه کدهای نرم افزار هم به درستی و بصورت کامل نوشته شده باشه، این کدها نمیتونن به شما بگن که این نرم افزار توسط کی و چطوری قراره استفاده باشه. اصلا نمیتونه بهتون بگه این نرم افزار قراره چطوری استقرار Deploy داده بشه و کدهای نرم افزار اصلا تصویر بزرگ و کاملی Big Picture از نرم افزار ندارند.

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

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

مدلسازی با زبان های غیر رسمی و بدون UML

ابهام Ambiguity ، سردرگمی Confusion ، گزافه گویی Verbosity

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

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

زبان های مدلسازی رسمی، تعادل در مدلسازی

خوب تا اینجا فهمیدیم اگه خیلی زیاد به جزییات بپردازیم مثل مدلسازی با کدنویسی و یا اگه خیلی کلی و گفتاری و مبهم به مدلسازی با زبان طبیعی بپردازیم، هردو حالت مستعد کلی مشکل و خطا هستند. برای مدل سازی یک سیستم بدون ابهام، بطور خلاصه و کلی نیاز به مدلسازی با یک زبان رسمی Formal Language داریم. در واقع یک زبان مدل سازی رسمی نوتیشن های خلاصه داره ای که بطور درست و خوش تعریف ایجاد شدند. Notation های مدلسازی باید کم باشند تا به سادکی قابل یادگیری توسط هر کسی باشند و نباید مبهم باشند و تعاریف مبهم و ناواضح داشته باشند. uml خیلی ساده، یکی از این زبان های رسمی مدلسازی است. در Uml همه نوتیشن ها تعاریف مشخص و واضح دارند و تعدادشون هم زیاد نیست. اگر شما طرح مدل نرم افزار رو به هر کدام از ذینفعان نرم افزار که uml بلد هست بدید، اون متوجه میشه شما دارین در مورد چی حرف میزنید و نرم افزار نهایی قراره چطوری کار کنه. این مزیت اصلی استفاده از زبان های مدلسازی رسمی و استاندارد است.

چرا UML 2 ؟ ورژن دوم از زبان مدل سازی نرم افزار با یو ام ال

نسخه شماره 1 از زبان مدل سازی Uml این امکان را فراهم میکرد که بدون ابهام بتونن با طرح ها و طراحی سیستم ارتباط برقرار کنند و بتونند اون عصاره و جوهره Essance یک طرح را منتقل Convey کنند و حتی الزامات عملکردی نرم افزار نهایی را براساس نیازمندی های تعریف شده مشخص کنند. ولی در کل دنیا و علم و تکنولوژی در حال تغییر و تحویله و بعد مدتی متوجه شدند همه سیستم های میتونند با  uml مدل سازی بشن و فقط نرم افزار نیست که میتونه مدل سازی بشه.

عوامل محرکه توسعه نرم افزار کامپوننت محور Component Oriented Software Development، معماری مدل گرا Model Oriented Architecture، یو ام الی قابل اجرا و درست تعریف شده، لزوم به اشتراک گذاری مدل بین ابزارهای مختلف، قراردادن تقاضاها و درخواست هایی از قبل در Uml نرم افزار تعریف نشده اند مواردی بودند که نیاز به uml 2 را ایجاد کردند. البته که uml 1 و همه ورژن های نسخه 1 برای انسان طراحی شده بودند ولی برای به اشتراک گذاری بین سیستم ها و ابزارهای مختلف قابل استفاده نبودند. وقتی لازم میشه که مدل ما بین ماشین های اتوماتیک بطور مثال کامپیوترها به اشتراک گذاشته شود نیاز به uml 2  ایجاد شد. در واقع uml 1 همه نوتیشن ها و متا مدل ها و تعریف کرده بود ولی برای اشتراک گذاری مدل با ماشین و کامپیوتر uml 2 ایجاد شد.

2 نیاز و رویکرد در مدلسازی سیستم باعث شد که نیاز به نسخه شماره 2 از زبان مدلسازی uml ایجاد شود.خلاصه کلام Nutshell اولی معماری مدل گرا Model Driven Architecture که بهش MDAs میگیم زیرساخت و فریمورکی را فراهم میکنه که از مدل سازی بدون وابستگی به پلتفرم پشتیبانی میکنه، یعنی مهم نیست زبان برنامه نویسی نهایی چی باشه؟هر چی که باشه این مدلی که معماریش کردیم اونو میتونه مدلسازی کنه. یعنی در واقع یک مدلی داریم که به پلتفرم وابسته نیست Platform Independent Model که بهش PIMs میگیم که مدلی رو طراحی میکنه که این مدل هیچ وابستگی به زبان برنامه نویسی نهایی نرم افزار نخواهد داشت.

این مدلی که به پلتفرم وابسته نیست PIM میتونه بعدا به مدلی که وابسته به یه پلتفرم خاص Platform Specific Model هست تبدیل بشه و دقیقا براساس شرایط استقرار و دیپلویمنت و برنامه نویسی سیستم های نهایی و ارتباط بین بخش ها و ...  مدل بشه. یعنی مدل کلی ما باید به به مدل وابسته به پلتفرم تیدبل بشه که این قابلیت در uml 2 وجود داره. که به این خروجی وابسته به پلتفرم، uml قابل اجرا هم میگیم.

از سوی دیگر وقتی در uml 1 پروژه بزرگتر میشو  بهش قابلیت های جدیدی اضافه میشد، نمودارهای ما پیچیده و بزرگ میشدند و نیاز بود که Re architecure انجام بدیم ولی این نمودارها و قواعد در uml2 بهتر شدند و مدلسازی براساس واقعیت های نرم افزار در سالهای اخیر ایجاد شد. مثلا دیاگرام Timing و یا Package در uml 2 اضافه شد و قبلا نبود.

مدل ها و دیاگرام های در UML

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

یک دیاگرام ساده بخشی از نرم افزار شما رو بهتون نشون میده و این همه چیز نیست. خوب منطقی به نظر میرسه که وقتی یک نمودار یا دیاگرام نمیتونه کل نرم افزار رو به شما نشون بده، شما با استفاده از چندین مدل مختلف نمودار و دیاگرام اینکارو انجام بدین. خوب اولین چیزی که باید متوجه بشیم اینه که مدل نرم افزار شما قراره با استفاده از چندین ابزار و چندین مدل مختلف و دیاگرام متفاوت ترسیم و شبیه سازی بشه که ممکنه هر المان و نموداری مانند یوزکیس Use Case ها یا کلاس دیاگرام Class Diagram و کلا هر چیزی که توسط Uml پشتیبانی میشه، هستند و در نهایت همه این نمودارها و اجزا و ارتباط بین اینها، مدل نرم افزاری رو ایجاد میکنند. و این تعریف دقیق مدل هست.

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

نحوه استفاده از Uml، درجات Uml

شما میتونید از uml در سطح کمی در نرم افزار استفاده کنید یا خیلی زیاد در نرم افزارتون درگیرش کنید. مارتین فولر معمار نرم افزار معروف ، 3 حالت کلی و رایج برای استفاده از Uml در نرم افزارها مطرح میکنه:

• uml به عنوان یه Skecth و طرح: در این حالت میایم از uml در حد کشیدن و ترسیم اسکچ های کلی از بخش های نرم افزار بسنده میکنیم و اینطوری قابلیت های اصلی نرم افزار رو نشون میدیم
• uml به عنوان به Blueprint و الگو: در این حالت همه جزییات سیستم رو با uml مشخص میکنیم، همه Specification هارو تعریف میکنیم. دیاگرام هایی که در این مدل تولید میشن قابل عرضه به تیم برنامه نویس نیستند ولی توسط ابزار Uml ایجادمیشن.این رویکرد استفاده از یو ام ال، بطور عمومی با سیستم های نرم افزاری گره خورده و بیشتر برای حالت های رو به جلو رفتن و مهندسی معکوس Reverse Engineering نرم افزار استفاده میشه.
• uml به عنوان زبان برنامه نویسی Programming Language: تو این روش از uml مستقیم میرسیم به کدهای قابل اجرا، منظورمون بخشی از کد واسه بررسی و مهندسی معکوس نرم افزاری نیست، بلکه رسیدن به کدهای کل پروژه است. به این معنی که همه وجوه و قابلیت های سیستم مدل شده است. بطور تئوری بخوایم بگیم میتونید همین مدل های خروجی رو تبدیل به کدهای نرم افزار بصورت اتوماتیک کنید و دقیقا براساس محیطی که قراره دیپلوی کنید و زبان برنامه نویسی مورد نظرتون، میتونید خروجی بگیرید.

اینکه از کدوم رویکرد استفاده کنیم،بستگی به نرم افزار نهایی داره. اینکه طرح کلی نرم افزار چقدر دقیق تعریف شده، بستگی به فرایندهایی داره که توی نرم افزار نهایی قراره وجود داشته باشند. توی بعضی صنایع مشخص مثل صنعت پزشکی یا صنعت نظامی یا صنایع بانکی و مالی، مدیران پروژه بیشتر دوس دارند از uml به عنوان یک الگوی دقیق از نرم افزار Blueprint Approach استفاده کنند زیرا که نیازمندی های سطح بالای پروژه باید تعریف بشوند. در این صنایع نرم افزار طراحی شده قبل کدنویسی و تولید،  باید خیلی دقیق تعریف بشوندف و خیلی دقیق طراحی بشن زیرا اهداف نهایی این نرم افزارهای خیلی مهم و حساس هستند. چرا که شما اصلا دوس ندارین کامپیوتری که حین عمل جراحی قراره وضعیت قلب شما رو رصد کنه و کنترل کنه یهویی بلو اسکرین Blue Screen بده.

در نقطه مقابل بعضی پروژه ها هستند که خیلی مدلسازی موضوع مهمی در این حد نیست. در واقع بعضی صنایع تجاری تر معتقدند مدلسازی نرم افزار اینقدر سفت و سخت باعث میشه خلاقیت کم بشه. در اون صنایع بهتره که از Uml به عنوان یه طرح کلی Sketch استفاده بشه و در نهایت مدل شما یه سری دیاگرام های معماری داشته باشه و یه تعداد محدودی از کلاس دیاگرام ها و یک تعدادی هم Sequence Diagram برای بهتر نشون ادن سیستم کافیه.

UML و فرآیند تولید نرم افزار

وقتی شما از UML برای مدلسازی یک سیستم نرم افزاری استفاده میکنید، درجه استفاده از uML تا حدی هم بستگی به فرآیند توسعه نرم افزار داره. فرآیند توسعه نرم افزار Software Development Process در واقع دستوری و روشی برای هدایت نرم افزار و تولید ان است، اینکه نرم افزار چطوری باید ساخته باشه؟ کی قراره ان هدایت کنه؟ فعالیت های تولید نرم افزار قراره چطوری پیش بره و انجام بشه؟فرآیندهای مشخص توسعه نرم افزار باعث میشن نظم و قابلیت پیش بینی در تولید نرم افزار بالاتر بره و همچنین شانس موفقیت پروژه نرم افزاری افزایش پیدا کنه. حالا وقتی uml زبان مدلسازی پروژه شماست پس بخش مهمی از نرم افزار و فرایند توسعه نرم افزار شما هم هست.

بعضی ار زوش های معروف فرآیند توسعه نرم افزار عبارتند از:

• روش واترفال آبشاری Waterfall: روش واترفال تلاش میکند که نیازمندی های پروژه رو از بالا به پایین بشکند و تولید کند.در این روش اول باید همه نیازمندی ها و ماژول های پروژه تعریف و مشخص شوند و سپس فرآیند کدنویسی بعد از آن شروع شود. ایراد این روش water fall این است که اگر تغییری در نیازمندی ها و نرم افزار خواسته شود،هزینه این تغییرات بسیار زیاد است.در این مدل uml میتواند به عنوان یک blueprint استفاده شود.
• روش تکرار پذیر Iterative: رویکردهای تکرار پذیر سعی میکنند این ایراد روش آبشاری که عدم پذیرش تغییر بود را درست کنند و در واقع تغییرات را با آغوش باز بپذیرند.در این مدل فرآیند یکپارچه یک فرآیند تکرار پذیر در کل نرم افزار است. در این روش پروژه دارای چندین فاز است و هر فاز دارای فعالیت هایی است: در هر فاز لیست نیازمندی Requirement، و طراحی Design و پیاده سازی Implementation که همان کدنویسی Coding است را خواهیم داشت. این مدل های تکرار پذیر میتوانند از uml هم به عنوان skecth و هم به عنوان blueprint بهره بگیرند.
• روش های اجایل Agile Methods: متدهای اجایل مثل Scrum اسکرام، همان مدل های تکرار پذیر هستند ولی بازه های زمانی خیلی کوتاه مثلا اسپرینت های 2 هفته ای دارند و در هر بازه نرم افزار تولید شده را با نیازمندی های اولیه مشتری تطبیق میدهند و از این طریق ریسک پروژه را کاملا پایین می آورند. متودولوژی هایی که در این بخش استفاده میشوند مانند برنامه نویسی همزمان و جفت Pair Programming و یا تست محور بودن نرم افزار Test Driven بودن هستند. Uml تاکید میکنند که در رویکردهای اجایل به عنوان Skecth استفاده شود.

ویووهای Views مدل ساخته شده در UML

روش های زیادی وجود دارد که شما بتوانید مدلی را که ساخته اید با ویوها و نماهای مختلف ارائه کنید. در این مقاله من مهدی محمدی با روش ویوهای 4 بعلاوه 1 کراچن Kruchen's 4 Plus 1 Views این مورد را بررسی خواهم کرد.در روش فور پلاس وان مدلسازی کل سیستم به تعدادی ویو شکسته خواهد شد و هر View سیستم را ار منظر متفاوتی مدلسازی خواهد کرد. این 5 تا ویوو عبارتند از:

• ویوی لاجیکال یا منطقی Logical View: این ویو Abstraction انتزاع (برداتش یا فهم) را از سیستم که مربوط به مشخص کردن اجزای سیستم است را ارائه میدهد.اینکه سیستم نهایی از چه چیزهایی قرار است ساخته شود و این اجزا چگونه قرار است با هم تعامل و ارتباط داشته باشند.در Uml دیاگرام هایی که قرار است این ویوو را بسازند، کلاس Class، اشیاء Object، ماشین وضعیت State Machine و دیاگرام های واکنشی و تعاملی Interactions Diagrams هستند.
• ویوی پردازشی Process Views: این ویو پردازش ها و پراسس های درون سیستم را مدل سازی میکند. این ویو از این جهت که نشان میدهد درون سیستم نرم افزاری نهایی قرار است چه اتفاقاتی بیفتد و آنها را به تصویر کشیده و Visualize میکند، خیلی ارزشمند و مفید است.این ویو با دیاگرام فعالیت Activity Diagram طراحی خواهد شد.
• ویوی توسعه یا Development View: این ویوو مشخص خواهد کرد که اجزا Componenet کامپوننت و ماژول Modules های پروژه شما چگونه قرار است با هم در تعامل و ارتباط باشند. اینکه کل سیستم به چه کامپوننت ها و ماژول هایی تقسیم و بخش بندی خواهد شد. این ویوو در Uml با پکیج دیاگرام Package Diagram و کامپوننت دیاگرام Component Diagram ایجاد میشود.
• ویوی فیزیکی Physical View: این ویوو تعریف میکند که 3 تا ویوی ایجاد شده قبلی چگونه سیستم را طراحی میکنند و در دنیای واقعی چگونه قرار خواهند گرفت. این View نشان میدهد که سیستم طراحی شده نهایی چگونه قرار است در سخت افزار و زیرساخت مستقر شده و Deployment سیستم چگونه خواهد بود. این ویو با دیاگرام دیپلویمنت Deployment Diagram ساخته خواهد شد.
• ویوی یوزکیس Use Case View: عملکرد سیستم را ار منظر یک کاربر بیرونی به تصویر خواهد کشید. اینکه این سیستم چیست و قرار است چه چیزی باشد؟در این بخش همه 4 تا ویوی قبلی روی یوزکیس ویو قرار خواهند گرفت که با هم سیستم را بصورت کلی نمایش دهند. این Use Case View در حالت کلی شامل یوزکیس دیاگرام Use case Diagram و توضیحات Descriptions و اورویو دیاگرام Overview Diagram خواهد بود.

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

قبل از اینکه به دیاگرام های Uml بپردازم لازم است با دو مفهوم آشنا شویم: اولی نوت ها Notes و دومی استیروتایپ StereoTypes ها هستند.

نوت ها به شما اجازه میدهند توضیحات بیشتری را در دیاگرام های خود بنویسید. مواردی که در دیاگرام ها وجود ندارند بصورت note ثبت کنید. در نوت میتوانید هر چیزی که دیاگرام شما را بهتر توضیح دهد بنویسید.note ها در دیاگرام میتوانند بصورت جدا نوشته شوند یا به بخشی از دیاگرام ضمیمه شوند. نوت ها با خطوط دش Dashed Line به بخشی از دیاگرام اضافه می شوند. نوت ها معنی و عملکرد دیاگرام را تغییر نمیدهد، فقط برای فهم بهتر دیاگرام هستند.

استیروتایپ Stereotypes ها یک عملکرد یا استفاده دلخواه برای یک المان را مشخص میکنند و تقریبا میتوانند به همه المان های uml اضافه شوند. استیریتایپ ها برخلاف نوت ها معنی و عملکرد المان را میتوانند تغییر دهند و نقش جدیدی به المان در مدل شما بدهند. مثلا در شکل زیر آدمکی که هست یک اکتور Actor در uml هست ولی ما بهش نقش ادمینیستریتور Administrator داده ایم

محدودیتی برای تعداد استیریوتایپ هایی که یک المان میتواند بگیرد وجود ندارد. بعضی وقتها ممکنه شما برای یک المان بیش از یک نقش stereotype ایجاد کنید و تخصیص بدهید. برای تعریف یک استریوتایپ قواعد خاصی وجود ندارد. اینکار میتواند مانند شکل بالا از طریق تصویر باشد و با گذاشتن نوت اینکار را بکنیم یا اینکه با استفاده از روش نوشتاری <> اینکار را انجام دهیم. مانند شکل زیر:

خود UML یکسری استیریوتایپ های پیشفرض و استاندارد رو تعریف کرده که مفید هستند و میتوانیم از آنها استفاده کنیم. برخی از آنها عبارتند از:

استریوتایپ های مربوط به کلاس ها که به کلاس ها متصل میشوند:

• یوتیلیتی Utility: این کلاسی را بیان میکند که قرار است به عنوان یک ابزار عمل کند و یک سرویس را از طریق متدهای استاتیک ایجاد کند. دقیقا مانند کلاس math در java

استریوتایپ هایی که به کامپوننت ها متصل میشوند:

• سرویس Service: یک کامپونت ststeless بدون حالت و فانکشنال functional component که یک مقدار را محاسبه میکند و یا میتواند نمایانگر یک وب سرویس web service باشد.
• ساب سیستم Subsystem: کامپوننت بزرگی که خودش زیرمجموعه ای از یک کامپوننت بزرگ سیستم هست.

استیریوتایپ هایی که به آرتیفکت Artifact ها وصل میشن:

• اجراشدنی Executable:یک فایل فیزیکی که قابل اجرا است مثلا یک فایل exe میتونه باشه.
• فایل File: فایل فیزیکی که توسط قراره استفاده بشه.مثلا میتونه یک فایل تنظیمات Configuration و یک فایل txt باشه.
• کتابخانه Library: یک فایل استاتیک یا دینامیک library هست که این استریوتایپ را میتونید واسه مدل ها استفاده کنید. فایل های  dll یا فایل های jar در جاوا
• منبع یا سورس Source: فایل های سورس حاوی کد نرم افزاری هستند. مثلا کدهای جاوا یا cpp میتونه باشه

تگ ولیووها Tagged Values: استیریوتایپ Stereotype ها میتوانند شامل اطلاعات بیشتری و اضافه تری باشند که مربوط به المانی باشه که اون استیریوتایپ ها بهش وصل شدند. این اطلاعات اضافه رو Tagged Value میگیم.در واقع tagged value ها با استیریوتایپ ها وصل میشن و باهاش ترکیب میشن. به عنوان مثال فرض کنید شما در مدلی که ساخته اید یک المان دارید که توسط stereotype ای به عنوان صفحه لاگین در وب سایت بهش نقش فرم Form لاگین داده شده باشد.طبیعتا اینکارو با استیریوتایپ فرم انجام دادین. این stereotype فرم نیاز داره بدونه که چه مواقعی باید این فرم رو هندل کنه و مقادیرشو ارزیابی کنه این تصمیم برای Validation رو به عنوان tag value ای برای استیریوتایپ فرم تعریف میکنیم. دقت کنید tag value واسه خود stereotype هست و نه واسه خود المان.تگ ولیوها مثل note ها ترسیم میشن و داخل اونها اسم استیریوتایپ رو مینویسیم و این Tag Value به استریریوتایپ باید وصل بشه، مانند شکل زیر:

مدل سازی نیازمندی های نرم افزار با Use Case دیاگرام

فرض کنید شنبه صبحه و شما اومدین سرکار،مدیر شما یه لیست 200 صفحه ای از نیازمندی هایی که کارفرمای نرم افزار در طول 6 ماه قبل نشسته و نوشته رو بهتون میده و بهتون میگه: خوب شروع کن و این نرم افزارو با کمک تیمت طراحی کن. ولی یه مشکلی وجود داره، نیازمندی هایی که نوشته شده با زبان نوشتاری طبیعی نوشته شده و توش یه سری ابهام وجود داره و شما متوجه خیلی جاهاش نمیشن و طبیعتا نمیتونید این نوشته هارو با هم تیمی هاتون به اشتر اک بگذارین، چون قابل فهم نیست و هر کسی ممکنه یه برداشتی ازشون داشته باشه. قبلا به مشکلات تعریف نیازمندی ها به روش زبان طبیعی اشاره کردم. خوب حالا بعد از این وحشت از این 20 صفحه ای که دقیقا منظورش مشخص نیست باید چیکار کنیم دقیقا؟ شما چطوری قراره این لیست 200 صفحه ای رو که نامشخص و مبهم نیازمندی های نرم افزار رو نوشته به یک داکیومنت قابل فهم از نیازمندی های نرم افزار تبدیل کنید؟ همانطور که قبلا بهش رسیدیم، UML راه حل این مشکله.و در این مرحله شما باید با بقیه اعضای تیم و ذینفعان پروژه بشینید و این نیازمندیها رو با زبان استانداردی تعریف کنید و احتمالا یوزکیس های جدیدی رو از روی نیازمندی های Recuirement پروژه بسازید.

یوزکیس چیست؟ Use Case

یوز کیس Use case یعنی یک کیس Case یعنی یک حالت یا یک وضعیت، یک موقعیت که سیستم نرم افزاری باید داشته باشه تا بتونه یک یا چند تا از نیازمندی های پروژه کارفرما رو پاسخ بده.یوزر کیس دقیقا یک فانکشنالیتی Functionality که نرم افزار باید داشته باشه رو تعریف و مشخص میکنه. یوز کیس ها در قلب مدلسازی شما قرار میگیرند.یوز کیس ها قراره تمامی بخش های بعدی سیستم را تعریف و مدیریت کنند. use case ها بهترین نقطع شروع برای یک طراحی شی گرا object-oriented design و انجام برنامه نویسی و توسعه Development، طراحی Design، تست Test و مستندسازی Documentation هستند.

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

یوزکیس ها مشخص میکنند که نرم افزار نهایی قراره چی باشه و چه کاری انجام بده؟ نیازمندی های فانکشنال و عملکردی سیستم چی هستند؟ یوز کیسها کاری به نیازمندی های غیرفانشنال non functional نخواهند داشت. مثلا پرفورمنس performance سیستم یا زبان برنامه نویسی مناسب این نرم افزار و .. ربطی به یوزکیس ندارند و اینها نیازمندیهای غیرفانکشنال محسوب میشن.

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

یکی از مزایای use case اینه که وقتی نیازمندیهای نرم افزار بصورت یوزکیس visualize بشن و خود کارفرمای پروژه بتونه این نیازمندیهارو یکجا ببینه میتونه بعضی از اونها رو که به نظرش خیلی ضروری نیستند رو حذف کنه تا هزینه نهایی پروژه براش کمتر بشه یا زمان کمتری برای تولید نرم افزارش لازم بشه.

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

و در آخر یوز کیس ها میتونن فرآیند ساخت تست نرم افزار رو فراهم کنند. یوزکیس ها بهترین نقطه شروع برای تعریف سناریوهای تست و ساخت  Test case ها هستند. زیرا use case ها کاملترین بیان از نیازمندی های پروژه و نرم افزار هستند و موفقیت پروژه یعنی برآورده شدن یوزکیس ها. پس چه روشی بهتر برای تست از تست کردن از روی use case ها میتونه وجود داشته باشه؟

تعریف نیازمندی های پروژه با Use Case بصورت عملی

خوب به اندازه کافی در مورد تئوری ها حرف زدم، بیاین با یک مثال ساده در مورد پیاده سازی نیازمندی های نرم افزار Software Requirement برای یک نرم افزار بلاگ Blog Content Management System یا همون CMS صحبت کنیم و پیش بریم.

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

در تعریف نیازمندی های یک نرم افزار دو مدل نیازمندی داریم: نیازمندی های ضروری و واجب که بهشون Shall Requirement میگیم و باید حتما در نرم افزار نهایی وجود داشته باشند و نیازمندی های اختیاری ولی مورد ترجیح که بهشون Should Requirement میگیم و در صورت امکان بهتره که در نرم افزار نهایی وجود داشته باشند.یعنی مثلا اگر مشکل زمانبندی و تاخیر در پروژه داشته باشیم اول نیازمندی های نوع should رو قربانی و حذف میکنیم.

بیرون و پیرامون نرم افزار شما، اکتورها Actors

اکتورها در Uml به شکل یک آدمک که نقشش زیرش نوشته شده یا بصورت یک استروید که یک باکس است و بلاش نوشته Actor و زیرش نقش اون آدک رو نوشته تعریف میشن. اینها آدم هستن، نقش هستن و اکتورها بخشی از سیستم نرم افزاری  نیستند. خیلی ارزشمنده که برای نامگذاری اکتور ها در uml دقت کافی به خرج بدید. بهتره نامی رو انتخاب کنید که هم توسط مشتری  و هم توسط طراحان سیستم و برنامه نویسان قابل درک باشه و این نقشی که تعریف میکنید یک نقش عمومی و generic باشه و اسم فرد یا شخصی نباید باشه.

اینکه بفهمیم توی سیستم در uml چی اکتور هست و چی اکتور نیست، براساس تجربه به دست میاد. ولی تا زمانی که قرار باشه این تجربه رو کسب کنید من یه روش ساده بهتون یاد میدم که بدونید در سیستم چیزهایی things که باهاش مواجه هستید، بدونید کدومش actor هست و کدومش actor نیست.اکتورها قرار نیست حتما معرف یه آدم یا شخصی باشند. در عین اینکه اکتور میتونه یه آدم و انسان باشه بلکه میتونه یک نرم افزار و سیستم بیرونی third party system باشه که مثل مدل نرم افزارهای B2B یعنی Business 2 Business قراره با نرم افزار ما کار کنه. یادتون باشه که اکتور رو مثل یک جعبه سیاه black box بدونید که شما نمیدونید اکتور چجوری قراره کار کنه و رفتار کنه و شما نمیتونید عملکرد و رفتار داخلی اکتور رو تغییر بدید. فقط نکته مهم اینه که اکتور با سیستم شما قراره interact داشته باشه.

اکتورهای حیله گر و فریبکار Tricky Actors:

لزوما همه اکتورها سیستم های بیرونی یا آدمهای بیرونی که قراره با نرم افزار شما کار کنند، نیستند. یکی از اکتورهای فریبکار به عنوان مثال ساعت سیستم system clock است. اسمش که میگه این ساعت بخشی از سیستم هست ولی آیا واقعا اینطور هست؟ از یه ور ساعت سیستم بخشی از سیستم شماست و از یه ست هم شما نمیتونید روی این ساعت سیستم تغییری ایجاد کنید و ممکنه همین ساعت سیستم باعث رفتاری بشه که در نرم افزار شما اتفاق بیفته. به همین دلیل بعضی actor ها واقعا سخته تشخیص بدیم که اکتور هستند یا نه. برای تشخیص اکتورها در سیستم به دو سوال باید پاسخ بدید:

• این چیزی که دارم در موردش حرف میزنم یه آدم بیرونیه که قراره با سیستم من تعامل برقرار کنه؟ پاسخ مثبت یعنی اکتوره
• این چیزی که دارم بهش فکر میکنیم،چیزیه که من در سیستمم نمیتونم روی عملکردش تغییری ایجاد کنم؟پاسخ مثبت یعنی actor هست
• این چیزی که دارم در موردش بررسی میکنم یه نرم افزار بیرونیه که کارکردشو من تعیین نمیکنم؟ پاسخ مثبت یعنی اکتور هست

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

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

پالایش اکتورها Refining Actors

درمرحله اول که دارین اکتورهای مدل رو پیدا میکنید و مشخص میکنید، متوجه میشد که بعصی از این actor ها با بعضی دیگه از اکتورها به هم مربوط هستند. مثلا Administrator سیستم یک اکتور هست که همه نقش هایی که user سیستم داره، داره و بعلاوه یه سری دسترسی های اضافه هم داره. ما باید این زیرمجموعه بودن اکتور و دسترسی هاشو ، در مدل uml نشون بدیم. یعنی یه جور generalization در سیستم اتفاق میفته که بعضی اکتورها عمومی تر هستند و بعضی دیگر از اون اکتورها برگرفته شده اند. در شکل زیر نحوه تعریف اکتور های سیستم و این generalization و ارتباط اکتورها با همدیگر رو میبینیم.

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