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

[ali]

دانلود پروژه مهندسی نرم افزار در قالب فایل WORD DOC سيستم اداره كل تجهيزات پزشكي در لینک زیر:

http://forum.a00b.com/upload/Uploads/636...780UML.doc

معرفي سيستم 5
روش ها 6
نتايج 7
نتيجه گيري 8
پيشنهادات 9
امكان سنجي 10
مصاحبه 11
تحليل مخاطره يا ريسك 11
نمودار زمينه اي – متن (Context Diagram) 13
چارت سازماني اداره كل تجهيزات پزشكي 14
نمودار جريان اسناد (Document Flow Diagram) 15
نمودار جريان داده ها سطح يكم (Data Flow Diagram) 16
نمودار جريان داده ها سطح دوم (Data Flow Diagram) 17
نمودار جريان داده ها سطح سوم (Data Flow Diagram) 18
نمودار LDM (Logical Data Model) 19
ماتريس تاثير اتفاقات بر موجوديت ها 20
نمودار تاريخچه حيات (Entity Life History) 21

[ali]

دانلود پروژه مهندسی نرم افزار خرید و فروش اینترنتی PPT فایل Power Point:

http://forum.a00b.com/upload/Uploads/636...450UML.ppt

[ali]

دانلود پروژه مهندسی نرم افزار امور دارویی

http://forum.a00b.com/upload/Uploads/636...430DFD.zip

[ali]

دانلود پروژه مهندسی نرم افزار مواد غذایی:

http://forum.a00b.com/upload/Uploads/636...ftEngr.doc

[ali]

فهرست مطالب
مقدمه اي بر متد Obiect-Oriented (شيءگرايي) 1
Encapsulation (نهان سازي) 3
Inheritance (وراثت) 6
‍Polymorphism(چند ريختي) 9
مدلسازي بصري (Visual Modeling) چيست؟ 12
Booch, OMT, and UML 14
نمودارهاي UML 15
نمودارهاي Use Case 16
نمودارهاي CLASS (كلاس) 17
نمودارهاي حالت (State Transition Diagrams) 20
مدلسازي بصري و پردازش توليد و توسعه نرم‌افزار 23
شناخت Inception 27
Iteration One Use Cases 1.5.6 28
مهارت Elaboration 29
ساختار Construction 30
انتقال Transition 32
Rational Rose چيست؟ 33
پرداختن به Rational Rose 39
بخش‌هاي صفحه نمايش 40
چهار نماي موجود در يك مدل Rose 40
نماي منطقي 41
نماي Component 42
نماي Deployment 42
كار با برنامه Rational Rose 43
ايجاد مدل‌ها 43
واردكردن و ارسال مدل‌ها 44
انتشار مدل‌ها بر روي وب 45
كار با واحدهاي كنترل شده 46
نماي Use case 47
نمودارهاي Rational rose 48
كار با Use case 51
مستند سازي جريان رخدادها (Flow of Event) 55
تعريف (descripition) 56
پيش شرايط (Precondition) 57
Post Conditions (شرايط پسين) 62
كار كردن با عامل ها (Actor) 62
ساخت يك عامل Abstract 64
چگونگي كار با رابطه ها 65
نمودارهاي Interaction 67
يك Object چيست؟ 68
يك كلاس چيست؟ 70
يافتن آبجكت ها 71
استفاده از نمودارهاي Interaction 73
نمودارهاي Sequence 75
نمودارهاي Collaboration 77
نماي Logical(منطقي) يك مدلRose 78
نمودارهاي class 79
استفاده از صفات 81
يافتن صفات 81
تنظيم Visibility صفت 85
يافتن عمليتها 89
نمودارهاي تغيير حالت(State Transition) 91
فعاليت(Activity) 93
Action ورودي (Entry Action) 93
Action خروج (Exit Action) 94
رخداد(Event) 95
Action 96
حالت آغازين(Start State) 97
حالت پاياني 97
استفاده از حالات تو در تو (Nested State) 98

مقدمه اي بر متد Obiect-Oriented (شيءگرايي)
شيءگرايي (Object-Oriented) لغتي است كه امروزه در صنعت نرم افزار، باب شده است. شركتها به سرعت حركت مي كنند تا خود را با اين تكنولوژي سازگار كنند و آن را در برنامه هاي خود وارد نمايند.
متد شيءگرايي (O.O) يك راه متفاوت مشاهده برنامه هاست. با متد شيءگرايي، شما يك برنامه را به قطعات بسيار كوچك يا آبجكت هايي تقسيم مي كنيد، كه تا اندازه اي مستقل از يكديگر مي باشند. مانند ساختماني از بلوك ها نگاه كنيد.
اولين قدم اين است كه آبجكت هاي اساسي (انواع مختلف بلوك ها) را بسازيد يا بدست آوريد. اولين باري كه شما اين بلوك هاي ساختماني را داريد، مي توانيد آنها را كنار هم گذاشته و قصرتان را بسازيد. به محض اينكه تعدادي آبجكت هاي اساسي را در دنياي كامپيوتر ساختيد يا بدست آورديد، مي توانيد به سادگي آنها را كنار هم بگذاريد تا برنامه‌هاي جديد ايجاد را كنيد. يكي از امتيازات اساسي متد شيءگرايي اين است كه مي توانيد يك بار Component (اجزاء) را ساخته و بارها و بارها از آنها استفاده كنيد. درست مانند زماني كه مي توانيد يك بلاك ساختماني را در يك قصر، يك خانه يا يك سفينه فضايي دوباره استفاده كنيد، مي توانيد از يك قطعه طرح يا كد شيءگرايي در يك سيستم حسابداري، يك سيستم بازرگاني يا يك سيستم پردازش سفارش استفاده مجدد نماييد.
تفاوت متد شيءگرايي با روش سنتي توسعه، چيست؟ در روش سنتي، روش توسعه به همراه اطلاعاتي كه سيستم نگهداري خواهد كرد به خودمان وابسته است.
در اين روش، ما از كاربران مي پرسيم كه چه اطلاعاتي را نياز دارند، پايگاه داده اي را طراحي مي كنيم كه اطلاعات را نگه دارد، صفحاتي را تهيه مي كنيم تا اطلاعات را بگيرد، و گزارشاتي را چاپ مي كنيم تا اطلاعاتي را براي كاربر نمايش دهد. به عبارت ديگر، ما بر روي اطلاعات متمركز مي شويم و كمتر توجه مي كنيم كه چه كاري با اين اطلاعات انجام شده يا رفتار سيستم چگونه است. اين روش data-centric (مبتني بر داده) ناميده شده است و براي ايجاد هزاران سيستم در سال، ايجاد شده است. مدلسازي data-centric مخصوص طراحي پايگاه داده و گرفتن اطلاعات خيلي مهم مي باشد، اما انتخاب اين روش در زمان طراحي برنامه هاي تجاري با مشكلاتي همراه است. يك چالش بزرگ اين است كه درخواستهاي سيستم چندين بار تغيير خواهند كرد. سيستمي كه از روش data-centric استفاده مي نمايد، مي تواند به آساني تغيير در پايگاه داده را مديريت كند. اما اجراي تغييرات در قوانين تجاري يا رفتار(behavior) سيستم آن قدر آسان نمي باشد. متد شيءگرايي در پاسخ به اين مشكل، ايجاد شده است. با متد شيءگرايي هم بر اطلاعات وهم بر رفتار متمركز مي شويم. در نتيجه اكنون مي توانيم سيستم هايي را ايجاد كنيم كه انعطاف پذير شده اند تا اطلاعات و يا رفتار را تغيير دهند.
مزيت اين انعطاف پذيري با طراحي يك سيستم شيءگرايي به خوبي شناخته شده است. اين مطلب، به شناخت تعدادي اصول شيء گرايي نياز دارد. نهان سازي (Encapsulation) وراثت(Inheritance) و چند ريختي (Polymorphism).

Encapsulation (نهان سازي)
در سيستمهاي شيءگرا، اينها (اطلاعات و رفتارها) را در يك آبجكت بسته بندي مي كنيم. اين مطلب در قالب اطلاعات Encapsulation (پنهان سازي) ارجاع داده شده است. راه ديگر براي نگاه كردن به توابع وابسته، اين است كه برنامه را به بخشهاي كوچكي از توابع وابسته، تقسيم كنيم. مثلاً يك حساب بانكي شامل: شماره حساب، تراز جاري نام مشتري آدرس نوع حساب، نرخ بهره و تاريخ باز كردن حساب مي باشد. همچنين رفتارهايي را براي يك حساب بانك داريم مانند: باز كردن يك حساب ، بستن حساب، به حساب گذاشتن، برداست از حساب، تغيير نوع حساب، تغيير مشتري و تغيير آدرس. ما اين اطلاعات و رفتارها را با هم در يك آبجكت account پنهان مي كنيم. در نتيجه همة تغييرات سيستم بانكي مربوط به حسابها، مي توانند به آساني در آبجكت حساب انجام شوند.

مـزيت ديگر پنهان سازي اين است كه تأثيرات اعمال شده به سيستم را محدود مي كند. به يك سيستم به عنوان بستري از آب و به تغيير درخواستها مانند يك صخره بزرگ نگاه كنيم. شما صخره را در آب مي اندازيد و امواج بزرگي در همه جهتها ايجاد مي شوند. آنها در سرتاسر درياچه حركت مي كنند، به كرانه ضربه مي زنند، طنين افكن مي شوند و با امواج ديگر برخورد مي كنند در حقيقت، حتي ممكن است مقداي آب بر روي ساحل و خارج از درياچه بريزد. بعبارت ديگر، برخورد صخره با آب باعث ايجاد ميزان زيادي موج هاي كوچك شده است. حال درياچه خود را پنهان مي كنيم. تدين ترتيب كه آن را به تكه هاي كوچكتري از آب با موانعي ميان آنها تقسيم مي كنيم. سپس، ضربات سيستم را تغيير مي دهد. قبل از اين، امواج در همه جهتها ايجاد مي شدند. اما اكنون، امواج فقط مي توانند از يكي از موانع عبور نمايد. و سپس متوقف مي گردند. بنابرين، با نهان سازي درياچه، ما تاثير موج كوچك حاصل از انداختن صخره در آب را محدود كرده ايم.
حال، بياييد ايدة نهان سازي را درسيستم بانكي به كار ببريم. اخيراً مديريت بانك تصميم گرفته است كه اگر مشتري در بانك يك حساب اعتباري دارد، بتوان از حساب اعتباري بعنوان يك مبلغ اضافه، برداشت كرده و براي حساب جاري آنها استفاده نمود. در يك سيستم غير نهان سازي، كار را با يك روش اجباري شروع مي كنيم تا تجزيه و تحليل كاراتر شود. اساساً، ما محل تمام جاهايي كه ازعمليات برداشت از حساب، در يك سيستم استفاده شده است را نمي دانيم،
بنابرين بايد به هر جايي نگاه كنيم و وقتي كه آن را پيدا كرديم، بايد يك سري از تغييرات را ايجاد كنيم تا اين درخواست جديد را يكپارچه كنيم. اگر كار به درستي انجام شده باشد، احتمالاً 80 % موارد برداشت از حساب را در سيستم پيدا كرده ايم. با يك سيستم نهان سازي، ما نيازي به استفاده از روش اجباري براي تجزيه و تحليل نداريم. ما به مدل سيستم خود نگاه مي كنيم و به آساني جايي كه رويداد برداشت از حساب پنهان شده بود را پيدا مي كنيم. بعد از اينكه عمليات را در حساب قرار داديم، يكبار درخواستمان را فقط در آن آبجكت تغيير مي دهيم، و كار ما تمام شده است. همان گونه كه در شكل زير مي بينيد، فقط كلاسAcount نياز به تغيير دارد.


يك مفهوم مشابه نهان سازي، Information Hiding (پنهان سازي) مي باشد. پنهان سازي اطلاعات، توانايي است كه جزئيات مبهم يك آبجكت را از دنياي خارج پنهان مي سازد. در يك آبجكت، دنياي خارج به معني هر چيزي خارج از همان آبجكت است حتي اگرچه دنياي خارج شامل بقية سيستم باشد. پنهان سازي اطلاعات (Information Hiding) همان مزيت نهان سازي (Encapsolation) را فراهم مي كند.

دانلود ادامه در قالب فایل WORD DOC به همراه نمودارهای UML و عکس و توضیحات کامل:

http://forum.a00b.com/upload/Uploads/636...ML_RUP.doc

[ali]

