مقدمه ای بر RUP

[h_rezaei]

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

• ثبت و جمع آوری
• نگهداری
• بازیافت
• قابلیت گردش و انتقال
• قابل پردازش و نتیجه گیری
• و در نهایت در تصمیم ساز و مؤ ثر در بهبود وضعیت

همه این موارد فرایند های اطلاعاتی نامیده می شوند.آنچه که در مورد این فرایندهای اطلاعاتی مهم است این است که:

• وضعیت آنها اکنون جگونه است(وجود،کیفیت،موارد وابسته و نابسته آنها)
• وضعیت مناسب و حالت بهینه آنها با توجه به خواسته های محیط درونی و بیرونی چیست؟
• چه راهکارهای مناسبی برای رسیدن به شرایط مطلوب وجود دارد؟
• اگر راه حل انتخابی یک سیستم نرم افزاری است این سیستم چه ویژگی ها یی باید داشته باشد؟
• سیستم نرم افزاری چگونه باید جایگزین بخش یا کل سیستم جاری شود؟
• و در همه این مراحل سیستم جدید چگونه نگهداری و بهبود وتوسعه می یابد؟

برای رسیدن به این اهداف شاخه های مختلف علوم و تخصصهای مهندسی و غیرمهندسی با روشها(متدولوژی)های مختلف بکار رفته و می روند.پیش از پرداختن به این روشها و تخصصها و مشخص شدن مفاهیم زیر به نظر ضروری می رسد

