استفاده از مفاهیم جدید تولید نرم‌افزار

روند طراحی و توسعه نرم‌افزار طی ده سال گذشته حتی در همین ایران خودمان هم تغییرات زیادی داشته. آن زمان یعنی حدود سال ۷۹ شمسی مردم تازه از شر FoxPro خلاص شده و به دیتابیس‌های مدرن‌تری مثل Access، MS SQL Server و Oracle رو آورده بودند. برنامه‌نویسی در عصر ویندوز راحت‌تر و منظم‌تر شده بود. تا قبل از آن عموماً کسی لذت Foreign Key و Delete/Update Cascade را کشف نکرده بود. طی این ده سال استفاده از Database Driver و ADO رواج زیادی پیدا کرد. در این دوره آنها که منظم‌تر بودند از نمودارهای ERD برای بیان ساختار دیتابیس، نرمال‌سازی، کلاس‌های مجزا برای دسترسی به دیتابیس (معماری سه لایه) و… استفاده می‌کردند.

اما اکنون آن دوران به سر آمده و ما خیلی وقت است که وارده دوران Domain Driven Design یا همان DDD شده‌ایم. در عصر DDD هیچکس مستقیماً به دیتابیس وصل نمی‌شود بلکه از ORM‌ استفاده می‌کند. روابط بین entityها به جای ERD با UML Class Diagram تعریف می‌شود و معماری‌های چندلایه‌ای با استفاده از DDD خیلی راحت‌تر شده و…

حال سوال این است که آیا لازم است ما هم صرفاً به خاطر همراهی با زمان یه سمت Domain Driven Design و Object Oriented برویم یا این که واقعاً نفعی برای ما و شرکت‌مان در آن وجود دارد؟ جواب این سوال هر دو است. چون اولاً وقتی که همه دنیا به این سبک جدید رو آورده‌اند خیلی سخت است که ما همان روش‌ها و ابزارهای قدیمی را نگه داریم و خلاف جریان آب شنا کنیم. ثانیاً عصر جدید امکانات بسیار خوبی را با خود به همراه آورده است و نباید آن را به این سادگی از دست بدهیم.

عصر جدید یعنی دنیای Domain Driven Design و Object Oriented که با استفاده از ORMها و UML محقق می‌شود به شما کمک می‌کند که:
‫۱- کد شما قابلیت نگهداری بالایی داشته باشد.
‫۲- پیدا کردن و برطرف کردن باگ‌ها راحت‌تر باشد.
‫۳- اگر طراحی درست انجام شده باشد، برنامه‌نویسی راحت‌تر خواهد بود.
‫۴- مزایای معرفی شده در Object Oriented به طور ملموسی در دسترس قرار خواهد گرفت. مفاهیمی مثل Inheritance باعث می‌شود حجم کد کاهش یابد.
‫۵- کدهای DDD خیلی منظم‌تر از کدهای تولید شده در دوران قبل هستند.
‫۶- تولید نرم‌افزارهای DDD هم‌خوانی بسیار بیشتری با متودولوژی‌های جدید اسکرام، XP و… دارد.
‫۷- …

در بین شرکت‌ها و تیم‌های نرم‌افزاری ایرانی تعداد قابل توجهی به روش‌های عصر جدید رو آورده‌اند. یعنی از ORM استفاده می‌کنند، کل کار را به صورت Object Oriented جلو می‌برند، Documentation آنها بر اساس UML است و … اما متاسفانه هنوز خیلی‌ها هستند که خود را از لذت و کارایی عصر جدید محروم کرده‌اند. به نظر من تنها عاملی که باعث می‌شود این طور افراد همچنان به استفاده از روش‌های قدیمی ادامه دهند عدم آگاهی نسبت به روش‌های جدید است. چون هیچ مدیر پروژه یا رییس شرکتی دوست ندارد کاری را که می‌شود در شش ماه انجام داد در هشت ماه انجام دهد و نهایتاً هم کدی را تحویل بگیرد که نگهداری و توسعه آن خیلی هم سخت باشد. به همین خاطر به این طور افراد توصیه می‌گردد اگر هم از روش‌های قدیمی خیلی هم راضی هستند اقلاً مطالعه‌ای در مورد روش‌های جدید و مزایای آن داشته باشند.

‫UML به زبان خیلی خیلی ساده