فصل اول : UML
مقدمه:
با كمی اغماض می‌توان ادعا كرد كه در ميان شاخه‌های مختلف مهندسی در هركدام كه دارای قدمت بيشتری است، همگرايی بيشتری در اتخاذ روش و ابزار برای انجام اعمال نسبتاً مشابه از ميان متخصصان و متوليان آن رشته وجود دارد. به طور مثال در حال حاضر برای اجرای يك سازه در هر نقطه از دنيا، مهندسين عمران از يك روند همسان با توالی مشابه شامل: الف)توليد طرح عمرانی ب)پياده‌سازی نقشه ج)محاسبات سازه‌ای د)اجرا استفاده می‌كنند. ولی در رشته نوپايی چون مهندسی نرم‌افزار، گاه چنان روش‌ها متفاوت است كه از ديد يك ناظر خارجی، دو تيم نرم‌افزاری مختلف كه هر دو قصد توليد محصولی مشابه را دارند، دو تيم در رشته‌های متفاوت به نظر بيايند. يكی از علل وجود تمايز در توليد نرم‌افزار ميزان تخصص نيرو و زمان به پياده‌سازی می‌باشد.بدين معنا كه در نزد بسياری از برنامه‌نويسان توليد نرم‌افزار معادل است با توليد كد. ولی از نظر بعضی ديگر توليد كد تنها بخشی از توليد نرم‌افزار است كه در بسياری از موارد حتی منابع و زمان. اختصاص داده شده به آن در طول پروسه.توليد نرم‌افزار كمتر از50% می‌باشد.
از يك ديدگاه كلی، پروسه توليد نرم‌افزار را می‌توان به دو بخش كلی شامل:
الف)تحليل و طراحی ب)پياده‌سازی تقسيم كرد. از ديدگاه دسته اول، برنامه‌سازان، تحليل و طراحی صرفاً فهم ذهنی مساله می‌باشد كه دقيقا پس از آن بايستی اقدام به پياده‌سازی كرد. در حاليكه در نظر دسته دوم، فاز تحليل و طراحی پر اهميت‌تر از فاز دوم می‌باشد كه بايستی برای انجام آن از متدولوژی‌ها و روش‌های استاندارد استفاده كرد. UML يك زبان مدلسازی می‌باشد كه در فاز تحليل و طراحی مورد استفاده قرار می‌گيرد.






مدل‌سازی (Modeling) چيست؟
مدل‌سازی يكی از تكنيك‌های ذهنی بشر می‌باشد كه نه تنها برای اهداف علمی، بلكه برای انجام امور روزمره بشر به دفعات مورد استفاده قرار می‌گيرد. مدل‌سازی به طور كلی يعنی شبيه‌سازی يك محيط با اندازه‌های متفاوت و از محيط واقعی و احتمالا مواد و مصالحی متمايز از جنس مواد و مصالح محيط مدل شده. در مدل‌سازی ابتدا اجزای محيط واقعی انتخاب شده و متناسب با هدف مورد نظر از مدل‌سازی خصوصياتی از هريك از اجزای واقعی انتزاع می‌شود، يعنی به ازای هزيك از اجزای محيط واقعی يك موجوديت تجريدی ساخته می‌شود و با برقراری ارتباطی مشابه با ارتباط اجزای واقعی، در ميان موجوديت‌های تجريدی، محيط واقعی مدل می‌شود. برای روشن شدن مثالی می‌زنيم:
فرض كنيم قصد داشته باشيم در فاز طراحی يك اتومبيل ميزان موفقيت هوا در مقابل اتومبيل در حال حركت را بسنجيم يكی از راه‌ها برای انجام اين آزمايش، ساخت يك اتومبيل واقعی، راندن و سپس اندازه‌گيری مقاومت هوا می‌باشد كه انجام اينكار اگرچه ما را به هدف می‌رساند، ولی دارای هزينه بالاييست چرا كه بايستی ابتدا ماشين ساخته شود، سپس مورد آزمايش قرار گيرد.در اين صورت اگر در آزمايش به نتيجه مورد نظر نرسيم، بايستی دوباره طراحی را تغيير داد، و پس از ساخت يك نمونه واقعی ديگر آزمايش را تكرار كنيم و اين روند آنقدر ادامه پيدا كند تا طراحی مناسب برای اتومبيلی با خصوصيات مورد نظر شكل گيرد. می‌بينيم كه چنين روشی بسيار پرهزينه است و اين هزينه هم شامل هزينه‌های اقتصادی است و هم هزينه‌های زمانی، چون علاوه بر اين كه در هر مرحله آزمايش بايستی اتومبيل با صرف هزينه بالا ساخته شود، زمان ساخت آن نيز طول خواهد كشيد.
ولی متخصصان برای انجام چنين آزمايشی به مدل روی می‌آورند. يعنی يك جسم فيزيكی كوچك با خصوصيات آئروديناميكی لحاظ شده در طراحی اتومبيل، ساخته می‌شود و با قرار دادن آن در يك تونل باد، حركت اتومبيل در فضای واقعی را شبيه سازی می‌كنند و بدين طريق ميزان مقاومت هوا را می‌سنجند.
نكات مورد توجه در اين مدل‌سازی، يكی اندازه مدل و ديگری خصوصيات آن می‌باشد. مدل بسيار ساده و كوچك می‌باشد و از طرفی تنها خصوصيت آئروديناميكی اتومبيل در مدل لحاظ می‌شود. چرا كه هدف ما از مدل‌سازی تنها بررسی خصوصيات آئروديناميكی اتومبيل است و مدل الزاماً نبايستی از جنبه‌های ديگر، شباهتی به اتومبيل واقعی داشته باشد. مثلا در ساخت چنين مدلی به هيچ‌وجه به استحكام اجزا و يا زيبايی مدل توجه نمی‌شود چون بررسی چنين خصوصياتی خارج از هدف اين مدلسازی خاص است.
مثال بالاتنها يك جنبه از مدل‌سازی را بيان می‌كند و آن جنبه شناختExploration می‌باشد. يعنی در مدلسازی‌های مشابه مدل‌سازی فوق‌الذكر، هدف از مدل‌سازی تنها شناخت محيط مورد مدل می‌باشد. يك جنبه ديگر از مدل‌سازی تبيين (specification) می‌باشد. يعنی گاه برای معرفی و ارائه خصوصيات يك موجوديت واقعی يك مدل از آن ارائه می‌شود. نقشه جغرافيايی مثال خوبی است كه اين جنبه از مدل‌سازی را مورد نظر دارد.
پس می‌توان گفت كه هدف از مدل‌سازی دو چيز می‌باشد:
الف)شناخت(exploration)
ب)تبيين(specification)
كه بر اساس تعريف مسئله، مدل‌سازی يكی يا هردو هدف را در نظر می‌گيرد.




مهندسي نرم افزار و معرفي UML
يكي از مباحث مهم در علم كامپيوتر بحث مهندسي نرم افزار مي باشد كه متاسفانه در ايران در وب سايت ها كمتر به آن پرداخته مي شود . در حاليكه امروزه شركت ها بدون داشتن اصول مشخص مهندسي نرم افزار هيچگاه تصميم به ايجاد سيستم هاي نرم افزاري نمي گيرند .
همانگونه كه مي دانيد طراحي و توليد سيستم هاي نرم افزاري داراي يك چرخه حيات مي باشد كه در علم مهندسي نرم افزار به بررسي اين چرخه حيات و عوامل مرتبط با آن پرداخته مي شود . به طور كلي مراحل اين چرخه به شرح زير مي باشد :
• فعاليت جمع آوري نيازمندي هاي و مشخص كردن آنها . اين نيازمندي ها كاري را كه سيستم مي بايست انجام دهد را مشخص مي كنند .
• فعاليت تحليل نيازمندي ها براي درك بهتر آنها .
• فعاليت طراحي براي اينكه مشخص شود كه سيستم چگونه نيازمندي ها را برآورده مي كند .
• فعاليت ساخت سيستم .
• آزمايش سيستم براي تاييد اينكه آيا سيستم نيازمندي ها را برآورده كرده است يانه ؟
• و در نهايت فعاليت تحويل سيستم .
حال متدلوژي هاي مختلفي براي انجام اين فعاليت ها وجود دارد و هر كدام به نحوي به انجام اين كار ها مي پردازند .
متدولوژي
در ابتدا بايد به تعريف متدلوژي و اينكه يك متدلوژي چه كاري انجام مي دهد پرداخت .
تعريف : متدلوژي يا فراروش مجموعه اي است همگرا و هدف مدار از مفاهيم ، عقايد ، ارزش ها و اصولي كه بوسيله منابعي در جهت حل مسايل گروهي بكار گرفته مي شود و مي خواهد تغييرات مطلوبي را در وضع موجود يك سيستم بطور غير تصادفي ايجاد نمايد .
يك متدلوژي در حقيقت سه وظيفه دارد .
1. فرموله كردن مسئله .
2. بيان نحوه حل مسئله
3. پياده سازي مسئله .
هدف من در اينجا بررسي متدلوژي هاي شي گرا مي باشد . ديدگاه شي گرايي از اواسط دهه 70 ميلادي در مباحث برنامه نويسي كامپيوتر متولد شد . پس از گذشت چند سال و در اوايل دهه 90 به جهت ناكارآمدي روش هاي سنتي در مباحث تحليل و طراحي سيستم هاي اطلاعاتي و كامپيوتري و نيز ظهور سيستم هايي كه مدل سازي آنها به روش هاي سنتي بسيار ناقص بود ، تحليل گران و طراحان سيستم را به اين فكر انداخت تا از ديدگاه شي گرا علاوه بر برنامه نويسي در زمينه تحليل و طراحي سيستم نيز استفاده كنند , و UML یک مدل سازی شی گراست.
زبان مدلسازي يكنواخت:
زبان مدلسازي يكنواخت يا Unified Modeling Language (UML)، يك زبان مدلسازي است كه براي تحليل وطراحي سيستمهاي شي‌گرا بكار مي‌رود. UML اولين بار توسط شركت Rational ارائه شد و پس از آن از طرف بسياري از شركت‌هاي كامپيوتري و مجامع صنعتي و نرم‌افزاري دنيا مورد حمايت قرار گرفت؛ به طوريكه تنها پس از يك سال، توسط گروه Object Management Group، به عنوان زبان مدلسازي استاندارد پذيرفته شد. UML تواناييها و خصوصيات بارز فراواني دارد كه مي‌تواند به طور گسترده‌اي در توليد نرم‌افزار استفاده گردد. در ادامة اين مقاله ابتدا به تاريخچة UML و در ادامه به معرفي، ويژگيها و نمودارهاي آن پرداخته مي‌شود و در پايان، روند حركت به سمت UML و اهميت آن براي ايران، بررسي خواهد شد.
تاريخچة UML :
ديدگاه شي‌گرايي (Object Oriented) از اواسط دهه 1970 تا اواخر دهه 1980 در حال مطرح شدن بود. در اين دوران تلاشهاي زيادي براي ايجاد روشهاي تحليل و طراحي شي‌گرا صورت پذيرفت. در نتيجة اين تلاشها بود كه در طول 5 سال يعني 1989 تا 1994، تعداد متدولوژيهاي شي‌گرا از كمتر از 10 متدولوژي به بيش از 50 متدولوژي رسيد. تكثر متدولوژيها و زبانهاي شي‌گرايي و رقابت بين اينها به حدي بود كه اين دوران به عنوان "جنگ متدولوژيها" لقب گرفت. از جمله متدولوژيهاي پركاربرد آن زمان مي‌توان از Booch، OOSE، OMT، Fusion، Coad-Yourdan، Shlayer-Mellor وغيره نام برد. فراواني و اشباع متدولوژيها و روشهاي شي‌گرايي و نيز نبودن يك زبان مدلسازي استاندارد، باعث مشكلات فراواني شده بود. از يك طرف كاربران از متدولوژيهاي موجود خسته شده بودند، زيرا مجبور بودند از ميان روشهاي مختلف شبيه به هم كه تفاوت كمي در قدرت و قابليت داشتند يكي را انتخاب كنند. بسياري از اين روشها، مفاهيم مشترك شي‌گرايي را در قالبهاي مختلف بيان مي‌كردند كه اين واگرايي و نبودن توافق ميان اين زبانها، كاربران تازه‌كار را از دنياي شي‌گرايي زده مي‌كرد و آنها را از اين حيطه دور مي‌ساخت. عدم وجود يك زبان استاندارد، براي فروشندگان محصولات نرم‌افزاري نيز مشكلات زيادي ايجاد كرده بود.
اولين تلاشهاي استانداردسازي از اكتبر 1994 آغاز شد، زماني كه آقاي Rumbaurgh صاحب متدولوژي OMT به آقاي Booch در شركت Rational پيوست و اين دو با تركيب متدولوژيهاي خود، اولين محصول تركيبي خود به نام "روش يكنواخت" را ارائه دادند. در سال 1995 بود كه با اضافه شدن آقاي Jacobson به اين دو، روش يكنواخت ارائه شده با روش OOSE نيز تركيب شد واين خود سبب ارائة UML نسخة 0.9 در سال 1996 گرديد. سپس اين محصول به شركتهاي مختلفي در سراسر جهان به صورت رايگان ارائه شد و استقبال شديد شركت‌ها از اين محصول و تبليغات گسترده شركت Rational، سبب آن شد كه گروه OMG، نسخة 1.0 UML را به عنوان زبان مدلسازي استاندارد خود بپذيرد. تلاشهاي تكميلي UML استاندارد ادامه پيدا كرد و نسخة 1.1 آن در سال 1997 و نسخه 1.3 آن در سال 1999 ارائه گرديد.

