تله هاي استفاده از UML در RUP

[Elham_gh]

Pitfalls using UML in RUP

Hans Admiraal
پيش مقاله! :

-اين نوشته از زبان Hans Admiraal است. و من براي اينكه از قلم خودموني و زبان خودش تعريف كرده ، با همان سبك مطالبشو مي يارم.
-من برخلاف نظر يكي از دوستان، سعي مي كنم لغات كاربردي و مفهوم دار رو به فارسي ترجمه نكنم.
-اين مقاله رو من در 6 قسمت ارائه خواهم كرد.( كه البته كم مطلب ترين قسمت ، همين قسمت اوله!!)
- در نهايت اميدوارم امانت داري خوبي باشم و از عهده ترجمه روان و قابل فهم آن بر آمده باشم. و اميدوارم شما هم با نظرات و راهنمايي هاتون منو همراهي كنيد.

(قسمت اول)

مقدمه
آيا تا حالا سعي كردين با استفاده از UML ، قوانين RUP رو پياده كردين؟
"خوب! سعي كردم كه اينكار رو بكنم!" اين پاسخي كه اغلب در جواب اين سوال شنيده مي شه.اين مقاله براي اونهايي كه سعي كردن يا قصدشو دارن. من خودم بارها سعي كردم و خوب مي شه گفت "بله! شكست خوردم! ". دنباله روي كوركورانه از RUP جواب نمي ده ، اما خدا روشكر لازم نيست با تمامي اين فرايند يكباره خدافظي كنيد.اجازه بديد كه با اشاره كردن به يكسري از تله هاي RUP كمكتون كنم. و اول از همه يك مروري داريم بر مدلهاي مختلف در RUP.

مدلها در RUP:يك مدل ، يك توصيفي است از نظر و وجه خاصي از سيستم نرم افزاري. شكل زير يك مروري دارد بر مدلهايي كه توسط RUP مشخص شده است.براي هر پروژه ، بايد تصمصم بگيريد كه كدام يك از اين مدها ارزش افزوده اي براي شما دارد.

http://barnamenevis.org/forum/attachment.php?attachmentid=19788&stc=1&d=1215969038
شكل 1
شكل 1 ، تصويري نيست كه شما در محصول رسمي RUP پيدا كنيد.(Elham_gh: اين تصوير بسيار بسيار كاربردي و گره گشاست. حتما ازش استفاده كنيد) . شبكه پهناور صفحات وبي ديد و مرور روشني از ارتباط بين مدلهاي مختلف UML به شما نمي دهند.البته بله، اطلاعات خيلي زيادي وجود داره ، اما همه اونها حول تشريح Artifact ها و Guidline ها مي چرخند.
اين سوال كه " كداميك از نموارهاي UML رو بايد بكشيم ، و اينكه اين نمودارها چه مناسبات مشتركي دارند؟"،هميشه در طول پروژه آدم رو گيج مي كنه.
جايي كه از UML استفاده مي شود،RUP سه Discipline رو مشخص كرده:
>Business Modeling
>Requirements
>Analysis and Design
براي هر كدام از اين Discipline ها ، من خلاصه اي از نگاه و ديد RUP به مدلهاي UML ي،انواع دياگرامهايي كه مي توانند استفاده شوند ، مفهومشون و ارتباطاتي كه بين element هاي دياگرامهاي مختلف وجود دارد ، بتون ارائه مي كنم. صرف نظر از اينها ، من نظرات و پيشنهادات خودم رو براي گرفتن تصميم عملي تر بهتون مي گم و در در مورد نقاط ضعف RUP بحث خواهم كرد.
(قسمت بعدي : Business Modeling)

[whitehat]

عنوان بحث ویرایش شد، امیدوارم مقاله کامل نوشته بشه
پ . ن: این پست بعدا پاک میشه

[Elham_gh]

(قسمت دوم)
Business Modeling
همه Application ها نياز به Business Modeling ندارند.اما براي اون دسته از Application هايي كه اداري-اجرايي هستند و Business Process هايي (Elham_gh:فرايندهايي كه در گردش كار سيستمي كه مي خواهيم پياده اش كنيم وجود دارند)دارند كه بايد آنها را درنظر بگيريم و پياده سازي كنيم ، اين مرحله انجام مي شود.


http://barnamenevis.org/forum/attachment.php?attachmentid=19909&stc=1&d=1216227824
(شكل 2)
RUP دو مدل را براي Business Modeling مشخص كرده:
1-Business Use case Modeling – كه ارتباطات خارجي سازمان را توصيف مي كند ، به اصطلاح Business Use case ها را.
2-Business Analysis Modeling - نشان مي دهد كه سازمان براي اينكه آن ارتباطاتش محقق شود ، چگونه رفتار مي كند.