1. Visionچشم اندازها ی کاری یا اهداف عمده سازمان یا تیم کاری
2. Process مجموعه ای از فعالیت های هدفمند که عمومآ در یک تیم کاری به صورت مقطعی یا دوره ای انجام می شوند(این فعالیت ها ممکن است دسته بندی و سطح بندی شوند.
3. Project مجموعه ای از فعالیت های هدفمند که عموماً در یک تیم کاری به صورت مقطعی انجاممی شوند(این فعالیت ها ممکن است دسته بندی وسطح بندی شوند)
4. Business شغل/ نوع کار عمده ای که در یک سازمان یا تیم کاری انجام می شود
5. role نقش های افراد یا گروهی از افراد در یک سازمان یا تیم
6. Person افرادی که در یک سازمان یا تیم فعالیت می کنند
7. Mission فرایند های عمده ای که عموماً برای رسیدن به اهداف یک سازمان در نظر گرفته می شود
8. Activity فعالیت هایی که در یک پروژه، پروسه انجام می شود
9. Work flow روال انجام فعالیت های یک پروسه وروال انجام پروسه های یک ماموریت(تقدم،وابستگی،چینش)
10. مهندسی صنایع : چیدمان فرایند ها برای رسیدن به اهداف، کنترل فرایندها (پروژه ها) و منابع و زمانبندی مربوط به آنها
11. مهندسی نرم افزار :در حوزه منابع وسیستم های اطلاعاتی(شناخت وضعیت جاری،نیازهای جاری،پیشنهاد وضعیت(سیستم یا روش مناسب،طراحی و پیاده سازی سیستم مناسب،ارایه روش نگهداری و بهبود سیستم) از وظایف مهندسی نرم افزار می باشد
12. مهندسی مجدد :چینش مجدد فرایندهای کاری،گردش های اطلاعاتی در یک سازمان(ممکن است در راستای شناخت وضعیت،نیاز سنجی،آنالیز،طراحی سیستم جدید)از وظایف مهندسی مجدد است
13. Document Flow :جریان گردش اسناد(بر اساس آیین نامه،اساس نامه وقوانین و...)موجود در یک سازمان یا پروژه

.........ادامه دارد

[h_rezaei]

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

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


حرفه ها وتخصص ها
به منظور بررسی(شناخت،آنالیز، نیاز سنجی،طراحی، پیاده سازی و...)فرایندهای یک سازمان یا یک تیم کاری حرفه ها و تخصص های مختلفی بکار میروند که در بکار گیری آنها عوامل زیر مؤثر می باشد:
ـ تنوع حوزه کاری سازمان یا تیم کاری
هر چه حوزه فعالیت های مورد بررسی وسیعتر باشد ونوع کارها متفاوت تر باشد تخصص های بررسی کننده نیاز بایستی متنوع تر باشند.از طرفیتخصص ها و دانشهایی که در مورد کلیت فعالیت ها و پروسه ها اظهار نظر می نماید نیز وابسته به تنوع حوزه فعالیت پروسه های مورد مطالعه می باشند.از نظر تعداد اعضا شرکت کننده در تیم امکان سنجی،نیاز سنجی،طراحی،پیاده سازی نیز بستگی به تنوع حوزه کاری مورد مطالعه دارد.
ـمیزان شناخت و متعاقب آن تغییرات مورد انتظار در سیستم
سازمان ها و تیم های کاری با اهداف مختلفی به مطالعه وامکان سنجی پروسه های خود می پردازند عمده این اهداف عبارتند از:
*شناخت ساختار و مدل ایستای سازمان یا تیم کاری مو جود یا در حال شکل گیری.
*شناخت(ایجاد شناسنامه) پروسه های موجود/در حال شکل گیری/امکان کشف در سازمان یا تیم کاری.
*شناخت روشها و متد های مدیریت پروژه بهینه.
*شناخت مستندات جاری یا در حال شکل گیری سازمان یا تیم کاری ودر نهایت بززسی گردش اسناد.
*شناخت گردش کار پروسه های موجود(DFD)
*شناخت موجودیت های سیستم و رسیدن به ERD متناسب با ساختار سیستم.
*شناخت مدل کامل سیستم که بیانگر وضعیت جاری/مناسب/مورد نظر باشد.
*زسیدن به مدلی که در طراحی سیستم کارا/قابل اطمینان/معقول و مقرون/ راحت و متناسب(اصول مهندسی نرم افزار) مؤثر باشد.
*رسیدن به مدلی که در پیاده سازی سیستم کارا/ قابل اطمینان/معقول و مقرون/ راحت و متناسب(اصول مهندسی نرم افزار) مؤثر باشد.
و اهداف دیگر...................
با توجه به اهداف نوع تخصص و سطح خروجی تخصص که همان پیشنهاد های مؤثر برای ابقا/ تغییر/ایجاد سیستم جایگزین برای سیستم جاری می باشد، مشخص می گردد.می توان گفت خروجی تخصص می تواند یکی از موارد زیر باشد:
_ مستندات واقعی/ استاندارد/ بهینه سیستم موجود یا در حال شکل گیری
_ ابزار های کمکی مؤثر در بهبود/ ایجاد سیستم موجود یا در حال شکل گیری
_ سیستم کاملاً جدید که در حوزه موضوع مورد نظر ایفای نقش خواهد کرد
_ پیشنهادات دستورالعملی ، سازمانی،آیین نامه ای و... برای سیستم موجود یا در حال شکل گیری

در انتخاب نوع خروجی باید موارد پیشنهادی را بر اساس( شاخص گذاری/ در نظر داشتن)موارد زیر ارائه کرد:
_ فرهنگ کاری و مسائل محیطی
_ میزان هزینه و منابع مورد نیاز دیگر مانند زمان
_ میزان انعطاف پذیری و علاقه مندی به تغییر
و...............

- سطح فن آوری و تکنیکی بکار رفته در شناخت و تغییر
در فاز امکان سنجی و کشف نیازمند یها وآنالیز:
OOPیا SSADM ؟
در فازطراحی سیستم جدید:
Tier3 یا؟
در فاز پیاده سازی و گذار به سیستم جدید:
Desktop یا Client/Server یا Web Base یا توزیعی؟چند کاره ؟ در چه محدوده هایی؟ با چه امنیتو سطح دسترسی؟

متد ولوژی ها :
به منظور مقایسه روشهای مختتلف تحلیل و بررسی سیستم مراحل کاری، تفاوتهای عمده و تشابهات دو متد ولوژی RUP,SSADM را بررسی می نماییم.

فاز ها یا مراحل کاری:




تفاوتها:
مشخصات تئوریRUP نسبت به SSADM متفاوت است:
1- دیدگاه دو بعدی نسبت به تقسیم بندی و پیشبرد مراحل تحلیل.
2- مبنا قرار گرفتن موجودیت(شئ) به جای روال ها و پروسه های کاری.
3- استناد بیشتر فاز طراحی به فازهای اولیه در RUP.
4- نزدیکی کامل مستند سازی سیستم به کلیه فازهای تحلیل.
5- همکامی بیشتر با تکنیکهاو مفاهیم پیاده سازی جدید.
6- کاربری بیشتر در تحلیل سیستمهایی که منجر به ایجاد یک سیستم نرمافزاری نمی شود.
تشابهات:
1- مشخص شدن ساختار(ایستا)سیستم
2- مشخص شدن رفتار (پویا)سیستم
3- مشخص شدن عوامل/ اطلاعات(موجودیتهای اطلاعاتی)در جریان گردش کار سیستم

[JavanSoft]

جالب بود ممنون

[h_rezaei]

تشریح فازهای مختلف در تئوری RUP:
بر اساس تئوری RUPدر هر یک از مراحل 6گانه اصلی یک سری مفاهیم قوانین و دستورالعمل های پایه ای وجود دارند.
مفاهیم:
Activity:
فعالیت هایی که اریوپی برای درست انجام شدن هر مرحله پیشنهاد می کند.
Artifcat:
هر سند،محصول و ... که در هر مرحله از انجام کار تولید می شود.
Worker:
افرادی که در هر مرحله فعالیت میکنندو یک سری سند با محصول محسوس تولید می کنند.
Guide Line:
راهبرد انجام کار که نحوه انجام و ممیزی هر کاری را مشخص می کند.برای خیلی ازARTIFACTها به خصوص در مرحله تحلیل و طراحیGUIDLINE وجود دارد.
Checkpoint:
سندی است که جهت ارزیابی هرARTIFACT بکار می رود.
TOOLMENTOR:
سندی است که نحوه انجام هر را با ابزار مشخصی توضیح می دهد(فعالیت های که ابزار مکانیزه دارند).
Business Modeling:
این فرایند ممکن است با اهداف زیر صورت گیرد:
1- استخراج ماژول ها و سازماندهی کاری(چارت سازمانی)
2- Domain Modelingشناخت دامنه کاری سازمان
3- One Business many System
شناخت اجزا سازمان(واحد ها، پروسه ها. پروژه ها، شغل ها، نقش ها ، جریانهای گردش کار،جریانهای گردش اسناد و...) جهت مکانیزه نمودن سیستم با طراحی سیستم های کامپیوتر و غیر کامپیوتری مختلف.
4-Business Generation
وقتی هدف تولید بسته های نرم افزاری چند کاربره برای سازمانهای مختلف می باشند.
5-New Business
سازمان می خواهد از فن آوری جدید، شغل جدید و هر چیز تازه ای که به سیستم و روال کاری جاری اضافه شود،استفاده کند.
6-Reorganization
هنگامی که یک سازمان بخواهد در جهت شناخت مشکلات سیستم جاری/ ایجاد تحول در سیستم جاری/ آزمایش سیستم جدید فعالیت نماید
در این بخش وضعیت سیستم از دیدگاه درون سیستم(Business Use case Modeling) و بیرون از سیستم Business Object Modeling)) مورد بررسی قرار می گیرد و مؤ لفه های آن بر اساس تئوری RUP به شرح زیر است:
شکل زیر ارتباط بین دو مدل را در این فاز نشان می دهد.