همیشه در فرایند توسعه یک نرم‌افزار (تحلیل، طراحی، پیاده‌سازی، استقرار و…) نیاز است که تفکرات و برداشت‌های خود را به نحوی بیان کرده تا هم برای آینده محفوظ داریم و هم برای تفهیم نظر خود به همکاران، کارفرما، مدیر و بقیه افراد مورد استفاده قرار دهیم. همه افرادی که در توسعه یک نرم‌افزار سهیم هستند حتماً به نحوی از یک یا چند روش مستندسازی استفاده می‌کنند. مثلاً بعضی‌ها شرح کارکرد سیستم را بر روی کاغذ می‌نویسند، بعضی‌ها هر واحد از سیستم را به شکل یک خانه روی کاغذ ترسیم می‌‌کنند، بعضی‌ها جداول دیتابیس مورد نیاز را روی کاغذ کشیده و آنهایی را که با هم ربط دارند را به هم متصل می‌کنند، بعضی‌ها روش انجام یک عملیات را به صورت یک الگوریتم چند خطی یا یک فلوچارت نمایش می‌دهند و قس علیهذا. حال فرض کنید در یک تیم بزرگ هر کسی از روش خودش استفاده می‌کند، آن وقت چه مشکلی پیش می‌آید؟ بله چون روش‌ها یکی نیست هیچ کس نمی‌تواند حرف دیگری را به خوبی متوجه شود. چندین سال پیش چند آدم خیلی باهوش که خیلی زودتر از ما با این مشکل برخورد کرده بودند سعی کردند این روش‌ها را با توجه به خصوصیات دنیای جدیدالظهور Object Oriented استاندارد و یک شکل کنند. آنها فرایند ترسیم این نمودارها را مدلسازی و نام مجموعه روش‌های استاندارد شده خود را UML به معنای «زبان مدل‌سازی متحدالشکل» گذاشتند.
UML شامل تعداد زیادی نمودار است که بعضی از آنها رواج بیشتری دارند و بعضی‌ها کمتر. من از میان نمودارهای مختلف آنهایی را که برای خودم به عنوان یک برنامه‌نویس ساکن ایران که بیشتر روی سیستم‌های مالی-اداری کار می‌کند اهمیت و کاربرد بیشتری داشته‌اند را انتخاب کرده و سعی کرده‌ام هر کدام از آنها را در چند گام کوچک توضیح دهم. برای دیدن هر کدام از راهنماها روی نام هر کدام از نمودارها کلیک کنید. مبنای همه این نوشته‌ها کتاب معروف UML Distilled نوشته مارتین فولر بوده است.

۱- Use Case Diagram: برای تشریح عملکرد سیستم به کار می‌رود و اولین موردی است که باید برای هر سیستم استخراج شود.
۲- Class Diagram: پرکاربردترین و به زعم بعضی‌ها تنها نمودار کاربردی UML است. از این نمودار برای نمایش ساختار اطلاعاتی و به عنوان جایگزینی برای ERD استفاده می‌شود.
۳- Sequence Diagram: با کمک آن می‌توان کلاس‌ها و متودهای مورد نیاز برای انجام هر کدام از Use Caseها را استخراج کرد.
۴- Activity Diagram: جزییات انجام یک عملیات را نشان می‌دهد و خیلی مشابه Flowchartهای قدیم است.
۵- State Machine Diagram: برای بیان حالات مختلفی که یک Object در آن قرار می‌گیرد به کار می‌رود و بسیار کم کاربرد است.

پی‌نوشت:
۱- راهنمای مربوط به Class Diagram هنوز نوشته نشده است.
۲- خواندن نوشته «آیا هنوز یادگیری UML کار با ارزشی است؟» توصیه می‌شود.

۳- خواندن این یکی هم توصیه می‌شود: UML عملی به طور خلاصه

‫Activity Diagram در ۵ گام!

۱- Activity Diagram تقریباً همان Flowchart قدیم است به علاوه امکان بیان فعالیت‌های موازی.
۲- برای یادگیری قوانین ترسیم Activity Diagram شکل زیر را مشاهده فرمایید. در این شکل برای بیان دو کار که موازی انجام می‌شوند از fork استفاده می‌شود. join هم برای وقتی استفاده می‌شود که انجام همه فعالیت‌های موازی به پایان رسیده و قرار است از آنجا به بعد دوباره همه چیز با هم شروع شود.
۳- از عبارت merge برای وقتی استفاده می‌شود که قرار است خروجی چند فعالیت با هم به آنجا برسد. تفاوت merge با join در این است که در merge با فرا رسیدن هر کدام از فعالیت‌ها ادامه روال پیگیری می‌شود ولی در join بایستی تک تک فعالیت‌ها انجام شده و به نقطه join رسیده باشند تا روال فعالیت‌ها ادامه داده شود.
۴- با استفاده از مفهوم partition می‌توان هر activity diagram را از نظر بصری به چند قسمت تقسیم کرد و نشان داد که هر کدام از فعالیت‌ها در کدام واحد یا کلاس انجام می‌شوند.
۵- مفاهیم دیگری مثل signal، pin، transformation و expansion regions وجود دارند که در Activity Diagramهایی که ما معمولا استفاده می‌کنیم کاربردی ندارند.