Dependency ي كه در شكل 2 وجود دارد ، اين حقيقيت را منعكس مي كند كه Business Analysis Modeling داراي يكسري ارجاعات به Business Use case Modeling است، چون براي هر business use case يك تحقق داخل سازماني را فراهم مي كند(منظور realization است).

Business Use Case Modeling
Business use Case Modeling ، ارتباط بين سازمان ( كه سازمان در اينجا به صورت black box ديده مي شود)و دنياي بيرونش را نشان مي دهد. دنياي بيرون شامل business Actor ها ست كه اغلب مشتريان و تهيه كننده ها هستند. يك business use case از ديدگاه Actor توصيف مي شود. مثلا، براي Business Actor ي به نام " مشتري" ، use case ي به نام "سفارش كالا" وجود داردو يا براي Actor ي به اسم "تهيه كننده" ، Use case ي به نام "تهيه مواد اوليه" وجود دارد.
دياگرامهايي كه براي مدل كردن Business use case استفاده مي شوند ، عبارتند از :
1.Package Diagram:مدلهاي بزرگ بين package ها تقسيم مي شوند.دايگرام package ارتباط بين اين Package هاست.
2. Use Case Diagram : use Case ها را نمايش مي دهد و ارتباطات مابينشان و ارتباطات با Business Actor ها را مدل مي كنند.
3. Activity Diagram-جريان اتفاقات داخل يك Business use case را نشان مي دهند.


Business Analysis Model
نحوه رفتار و عملكرد داخلي سازمان با اين هدف تحقق بخشيدن به business Use case ها ، موضوع business Analysis Modeling است.
همچنين شما ساختار سازماني و گردش و جريان اطلاعات را تا جايي كه مرتبط است ، در اينجا مدل مي كنيد.
دياگرامهايي كه براي مدل كردن business Analysis استفاده مي شوند ، عبارتند از:
1.package Diagram – ارتباط بين Package ها را نشان مي دهد.
2.Class Diagram - ساختار سازماني و اطلاعاتي را نشان مي دهد.در اينجا Business Worker ها Active Object ها هستند(كاركنان و سيستمهاي اطلاعاتي) وPassive Object ها (مستندات و محصولات)، Business Entity ناميده مي شوند.
3.Activity Diagram – مدل Workflow ي است و روي فعاليت ها(activity) تمركز دارد.Business worker ها ، تقسيمات دياگرام هستند(elham_gh : منظور swimlane هاست) و در بر گيرنده Action ها و Business Entity ها ورودي ها و خروجي هاي اين Action ها هستند.
4.Interaction Diagram -مدل Workflow ي است و روي تبادل پيغامهاي مابين كارمندان(Employee) و تيمها تمركز دارد.
5. State Machine Diagram –چرخه حيات يك Business Entity را نشان مي دهد(وضعيت و تغيير وضعيتش را)

RUP به عنوان يك جايگزين سبك و راحت ، Domain Model را به عنوان يك Business Model پيشنهاد مي دهد. Business Model تنها Business Entity ها و ارتباطاتشان و Business Rule ها توصيف مي كند.

(قسمت بعدي-Domain model)

[Elham_gh]

ميان مقاله-1!!

قبل از ادامه دادن مقاله ، حس كردم نياز است كه يكسري مفاهيمي كه تا حالا به اونها اشاره شده، يا بعدا اشاره مي شه رو كمي توضيح بدم.
قبل از هر چيز فرض رو بر اين مي ذاريم كه شما با UML و دياگرامهاي اون آشنا هستيد.
Stereotype :خصيصه اي ست كه به عناصر UML اضافه مي شوند تا آنها را خاص تر كنند! مثلا Use case يكي از عناصرهاي UML ي است كه نشان دهنده يكسري فعاليت است.مثل "صدور چك". حالا Business Use case همان مفهوم را دارد با توضيح بيستر يعني يكسري فعاليت كه در دنياي واقعي عينا انجام مي شود.
Business :معادل فارسي آن "كسب و كار" است. و در حقيقت مفهوم آن يعني آن چيزي كه مي خواهيم آن را مدلسازي و تبديل به سيستم كنيم. و در حقيقت هر ان چيزي است كه در دنياي واقعي ، موجوديت و واقعيت دارد. حالا تركيبات زيادي ازBusiness وجود دارد، مثل Business Worker ، Business Actor ، Business Use Case و.... تمام آنها مرتبط با دنياي واقعي هستند و موجوديتهاي دنياي واقعي را نشان مي دهند.مثلا اگر در مدلمان يك Business Worker تعريف كنيم به اسم "Sale Manager" يعني در محيط واقعي كه ما آن را مدل كرديم ، كارمندي وجود دارد كه عنوانش "مدير فروش" است. به اين ترتيب عامل يا Actor ي به اسم "System User" (كاربر سيستم) نمي تواند از نوعBusiness ي باشد. تا آنجا كه لازم باشد ، مشتقات Business ي را توضيح خواهم داد.