[faramarz_s]

من یک چیز را درست متوجه نمی شوم و آن تفاوتهای و مزایای RUP و UML است.
اگر ممکنه توضیحی بفرمایید :flower:

[h_rezaei]

RUP یک متدولژی هست وUML زبان مدلسازی. و قیاس این دو مع الفارق است .
میشه متدولژی RUP رو با سایر متدولژی ها مثل SSADM یا XP مقایسه کرد گرچه معمولا در مباحث مهندسی نرم افزار (SE) هم بحث uml هست هم rup .ولی این دو کاملا مستقل هستند یعنی شما برای رسم دیاگرامهای UML احتیاجی نیست حتما از متدولژی RUP استفاده کنید .فقط کافیست متدولژی و طراحی شما باید OO (شی گرا ) باشد.
شاید هم این خلط به خاطر این باشه که تو ایران از ابزارهای رشنال فقط rose جا افتاده در حالی که ابزارهای مختلفی برای BM , requirement management , analyse ,... توی پک کامل Rational Suite هست .
به طور خلاصه میشه گفت که RUP مجموعه روشها و دیدگاههای شناختی لازم برای شناخت ، نیاز سنجی ، تحلیل ، طراحی ، پیاده سازی و تست و نصب یه محصول نرم افزاری رو ارائه میده . ولی UML (متشکل از تعدادی دیاگرام) مربوط به زمانی هست که Business شنا خته شده و حال برای مدلسازی view ما از سیستم متوسل به این دیاکرامها می شویم .
در واقع برای هرکدام از فازهای RUP دو یا سه دیاگرام UML می تواند کار ساز باشد .(بیشتر از همه طراحی ) اما فقط برای ترسیم یک مدل به آنچه از سیستم رسیده ایم :idea: یعنی UML چگونگی رسیدن به این شناختها و تشخیص ها را قرار نیست مشخص کند ولی RUP سعی در ارائه چنین ساز و کاری دارد . البته برای مدلینگ آنچه RUP در هر فاز ارایه میدهد نیز بهترین استاندارد مدلسازی شاید UML باشد.