منبع: فصل ۱۱ کتاب UML Distilled مارتین فولر

‫State Machine Diagram در ۳ گام

۱- State Diagram خیلی خیلی کم کاربرد است. به طوری که در یک سیستم جامع مالی اداری فقط ممکن است یک یا دو مورد وجود داشته باشد که بتوان برای آن State Diagram در آورد.
۲- قوانین رسم State Diagram آنقدر ساده است که در شکل زیر خلاصه می‌شود:

۳- دو مفهوم Super State و Conurrent State هم بعضی اوقات کاربرد دارد

‫مورد کارکرد (Use Case) در ۱۰ گام

۱- مورد کارکرد به دو بخش محتوای متنی و نمودار (Use Case Diagram) تبدیل می‌شود.
۲- بخش محتوای متنی Use Case خیلی خیلی مهم‌تر از «نمودار مورد کارکرد» است.
۳- استاندارد چندان سفت و سختی برای بخش محتوای متنی Use Case وجود ندارد.
۴- بخش محتوای متنی «مورد کارکرد» هر چه کوتاه‌تر و گویاتر باشد بهتر است.
۵- روابط مختلفی بین موارد کارکرد وجود دارد ولی توصیه شده به جز Include از هیچ کدام آنها استفاده نشود. Include یعنی یک «مورد کارکرد» در یکی از مراحل سناریوی خودش یک «مورد کارکرد» دیگر را مورد استفاده قرار می‌دهد.
۶- «موارد کارکرد» را می‌توان خیلی نزدیک به سیستم یا خیلی نزدیک به فهم کاربر یا در یک حالت بینابین نوشت. این سه حالت به ترتیب به اسامی Fish Level و Kite Level و Sea Level معروفند. توصیه شده «موارد کارکرد» بیشتر به صورت Sea Level نوشته شود.
۷- ممکن است نوشتن «مورد کارکرد» ما را به یاد «رابط کاربری-UI» بیندازد ولی این صحیح نیست چون طراحی UI بعد از تکمیل «موارد کارکرد» شروع می‌شود. علاوه بر این «مورد کارکرد» قصد و غرض Actor را نشان می‌دهد نه مراحلی را که طی می‌کند.
۸- هر «مورد کارکردی» معمولا شامل یک سناریوی موفق و یکی دو سناریوی ناموفق است.
۹- معمولا در هر «مورد کارکردی» یکی دو تا «گام» را به تشریح «پیش شرط» یا «حالت استثنا و خطای» سناریوها اختصاص می‌دهند.
۱۰- به عنوان نکته تکمیلی به عکس زیر که از کتاب UML Distilled مارتین فولر برداشته شده دقت کنید. این عکس یک «مورد کارکرد» نمونه را نمایش می‌دهد.
‫یک Use Case نمونه که از کتاب مارتین فولر برداشته شده

منبع: فصل ۹ کتاب UML Distilled مارتین فولر

‫‫‫Sequence Diagram در ۷ گام

۱- Sequence Diagram را در فارسی، نمودار توالی می‌گویند.
۲- تقریباً به ازای هر «سناریو» یک نمودار توالی وجود دارد. برای انجام هر «سناریو» چندین آبجکت با همدیگر تعامل دارند.
۳- نمودار توالی برای نشان دادن جزییات الگوریتم اجرای عملیات مثل حلقه و شرط خیلی ضعیف است و بهتر است برای این کار از Activity Diagram استفاده کرد.
۴- برای کشیدن «نمودار توالی» از دو روش رایج به نام‌های centralized control و distributed control استفاده می‌شود. روش «توزیعی» در دنیای شی‌گرا خیلی رایج‌تر است. این روش طراح را تشویق می‌کند به جای یکی دو تا کلاس بزرگ و چند متود خیلی طولانی، از چندین کلاس کوچک و چندین متود خیلی کوتاه استفاده کند.
۵- فراخوانی متود هم به روش هم‌زمان و هم به روش غیرهم‌زمان قابل انجام است. روش غیرهم‌زمان در برنامه‌های Multi Thread کاربرد دارد.
۶- بعضی افراد به جای «نمودار توالی» از CRC که یک ابزار غیر UMLی است به عنوان یک جایگزین استفاده می‌کنند. CRC بسیار مشابه «نمودار توالی» است ولی رسم آن خیلی راحت‌تر و استفاده از آن هم خیلی رایج است.
۷- به عکس زیر به عنوان نمونه‌ای از «نمودار توالی» که در پروتکل ای.سی.ای استفاده می‌شود نگاه کنید.

نمودار توالی

منبع: فصل چهارم کتاب UML Distilled نوشته مارتین فولر