Business Worker – كسي است كه داخل سازمان كار مي كند.(يك Stereotype است براي Actor )
Business Entity – يك Object ي است كه سازمان از آن براي اداره كردن كسب و كارش و محصولات و فرآورده هايش در طي مسير كسب و كار ، استفاده مي كند.Business Entity همانطور كه از اسمش معلوم است Entity ي است كه Business از آن استفاده مي كند.Entity شامل تمام اون چيزهايي است كه Business worker ها هرروز با انها در ارتباطند. براي مثال سفارش فروش ، حساب بانكي ، قرار داد و هر آنچه با كسب و كار مرتبط است

[Elham_gh]

(قسمت سوم)
Domain Model
با اينكه RUP فعاليت Business Modeling رو اختياري در نظر گرفته، اما من هميشه ، حداقل Domain Model رو مي سازم.در يك همچين مدلي ، من مفهوم ها را تعريف كرده و آنها را با Class Diagram نمايش مي دهم.همراه با يك business glossary كه تصوير روشني از هر business Class ارائه مي دهد.

http://barnamenevis.org/forum/attachment.php?attachmentid=20085&stc=1&d=1216483999
(شكل 3)
Domain Model يك اسكلت فني مهم براي مشخص كردن use case ها در Requirement Discipline است ، ازش نگذريد!! يك نكته ديگر در مورد مثالي كه در شكل ارئه شده اينكه، من هيچ attribute يا Operation ي را نشان ندادم، اين بدين معني نيست كه اونها وجود ندارند. در مقابل ، بعضي از مفاهيم Domain مي توانند با attribute و operation ها به بهترين شكل مدل شوند.( اگر چه Business Entity ها هيچ Operation ي ندارند ، چون Passive هستند)

More Business Analysis
اگر application بخواهد يك يا چند Business process را كه خوب تعريف نشده اند ، پشتيباني كند ، آنوقت بايد Business را يشتر مدل كنيد.شما مي توانيد اين مدلسازي را با Business Use case Modeling انجام دهيد. اما من پيشنهاد مي كنم كه فراموشش كنيد!! در عوض من Activity Modeling سطح بالا را در Business Analysis Modeling جايگزين مي كنم.اين دياگرام actionي(از موجويتهاي UML) با stereotype ي به نام <<business process>> ،كه براي هر Business process لازم دارد كه پشتيبانيش كند ، نمايش مي دهد.

http://barnamenevis.org/forum/attachment.php?attachmentid=20086&stc=1&d=1216483999
(شكل 4)

توجه كنيد كه نماد شن كش ، كهدر قسمت پايين process ديده مي شود ، دلالت بر اين داد كه اين business process به يك دياگرام activity سطح پايينتري تجزيه مي شود(مطابق شكل 5) .
در شكل 5 ، براي هر business worker يك swimlane وجود دارد.


http://barnamenevis.org/forum/attachment.php?attachmentid=20087&stc=1&d=1216483999
(شكل5)

جداي اينكه business use case كار زيادي مي برد ، بسياري از business process ها را اصلا نمي شود با business use case ها توصيف كردو اين حالتي است كه آنها فرايندهايي هستند كاملا ناشي از داخل سازمان.مانند "Check administration" يا "update website"
تله ديگري هم هست! و اون اينكه Business use case ها بايد از ديدگاه business actor ها نامگذاري شوند("let the organization handle my issue" ("بذار سازمان مسئله رو بدست بگيرد")) در صورتيكه business process ها عموما از ديدگاه سازماني نامگذاري مي شوند("Handle the customer's issue") . وقتي يك مقايسه بين Business use case modeling و Business analysis modeling انجام مي دهيم، مي بينيم ديدگاه تغيير كرده است.
پس Interaction Diagram ها چي؟خوب! من فكر مي كنم كه Activity Diagram ها براي مدلسازي فرآيندها به اندازه كافي خوب تجهيز شده اند . Interaction Diagram ها اطلاعا بيشتري نمي دهند و معمولا خوانايي كمتري دارند.