[h_rezaei]

Workers
Business Process Analyst
Business Designer
Stakeholder
Business Reviewer

Activities
Access Business Status
Descript Current Business
Identify Business Process
Refine Business Process Definition
Define Business Process Realization
Refine roles and responsibilities
Explore process automation
Develop a domain modeling

Artifacts
Support Specification
Business glossary
Business rules
Business use case model
Business object model
Target organization assessment
Business vision
Business architecture document
Supplement business specification
Business use case
Business use case realization
Organization Unit
Business Entity
Business worker
Business modeling guidelines
Review record
Analyse model

Business Use Case Modeling
پس از انجام فعالیت های لازم و تولید محصولات مشخص فرایند هایکلاسیک زیر صورت می گیرد:
Actor Detecting
Business Actor
هر واحد/ شخص عمدهای که Business Modeling برای او انجام می شود.
Business Worker
ماشین‏‏‏‏‏‏،سیستم،سروی سی که در حال حاضر در خدمت سیستم می باشد.
-مشخصات ضروری Actor:
1- نام
2- شرح مختصر
3- سلسله مراتب مربوط به Actor
-روابطی که برایActor مجاز است:
Generalization
با سایر Actorها
Association
باUse caseهای سیستم

Use case Derivation:
Use case
انتظاری است که از واحد/ سازمان/تیم یا هر مجموعه کاری مورد مطالعه وجود دارد.
Unit/Package
مجموعه ای از Use case هایی که در راستای یک هدف پیش می روند.این مجموعه ممکن است با یک سریBusiness Actor یاBusiness Entity در ارتباط باشند.

مشخصاتUse case که مورد نیاز است:
1- نام
2- شرح مختصر عملکرد
3- شرح مراحل تحققUse case
4- شرایط سیستم برای شروع/بکار گیری (Pre Condition)Use case
5- شرایط سیستم بعد از بکار گیری(Post Condition)Use case
6-خواص و شرایط خاص که در هنگام تحقق Use caseمطرح می شود.

Use case Realization:
: راتباط بین Use case ها
Realization
رابطه ای که نشان می دهد تحقق و عینیت یک Use case چگونه اتفاق می اقتد.
در این حالت یک رابطه Realization از طرف Use case تحقق دهنده به Use caseتحقق یافته ترسیم می گردد.
Include
هر گاه در راستای انجام یکUse case بکار گیری یا فراخوانی یک Use case حتمی باشد،این دو Use caseارتباط Include دارند یعنیUse case اول Use case دوم را Include می کند.
Exclude
هر گاه در راستای انجام یکUse case بکار گیری یا فراخوانی یک Use case محتمل باشد،این دو Use caseارتباط Exclude دارند یعنیUse case اول Use case دوم را Exclude می کند.

- رسم نمودار انجام و تحقق
· ترسیم ارتباط بین Use case ها وActor ها
· تقسیم سیستم به چند زیر سیستم و شناسایی Use case ها هر زیر سیستم (پکیج بندی سیستم)
· کشیدن نمودار ساده مراحل کار(Sequence Diagram)Use case
· راههای عمومی رسیدن به Use case:
کشفActor های سیستم
کشفUse case های Actor های سیستم
تشخیص رفتار مشترکExclude ،Include در Use case ها
آنالیز شرح عملکرد Use caseها

Business Entity
موجوداتی هستند که آغاز کننده کار نیستند بلکه در جریان یک کار به عنوان یک آیتم اطلاعاتی در سیستم منتشر می شوند و ممکن است در سیستم تغییر شکل دهند و حالات مختلفی داشته باشند. بررسی چنین موجوداتی مستقل از نوع فن آوری می باشد.

Glossary
شناسنامه موضوعاتی که بررسی می شوند.

[h_rezaei]