UML چيست؟
UML يا زبان مدلسازي يكنواخت، زباني است براي مشخص كردن (Specify)، مصورسازي (Visualize)، ساخت (Construction) و مستندسازي (Documenting) سيستمهاي نرم‌افزاري و غير نرم‌افزاري و نيز براي مدلسازي سيستمهاي تجاري. مجموعه اي از استاندارد هاست براي طراحي شي گراي يك نرم افزار با ديد مفهوم شی گرا ! يك طراحي UML با كدنويسي كاري ندارد . به او ميگويند برنامه بايد * چه* كاري انجام دهد و او اجزاي برنامه را * طراحي* ميكند و البته هميشه يك تيم خوب برنامه نويسي در كنار او هستند تا با استفاده از اين مدل استاندارد كد برنامه را بنويسند .
اما چرا مدل و مدلسازي؟
ايجاد يك مدل براي سيستمهاي نرم‌افزاري قبل از ساخت يا بازساخت آن، به اندازه داشتن نقشه براي ساختن يك ساختمان ضروري و حياتي است. بسياري از شاخه‌هاي مهندسي، توصيف چگونگي محصولاتي كه بايد ساخته شوند را ترسيم مي‌كنند و همچنين دقت زيادي مي‌كنند كه محصولاتشان طبق اين مدلها و توصيفها ساخته شوند. مدلهاي خوب و دقيق در برقراري يك ارتباط كامل بين افراد پروژه، نقش زيادي مي‌توانند داشته باشند. شايد علت مدل كردن سيستمهاي پيچيده اين باشد كه تمامي آن را نمي‌توان يكباره مجسم كرد، بنابراين براي فهم كامل سيستم و يافتن و نمايش ارتباط بين قسمتهاي مختلف آن، به مدلسازي مي‌پردازيم. UML زباني است براي مدلسازي يا ايجاد نقشه توليد نرم‌افزار.
به عبارت ديگر، يك زبان، با ارائه يك فرهنگ لغات ويك مجموعه قواعد، امكان مي‌دهد كه با تركيب كلمات اين فرهنگ لغات و ساختن جملات، با يكديگر ارتباط برقرار كنيم. يك زبان مدلسازي، زباني است كه فرهنگ لغات و قواعد آن بر نمايش فيزيكي و مفهومي آن سيستم متمركزند. براي سيستمهاي نرم‌افزاري نياز به يك زبان مدلسازي داريم كه بتواند ديدهاي مختلف معماري سيستم را در طول چرخة توليد آن، مدل كند.
فرهنگ واژگان و قواعد زباني مثل UML به شما مي‌گويند كه چگونه يك مدل را بسازيد و يا چگونه يك مدل را بخوانيد. اما به شما نمي‌گويند كه در چه زماني، چه مدلي را ايجاد كنيد. يعني UML فقط يك زبان نمادگذاري (Notation) است نه يك متدولوژي. يك زبان نمادگذاري شامل نحوة ايجاد و نحوة خواندن يك مدل مي‌باشد، اما يك متدولوژي بيان مي‌كند كه چه محصولاتي بايد در چه زماني توليد شوند و چه كارهايي با چه ترتيبي توسط چه كساني، با چه هزينه‌اي، در چه مدتي و با چه ريسكي انجام شوند.


ويژگيهاي UML :
UML داراي ويژگيهاي بارز فراواني است كه در اين قسمت به آنها مي‌پردازيم. UML يك زبان مدلسازي است اما چيزي فراتر از چند نماد گرافيكي است. بطوريكه در وراي اين نمادها، يك سمانتيك (معناشناسي) قوي وجود دارد، بطوريكه يك توليدكننده مي‌تواند مدلهايي توليد كند كه توليد‌كننده‌هاي ديگر و يا حتي يك ماشين آن را بخواند و بفهمد. بنابراين يكي ديگر از نقش‌هاي مهم UML "تسهيل ارتباط" بين اعضاي پروژه و يا بين توليدكنندگان مختلف مي‌باشد. اين ارتباط بسيار مهم است. شايد دليل اصلي اينكه توليد نرم‌افزار به صورت فريبنده‌اي دشوار است، همين عدم ارتباط مناسب بين اعضاي پروژه باشد و اگر در توليد نرم‌افزار، بين اعضاي پروژه گزارشهاي هفتگي و مداوم وجود داشته باشد، بسياري از اين دشواريها برطرف خواهد شد.
البته اين را هم بايد در نظر گرفت كه UML كمي پيچيده است و اين به خاطر آن است كه سعي شده است نمودارهايي فراهم شود كه در هر موقعيتي و با هر ترتيبي قابل استفاده باشند. دليل ديگر پيچيدگي از آنجا ناشي مي‌شود كه UML تركيبي است از زبانهاي مختلف، كه براي حفظ سازگاري و جمع كردن خصوصيات مثبت آنها، ناگزير از پذيرش اين پيچيدگي مي‌باشد.
UML موفقيت طرح را تضمين نمي‌كند، اما در عين حال خيلي چيزها را بهبود مي‌بخشد. به عنوان مثال استفاده از UML، تا حد زيادي، هزينه‌هاي ثابتي نظير آموزش و استفاده مجدد از ابزارها را در هنگام ايجاد تغيير در سازمان و طرحها كاهش مي‌دهد.
مساله ديگر اينكه، UML يك زبان برنامه‌نويسي بصري (visual) نيست، اما مدلهاي آن را مي‌توان مستقيماً به انواع زبانهاي مختلف ارتباط داد. يعني امكان نگاشت از مدلهاي UML به كد زبانهاي برنامه‌نويسي مثل Java و VC++ وجود دارد كه به اين عمل "مهندسي روبه‌جلو" مي‌گويند. عكس اين عمل نيز ممكن است؛ يعني اين امكان وجود دارد كه شما بتوانيد از كد يك برنامه زباني شي‌گرا، مدلهاي UML معادل آن را بدست آوريد. به اين عمل "مهندسي معكوس" مي‌گويند. مهندسي روبه‌جلو و معكوس از مهمترين قابليتهاي UML به شمار مي‌روند، البته نياز به ابزار Case مناسبي داريد كه از اين مفاهيم پشتيباني‌كنند.
اگر با زبانهاي مدلسازي ديگر كار كرده باشيد، براي كار با UML مشكل چنداني نخواهيد داشت. اما براي شروع كار با UML به عنوان اولين زبان مدلسازي، بهتر است فقط با نمودارهاي خاصي كار كنيد. براي اين كار بهتر است ابتدا با نمودارهاي مورد كاربرد و تعامل كار كنيد و پس از مدتي كار و آشنا شدن با ويژگيهاي اولية آن، به يادگيري و استفاده از نمودارها واجزاي ديگر بپردازيد. در مقايسه با زبانهاي مدلسازي ديگر مثلER و زبان فلوچارتي DR، زبان UML نمودارهاي قويتر و قابل‌فهمتري را ارائه مي‌دهدكه شامل تمامي مراحل چرخة حيات توليد نرم‌افزار (تحليل، طراحي، پياده‌سازي و تست) مي‌شود.
يكي ديگر از ويژگيهاي مهم UML اين است كه مستقل از متدولوژي يا فرايند توليد نرم‌افزارمي‌باشد و اين بدان معني است كه شما براي استفاده از UML، نياز به استفاده از يك متدولوژي خاص نداريد و مي‌توانيد طبق متدولوژي‌هاي قبلي خود عمل كنيد با اين تفاوت كه مدلهايتان را با UML نمايش مي‌دهيد. البته مستقل‌بودن از متدولوژي و فرايند توليد، يك مزيت براي UML مي‌باشد؛ زيرا بسياري از انواع پروژه‌ها و سيستمها نياز به متدولوژي خاص خود دارند. اگر UML در پي پياده كردن همة اينها بر مي‌آمد، يا بسيار پيچيده مي‌شد و يا استفاده خود را محدود مي‌كرد. البته متدولوژيهايي براساس UML در حال شكل‌گيري مي‌باشند.
از ديگر ويژگيهاي UML مي‌توان به پشتيباني از مفاهيم سطح بالاي شي‌گرايي مثل Collaboration، Framework، Pattern و Component اشاره كرد. همچنين UML با استفاده از يك سري مكانيزمهاي گسترش‌پذير امكان مي‌دهد كه بتوان زبانهاي مدلسازي جديدتري (با گسترش مفاهيم پايه‌اي موجود) ايجادكرد.
نمودارهاي UML :
در اين بخش به معرفي نمودارهاي UML مي‌پردازيم وعلاقمندان به آشنايي بيشتر را، دعوت به مطالعه مراجع معرفي شده، مي‌نماييم:

نمودار كلاس (Class Diagram):
اين نمودار،كلاسها، واسطها و همكاري و روابط بين آنها را نمايش مي‌دهد. و نمودار اصلي و مركزي UML مي‌باشد. كه بيان‌كننده ساختار ايستاي سيستم نرم‌افزاري مي‌باشد.
نمودار اشياء (Object Diagram):
اين نمودار، اشياء سيستم و روابط بين آنها را نمايش مي‌دهد. در واقع يك تصوير لحظه‌اي از نمودار كلاس مي‌باشد.
نمودار موردكاربرد (Usercase Diagram):
اين نمودار، تعامل كاربران خارجي و سيستم را مدل مي‌كند و از جهاتي شبيه نمودار سطح صفر DFD مي‌باشد كه جنبه‌هاي رفتاري سيستم را نمايش مي‌دهد. اين نمودار نقطه‌ ورودي براي تمامي نمودارهاي ديگري است كه به تشريح نيازمنديها و معماري و پياده‌سازي سيستم مي‌پردازند.
نمودارهاي تعامل (Interaction Diagram):
اين نمودارها، بيان كننده تعامل هستند كه شامل اشياء مختلف و روابط بين آنها و همچنين پيغامهايي كه بينشان رد و بدل مي‌شود مي‌باشند. اين نمودارها جنبه‌هاي پوياي يك سيستم را مدل مي‌كنند و خود بر دو نوعند: نمودار توالي(Sequence Diagram) كه ترتيب زماني تعامل‌ها را نشان مي‌دهد و نمودار همكاري(Collaboration Diagram) كه تاكيد بر نمايش ساختاري تعامل‌ها دارد.

نمودارحالت (Statechart Diagram):
اين نمودار، بيان‌كننده جنبه‌هاي رفتاري سيستم مي‌باشد و در واقع توصيف رسمي يك كلاس بوده كه شامل حالات، انتقال بين حالات، رخدادها و فعاليتها مي‌باشد. از اين نمودارها براي نمايش دادن چرخه حيات اشياء يك كلاس خاص نيز مي‌توان استفاده كرد.
نمودار فعاليت(Activity Diagram):
اين نمودار، نوع خاصي است از نمودار حالت، كه انتقال جريان از يك فعاليت به فعاليت ديگر را نمايش مي‌دهد. اين نمودار جنبه‌هاي پوياي يك سيستم را نمايش مي‌دهد. در واقع حالات اين نمودار، گامهاي ترتيبي انجام يك عمل را نمايش مي‌دهند.