State Machine
Business Entity هايي كه داراي چرخه حيات بين حالات مختلفشان هستند ، نياز به state machine دارند.براي مثال : وقتي مسدله و مشكل (issue) ثبت مي شود(register) ، اول منتظر مي ماند كه توسط يكي از اعضاي help desc بررسي شود. اگر آن شخص تصميم بگيرد كه آن را به تيم ارجاع دهد ، مسئله به حالت "Forwarded" تغيير مي كند.


http://barnamenevis.org/forum/attachment.php?attachmentid=20088&stc=1&d=1216483999
(شكل 6)

State machine اغلب يك ديدگاه ديگري است از workflow ، بنابراين در business analysis model مقداري افزونگي ايجاد مي كند(elham_gh : افزنگي يعني تكرار اطلاعات در جاهاي مختلف) . از طرف ديگر اين ديدگاه دوم يك فرصت و امكان خوب براي چك كردن و بهينه كردن Activity Diagram است. و از طرف ديگر state ها مي توانند براي رجوع كردن به تعريف business rule ها خيلي مفيد باشند.

(قسمت بعدي:Requirements)

[Elham_gh]

قسمت چهارم

خلاصه Business modelingشكل زير انواع دياگرامهايي را نشان مي دهد كه من براي مدلسازي business و وابسته هاش ازشون استفاده مي كنم


http://barnamenevis.org/forum/attachment.php?attachmentid=20968&stc=1&d=1218141876
(شكل 7)
• Class diagram هميشه وجود دارد ، به همين جهت با رنگ ديگري مشخص شده است.
• Activity Diagram زماني استفاده مي شود كه application از workflow خاصي پشتيباني كند. از اين دياگرامها مي توانيد به كلاس مشخصي (Business Entity) در class diagram تان برسيد
• دياگرامهاي state machine براي مدلسازي چرخه حيات business entity ها استفاده مي شوند.بالطبع به class diagram ها وابسته اند.transition ها به وسيله action هاي business worker ها رها مي شوند(trigger)، پس وابسته به activity diagram ها هستند.


Requirement

در Requirement Discipline ، براي بيرون كشيدن نيازمنديهاي application كه بايد از business پشتيباني كند، از Business model استفاده مي شود.تا آنجا كه براي UML اهميت دارد اين است كه بايد Use case model بسازيم.اين مدل به هر دو مدل business وابسته است.شكل زير نشون مي ده كه RUP براي اين مرحله چي ميگه.


http://barnamenevis.org/forum/attachment.php?attachmentid=20969&stc=1&d=1218141876
(شكل8)
Use Case Model
اين مدل براي تمام پروژه هاي RUP توصيه مي شود. اساسا اين مدل بر اساس تكرار 3 فعاليت شكل مي گيرد:
1.اول actor ها توصيف مي شوند- كساني كه واقعا با سيستم كار مي كنند و يا به اصطلاح user role ها.
2.سپس use case ها خودشان شناسايي مي شوند.اينكه actor ها چه چيزي مي خواهند با استفاده از سيستم به دست آورند(شكل 9)


http://barnamenevis.org/forum/attachment.php?attachmentid=20970&stc=1&d=1218141876
(شكل 9)


3. بلاخره براي هر use case ارتباط actor مربوطه و سيستم تعيين مي شود. و يا به اصطلاح سناريو نويسي مي شود. اين سناريو يك مشخصه متني است كه مي تواند به صورت activity diagram هم مدل شود.

ACTORS
Actor ها اغلب در business analysis model به عنوان business worker از پيش شناسايي شدند. آنها كساني هستند كه سيستم براي انجام كارهايش به انها نياز دارد.
Actor ها در شكل 9 همان business worker هايي بودند كه در domain model تعيين كرده بودم. به خاطر مي آريد؟ يك actor مي تواند با يك business actor هم مرتبط باشد. در اين وضعيت business actor مي تواند مستقيما به سيستم دسترسي داشته باشد(براي نمونه از طريق internet)

Use Case Identification
مطابق RUP ، Use case ها مي توانند business use case ها استنتاج شوند، اما اين زماني درست است كه actor هاي شناسايي شده از business actor ها استنتاج شده باشند.در مورد مثال ما ، actor هايما از business worker استنتاج شده اند كه يك حالت عمومي تري است، در اين حالت use case ها بايد با نگاه كردن به action هي تعريف شده براي business worker ها شناسايي شوند.اين بدين معني نيست كه يك تناظر يك به يك وجود دارد(شكل9 را با activity diagram در business analysis model مقايسه كنيد)
من توصيه مي كنم كه ارتباط بين use case ها و work flow ي تعريف شده در business model را مستند كنيد.