Business Object Modeling
در این مرحله تمامیBusiness Workers وBusiness Entity باید قابل شناسایی باشند
این مدل کلیهRole ها و Thing ها راشناسایی می کند که تولید کننده کلاس در دیدگاه منطقی سیستم خواهد بود.
پیش از پرداختن به این مبحث مفاهیم زیر معرفی می گردد:
در دنیای شئ گرا هر چیز قابل لمس که دارای یک سری ویژگی و رفتار باشد راObject می گوییم.
ـ OBJECT دارایIdentify ، Behavior،State میباشد.
- IDENTIFYباید زیر مجموعه ای از State ها باشد (Identify می تواند در دنیای خارجی وجود نداشته باشد)
CLASS (TYPE)
در اثر دسته بندی OBJECT های مشابه گروههایی به نام کلاس تشکیل می شود.
INSTANCE ( نمونه ):
یک مورد اجرایی از کلاس را نمونه می نامند(تفاوت جزئی بین ابجکتو نمونه وجود دارد)
ATTRIBUTE (ویژگی):
اطلاعاتی که در کلاس تعریف می شوند.مقادیر این ویژگی ها راSTATE می نامند.
METHOD/ SERVICE:
معادل تابع در زبانهای ساختار یافته است.
در خواستی را که به یک ابجکت می فرستیم( MESSAGE ) و ابجکت رفتار متناسب با آن را انجام می دهد.
رفتار تابع همیشه ثابت است و نتیجه آن مشخص ولی رفتار متدعای کلاس بستگی به نوع ابجکت دارد.
GENERALIZATION / INHERITANCE:
مشخص میکند که یک کلاس از کلاس دیگر مجرد تر استیا کلی تر و این رابطه بیانگر یک نوع توازن است.
در دیدگاه شئ گرایی موضوعات را ابتدا کلی می بینیم تا جهت اضافه کردن شئ جدید مشکلی وجود نداشته باشد.
ASSOCIATION (انجمنی):
بینگر ساختار موجود در کلاسهاست و تناظر بین اشیا را مشخص می کند(مانند ساختاری است).این رابطه بیانگر ارتباط اجزا درونی،مرتبط و معنا دهنده به یک کلیت با یک مفهوم کلی می باشد مانند نسبت کلاس کارمندان به کلاس شرکت انجمنی استولی نسبت کلاس چاپ فاکتور به کلاس فاکتور انجمنی نیست.
AGGREGTION (تجمعی):
همان رابطه ساختاری انجمنی است که نسبت کل به جز را مشخص می کند.مانند سند به اقلام سند.
· خیلی از روابط ممکن است صریحاَ و مستقیماَدر شئ به موجود بر قرار نباشد ولی از روی سایر روابط برداشت می شوند،در این موارد نیازی به ایجاد ارتباط مستقسم نیست.گاهی ممکن است به دلیل افزایش سرعت این روابط را ایجاد نماییم.
COMPOSITION
در رایطه تجمعی کل بدون جز معنا ندارد.اگر جز بدون کل هم معنا نداشته باشد رابطه تجمعی از نوع COMPOSITIVEمی باشد.
ENCAPSULATION
قرار دادن مجموعه ای ازامکانات (رفتار و ویژگی) در یک بسته طوری که پیچیدگیهای امکانات را از دید کاربر پنهان کند.در این حالت سرویس گرفتن از این مجموعه امکانات برای کاربر منظم و راحت است.
POLYMORPHISM
با وجود یک اسم و یک انتظار رفتارهای مختلفی را انتظار داشته باشیم.
گاز دادن دو خودرو
محاسبه حقوق برای پرسنل مختلف

بر اساس Business Object Model میتوان در مورد نحوه تحقق UseCaseها و ارتباط بین UseCaseو Objectهای سیستم(گذار یا Transaction) تصمیم گیری کرد و به مدل Business Transaction Model رسید.
· مبنای کار در این بخش استناد به Business UsaCase Modeling است.
· کشف و جستجوی موضوعات و موجودیت هایی که هدف کاری UsaCaseهای سیستم می باشد منجر به کشف مدل موضوعی سیستم می شود.
· در تئوری RUP پیشنهاد میشود که پیش از دسته بندی موضوعی فعالیت ها یک شناسنامه گویا MOM(Meta Object Model)برای سیستم مشخص کنیم