نمودار اجزاء(Component Diagram):
از جمله نمودارهاي پياده‌سازي مي‌باشد و سازماندهي و روابط بين مجموعه‌اي از اجزاء را نمايش مي‌دهد. اين نمودار، جنبه هاي ايستاي پياده‌سازي يك سيستم را مدل مي‌كند.
نمودار به‌كارگماري(Deployment Diagram):
پيكربندي گره‌هاي پردازشي زمان اجرا را نمايش مي‌دهد. كه براي مدل كردن جنبه‌هاي ايستاي به‌كار‌گماري يك معماري بكار مي‌رود. همچنين نمايش‌دهندة اجزاي استفاده‌شده زمان اجرا مثل كتابخانه‌هاي DLL، فايل‌هاي اجرايي، كدهاي مبدا و روابط بين آنها مي‌باشد.
البته اين نمودارها تمام نمودارهاي UML نيستند بلكه بسته به نياز و با كمك ابزارهاي Case ميتوان نمودارهاي ديگري نيز تعريف و استفاده كرد
روند حركت به سمت UML در جهان:
قبل از ارائه UML، زبان مدلسازي استانداردي وجود نداشت و استفاده‌كنندگان مجبور بودند از ميان زبانهاي مختلف موجود ‌كه هيچيك تقريباً كامل نبودند و تفاوتهايي با هم داشتند، يكي را انتخاب كنند. تفاوتهاي زبانهاي مدلسازي، چندان قدرت مدلسازي را افزايش نداده بود، اما در عوض باعث افول صنعت شي‌گرايي و سردرگمي كاربران شده بود. در چنين شرايطي طبيعي بود كه استقبال زيادي از يك زبان مدلسازي استاندارد كه ويژگيهاي بارز زيادي داشت، بشود. بسياري از شركتها در همان اوايل كار به UML روي آوردند و تعداد ديگري نيز پس از تثبيت UML، آن را به عنوان استراتژي توليد ومستندسازي خود پذيرفتند.
OMG كه كنسرسيومي است متشكل از 700 شركت معتبر آمريكا، از UML حمايت كرد و آن را به عنوان زبان مدلسازي استاندارد خود اعلام كرد. البته علاوه بر استاندارد شدن، حمايت جداگانه شركت‌هاي بزرگ دنيا مثل Hewlett-Packard، I-Logix، Microsoft، IBM، Oracle و بسياري ديگر، خود سبب افزايش كاربرد آن در محافل صنعتي و نرم‌افزاري دنيا گرديد. امروزه نيز با ارائه نسخه 1.3 و رفع مشكلات گذشته، روز به روز بر كاربران آن افزوده مي‌شود.
روند حركت به سمت UML در ايران:
در ايران حركت برخي شركتها به سمت UML سريعتر انجام شد؛ بطوريكه در همان زمان استاندارد شدن UML در سال 1997، شركتهايي در ايران، اين ابزار را به عنوان استاندارد خود پذيرفتند و از آن در توليد محصولات خود استفاده كردند.
يكي از مشكلات پذيرش اين زبان در ايران، مقاومتهايي است كه در رابطه با خود شي‌گرايي مطرح مي‌شود. البته نظير اين مقاومتها در دنيا نيز وجود داشت و سرو صداهاي بسياري را سبب شد. اما تا قبل از ظهور UML و با ارائه متدهاي فراوان شي‌‌گرايي، اين مشكل تا حدودي حل شده بود.
با توجه به روند حركت شتابان به سمت UML در دنيا و با توجه به اهميت استانداردسازي براي صنعت نرم‌افزار كشور، حركت هرچه‌سريعتر به سوي اين فناوري در كشور توصيه مي‌شود.
اهميت ترويج UML در كشور:
در كشور ما شركتهاي نرم‌افزاري كه روشهاي علمي طراحي و مهندسي نرم‌افزار را به كار برند بسيار كمياب هستند. در واقع رقابت بين شركتها بيشتر بر سر كاهش قيمت است و نه بهبود كيفيت. ممكن است تصور شود عامل اصلي بروز اين مشكل، فرهنگ مصرف غلط در كشور است و لذا حل مشكل نيز به دست مصرفكنندگان است. اما بايستي از خود پرسيد كه مصرفكنندگان چگونه خواهند توانست يك محصول نرم‌افزاري را ارزيابي كرده و انتظارات خود را به طور دقيق مطرح نمايند؟ در اين زمينه دولتها وظايف مهمي دارند و مي‌توانند ابزارهاي لازم را فراهم نمايند.
هرچند UML يك استاندارد براي تشخيص كيفيت نرم‌افزارها نيست ولي استانداردي براي مدلسازي نرم‌افزار است ولذا مراحل مختلف تعريف، طراحي و حتي تست نرم‌افزار را تسهيل نموده و كار تيمي و ارزيابي ناظران خارجي را آسان و ممكن مي‌نمايد. اگر استفاده از UML در توليد نرم‌افزار در كشور به يك فرهنگ تبديل گردد، گام بزرگي به سوي دقت، كيفيت، مستندسازي و رعايت اصول مهندسي نرم‌افزار برداشته شده است.
فصل دوم : ASP.Net

مقدمه ای در باره سایت ها و اطلاع رسانی از طریق internet

گذار از عصر صنعتی (industry revolution)به دوران طلایی عصر اطلاعات(communication revolution) ، فضای جوامع اطلاعاتی (information society) را با تغییر روبرو کرده است . وقتی ابزارهای نوین در ارتباطات و اطلاع رسانی به خدمت شهروندان در می آیند ، باید منتظر تغییر در شیوه های زندگی روزمره بود. یکی از این تغییرات ، دگردیسی در گردشگری و تولد گردشگری مجازی است.
گردشگری مجازی (e-tourism) مقوله جالبی است که دو دهه از پدید آمدن آن نمی گذرد. گردشگری مجازی ، حضور در سرزمین دیجیتالی وب و مشاهده داده های صوتی ، متنی و تصویری از دنیای فیزیکی پیرامون ما است .
دور دنیا با یک کلیک ، آرزویی بود که امروزه از مرحله واقعیت به حقیقتی غیر قابل انکار مبدل شده است . بااستفاده از سایت های کاخ موزه ها ، اماکن باستانی جهان می توان به دنیایی اطلاعات متنی و تصویری از نمادهای تاریخ باستان دست یافت. برخی از پایگاه های دولتی در اینترنت ، امروزه سیستم های دوربین شهری خود را به سرزمین دیجیتال نیز پیوند داده اند.
حتی ، رزرو بلیط هواپیما ، هتل ، مسابقات بین المللی ورزشی و جشنواره های فرهنگی هنری جهانی ، امروز با رفتارهای سازمانی الکترونیکی همراه شده است . میلیون ها کاربر از سراسر جهان ، به دنبال برگزاری تابستانی مسابقات جام جهان در شهرهای آلمان ، امروزه از سایت های دولتی و غیر دولتی گردشگری این کشور استفاده می کنند.
پیشنهاداتی برای گسترش گردشگری مجازی در کشور در خاتمه ارائه می شود که عبارتند از :

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

دانلود فایل اصلی در قالب WORD DOC در لینک مستقیم زیر:
http://forum.a00b.com/upload/Uploads/636..._11_20.doc

[ali]