(قسمت بعدي:Use case specification)

[shayesteh_bh]

با تشكر از شما ولي اگر اشتباه نكنم قسمتهاي 5 و 6 در اينجا نيامده. بعدا مي گيد؟

[Elham_gh]

(قسمت پنجم)


Use case specification

اكثر RUP كارها ، مشخصه هايuse case را تنها به صورت يك متن ساخت يافته مي نويسند.كه مي تونه خيلي خوب كار كنه . هم يه كم مصيبت بار باشه!! هر چند وقت يكبار قدمهاي flow تون را دوباره شماره گذاري مي كنيد؟ هر چند وقت alternative flow هاتون شبيه يك دسته مار پيچ در پيچ به نظر ميان؟ اونهايي كه به سوالات من لبخند مي زنند، بدونند كه مي تونن از امكان استفاده كردن از activity diagram ها براي مشخص كردن تمام مسيرهاي Alternative در يك تصوير ساده ، سود ببرند. Tester ها هم وقتي آناليز مسيرهاي تست را انجام مي دهند مي تونن از اين تصاوير لذت ببرند!! شكل 10 داخل يك use case ي به نام examine issue را نشان مي دهد.


http://barnamenevis.org/forum/attachment.php?attachmentid=21040&stc=1&d=1218320383
(شكل 10)بدين صورت كه helpdesk member يك موضوع را به تريب از صف موضوعات كه وضعيتش to be examined است مي گيرد، يا به موضوع سريعا جواب مي دهد و يا به تيم مرتبطش براي آناليز و بررسي بيشتر منتقل مي كند.اميدوارم بدون توضيحات بيشتر بتوانيد flow را تفسير كنيد. اما در عمل وقتي دياگرامها كامل مي شوند ، من تكه هاي متني را هم به دياگرام اضافه مي كنم كه كمك بيشتري به خواننده بشود. حتي مهمتر مشخصه هر action است.هرaction در دياگرام بايد با يك متن يك يا چند خطي و يا با دياگرامهاي جداگانه مشخص و تصريح شود. متاسفانه لان جايي براي اين موضوع نيست و از اون مي گذرم!
همانطور كه مي بينيد use case با يك included use case شروع شده. علامت شن كش در گوشه پايين نشون دهنده اين است كه يك activity diagram جداگانه براي اين action وجود دارد.آيا به reference هاي به state machine ام در business model توجه كرديد؟

خلاصه Requirement

دياگرامهاي UML زير مي توانند در Use case model استفاده شوند:
Package diagram
Use case diagram
Activity diagram



http://barnamenevis.org/forum/attachment.php?attachmentid=21041&stc=1&d=1218320383
(شكل11)و حتما مي دونيد چرا use case diagram را با رنگ ديگه اي مشخص كردم!
نكته خيلي مهم اينكه ؛ به خاطر داشته باشيد كه دربه كارگيري RUP ، در مورد انجام انتخابها و اتخاذ تصميمهاي درست، تمام بر پايه خصوصيات يك پروژه و اختصاصي آن پروژه است

[Elham_gh]

(قسمت ششم)

Analysis & Design

در اين discipline ، 5 مدل به مجموعه مدلهاي discipline هاي قبلي اضافه مي شود.
Navigation Map, Analysis Model, Design Model, Data Model, Deployment Model
مدلهاي قبلي هم بينش لازم را به ما مي دهند ، اما اين 5 مدل تازه وارد، مدلهايي براي نرم افزار واقعي هستند براي اينكه بتواند ساخته شود.

http://barnamenevis.org/forum/attachment.php?attachmentid=21309&stc=1&d=1218841616
Navigation Map

RUP نتيجه navigation map را Activity Design the User Interface تعريف مي كند. اين map (طرح) بر پايه use case هاست و مهمترين مسيرهاي navigation را نشان مي دهد.
مسير navigation چي هست؟ يك سري متوالي صفحه است (چه تحت ويندوز ، چه تحت وب) كه توسط كاربر پيمايش مي شود.
اين map (طرح) چه شكلي بايد باشد؟ در RUP هيچ قانون و قاعده اي براش مشخص نشده.و UML هم در اين مورد كاربردي و قابل استفاده نيست!
البته من با اين نظر اصلا موافق نيستم! دياگرامهاي state machine در UML خيلي خوب مطابق Navigation map ها هستند. Active Screen به عنوان state ي از يك واسط كاربري در نظر گرفته مي شوند و برداردهاي transition هم، مسيرهاي Navigation را نشان ميدهد.در شكل زير من يك تصوير ناقصي از يك state machine دارم. اين نمودار فاقد trigger هايي است كه باعث transition ها مي شوند و action هايي كه توسط سيستم انجام مي شوند و همينطو فاقد exception هاست.