تعریف (Meta Object Model)
مدلی که شرح حالت کلی یک موضوع ، ارتباط بین موضوعات کلی، ارتباط بین موضوعات جزئی وموضوعات کلی و دامنه موضوع را مشخص کند.
· به جز ویژگی تشریحی این مدل دیگر ویژگی های این مدل مانند مدل کلاسیک سیستم
(Class Diagram ) می باشد

ویژگی های (Meta Object Model)

1- موضوعات مرتبط با UseCaseهای سیستم را تا جای ممکن شناسایی کند.
2- حالتهای جایگزین (Alternative)موضوعات کلی را تا جای ممکن شناسایی کند.در صورت امکان نحوه دسته بندی این حالتها و افراد (Actor)ها و UseCaseهایی در گیر با این حالتهای موضوعات را شناسایی کنیم.
3- شناسایی موقعیت هایی که در آنها عملیات نمونه گیری از موضوعات صورت می گیرد.کشف این موقعیت ها منجر به شناسایی stateهای Object واز آنجامنجر به شناسایی propertyموضوعات می شود.در این حالت باید بشتر هدف رسیدن به Strotype های ویژگیها باشد نه خود ویژگی ها.
4- اگر شناسنامه گویای موضوعات کلی دیده شود و رفتار و ویژگی های آن نیز کلی دیده شود مدل موضوعی سیستم خوب تشریح می شود.
5- در مدلmomبرداشت و انتظار سیستم از موضوع به هنگام اجرا و بهره برداری از موضوع به صورت کلی مطرح می شود.(شرح)
در این مدل سازی بیشتر موارد زیر را بررسی می کنیم.این موارد بایستی از Business Object Model سیستم قابل لستخراج باشد:
Business Instance Worker
در هر UseCase ممکن است چندین Actor با چندین نمونه و نقش فعالیت کنند. هریک از این actorها ممکن است در ایجاد/اصلاح تعریف و ویژگی های موضوع اصلی نقش داشته باشند.
Business Entity
مدارک ، اطلاعات و ... که پیرامون یک موضوع عمده در یک سیستم کاربرد دارد.
Object Colabration
کارهای که هدفمند و متمرکز بر روی یک هدف خاص و عمده صورت میگیرد ممکن است چندین موضوع هدفساز و جانبی نیز در کنار موضوع هدف و اصلی قرار گیرند ولی موضوع هدف و اصلی مهم است.
· برای رسیدن به یک مدل موضوعی مناسب و کارا که در مراحل بعد(نیاز سنجی/آنالیز/طراحی)نیز بکار می رود.پیشنهاد می شود که یک مدل پیشنویس (Adaaptive Object Model)AOMدر این بخش شناسایی و طراحی شود. این مدل پسنویس از روی مدل گویا (MOM) ساخته می شود.
نتایج یکMOMکامل در فاز :Business Object Modeling
1-UseCase ها ی سیتم به صورت کامل (تعداد/ویژگی)شناسایی می شوند.
2- aom مناسب برای مراحل بعدی بدست می آید.
3- یک مدل موضوعی پویا با تغییر نیازهای سیستم بوجود می آید.
4- مدل موضوعی ((Business Object Modeling سیستم برای استفاده در فاز Business Modeling کامل می شود.
5- شناسایی/ شبیه سازی موضوعیرفتار سیستم در آینده کامل تر می شود.
تعریف (Adaptive Object Model)
مدل کلی اما واقعی موضوعی سیستم که از روی momبدست می آید.

ویژگی های ) (Adaptive Object Model
1- تمامی دستورات/ عملکرد ها / انتظارات و هر فعلی که باعث انجام یک کار مرتبط با موضوع شود.در این مدل تشریح می شود.
2- یک شناسنامه برای دسته بندی موضوعات کلی تهیه می شود(لیست و شرحObject Type
3- برای رفتارهای مرتبط با موضوعات با یک strategy و سپس یک شناسنامه رفتاری
(Method Type )تهیه می شود.
4- برای ویژگی های موضوع Attribute Typeتهیه می شود.
5- برایEntity های مرتبط با موضوع هم یک سری تهیه Entity Typeتهیه می شود.
· در تمامی این بررسی ها موقعیت/ مقدار/ نوع/ نحوه عملکرد ویژگی ها و رفتار و موارد خارجی را به هنگام اجرا و بهره برداری از سیستم بررسی می کنیم نه در حالت انتزاعی/بهینه/مورد نیاز.

[Navid7h]

این هم فایل PDF

[delphi developer]

قسمت اولش هم تو تاپیک Business Modeling گذاشتم...