آشنايي با UML
زبان مدل سازي يكپارچه (UML) زباني است براي مشخص سازي ، مجسم سازي ، ساخت و مستند سازي دست آوردهاي سيستم هاي نرم افزاري و مدل سازي و كار و ديگر سيستمهاي غير نرم افزاري .
Uml مجموعه اي از بهترين تجربيات مهندسي كه موفقيتشان در مدل سازي سيستمهاي بزرگ و پيچيده به اثبات رسيده است را عرضه مي دارد.
تعريف UML شامل اسناد زير مي گردد :
معنا شناسي UML : كه مفاهيم غني و دستور نگارش وعلا ئم زبان مدلسازي يكپارچه را تعريف مي كند UMLبه وسيله بسته ها به صورت معماري گونه لا يه بندي و سازماندهي ميشود . در هر بسته عناصر مدل بر حست دستور نگارش (با استفاده از متن و عبارت زبان محدوديت شيء معروف به OCL )و معاني (با استفاده از متن دقيق) تعريف مي شوند .
راهنماي علائم UML : فكر و انديشه را تعريف مي كند و مثال هاي خوبي را ارائه مي كند. علائم UML نحو گرافيكي را براي بيان معاني توصيف شده توسط فرا مدل هاي UML ارائه مي كند.
توسعه ي UML براي فرايند شيءدر مهندسي نرم افزارو توسعه UML براي مدل سازي تچارت : اين توسعه هاي UML شامل توسعه خاص فرايند و توسعه خاص حوزه مسئله در UML برحسب مكانيزم هاي توسعه اي شان و آيكون نمودار فرايند مي گردد .
2) فراهم آوردن مكانيزم هاي توسعه و تخصيص براي بسط مفاهيم اساسي : بدين معنا كه در عين آنكه انتظار ميرود UML براساس نيازهاي جديد در حوزه هاي خاص جفت و جور شود نمي خواهد اجبار كند تا مفاهيم اساسي و مشترك براي هر حوزه جديدي دوباره تعريف شود و پياده سازي گردد. البته مفاهيم اساسي نبايد بيش از حد تغيير يابند. بنابراين كاربران نيازمندند كه قادر باشند : 1- مدل ها را با استفاده از مفاهيم اساسي بسازند بدون آنكه مكانيزم هاي توسعه را براي بسياري از برنامه هاي كاربردي نرمال بكار گيرند .
2- مفاهيم و علائم جديد را اضافه كنند البته براي مواردي كه توسط اصول پوشيده نشده باشند .
3- زماني كه هيچ اتفاق نظر روشني وجود ندارد تفاسير مختلف را از مفاهيم موجود انتخاب كنند .
4- مفاهيم، علائم و محدوديت ها را براي حوزه هاي كاربردي خاص مشخص سازند .
3) استقلال از زبان هاي برنامه نويسي خاص و فرايندها ي توسعه .
4) فراهم آوردن پايه و اصولي رسمي براي درك زبان مدل سازي كه براي اين منظور UML تعريف رسمي از قالب استاتيك مدل را با استفاده از نمودار كلاس ارائه مي كند اين نمودار ، نموداري مشهور و مورد قبول در سطح وسيع براي تعييين قالب يك مدل است UML همچنين محدوديت هايي را بيا ن ميدارد كه در قالب زبان دقيق طبيعي و عبارات زبان محدوديت شيء (OCL ) بيان مي شود .
5) تشويق به رشد بازار ابزارهاي OO .
6) حمايت و پشتيباني از مفاهيم توسعه سطح بالاتر نظير : همكاري ها ، چهارچوب ها ،الگوها و اجزاء .
7) مجتمع سازي بهترين تجربيات : UML بدنبال آن است كه بهترين تجربيات درصنعت
حوزه هاي مسئله ، معماري ها و … را يكجا بياورد .
محدوده UML
زبان مدل سازي يكپارچه UML زباني است براي مشخص سازي ساخت ،مجسم سازي و مستند سازي دست آوردهاي يك سيستم متمركز نرم افزاري اول آنكه اين زبان از مفاهيم OOSE,OMT,BOOCH كه متدولوژيهاي متداول OOميباشند متنج شده است . دوم ، UMLبر آنچه كه در حال حاضر توسط روش هاي موجور فابل انجام همتند ، بان شده است . سوم زبا ن مدل سازي يكپارچه بر يك زبان مدل سازي استانارد تمركز مي كند و نه يك فرآيند استاندادر اگر چه UMLبايستي در زمينه يك فرايند به كارگيري شود تجرته نشان ميدهد كه در سازمان هاي مختلف و با حوزه هاي مسئله متفاوت فرايندهاي متفاوتي مورد نياز است بنابراين تلاش بر اين است كه ابتدا بر يك فرامدل مشترك (كه معاني را يكپارچه ميكند )تمركز شود و در درجه دوم بر يك علامت گذاري مشترك (كه براي فرد استنباط اين معاني را فراهم ميكند )تمركز گردد مبدعين UMLبر فرايند توسعاي تاكيد ميكنند كه مورد كاربرد گرا معماري گرال و تكراري و افزايشي است .
UML يك زبان مدلسازي را مشخص مي كند كه اتفاق نظر جماعت شيگرا بر مفاهيم اساس مدل سازي است .
1) UMLبراي ايجار مدلها و نمرارهاي حوزه مسئله هيچ توصيه اي نميشود و اين تجربيات و يادگيري افراد است كه تشخيص استفاده از كدام نمودارها و مدل ها را به ايشان مي دهد دريك ديدگاه مدل سازي UML نمودارهاي گرافيكي زير را تعريف مي كند مورد كاربرد
نمودار مورد كاربرد diagram ) (use ca
نمودار كلاس (ClassDiagram)
نمودارهاي رفتار: (BehaviorDiagra
نمودارهاي حالت : (State Chart Diagram)
نمودار فعاليت : )Activity Diagram(
نمودارهاي تعامل Interaction Diagrams ))
نمودار توالي ((Sequence Diagram
نمودار همكاري ((Collaboration Diagram
* نمودارهاي پياده سازي) (Implementation Diagram
نمودار اجزاء (Component Diagram )
نموداراستقرار (Deployment Diagram)
اين نمودارها منظر گاه هاي مختلفي از سيستم تحت تحليل يا توسعه را فراهم مي آورند. مدل در حال مطالعه اين منظر گاه ها را يكپارچه مي كند به گونه اي كه يك سيستم متكي به خود تحليل و ساخته شود. اين نمودارها با پشتيباني مستندات ، دست آوردهاي اوليه اي مي شوند كه يك مدل ساز آن را ايجاد مي كند، اگر چه UML بيشتر توصيف و تشريح شده اند.
يك سوال كه مكررا پرسيده مي شود اين است كه چرا UML از نمودارهاي جريان داده معروف به حمايت نمي كند ؟ به طور ساده نمودارهاي جريان داده و ديگر نمودارهاي از اين نوع كه در UML قرار داده نشده اند ، با ديدگاه مستحكم شي گرا به روشني جفت و جور نمي شوند. نمودارهاي فعاليت بسيار بيشتر از آنچه كه افرااد از مي خواهند را برآورده مي كند. به علاوه موارد ديگر ، نمودارهاي فعاليت همچنين براي مدل كردن جريان كار مفيد هستند. مؤلفين UML در حال ايجاد نمودارهاي UML بر فراز همه پروژه هاي شي گرا هستندئ ، اما ضرورتا نيازي هم به نمودارهاي ديگر نيست . مبدعين UML معتقدند كه مجموعه اي از تكنيك هاي موفقيت آميز و عملي را كه در يك ديدگاه مستحكم و پا بر جا جفت مي شود ، تعريف كرده اند.

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

بسياري از سازما ن ها ، UML را به عنوان زبان متداول براي توليد دست آوردهاي پرروژه هايشان استفاده مي كنند، اما انواع نمودارهاي UML را در فرآيندهاي مختلف استفاده مي كنند. UML اساسا مستقل از فرآيند است ولي فرآيند استانداردي را نيز تعريف ميكند كه هدف UML نيست. فرآيندها بر اساس طبيعت شان بايستي براي سازمان ها ، فرهنگ ها و حوزه هاي مسئله دوخته شوند.

مقايسه UML با د يگر زبان هاي مدل سازي

UML بر اساس موفقيت هاي سه روش مدل سازي OOSE , OMT , BOOCH و ايجاد شده است و كاربران هر يك از اين سه روش ،‌ مي توانند به راحتي از UML استفاده نمايندت. UML براي استفاده شدن توسط كاربران روش هاي ديگر نيز آماده و آسان مي باشد.
UML هم اكنون روشن تر ، مستحكم تر و يك شكل تر از Booch,OMT.,OOSE و ديگر روش ها مي باشد . اين بدين معنا است كه در انتقال به UML اين ارزش وجود دارد كه به شما اجازه مي دهد تا در پروژه ها چيزهايي را مدل سازي كنيد كه قبل از اين انجام شدني نبودند.
كاربران روش هاي موجود، تغييرات اساسي و زيادي را در علامت گذاري تجربه خواهند كرد. اما اين به معناي نياز به يادگيري مجدد با تعريف مجدد مفاهيم حاضر نيست. كاربران هر يك از روش هاي OO مي توانند سرعت زيادي را در يادگيري شان انتظار داشته باشند. تكنيك هاي پيشرفته نظير به كارگيري كليشه ها و خواص ، نيازمند مطالعه هستند. البته اين موارد نيز در زمان برخورد با مسئله ، مورد نياز مي شوند.
ويژگي هاي جديد UML
هدف كليه تلاش هاي يكپارچه سازي كه در UML به كار مي رود ، حفظ سادگي است به گونه اي كه عناصر غير كاربردي روش هاي OMT, Booch,OOSE طرد شوند و عناصر مؤثر از روش هاي ديگر به آن اضافه گردند.
مفاهيم جديد زيادي در UML وارد شده اند ، نظير : مكانيزم هاي توسعه شامل كليشه ها ، مقادير ضميمه و محدوديت ها ، توزيع و همروندي (‌به عنوان مثال برا ي مدل سازي CORBA,Active/DCOM الگوها / همكاري ها ، نمودارهاي فعاليت (‌براي مدل سازي فرآيند كار ) ، پالايش (‌براي اجرا يا به كارگيري ارتباطات بين سطوح مجرد ) واسطه ها و اجزاء ، و يك زبان محدوديت .
بسياري از اين مفاهيم در نظريه ها و روش هاي انفرادي مختلف وجود داشتند و UML آنها را به دورن انسجام خودش كشاند . به علاوه اين تغييرات اساسي ، بهبودهاي ريز ديگري نيز بر اساس مفاهيم و علائم ،OOSE ,Booch.OMT وجود دارد. بنابراين بسياري از مفاهيم و علائم UML را خود نويسندگان آن ايجاد نكرده اند بلكه نقش آنها ، جمع آوري مناسب ، انتخاب و يكپارچه كردن اين مفاهيم و علائم در UML بو ه است . در اين زمينه ، موارد زير قابل ذكر است :
• نمودارهاي مورد كاربرد مشابه آنچه درOOSE ارائه شد مي باشند.
• نموداراهاي كلاس ، ذوب شده Booch،OMT و ديگر روش ها است. كليشه ها ، محدوديت و مقادير ضميمه مفاهيمي هستند كه قبلا در زبان هاي مهم مدل سازي وجود نداشتند و اكنون در UML ظهور كرده اند.
• نمودارهاي حالت اساسا مبتني بر جداول حالت David Harel مي باشند. نمندار فعاليت كه مفاهيم مشابهي را بيان مي دارد ، مشابه نمودئار جريان كار است كه توسط بسياري از منابع پيش از OO ايجاد گرديدند. شركت Jim Odell , Oracle سبب ساز ورود نمودارهاي فعاليت به UML بودند.
• نمودارهاي توالي در بسياري از روش هاي OO تحت نام هاي متفاوت (نظير : تعامل ، ردگيري پيام و ردگيري واقعه ) و نيز روزهاي قبل از OO يافت مي شدند. نمودارهاي همكاري از Booch ( با نام Object Diagram) و Fusion ( با نام Object Interaction Graph) ، و تعدادي منابع ديگر پذيرفته شدند.
• نمودارهاي پياده سازي (‌شامل نموداراهاي اجزاء و استقرار ) از نمودارهاي ماژول و فرآيند در Booch مشتق شدند، اما هم اكنون اين نمودارها به جاي آنكه ماژول گرا باشند ، اجزاء گرا هستند و خيلي بهتر به هم متصل مي شوند
• كليشه ها يكي از مكانيزم هاي توسعه هستند و مفاهيم فرامدل را بسط مي دهند. آيكون هاي تعريف شده كاربر با كليشه هاي موجود متناظر مي شوند تا UML را براي فرآيندهاي مشخصي خياطي كنند.
• زبان محدوديت شي (OCL) به وسيله UML استفاده مي گردد تا مفاهيم را مشخص سازد و به عنوان زباني براي بيان مدل سازي جاري به كار گرفته شود. OCL يك زبان بياني است كه در روش Syntropy ريشه دارد و به وسيله زبان هاي بياني ، در روش هاي ديگر نظير Catalysis مورد تاكيد واقع مي شود.
• هر يك از اين مفاهيم ، پيش فر ض ها و اثرات بسيار زياد ديگري هم دارند. OMG اعتراف مي كند كه هر فهرست خلاصه اي از اين اثرات ، ناقص است . UML محصولي از يك تاريخ عظيم انديشه ها در علم كامپيوتر و ناحيه مهندسي نرم افزار است.
UML ، گذشته ، حال و آينده

UML به وسيله شركت نرم افزاري (Ration So ftware ) و شركايش ايجاد شد . UML جانيشين هاي زبان هاي مدل سازي اي است كه در ،‌ Booch Reumbugh // OOSE Jacoboson و روش هاي ديگر يافت مي شوند. بسياري از شركت ها در حال جاي دادن UML در خود به عنوان يك استاندارد در فرآيند توسعه و محصلوات شان هستند ، كه نظام هايي نظير : مدل سازي كار ؤ مديريت نيازمندي ها ؤ تحليل و طراحي ؤ برنامه نويسي و تست را مي پوشاند.
UML0.8-0.91
زمينه UML
زبان هاي مدل سازي شي گرا از اواسط دهه 1970 آغاز به ظهور كردند و از اواخر دهه 1980 ، متدولوژيست هاي زيادي ، رويكردهاي متفاوتي را براي تحليل و طراحي شي گرا بيان كردند. تكنيك هاي متعدد ديگري نيز بر اين زبان ها اثر گذاشتند ، نظير : مدل ساز ي ارتباط موجوديت ، زبان SDL و ديگر تكنيك ها .
تعداد زبان هاي مدل سازي تعريف شده در دوره زماني بين 1989 تا 1994 ، از 10 عدد به بيش از 50 عدد رشد كرد. بسياري از كا ربران روش هاي OO در يافتن يك زبان مدل سازي كه رضايت كامل آنها را جلب كند ، با مشكل مواجه بودند و از طرفي در حال سوخت رساني به جنگ روش ها بودند. از اواسط دهه 1990 ، تكرار جديدي از اين روش ها آغاز به ظهور كرد، نظير Booch 93 ، تكامل مستمر OMT/Rumbugh و Fusion . اين روش ها آغاز به داخل كردن تكنيك هاي ديگران به روش هاي خودشان كردند و روش هايي نظير Booch93 , OMT-2.OOSE/Jacobson ايجاد گرديد . هر يك از اين روش ها نيز به نوبه خود يك روش كامل بود.
Jacobson, Rumbaugh ,Booch نيروهايشان را به هم پيوستند توسعه UML در اكتبر 1994 زماني كه Jim Rumbaugh,Grady Booch از شركت Rational Software Corporation كارشان را براي يكي كردن روش هاي Booch و OMT آغاز كردند ، شروع گرديد . در اكتبر 1995 نسخه 8 ، از Unified Method (كه همين طور نام گذاري شده بود ) بيرون آمد . در پائيز 1995 ، Ivar Jacoboson و شركت Objectory اش به Rational پيوستند. و روش OOSE را نيز در آن ادغام كردند. هم اكنون از نام Objectory براي توصيف فرآيند UML استفاده مي شود.
تلاش هاي Jacobson.Rumbaugh,Booch در اصلاح و انتشار اسناد 0.9-0.91 در ژوئن و اكتبر 1996 به نتيجه رسيد. در سال 1996 ، نويسندگان UML از جامعه دعوت كردند و بازخورهايي را نيز دريافت كردند. اگر چه آنها اين بازخورها را يكپارچه كردند ، اما توجه متمركز بيشتري هنوز مورد نياز بود.
UML 1.0-1.1 و شركاي UML

در سال 1996 مشخص شد كه سازمان هاي متعدد ، UML را از ديد استراتژيك مي بينند. درخواست پيشنهادي كه از سوي OMG منتشر شد ، كاتاليزوري را فراهم كرد تا اين سازمان ها براي توليد يك پيشنهاد به درخواست فوق بپيوندند. Rational ، كنسرسيوم شركاي UML را با سازمان هاي چندي ايجاد كرد تا منابع شارن را براي كار كردن بر روي تعريف UML 1.0 متمركز كنند.
بيشترين مشاركت كنندگان در تعريف UML1.0 عبارت بودند از :
ICON,IBM , IntelliCrop > I-Logix, HP, Digital Equipment Corp.
Tl, Rational Software, Oracle, Microsoft, MCI Systembouse, Computing Unisys. اين همكاري ، UML 1.0 را توليد كرد كه يك زبان مدل سازي با تعريف ، بيان قدرت و كاربرد عمومي خوبي بود. اين كار در ژنوايه 1997 به عنوان عكس العمل اوليه به درخواست فوق به وسيله OMG پذيرفته شد.
در ژانويه 1997 ، شركت هاي ‍‍‍Ptech, platinum Technology و Taskon & IBM & ObjecTime SofteamوReich Technologies نيز يك پيشنهاد مجزا را به OMG ارائه كردند . اين شركت ها به شركاي UML پيوستند تا افكارشان را سهيم كنند و با يكديگر UML 1.1 را ايجاد نمايند. تمركز به UML 1.1 بهبود وضوح و روشني مفاهيم UML 1.0 و نيز شركت دادن شركاي جديد در اين همكاري بود. اين نسخه نيز توسط OMG به تصويب رسيد.

UML حال و آينده
UML غير خصوصي است و براي همه باز است . UML نيازهاي كاربران و اجتماعات علمي را نشانه مي رود. بسياري از متدولوژيست ها ، سازمان ها و توليد كنندگان ابزار ، خود را در استفاده از آن متعهدا كرده اند. از آنجا كه UML مفاهيم و علائم مشابهي از Booch,OMT,OOSE و ديگر روش هاي مهم را ارائه مي كند و با وارد كردن شركاي UML و باز خور عمومي به خود ، شخصيت قانوني ارائه كرده است ، انتخاب وسيع UML بايستي كار درستي باشد.
دو جنبه يكپارچگي كه زبان مدل سازي يكپارچه (UML ) به دست آورده است عبارتند:
1) UML به صورت مؤثري به بسياري از اختلاف ها پايان مي دهد كه غالبا هم در زبان هاي مدل سازي روش هاي قبلي ظهور كرده بود.
2) UML ، ديدگاه ها را در انواع مختلف سيستم ها ( كسب و كار در مقابل نرم افزار ) ، مراحل توسعه (تحليل نيازمندي ها ، طراحي و پياده سازي )، و مفاهيم دروني ، يكپارچه مي كند.
3) استاندارد سازي UML
بسياري از سازمان ها ، UML را به عنوان استاندارد سازماني شان تاييد كرده اند ، به دليل آنكه UML از زبان هاي مدل سازي كه توسط روش هاي مهم OO ارائه شده اند منبعث شده است . UML براي استفاده روزمره و همگاني بسيار مطلوب است.
صنعتي سازي
بسياري از سازمان ها و تامين كنندگان جهان ، UML را پذيرفته اند. تعدادي از سازمان هاي تاييد كننده UML انتظار مي رود تا در آينده رشد قابل توجهي بنمايند. اين سازمان ها ، استفاده از UML را به وسيله ايجاد اسناد قابل دسترس و ساده تشويق مي كنند. همچنين با تشويق متدولوژيست ها ، تامين كنندگان ابزار ، سازما ن هاي آموزشي و نويسندگان به انتخاب UML در كارهايشان ، مسير صنعتي سازي آن را هموارتر مي نمايند.
تكامل UML آينده

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

[ali]

فرآيند توسعه
مقدمه
UML يك زبان مدل سازي است و نه يك فرآيند و بر اين اساس هيچ گونه علامت گذاري نيز براي فرآيند توسعه و ايجاد سيستم ارائه نمي دهد. سه مبدع UML ، فرآيندي را كه در ابتدا به Objectory و هم اكنون به Unified Process معروف است را ارائه كرده اند. اين فرآيند در شركت Rational از سال ها قبل در حال اجرا است . البته در ايجاد يك سيستم نرم افزاري نمي توان فقط يك فرآيند را مطرح كرد. عوامل مختلفي كه مي توانند در فرآيند توسعه نرم افزار اثر گذار باشند ، موارد متعددي هستند ، مواردي نظير : نوع نرم افزار (‌بيلادرنگ ، سيستم اطلاعاتي ، محصول روميزي ، بازي كامپيوتري ) ، اندازيه (‌يك نفر توسعه دهنده ، گروه كوچك ، گروه بيش از 100 نفر ) و غيره .
بنابراين براي درك بهتر خواننده كمي هم از Unified Pricess مي گوييم. فرآيند توسعه ، فرآيندي تكراري و افزايشي است و در چهار مرحله به انجام مي رسد (شكل 1-7 ) . هر مرحله مي تواند از چند تكرار تشكيل شود. در هر تكرار ، قدم هاي چرخه عمر وجود دارد. يعني قدم هاي تعيين نيازمندي ها ، تحليل ، طراحي ، پياده سازي و تست در هر تكرار انجام مي شود.
تعيين اساس كار و محدوده پروژه و اخذ تعهد از كاربر براي ادامه كار در اولين مرحله يعني مرحله شروع انجام ميشود.
جمع آوري مفصل نيازمندي ها و تحليل و طراحي سطح بالا براي ايجاد خطوط پايه معماري در مرحله دوم يعني مراحل تفضيل انجام مي گردد.
در عين حال كارهايي را مجبوريد به آخرين مرحله بياندازيد، به عنوان مثال بتاتست ، آموزش كاربر ، و … به آخرين مرحله يعني مرحله انتقال سپرده مي شود.
ساخت نرم افزار كه عمده وقت پروژه را به خود اختصاص مي دهد سومين مرحله فرآيند توسعه است. كليه مدل هاياساس و ريز تا حد پياده سازي در اين مرحله ساخته مي شود.
هر يك از مراحل مي تواند داراي چندين تكرار باشد. اما در شكل 1-7 اين تكرار را فقط برا ي مرحله سوم يعني مرحله ساخت نشان دادم. فرض بر اين است كه در هر تكرار ، حداقل چهار قدم چرخه عمر وجود دارد. يعني قدم هاي تحليل ، طراحي ، پياده سازي و تست در هر تكرار انجام مي شود . اين تكرارها به وسيله شكل هاي7-2 و 7-3 نيز قابل مشاهده است . در شكل 7-3 قدم هاي بيشتري براي چرخه عمر ذكر شده است كه در صورتع علاقه مندي خواننده مي تواند به سايت شركت Rational مراجعه كند و توضيحات بيشتري را ببيند.

مرحله شروع
در اين مرحله ممكن است به امكاان سنجي ، تحليل مقدماتي براي به دست آوردن اندام پروژه و … نياز شود. اين مرحله با توجه به پروژ ه مي تواند خيلي كوتاه و يا طولاني باشد. اساس كار و تعيين نيازمندي هاي كلي كاربر و نيز محدوده و مرز سيستم پروژه در اين مرحله انجام مي شود. وقتي كه از نقطه نظرات جدي كاربر آگاه شديم، مجوز ادامه كار را از او مي گيريم. اين مرحله از ديد كاربر نبايد چندان طولاني شود.

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

انواع ريسك هاي ممكن مي تواند به صورت زير دسته بندي شود.:
1 – ريسك نيازمندي ها : احتمال آنكه نيازمندي را خوب تشخيص ندهيم. كاربر چيزي بگويد و چيز ديگري فكر كنيم. نقطه شروع تعيين نيازمندي ها ، تعيين موارد كاربرد هستند.
2 – ريسك فني : آيا مي توانيم طراحي OO كنيم ؟ آيا با Web,java و بانك اطلاعاتي مي توانيم خوب كار كنيم ؟ به عبارتي احتمال انتخاب معماري فني مناسب چقدر است ؟
3 – ريسك مهارت ها : آيا نيروي متخصص داريم ؟ احتمال آنكه تخصص هاي لازم در پروژه را در دسترس داريم يا نه ، تحت عنوان ريسك مهارت ها مطرح مي شود.
4 – ريسك شناسي : آيا نيروهاي اثر گذار بيروني وجود دارند ؟ يعني چقدر احتمال دارد كه از نظر سياسي ، پروژه تحت تاثير نيروهاي بيروني قرار گيرد؟


ريسك نيازمندي ها
نقطه شروع تعيين نيازمندي ها ، تعيين موارد كاربرد است . مورد كاربرد تعاملي نوعي اس كه كاربر با سيستم دارد براي آنكه به هدفي دست يابد. نقطه اساسي در هر مورد كاربرد اينست كه هر مورد كاربرد ، يك وظيفه با اهميت براي كاربر است . مهم ، كشف و شناسايي هر چه بيشتر موارد كاربرد بالقوه و مهم در سيستم است. موارد كاربرد خيلي ريز نمي شوند . ما بهتر است قبل از ترسيم نمودار مورد كاربرد ، نمودارهايي را كه مدل حوزه مسئله را نشان مي دهد ترسيم كنيم. مدل حوزه مسئله به مدل هايي اطلاق مي شود كه به حوزه مسئله و جهان واقعي بر مي گردد و به نوعي حوزه مسئله مورد مطالعه ما را توصيف مي كند. اين مدل مي تواند هر نوع شكل ، نمودار ، تصوير ، جمله ، متن ، جدول ، ماكت و …. باشد تنها چيزي كه از آن انتظار داريم آن است كه بتواند تصوري كلي از ماهيت سيستم تحت مطالعه و عناصر آ را در اختيار ما قرار دهد.
انواع مدل ها

مدل هاي مختلفي را مي توان ترسيم نمود :
1) مدل هاي حوزه مسئله و موارد كاربرد : اين مدل ها ، نيازمندي هاي وظيفه هاي سيستم را نشان مي دهند. با ترسيم اين مدل ها نيازمندي هاي كاربر شناسايي مي گردد.
2) مدل هاي تحليلي : كاربرد خاص و تفصيل هر يك از نيازمندي هاي كاربر توسط مدل هاي تحليلي نشان داده مي شود. اين مدل ها هر مورد كاربرد را به صورت مفصل تر نشان مي دهند.
3) مدل هاي طراحي : كه ساختار ايستاي سيستم را به صورت زير سيستم ، كلاس ها و واسط ها براي پياده شدن بر اساس زير ساخت هاي كاري نشان مي دهند.
مدل هاي حوزه مسئله حتما قبل از مورد كاربرد ساخته مي شود تا با فرهنگ حوزه مسئله آشنا شويم.
دو روش بر اساس UML مي تواند براي ايجاد مدل هاي حوزه مسئله پيشنهاد شود:

1) نمودارهاي كلاسي كه از چشم انداز مفهومي ترسيم شده اند و بيشتر واژه ها و مفاهيم خبره هاي حوزه مسئله و نحوه ارتباط مفاهيم با يكديگر را نشان مي دهند. توجه شود كه در الگوي حوزه مسئله بيشتر ، ساختا ر و فرهنگ لغات مسئله مورد توجه است در حالي كه در مورد كاربرد ، بيشتر رفتار و فعاليت هاي حوزه مسئله مورد توجه قرار مي گيرد.
2) نمودارهاي فعاليت كه به عنوان تكميل كننده نمودارهاي كلاس ، توصيف كننده جريان كار سيستم هستند.
3) نكته مهم نمودارهاي فعاليت اينست كه فرآيندهاي موازي سيستم در آن كشف مي شوند و توالي غير ضروري فرآيندها مشخص مي گردند. برخي افراد به جاي نمودار فعاليت ، نمودار تعالم را مي پسندند.
4) بعد از الگوي حوزه مسئله ، نوبت به موارد كاربرد مي رسد. همانطور كه قبلا نيز اشاره شد در مورد كابرد نيازمندي هاي سيستم شناسايي مي گردند سپس همه نمودارها را در قالب يك نمودار حوزه مسئله مي آوريم و با يك يا دو نفر از متخصصين خود حوزه مسئله تبا دل نظر مي كنيم حال يك الگوي حوزه مسئله كه همه نيازمندي ها را نشان مي دهد در دست داريم. سپس به ساخت كلاس ها و ورود به مرحله ساخت مي پردا زيم. حداقل گروه ايجاد كننده مدل حوزه مسئله يك يا دو توسعه دهنده و يك يا دو خبره مسئله و حداكثر 4 نفر براي اين كار مناسبند. ايجاد نمونه اوليه نيز وسيله مناسبي در محقق سازي بهتر اين مرحله است . البته همه اين نكات صرفا يك توصيه است.
ريسك فني

در بررسي فني براي ايجاد نرم افزار ، لازم است تا تبعات به كار گيري تكنولوژي بررسي شود. به عنوان مثال از چه كامپايلري استفاده شود؟ (C++,Delphi,….. ) ؤ موتور پايگاه داده چيست ؟ (Oracle, SQL,…. ) . همچنين اثر متقابل اين انتخاب ها بر يكديگر مهم است. در اين بررسي لازم است تبعات سخت افزاري اين انتخاب بر يكدگير مهم است در اين بررسي لازم است تبعات سخت افزاري اين انتخاب نيز بررسي شود. به هر حال تصميمات طراحي معماري مهم است . در اين ميان تمركز بر نواحي اي كه در آينده به سختي قابل تغيير باشند مهمتر است . براي كشف اين نقاط نيز موارد كاربرد مناسب هستند. همچنين نمودارهاي كلاس و تعامل براي نمايش اينكه اجزاء چگونه با هم مرتبط مي شوند مفيد هستند. نمودارهاي بسته نيز مي توانند تصوير سطح بالايي از اجزا را نشان دهند. همچنين نمودارهاي استقرار مي توانند منظر گاهي را از اينكه چگونه قسمت هاي مختلف سيستم توزيع شده اند به دست دهند. براي كسب اطلاعات بيشتر به فصل هاي مربوطه مراجعه كنيد.
ريسك مهارت
براي كسب مهارت در مبحث شي گرا ، بهترين راه استفاده از مربي است كه در طول پروژه در كنار شما قرار گيرد اگر چنين حالتي امكان نداشته باشد استفاده از مربيان تمام وقت يا پاره وقت نيز براي بازنگري پروژه مفيد است. اگر اين حالت نيز امكان نداشت، هر ماه يا هر دو ماه با دعوت از يك مربي خبره مدل هاي خود را بازنگري كنيد. توصيه مي شود هر ماه يك كتاب تكنيكي بخوانيد حتي بهتر است كه به صورت گروهي مطالعه كنيد و به تبادل نظر بپردازيد .
الگوها نيز ابزا رهاي مناسبي براي آموزش و اعتبار سنجي مدل هاست. بنابراين لازم است از آخرين وضعيت الگوها باطلاع باشيد.
معماري خط پايه

نتايج و خروجي مرحله تفصيل ، معماري خط پايه است اين معماري شامل موارد زيرمي
گردد.
• فهرست موارد كاربرد كه نيازمندي هاي سيستم را بيان مي كند
• مدل حوزه مسئله كه درك شما را از سيستم نشان مي دهد و نقطه شروع كلاس هاي اساسي حوزه مسئله است.
• ساختار تكنولوژي انتخاب شده كه تكنولوژي پياده سازي و جفت و جور شدن عناصر آنها را توصيف مي كند.
اين معماري ، پايه اي براي توسعه است . اصطلاحا به اين معماري ، طرح اوليه مراحل بعد گفته ميشود.
چه زماني مرحله تفصيل پايان مي يابد؟
دو رخداد مهم براي نمايش دادن پايان مرحله تفصيل عبارتند از :
1) تقريبا با اطمينان بتوان براي آينده پروژه تخمين زد.
2) شناسايي همه ريسك ها و آمادگي براي حل هر كدام از آنها انجام شده باشد.
برنامه ريزي