http://barnamenevis.org/forum/attachment.php?attachmentid=21310&stc=1&d=1218841616(َشكل 13)

بعضي از مردم دوست دارند با تمام قدرت UML ، جزئيات navigation را مدل كننئ. اگر من فقط بخواهم براي 2 صفحه اينكارو انجام دهم ، مثل شكل 14 مي شود. و بهتون قول مي دم اگر بخواهيد اين كار را براي تمام application انجام بديد، state machine بسيار پيچيده اي خواهيد داشت. من معمولا خيلي رسمي و صوري( formal )مدلسازي مي كنم و جزئياتش رو بدون استفاده از UML به صورت يادداشت ، صفحه به صفحه مشخص مي كنم.


http://barnamenevis.org/forum/attachment.php?attachmentid=21311&stc=1&d=1218841616
(شكل 14)
اينها براي پياده سازي و تست خيلي مهم هستند.ولي هيچ artifactي در RUP براي اين مورد وجود ندارد. RUP حتي به Navigation map به عنوان ورودي هيچ فعاليت طراحي و پياده سازي و تستي اهميت نمي دهد و اين جاي تاسف دارد.
Navigation map در RUP اختياري است.اگر شما يك prototype كامل تهيه كرديد، مي توانيد از آن صرفنظر كنيد.
براي سيستم هاي بزرگ، اين map مي تواند خيلي پيچيده باشد.مطابق RUP شما بايد همهچيز را در يك دياگرام قرار دهيد. اما من حداقل يك navigation map براي هر use case package ام مي سازم
(قسمت بعدي:Analysis Model)

[Elham_gh]

(قسمت هفتم)
Analysis Model:

Analysis model و Design model با يكديگر جزييات سيستمي را كه با use case محقق شده بود ، تصوير مي كنند.analysis model اين كار را در درجه بالاتري از abstraction (انتزاع) ، نسبت به design model انجام مي دهد.در analysis model ،analysis object ها همجنان طبيعت منطقي دارند، در حاليكه element ها در design model مستقيما براي كدهاي برنامه نويسي قابل تشخيصند.
RUP به شما اين اجازه رو مي ده كه بعد از use case ها مستقيما بريد سراغ design model.اما اگر در پروژه شما اين گام خيلي بزرگ باشه ، مي تونيد اول بريد سر وقت analysis model و با آن آماده سازي انجام بدين.اين تصميم بايد پروژه به پروژه گرفته شود .
هردو مدل analysis و design ، براي مشخص كردن ساختارهاي استاتيك ،داراي نمودارهاي class هستند و از نمودارهاي interaction راي تحقق بخشيدن به use case ها استفاده مي كنند.
اين روزها ، من ديگه analysis model رو نمي سازم.مدل business analysis و مدل use case من با همديگر به اندازه كافي اطلاعات دارند كه بشه ائلين پيش نويس معماري component ها رو در design model در اورود و شروع به ساخت use case realization كرد(كه اصطلاحا مي گويند component ها را interacting كرد)
مشكل اصلي با مدل analysis در RUP كلاسيك اينه كه Component base نيست.بلكه شامل يك عالمه analysis class هايي است كه مستقيما به يكديگر پيغام مي فرستند ، بدون اينكه به سراغ واسط component ها برود(منظور component interface است)
به عقيده من ، شما بايد مقدمتا معماري component ها و interaction هايشان را طراحي كنيد و در اين سطح component ها به صورت black box در نظر گرفته مي شوند و در سطح پايين تر ، بايد كلاسهاي داخلي هر component و تحقق operation هاي هر component را نيز طراحي كنيد.
مشكل دوم اين است كه analysis object ها منطقي هستند و ممكن است خيلي راحت به design object ها معادل (map) نشوند.( با وجودي كه مستندات RUP ميگه design object ها فقط جزييات بيشتري نسبت به analysis object هاي معدلشون دارند)
در هر صورت توصيه من اينه كه : تمام business entity ها و business process مربوطه را در مدل business analysis تان قرار دهيد و ديگه اونوقت احتياج به analysis model نداريد.

Design Model:
يكي از 6 بهترين الگوهاي RUP (RUP best practice) استفاده از معماري component هاست. من حتي بيش از RUP به ساختن Design model در 2 سطح تاكيد مي كنم:
1- سطح معماري- كه component ها به صورت black box در نظر گرفته مي شوند.
2- سطح جزييات- جايي كه داخل component ها نيز طراحي مي شوند.
در ه دو سطح ، ساختار استاتيك ، پايه و اساس هر رفتار دايناميكي است كه مدل مي شود.


