# مهندسی نرم افزار > مباحث مرتبط با مهندسی نرم‌افزار > تحلیل و طراحی نرم افزار > مقاله: تله هاي استفاده از UML در RUP

## Elham_gh

*Pitfalls using UML in RUP*
_Hans Admiraal_*پيش مقاله! :*

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

*(قسمت اول)*

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

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

شكل 1شكل 1 ، تصويري نيست كه شما در محصول رسمي RUP پيدا كنيد.([_I]Elham_gh:_ اين تصوير بسيار بسيار كاربردي و گره گشاست. حتما ازش استفاده كنيد)[/I] . شبكه پهناور صفحات وبي ديد  و مرور روشني از ارتباط بين مدلهاي مختلف 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_:فرايندهايي كه در گردش كار سيستمي كه مي خواهيم پياده اش كنيم وجود دارند_)دارند كه بايد آنها را درنظر بگيريم و پياده سازي كنيم ، اين مرحله انجام مي شود.


(شكل 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  ارائه مي دهد.

(شكل 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  لازم دارد كه پشتيبانيش كند ، نمايش مي دهد.

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


(شكل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" تغيير مي كند.


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

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

----------


## Elham_gh

*قسمت چهارم*

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


(شكل 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 براي اين مرحله چي ميگه.


(شكل8)Use Case Model
  اين مدل براي تمام پروژه هاي RUP توصيه مي شود. اساسا اين مدل بر اساس تكرار 3 فعاليت شكل مي گيرد:
1.اول actor ها توصيف مي شوند- كساني كه واقعا با سيستم كار مي كنند و يا به اصطلاح user role ها.
2.سپس use case ها خودشان شناسايي مي شوند.اينكه actor ها چه چيزي مي خواهند با استفاده از سيستم به دست آورند(شكل 9)



(شكل 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 را نشان مي دهد. 


(شكل 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



(شكل11)و حتما مي دونيد چرا use case diagram را با رنگ ديگه اي مشخص كردم!
نكته خيلي مهم اينكه ؛ به خاطر داشته باشيد كه دربه كارگيري RUP ،  در مورد انجام انتخابها و اتخاذ تصميمهاي درست، تمام بر پايه خصوصيات يك پروژه و اختصاصي آن پروژه است

----------


## Elham_gh

(قسمت ششم)

Analysis & Design

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

(َشكل 13)

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


(شكل 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)


(شكل 14)



(شكل 15)

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


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


(شكل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 تعريف مي شود)



(شكل 18)

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



(شكل 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/19287779...n_RUP.rar.html

----------


## en_c_778

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

----------


## fmostafa

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


 دوست عزیز 
بسیار ممنونم از لطفتون واقعا مقاله خوبی بود ، اگر برای شما امکان داره فایل PDF این مقاله رو برام ایمیل کنید .

----------


## pmkm1377

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

----------


## morowatali

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

----------


## tavrij

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

----------


## mpr134

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


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

----------