اساس برنامه ريزي تعيين تكرارهاي ساخت و تخصيص مورد كاربرد به هر تكرار است. براي اين منظور قدم هاي زير پيشنهاد مي شود:
قدم اول : طبقه بندي موارد كاربرد : كاربر بايستي سطح اولويت هر يك از موارد كاربرد را مشخص كند. معمول مي توان اين كار را در سه سطح بالا ، متوسط و پايين انجام داد
قدم دوم : در نظر گرفتن ريسك معماري براي هر مورد كاربرد : توسعه دهنده ، اين ريسك را در سه سطح مشخص مي كند . اين ريسك عبارت است از ريسكي كه اگر اين مورد كاربرد در پروژه براي مدتي به تعويق افتد ، تكميل كارهايي كه تاكنون انجام شده اند ، چقدر باعث دوباره كاري مي گردد؟
قدم سوم : در نظر گرفتن ريسك برنامه ريزي براي هر مورد كاربرد : كه عبارت از ميزان اطمينان توسعه دهنده نسبت به تخمين كار مورد نياز براي هر مورد كاربرد است.
طول زماني كه هر مورد كاربرد بر حسب نفر ـ‌ هفته را با فرض انجام تحليل ، طراحي ، كدنويسي ، تست ، مجتمع سازي و مستند سازي به دست آوريد. نكته قابل توجه اينست كه تخمين زدن را بايد كارشناس توسعه انجام دهد نه مدير. اگر برخي از موارد كاربرد داراي ريسك بالا بودند نياز به مرحله تفصيل دوباره ، براي اين موارد كاربرد پيش مي آيد.
قدم چهارم : تعيين طول تكرار براي كل پروژه : لازم است يك طول ثابت زماني براي كليه تكرارها در كل پروژه مشخص گردد. اين طول زماني بايستي باندازه كافي بزرگ باشد تا بتوانيد چند مورد كاربرد را در هر تكرار انجام دهيد. به عنوان مثال براي زبان Smalltalk ميتوانيد دو تا سه هفته و براي c++ شش هفته يا بيشتر باشد. در محاسبات لازم است اين گونه در نظر بگيريد كه از 50 % توان يك كارشناس توسعه استفاده مي شود ، سپس طول تكرار را در نصف تعداد توسعه دهنده ها ضرب كنيد ، نتيجه به دست آمده ، مقدار كار توسعه را براي هر تكرار مشخص مي كند. براي نمونه با 8 توسعه و طول تكرار 3 هفته اي
در هر تكرار (12 = 8 * 3 * 1.2 ) نفر – هفته در هر تكرار داريم.
جمع كل زمان موارد كاربرد را بر مقدار مورد نياز در هر تكرار (عدد به دست آمده در مرحله قبل ) تقسيم كنيد و با عدد يك جمع كنيد ، عدد به دست آمده اولين تخمين شما از تعداد تكرارا مورد نياز در پروژهتان است. عدد يك براي اطمينان بيشتر به مقدار فوق افزوده مي شود.
قدم پنجم : تخصيص موارد كاربرد به تكرارها: بر اساس اولويت هايي كه قبلا توضيح داده شد، در هر تكرار ، تعدادي مورد كاربرد قرار دهيد. ابتدا موارد كاربرد با اولويت بالاتر را به تكرارها تخصيص دهيد. براي پيش بيني مقدار زمان مورد نياز در مرحله انتقال معمولا 10 % تا 35 % از مرحله ساخت را به عنوان تخمين مرحله انتقال قرار مي دهند . همچنين 10% تا 20 % از مرحله ساخت را براي پيشامدهاي اتفاقي قرار ميدهند.
برنامه اي كه به روش فوق به دست مي آيد و با تبادل نظر كاربر و كارشناس توسعه ايجاد مي شود به برنامه توصيه اي معروف است .
بنابراين ، موارد كاربرد پايه هاي برنامه ريزي هستند كه UML نيز بر آنها تاكيد زيادي دارد.
مرحله ساخت
در مرحله ساخت ، سيستم در طي يك سري تكرار ايجاد مي شود در هر تكرار نيز تأييد كاربر اخذ مي شود . هدف از اين فرايند كاهش ريسك است .


معمولا تست ها را نيز به دو دسته تقسيم مي كنند.

1) تست واحد : كه به وسيله كارشناس توسعه انجام مي شود .
2) تست سيستم : كه به وسيله گروه تست بيروني انجام مي شود اين گروه بايد به ديديك جعبه سياه به برنامه اصلي نگاه كند .
دسته بندي مجدد
وقتي تابعي را به برنامه اي اضافه مي كنيد چون از قبل براي حضور آن پيش بيني نكرده ايد برنامه ازكيفيت خوبي برخوردار نخواهد شد .براي جلوگيري از خراب شدن كيفيت برنامه دو راه وجود دارد :
1) طراحي دوباره برنامه و كدنويسي كامل براي طراحي جديد
2) اضافه كردن به برنامه موجود و اصلاح و تطبيق آن با برنامه
قدم هاي دسته بندي مجدد

تغييرات دسته بندي مجدد معمولا قدم هاي كوچكي دارد : تغيير نام يك متد ، انتقال يك صفت از كلاسي به كلاس ديگر ، تفكيك كردن متدهاي مشابه از كلاس ها و قرار دادن در يك فوق كلاس و…

نكاتي در مورد دسته بندي مجدد

1) دسته بندي مجدد واضافه كردن به كد را هم زما ن ا نجام ندهيد .
2) قبل از دسته بندي مجدد از تست برنامه مطمئن شويد .
3) ابتدا خوب فكر كنيد و صفات مناسب را جابجا كنيد و موارد مشابه را در فوق كلاس ها قراردهيد .
چه وقت دسته بندي مجدد كنيم ؟
1) وقتي براي اضافه كردن وظيفه اي ، به يك كد قديمي برمي خوريم كه مشكل اضافه كردن كد ايجاد مي شود .
2) وقتي فهميدن كد موجود ، سخت است .
همه تكنيك هاي UML در مرحله ساخت مفيد هستند . برخي از نمودارها كه استفاده فراوان تري دارند در زير توضيح داده مي شود .
1) از نمودار مورد كاربرد براي تعيين محدوده مورد نظرتان استفاده كنيد .
2) نمودار كلاس مفهومي براي درك مفاهيم درون مورد كاربرد مفيد است .
3) نمورار فعاليت را براي تشخيص جريان كار عناصر درون مورد كاربرد مفيد است .
قدم بعدي ،تحليل اين نمودارها و اصلاح آن با كمك و نظر كاربر است . در اين مرحله به نظر كاربر بسيار اهميت داده ميشود و برون نظر او تصميم گيري كردن كار نادرستي است.
براي ورود به طراحي ترسيم نمودار كلاس از چشم انداز تشخيصي براي آنكه كلاس را با جزئيات بيشتر ببينيم مفيد است . نمودارهاي تعغامل براي نمايش اينكه چگونه كلاس ها با هم تعامل ميكنند تا مورد كاربرد را پياده كنند ارزشمند هستند
براي ترسيم نقشه اي منطقي از سيستم از نمودارهاي بسته استفاده كنيد . اين نمودار نقشه منطقي سيستم ووابستگي بين آنها را به خوبي نشان ميدهد .



الگو ها

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

مرحله انتقال

پس از همة تكرارها هنوز يك قدم باقي مانده است و آن مرحله انتقال است . بنابراين پس از همه تكرارها گروه توسعه دهنده به پايان كد نويسي مي رسند . و آماده اند تا محصول را به كاربر تحويل دهند .
بهينه سازي ، كارايي را بهبود مي بخشد . بهينه سازي براي آن است كه سرعت سيستم را در جهت رفع نيازمندي هاي كاربر ، به اندازه كافي بالا ببرد . در طول مرحله انتقال ، اضافه كردن وظيفه اي به سيستم وجود ندارد بلكه حداكثر براي رفع اشكال سيستم اين مورد مي تواند بروز كند . مثال خوبي از مرحله انتقال فاصله زماني مابين محصول بتا و محصول نهايي است . در زمينه فرآيند مراجع (Booch-94 ) و (Jacobson –99 ) مناسب هستند .
مرور

در ايجاد يك مدل شيء گرا مي توان مدل را براساس سه ديدگاه يا چشم انداز ترسيم كرد كه عبارتند از : مفهومي ، تشخيصي و پياده سازي . بسته به آن كه ترسيم كننده مدل ، با چه ديدگاهي در حال ترسيم مدل است جزئيات درون مدل كمتر يا بيشتر مي باشند .
ديد عميق تر نسبت به سيستم و اينكه در هر مورد كاربردي چه اشيائي با هم در ارتباط هستند از طريق نموداركلاس فراهم مي آيد در ابتدا بهتر است كه نمودار كلاس را از ديدگاه يا چشم انداز مفهومي ترسيم كنيد دراين ديدگاه در حال ترسيم نموداري هستيد كه زبان كاربر را نمايش مي دهد .
همچنين براي آنكه جريان كاري سيستم كاربر را درك كنيد و بفهميد كه براي هر مورد كاربرد از چه فعاليت هايي و با چه ترتيبي استفاده مي گردد، نمودار فعاليت ابزار مناسبي است .
در پروژه هاي پيچيده و بزرگ تحليل گر يا مدير پروژه براي آنكه بتواند سيستم را خيلي سريع مرور كند و از پيشرفت امور با خبر شود و نيز براي آنكه كنترل مدل آسانتر و درك آن ساده تر شود نياز به ابزاري است تا اين پيچيدگي را مديريت كند . براي اين منظور نموداربسته ها وسيله اي مناسب است .
مجموعه اي از كلاسها كه با يكديگر ارتباط تنگاتنگ دارند را در يك بسته قرار مي دهيم و اين كار را تكرا ر مي كنيم در نهايت به عنوان مثال از يك نمودار كلاس كه داراي 100 كلاس مي باشد به يك نمودار بسته مي رسيم كه از 10 بسته تشكيل شده است اين مديريت پيچيدگي براي تمام عناصر درون مدل UML نظير : مورد كاربرد ، نمودارفعاليت نمودار حالت و … كاربرد دارد و تنها مختص كلاس نيست .
الگوها نيز ابزار مناسبي هستند تا بتوا نيد ايده هاي اساسي سيستم را بيان كنيد الگو كمك مي كند تا ارزيابي خوبي از طرح و مدل تان بيان كنيد . آنها براي توصيف طرح هايي كه پذيرفته نمي شوند نيز مفيد هستند .
UML يك زبان مدل سازي است وفارغ ازفرايند و متدولوژي است .UML هيچ توصيه اي
به روش به كارگيري خود نمي كند و به همين دليل است كه سه مبدأ آن را با عنوان زبان مدل سازي نام مي برند و نه روش يا فرايند .
اما از آنجا كه به هرحال ايجاد هر مدلي مبتني بر يك متدولوژي يا فرايند خواهد بود ، سه مبدع UMLكتابي نيز براي بيان فرايند با استفاده از UML به چاپ رسانده اند و در آن متذكر شده اند كه براي استفاده از UMLچه فرايند و روشي را به كار مي گيرند .

[ali]