Design Model-Architecture level:

ساختار استاتيك سطوح معماري با 2 دياگرام ارائه مي شود:
Package Diagram- كه ديدگاه و رويكرد لايه اي دارد.(شكل 14)
Component Diagram-كه نشان مي دهد كدام component ها ، كدام interface مربوط به component هاي ديگر را استفاده مي كنند.(شكل 15)


http://barnamenevis.org/forum/attachment.php?attachmentid=21708&stc=1&d=1219532033
(شكل 14)


http://barnamenevis.org/forum/attachment.php?attachmentid=21709&stc=1&d=1219532033
(شكل 15)


قسمت دايناميك معماري ، مشتمل بر use case realization هاست(UCR).
معمولا كافي است كه براي هر use case يك نمودار interaction داشته باشيم.(خوب ممكن است جندين use case باشند كه مسيرهاي interaction شان بسيار شبيه هم باشد. در اينصورت من فقط براي يكي از اونها خودم رو به زحمت مي اندازم و تعين مي كنم كه بقيه مشابه هستند). نمودارهاي interaction در سطح component ها مي مانند. شكل 16 نمونه اي از آن است


http://barnamenevis.org/forum/attachment.php?attachmentid=21710&stc=1&d=1219532033
(شكل 16)

يك معماري component ي كه خوب طراحي شده باشد و مجموعه component interface هاي تمام application ها تعيين كننده و حياتي هستند. محتويات داخلي component ها به مراتب از اهميت كمتري برخوردارند.
من به يكي از جنبه هاي معماري كه اون هم مورد نياز است اشاره نكردم . عملگرهاي(operation) يك component ممكن است پارامترهايي دشته باشند كه يك نمونه (instance) از كلاسهاي non-primitive باشند. 2 نمونه از اين كلاسها در شكل زير مشخص شدند:Issue و IssueList
براي تهيه كردن مشخصات كاملي از interface هاي component، من آنها را در class diagram رسم كردم.


http://barnamenevis.org/forum/attachment.php?attachmentid=21711&stc=1&d=1219532242
(شكل17)


(قسمت بعدي-Design Model: Component Detail level)

[Elham_gh]

(قسمت آخر)


Design Model: Component Detail level:
در سطح جزييات component، من براي تك تك Component ها ، از جايي كه interface ها و ازتباطات با ديگر Component ها در سطح معماري تعريف شده ، مدل مي سازم.
قسمت استاتيك شامل class diagram است. كه شامل كلاسهايي است كه براي پياده سازي component ها برتامه نويسي مي شوند.
قسمت دايناميك ، مجموعه اي از component operation realization مي باشد.براي هر عملگر(operation) ،با پياده سازي نه خيلي جزئي (non-trivial)، يك interaction diagram ايجاد مي شود.(بسته به پروژه ميزان و مفهوم non-trivial تعريف مي شود)



http://barnamenevis.org/forum/attachment.php?attachmentid=22280&stc=1&d=1220642703
(شكل 18)


Component هاي واسط كاربري(user interface ) توسط عملگرها (operation) فراخواني (trigger) نمي شوند، بلكه با event هايي كه توسط كاربر فراخواني مي شود ، اجرا ي شوند مثل كليدي كه فشار داده مي شود يك event است كه توسط كاربر فرخواني مي شود.براي اين component ها ، interaction diagram ، واكنش سيستم را به اين نوع event ها نمايش مي دهد..
شكل زير خلاصه دياگرامهاي ارزشمند design model را نشان مي دهد.



http://barnamenevis.org/forum/attachment.php?attachmentid=22281&stc=1&d=1220642703
(شكل 19)
Data Model:

Data model مدل database است كه جداول ، فيلدها ، ارتباطلات Foreign key و اغلب stored procedure ها و trigger ها را نيز مشخص مي كند. همه اين عناصر در class diagram تعريف مي شوند اما با يك stereotype خاص مثل <<Table>> يا <<Column>>. اگر از چند database استفاده مي كنيد، هر database بايد به صورت يك component در design model ،مدل شود.
گاهي data model به package هايي تقسيم مي شود كه هر كدام مي توانند نشان دهنده يك schema باشند.package diagram ، Dependency ها را نمايش مي دهد.

Deployment Model:
اين مدل نيازهاي سخت افزاري و ارتباطلات شبكه اي را مشخص مي كند. داخل آن framework ، شما component هاي نرم افزاري را به ماشينهايي كه بايد روي آنها نصب شوند ، اختصاص مي دهيد.

Implementation Model:
اين مدل فقط وقتي لازم است كه ساختار physical source code با ساختار package و component هاي design model متفاوت باشد. در اين حالت ، implementation model ساختار source code و ترتيب كامپايل شدن رو توصيف مي كند. براي اينكه اين مدل رو بصري (visualize) كنيد ، مي توانيد از Package diagram استفاده كنيد. ارتباطلات بين package ها و package ها يا component ها در design model بايد واضح و شفاف باشد يا با استفاده از قراردادهاي اسم گذاري خاص و يا با explicit mapping .

Software Architecture Document:
اين مستند مرور و بررسي جامعي بر معماري سيستم است كه ديدگاههاي متفاوت بر جنبه هاي مختلف معماري را شامل مي شود.اين مستند شامل مدلهاي مختلفي است به جز مدلهاي business ي.متاسفانه مجموعه ديدگاههاي معماري دقيقا منطبق با مجموعه مدلها نيستند .اما براي منطبق كردنشان از موارد زير پيروي كنيد:
• Use case view زير مجموعه use case model است و در بردارنده تمام use case هايي است كه براي تصميم كيريهاي معماري حائز اهميتند.
• Logical view و proves view با يكديگر سطح معماري design model را تشكيل مي دهند.
• Deployment view معادل deployment model است و يا جرييات كمتري نسبت به مدلش دارد.
• Implementation view معادل implementation model است و يا جزئيات كمتري نسبت به مدلش دارد.

در استفاده از UML در RUP موفق باشيد!!
مسندات RUP خيلي پراكنده و تكه تكه اند. در اين مقاله من سعي كردم ، اين پراكندگي ها رو يك جا جمع كنم با تجربيات تلفيق كنم.
به شما كمكي كرد؟
شما و تيمتان بايد با هم جمع شويد و روش خودتان را پيدا كنيد.به خاطر داشته باشد كه RUP هميشه خيلي بزرگ است. فقط مدلهايي رو بسازيد كه براي شما ارزشي داشته باشند. منتظر شنيدن نقطه نظرات شما هستم



Hans Admiraal,
IT architect at Ordina, an IT company based in The Netherlands.
hans.admiraal@ordina.nl

[golihaghighi]

دوست عزیز عالی بود ولی ای کاش PDF می کردی با این حال واقعا قابل استفاده بود . مرسی از وقتی که گذاشتی.
دوست عزيز مقالتون بسيار عالي و كاربردي بود.
من هم خواهش ميكنم اگه امكان داره PDF اونو بزاريد.

[Future]

سلام
خيلي خيلي خيلي عالي بود. واقعا ممنون. من تازه كارم ولي خب خيلي چيزها نصيبم شد. اميدوارم اگه موضوعاتي هم در مورد UML در نظر داريد حتي مثالهاي ساده اينجا مطرح كنيد تا ما مبتدي ها از شما اساتيد استفاده كنيم

[Elham_gh]

راستش pdf ش كردم .اما هيچجوري حجمش كم نمي شه كه بشه اينجا گذاشت.
فكر كنم تنها راه حلش ايمل براي دوستاني است كه مي خوان.

[Elham_gh]

اين هم آدرس فايل pdf مقاله كه upload ش كردم.
http://rapidshare.com/files/192877795/Pitfalls_using_UML_in_RUP.rar.html

[en_c_778]

مرسی از مطالب مفیدی که گذاشتین

[fmostafa]

اين هم آدرس فايل pdf مقاله كه upload ش كردم.
http://rapidshare.com/files/192877795/Pitfalls_using_UML_in_RUP.rar.html
دوست عزیز
بسیار ممنونم از لطفتون واقعا مقاله خوبی بود ، اگر برای شما امکان داره فایل PDF این مقاله رو برام ایمیل کنید .

[pmkm1377]

ممنون
میشه تو 4shared لودش کنی که بشه راحت تر برشداشت

[morowatali]

سلام
ممنون از مقالتون و زحمتی که برای اون کشیده بودید

[tavrij]

با سلام
لینک فایلتون مشکل داره، متاسفانه!

[mpr134]

اين هم آدرس فايل pdf مقاله كه upload ش كردم.
http://rapidshare.com/files/192877795/Pitfalls_using_UML_in_RUP.rar.html

-------------------
باسلام و تشکر فراوان از مقاله بسیار مفیدتون واقعا قدر دانم . ازتون خواهش دارم که لینک مقاله رو اصلاح کنید تا بتونیم این مقاله ارزشمند رو دانلود کنیم با تشکر .