نمودارهاي UML
UML به افراد اجازه مي دهد تا چندين نوع مختلف از نمودارهاي بصري را به وجود آورند كه جنبه هاي مختلف سيستم را نمايش مي دهد . Rational Rose از ايجاد اكثر اين مدلها ، همانطور كه در زير آمده ، پشتيباني مي كند .
- نمودار Use Case
- نمودارهاي Sequence(توالي)
- نمودار Collabration(همكاري)
- نمودار Class (كلاس)
- نمودار State Transition (حالت)
- نمودار Deployment
اين نمودارهاي مدل ، جنبه هاي مختلف سيستم را نشان مي دهند . مثلاً نمودار Collaboration (همكاري محاورات ضروري ميان آبجكت ها را نشان مي دهد ، به اين منظور كه تعدادي از توابع سيستم را به انجام برساند . هر نمودار يك هدف و يك شنوندة در نظر گرفته شده دارد .


نمودارهاي Use Case :
نمودارهاي Use Case محاورات ميان Use Case ها را نشان مي‌دهند ، كه عمليات سيستمي و عامل ها (Actor) كه نشان دهندة افراد يا سيستم هايي كه اطلاعات را براي سيستم فراهم كرده و يا از آن دريافت مي كنند را نمايش مي دهند . مثلاً نمودار Use Case سيستم Automated Teller Machine در شكل نشان داده شده است .

نمودار Use Case محاورات ميان Use Case ها و عامل ها را نشان مي دهند ،
Use Case‌ها درخواستهاي سيستم را از ديد كاربرد نشان مي دهند ، بنابراين
Use Case ها عملياتي هستند كه سيستم فراهم مي كند . عامل در واقع نگهدارنده پول (بانكدار) يك سيستم هستند . اين نمودارها نشان مي دهند كه چه عامل هايي به
Use Case ها مقدار اوليه مي دهند . همچنين آنها نشان مي دهند كه چه موقع يك عامل ، اطلاعات را از يك Use Case دريافت مي كند .
نمودار Use Case محاورات ميان Use Case ها و عامل هاي يك سيستم Automate Teller (ATM)Machine را نشان مي دهد . بر اين اساس ، نمودار Use Case مي‌تواند درخواستهاي سيستم را نشان دهد . در اين مثال مشتري بانك تعدادي از
Use Case ها را مقداردهي مي كند : برداشت پول (withdraw Money) ، واريز (Deposit Fands) ، انتقال از حساب (Transfer Fands) ، پرداخت (Make Payment) ، مشاهده تراز (موجودي) (View Balance) و تغيير PIN (Change PIN) .
تعدادي از ارتباطات اين ارزش را دارند كه بيشتر به آنها اشاره شود . كارمند بانك همچنين به Use Case تغيير PIN مقدار اوليه مي دهد . Use Case پرداخت ، فلشي را نشان مي دهد كه به سيستم اعتباري مي رود . سيستم هاي خارجي ممكن است عامل هايي باشند و در اين مورد ، سيستم اعتباري بعنوان يك عامل نشان داده شده است ، زيرا خارج از سيستم ATM ، است . فلشي كه از يك Use Case به يك عامل مي رود نشان مي دهد كه Use Case اطلاعاتي را توليد مي كند كه يك عامل از آن استفاده مي كند . در اين مورد Use Case پرداخت ، اطلاعات پرداختي كارت اعتباري را براي سيستم اعتباري آماده مي كند . اكثر اطلاعات از ديدن نمودارهاي Use Case قابل فهم مي باشد زيرا اين نمودار همة عمليات سيستم را نشان مي دهد . كاربران ، مديران پروژه ، تحليلگران ، برنامه نويسان ، مهندسين تضمين كيفيت و هر شخص ديگري كه به سيستم وابسته است ، مي تواند مانند همه ، اين نمودارها را ببيند و بفهمد كه چه سيستم قرار است به انجام برسد .

ايجاد نمودارهاي Use Case
در Rose ، نمودارهاي Use Case در نماي Use Case ساخته مي شوند . Rose يك نمودار Use Case پيش فرض به نام Main را براي شما مي سازد . مي توانيد هر تعداد نمودارهاي اضافي كه براي مدل دهي به سيستم خود نياز داريد را بسازيد .
براي دستيابي به نمودار Main Use Case ، مراحل زير را انجام دهيد :
1-بر روي علامت + كنار نماي Use Case موجود در مرورگر كليك نماييد .
2-نمودار Main Use Case ظاهر خواهد شد . دقت كنيد كه در Rose علامت زير در كنار نمودار Use Case وجود دارد .
3-بر روي نمودار Main دوباره كليك كنيد تا باز شود . ميلة عنوان به اين عنوان تغيير مي نمايد :
[Use Case Diagram: Use Case View / Main]
براي ايجاد يك نمودار Use Case جديد مراحل زير را انجام دهيد :
1-در مرورگر بر روي نماي Use Case كليك راست نماييد .
2-از منوي باز شده گزينه New و سپس فرمان Case Diagram را به صورت آنچه در شكل زير نشان داده شده است انتخاب كنيد .
3-در نمودار جديد ، نام مورد دلخواه را براي نمودار جديد بنويسيد .
4-در نمودار جديد . نام مورد دلخواه را براي نمودار جديد بنويسيد .
براي باز كردن يك نمودار Use Case كه از قبل موجود است ، مراحل زير را طي كنيد:
1-مكان نمودار Use Case را در نماي Use Case موجودي در مرورگر بيابيد .
2-بر روي نام نمودار Use Case دو بار كليك كنيد تا آن را باز نماييد .
يا به روش زير كار كنيد :
1-به ترتيب گزينه Browse و سپس Use Case Diagram را انتخاب كنيد .
2-در ليستي كه در قسمت Package وجود دارد ، بستة نرم افزاري كه نمودار موردنظر شما در آن وجود دارد را انتخاب كنيد .
3-در ليستي كه در قسمت Use Case Diagram باز شده ، نموداري كه مي خواهيد باز كنيد را انتخاب نماييد .
4-بر روي Ok كليك كنيد .
از دكمه هاي نوار ابزار به صورتي كه در بخش زير توضيح داده شده ، براي افزودن Use Case ، عامل و ارتباطات به نمودار Use Case ، استفاده مي شود .
دو راه براي حذف يك آيتم از يك نمودار Use Case وجود دارد . روش اول ، مورد حذف شدني را از نمودار باز شده حذف مي كند ، ولي به موقعيت آن بر روي مرورگر يا نمودارهاي ديگر كاري ندارد . روش دوم آن آيتم را از تمام مدل ، تمام نمودارها و همچنين مرورگر حذف مي كند . براي اينكه يك آيتم را فقط از نمودار جاري حذف كنيد ، آن را در نمودار انتخاب كنيد (high light) و سپس دكمه Delete را بفشاريد .
براي حذف يك آيتم در سرتاسر مدل ، آن را در مرورگر انتخاب كرده و روي آن كليك راست كنيد تا يك منو باز شود . از منوي باز شده Delete را انتخاب كنيد يا آيتم را در نمودار انتخاب كرده و Ctrl+D را فشار دهيد .

حذف نمودارهاي Use Case
ممكن است بخواهيد برخي از نمودارهاي Use Case كه ساخته ايد را حذف كنيد . غيرعادي نيست كه در ابتداي پروژه براي فهميدن محدوده پروژه نمودارهاي
Use Case زيادي را ايجاد نماييد .
برخي از نمودارها ممكن است Use Case ها را نگهداري كنند ، برخي ديگر عامل ها را نشان دهند ، در حالي كه برخي از آنها زير مجموعه‌اي از Use Case و عامل ها را نشان مي دهند . در روند پيشرفت پروژه ، ممكن است نياز باشد كه برخي از اين نمودارهاي قديمي را حذف كنيد . شما مي توانيد يك نمودار Use Case را مستقيماً در مرورگر حذف كنيد . توجه داشته باشيد كه اگر يك نمودار را حذف كنيد هيچ راهي براي برگرداندن آن وجود نخواهد داشت .
براي حذف يك نمودار Use Case :
1-مرورگر ، بر روي نمودار موردظر كليك راست كنيد .
2-از منوي باز شده گزينة Delete را انتخاب كنيد .

الصاق فايل ها و URL به يك Use Case
Rose به شما امكان الصاق يك فايل يا URL به يك نمودار Use Case را مي دهد . تمام اسناد ضميمه مانند مشخصات نيازمنديهاي سطح بالا ، سند مربوط به حوزة ديد پروژه يا چهارچوب تجارت (business case) ، و يا حتي طرح پروژه را مي توان به نمودار Use Case متصل كرد . شما مي توانيد هر كدام از فايل ها و يا URL هاي الصاقي كه در مرورگر و در زير نمودار Use Case ليست شده اند را ببينيد . مي توانيد در مرورگر مستقيماً بر روي فايل يا URL دو بار كليك كنيد تا به طور خودكار برنامة كاربردي مناسب را سريعاً اجرا كنيد و فايل يا URL را بارگذاري نماييد .
براي الصاق يك فايل به يك نمودار Use Case مراحل زير را دنبال كنيد :
1-در مرورگر بر روي نمودار Use Case كليك راست كنيد .
2-ابتدا گزينه New و سپس File را انتخاب كنيد .
3-با استفاده از كادر محاورة Open، فايلي كه مي خواهيد الصاق نماييد را بيابيد .
4-Open را انتخاب كنيد تا فايل به نمودار Use Case متصل شود .
براي اتصال يك URL به يك نمودار Use Case مراحل زير را دنبال كنيد :
1-در مرورگر بر روي نمودار Use Case كليك راست كنيد .
2-ابتدا گزينه New و سپس URL را انتخاب كنيد .
3-نام URL را تايپ كنيد تا به نمودار متصل شود .
باز كردن يك فايل الصاق شده :
1-فايل موردنظر را در مرورگر مكان يابي كنيد .
2-بر روي نام فايل دو بار كليك كنيد . Rose برنامة كاربردي مربوطه را باز كرده و فايل را بارگذاري مي كند .
يا
1-روي نام فايل در مرورگر كليك راست كنيد .
2-از منوي باز شده گزينه Open را انتخاب كنيد . Rose برنامة كاربردي مناسب را باز كرده و فايل را بارگذاري مي كند .
باز كردن يك URL الصاقي بدين صورت است :
1-URL را در مرورگر مكان يابي كنيد .
2-بر روي نام URL دو بار كليك كنيد . Rose به طور خودكار برنامة مرورگر وب موردنظر شما را به جريان مي اندازد و URL را بارگذاري مي كند .
يا
1-در مرورگر روي URL موردنظر كليك راست كنيد .
2-از منوي باز شده ، گزينه Open را انتخاب كنيد . Rose به طور خودكار برنامة مرورگر وب را راه اندازي كرده URL را بارگذاري مي كند .
روش حذف يك فايل يا URL الصاقي به صورت زير است :
1-بر روي نام فايل يا URL در مرورگر ، كليك راست كنيد .
2-از منوي باز شده گزينه Delete را انتخاب كنيد .

نوار ابزار براي نمودار Use Case
وقتي كه نمودار Use Case باز مي شود ، نوار ابزار مربوط به نمودار به نحوي تغيير مي كند كمه آيكون هاي استفاده شده در نمودار Use Case را نشان دهد . Rose تمام ميانبرهاي استفاده شده براي عمليات هاي معمول ، كه در نمودار Use Case زياد استفاده مي شوند را در نوار ابزار مهيا كرده است . برخي از دكمه هايي كه آنها را در دسترس خواهيد داشت در جدول زير نشان داده شده اند . در باقي ماندة اين فصل ، دربارة نحوة استفاده از دكمه ها نوار ابزار براي افزودن Use Case ها ، عامل ها و ديگر جزئيات مربوط به نمودار Use Case صحبت خواهيم كرد .







كار با Use Case ها
Use Case بخش سطح بالايي از عملياتي است كه سيستم مهيا مي كند . به عبارت
ديگر ، Use Case ، اينكه شخص چگونه از سيستم استفاده مي كند را شرح مي دهد .
بياييد با نگاه به يك مثال كار را شروع كنيم . يك ماشي ATM ، يك سري عمليات اصلي را براي مشتري انجام مي دهد . به مشتري اجازه مي دهد تا پول به حساب بريزد ، نقداً از حساب برداشت كند ، پول را از يك حساب به حساب ديگر منتقل نمايد ، مقدار و موجودي را مشاهده كند ، PIN را تعويض نمايد و يا توسط كارت اعتباري پول پرداخت نمايد . هر كدام از اين Transaction ها روش متفاوت استفاده مشتري از سيستم مي باشد . به هر حال هر كدام از آنها يك Use Case متفاوت هستند . در UML يك Use Case با استفاده از علامت زير نمايش داده مي شود :

Use Case
يك مزيت نگاه به سيستم با استفاده از Use Case اين است كه مي توان پياده سازي سيستم را از دليل ايجاد سيستم در ابتدا ، جدا نمود . ذهنتان را بر آنچه كه مهم است متمركر كنيد - يعني برطرف كردن نيازها و توقعات مشتري بدون نياز به درگير شدن با جزئيات پياده سازي . با نگاه كردن به Use Case ها ، مشتري خواهد فهميد كه چه عملياتي مهيا خواهد شد و قبل از اينكه پروژه به مراحل جلوتر برود ، مي تواند خودش را با سيستم وفق دهد .
Use Case ها به صورت ديگري به متدهاي سنتي نزديك مي شوند . شكستن پروژه به Use Case ها ، يك روش نگاه كردن به پروژه به صورت پردازش گرا است و نه به صورت عملگرا . البته با تجزية عملياتي كه گاهي اوقات انجام مي شود ، تفاوت دارد . تجزية عملياتي بر اينكه چگونه باشد مشكلات سيستم را براي حل شدن به قطعات كوچك و كوچكتر تبديل كرد ، تمركز دارد ، در حالي كه Use Case تمركز كار را بر روي آنچه مشتري از سيستم توقع دارد ، قرار مي دهد . وقتي در حال شروع يك پروژه هستيد ، يك سوال طبيعي اين است : چگونه بايد Use Case ها را پيدا كرد؟
يك راه خوب براي شروع اين است كه سندي كه مشتري تهيه كرده است را در نظر بگيريد . اغلب اوقات ، يك سند كه داراي نسخه يا محدودة سطح بالايي است مي‌تواند به شما در شناسايي Use Case ها كمك كند . هر كدام از بانكدارهاي موجود در پروژه را در نظر بگيريد . از خودتان بپرسيد كه هر بانكداري چه توقعي از سيستم دارد .

دانلود فایل اصلی در قالب Word Doc در لینک مستقیم زیر:
http://forum.a00b.com/upload/Uploads/636...s_2017.doc

[ali]

تبديل توصيف UML معماري نرم‌افزار به مدل كارايي شبكه‌هاي صف (QN) و توليد بازخورد از نتايج ارزيابي كارايي
انگيزه‌ها و اصول عمومي
پيش زمينه
ضرورت و اهداف
تشريح متدولوژي ارزيابي کارايي
مثال كاربردي: سيستم خود پرداز بانكي(ATM)
جمع بندي و نتيجه گيري

دانلود فایل Powerpoint PPT در لینک زیر:

http://forum.a00b.com/upload/Uploads/636...ML2017.ppt