مهندسی نرم افزار

مهندسی نرم افزار

اسلاید 1: مهندسي نرم افزار (1)مدرس : دكتر سعيد پارسابه نام آنكه جان را فكرت آموختچراغ دل به نور جان برافروختنيمسال دوم سالتحصيلي 82-81دانشگاه آزاد اسلامي واحد شبستر

اسلاید 2: فرآيند مهندسي نرم افزار شناخت طراحي پياده‌سازي پشتيباني

اسلاید 3: شناخت سيستم تعيين چارت سازماني تعيين چارت عملياتي براي هر واحد عملياتي بايد نيازهاي آن واحد مشخص شوند مقوله آناليز وظايف براي شناخت بهتر مطرح مي گردد

اسلاید 4: شناخت سيستم System Centric User Centric شناخت سيستمها معمولا به دو صورت است :

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

اسلاید 6: گزارش شماره 1شرح مسئله حوزه مساله : افراد مرتبط باسيستم نياز مساله : افراد چه نيازهايي از سيستم دارند راه حل پيشنهادي : نقطه فروش : وجه تمايز سيستم با ساير سيستمها

اسلاید 7: پايان جلسه اول خسته نباشيد... الله نورالسموات و الارض...

اسلاید 8: شناخت نيازها براي تعيين نياز دانستن اهداف كلي سيستم دانستن اهداف كاري افراد فعال در سيستمسيستم كنوني را شناخت

اسلاید 9: شناخت نيازهاسيستم جاريسيستم آتيدو نكته اساسي :سيستم جاري ممكن است دستي يا كامپيوتري و يا تركيبي از اين دو باشد

اسلاید 10: شناخت نيازها دلايل شناخت سيستم جاري (كنوني) : مشخص شدن نيازها براي سيستم آتي (تا حدودي) مشخص شدن نقصها و تحميدهاي سيستم كنوني تعيين كارهاي زائد و اضافي شناخت جزئيات سيستم كنوني = اتلاف وقتنظر ادوارد يوردون(سال 1589)

اسلاید 11: شناخت نيازها SSADM (بعنوان يك روش ساختيافته) صرف زمان زيادي براي مدلسازي سيستم جاري اعتقاد بنيانگذاران UML و صاحبان متدلوژي USDPمطالعه سيستم كنوني

اسلاید 12: شناخت نيازها دلايل مطالعه سيستم جاري (كنوني) : لزوم وجود برخي عملكردهاي سيستم موجود در سيستم جديد لزوم انتقال برخي اطلاعات سيستم جاري به سيستم جديد انتقال مستندات سيستم جاري و استخراج الگوريتمها درصورت مكانيزه بودن سيستم جاري درك كلي از سازمان با مطالعه سيستم جاري انعكاس برخي از عمليات سيستم جاري در سيستم آتي لزوم درك كار افراد براي ايجاد سيستم مناسب كامپيوتري امكان مشخص كردن ميزان كارايي سيستم آتي با مطالعه سيستم جاري

اسلاید 13: شناخت نيازها اعتقاد بر اينست كه : سيستم جاري بايد تاحدي مورد شناخت قرارگيرد نيازها نيازهاي عملياتي نيازهاي كيفي نيازهاي قابل استفاده بودن

اسلاید 14: شناخت نيازها تعريف نيازهاي عملياتي :سيستم چه كاري بايد انجام دهد يا چه انتظاراتي از سيستم مي رود مشخص كردن UseCaseها يا سرويسهاي سيستم در ديدگاه شيء گرا ابتدا چارت سازماني معاون آموزش سرپرست آموزشي دانشكدهكارمند آموزشكارمند آموزش سرپرست آموزشي دانشكدهمنشي آموزش

اسلاید 15: شناخت نيازها يك Function توسط افراد مختلف انجام مي شود سپس چارت عملياتي عمليات آموزش عمليات آموزشي دانشگاه برنامه ريزي براي آموزش دانشگاه ثبت نام حذف و اخذ ......چارت عملياتي تاحدي متفاوت از چارت سازماني

اسلاید 16: شناخت نيازها نيازهاي عملياتي اصولا شامل : توصيف فرآيندهاي عملياتي كه سيستم آتي بايد انجام دهد جزئيات وروديهاي به سيستم ازطريق فرمهاي ورودي يا فرمهاي كاغذي، مستندات ، ارتباط با افراد ، ساير سيستمها يا مكالمات تلفني جزئيات خروجيهايي كه سيستم بايد فراهم نمايد جزئيات داده هايي كه در داخل سيستم بايد حفظ و نگهداري شوداست

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

اسلاید 18: پايان جلسه دومخسته نباشيد... با خدا باش و پادشاهي كن...

اسلاید 19: روشهاي استخراج نياز روشهاي استخراج نياز (5 روش) : مطالعه اوليه (Background Reading)مصاحبه (Interview) مشاهده (Observation) ارجاع به مستندات (Documentations) تهيه پرسشنامه (Questions)

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

اسلاید 21: مطالعه اوليه مزايا كمك به شناسايي عملكرد سازمان قبل از ملاقات با افرادمشخص شدن سؤالات لازم بر مبناي اطلاعات جمع شدهمشخص شدن نيازها از طريق مراجعه به مستندات سيستم جاري مشكلمعمولا مستندات سيستم با واقعيتها متفاوت هستند كه علت بايد توسط آناليست مشخص شود.

اسلاید 22: روشهاي استخراج نياز مصاحبه : قبل از مصاحبه : بايد وقت ملاقات و موضوع ملاقات مشخص شوند نكته  مصاحبه يك اتلاف وقت براي مصاحبه شونده است در مصاحبه :انتخاب افراد باتجربهتعيين افراد مورد مصاحبهتعيين وقت مصاحبهتعيين اهداف مصاحبهلازم استشرح وظايف افراد نيز بايد مطالعه شود

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

اسلاید 24: مصاحبه مزايا ارتباط با افراد موجب مي شود آناليست پاسخگوي نيازهاي افراد باشدآناليست ممكن است روشهاي ديگري براي ساده ترشدن كار افراد پيشنهادكند مشكلات مصاحبه ها هزينه برندتنها انجام مصاحبه كافي نيست، بلكه آناليست بايد برروي نتايج كار كند و Prototype تهيه نمايد مصاحبات وابسته به نقطه نظرهاي مصاحبه ـ شونده است

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

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

اسلاید 27: ارجاع به مستنداتبا ارجاع به Prototype و گزارشهاي تهيه شده توسط افراد، بخصوص در هنگام مصاحبه، بخش اعظمي از نيازها مشخص مي شوند با ارجاع به اين فرمها، ميزان داده ها، فرمت داده ها و نهايتا ساختار بانكهاي اطلاعاتي و گزارشهايي كه بايد استخراج شوند، مشخص مي شود

اسلاید 28: ارجاع به مستندات مزايا حجم داده ها و اطلاعات موردپردازش مشخص مي گرددفرمت داده ها تعيين مي گرددمشكلات و خطاهايي كه بواسطه پركردن دستي مستندات ايجاد مي گردد، تعيين مي شود مشكلاگر قرارباشد سيستم كاملاً تغيير كند، ممكن است اطلاعاتي گردآوري شود كه در آتيه اصلاً نيازي به آنها نباشد

اسلاید 29: پرسشنامهپرسشنامه ها مجموعه اي از سؤالات هستند كه توسط مشاورين و كساني كه با اهداف و عملكرد دستي سيستمها آشنايي دارند، تهيه شده و در يك سازمان پخش مي شود و جوابها مطالعه مي گردند

اسلاید 30: ارجاع به مستندات مزايا بر مبناي پاسخها نيازها مشخص مي شوندبا استفاده از پرسشنامه ها، تعداد افراد زيادي را مي توان به كارگرفت مشكلتهيه پرسشنامه نياز به تجربه زياد داردعدم دريافت پاسخ به موقع از افراد

اسلاید 31: مثال تعيين نيازهاFact Finding (تعيين نيازها ) براي يك شركت تبليغاتي

اسلاید 32: مثال تعيين نيازها

اسلاید 33: مثال تعيين نيازها

اسلاید 34: مثال تعيين نيازها

اسلاید 35: پايان جلسه سومخسته نباشيد... بيـنديـش ....

اسلاید 36: دسته بندي نيازهابرطبق دسته بنديهاي RUP(Rational Unified Process) نيازها شامل : Functionality (نيازهاي عملياتي) Usability (قابل استفاده بودن)Reliability (قابليت اطمينان)Performance (كارايي)Supportability (قابليت پشتيباني)

اسلاید 37: VISION Vision  چشم انداز سيستم است.  نيازهاي كلي سيستم با اين مستند تهيه مي شود. بخشهايي از Vision : هدف (Objective): هدف كلي از مستند را براي سيستم مشخص مي كند.دامنه (Scope): در هنگام مشخص كردن دامنه يا حوزه عملكرد سيستم، موجوديتهاي با ارتباط خارجي تعيين مي گردد. افراد يا اشيائي كه در خارج از سيستم قراردارند، مشخص مي شوند.

اسلاید 38: VISIONمراجع (Refrances): در اين بخش مستنداتي كه جهت ايجاد سيستم به آنها ارجاع مي شود، آورده مي شوند. از جمله مستندات مي توان به : مستندات شرح وظايف سازماني، روندهاي كاري و ... اشاره نمود.موقعيت : 4-1. موقعيت كاري : مشخص مي كند هنگاميكه سيستم كامپيوتري جايگزين سيستم جاري شد، چه شرايطي و چه تسهيلاتي ايجاد خواهدشد.

اسلاید 39: VISION 4-2. شرح مسئله : در اينجا مشكل سيستم و مزاياي سيستم كامپيوتري مطرح مي شود.4-3. شرح كاربرها : در اين قسمت توضيحي درمورد شرح كاربرها و نيازهاي آنها تهيه شده و كاربرهاي اصلي مشخص مي شوند.توصيف محصول نرم افزاري : در اين قسمت در قالب يك دياگرام متن توصيفي از محصولي كه بايد به مشتري تحويل داده شود، ارائه مي شود. قابليتهاي نرم افزار و ويژگيهاي آن، هزينه توليد و نكات مربوطه در اين قسمت تعيين مي شود.

اسلاید 40: VISIONهزينه ها : بايد قسمتها را مشخص كرده و تعيين كرد كه براي هر قسمت عمليات چه هزينه اي نياز است. در ارتباط با هزينه ها درمجموع مي بايست هزينه انجام پروژه مشخص شود.

اسلاید 41: چرخه حيات نرم افزار مراحل چرخه حيات يا فرآيند توليد نرم افزار : شناخت اوليه (Inception) تشريح (Elaboration) ايجاد (Construction) انتقال (Transition)

اسلاید 42: چرخه حيات

اسلاید 43: شناخت اوليهباتوجه به دياگرام ؛ براي توليد نرم افزار عمليات مدلسازي سيستم جاري، تعيين نيازها، تجزيه و تحليل، پياده سازي، آزمون و نهايتاً نصب نرم افزار در هر مرحله تكرار مي شود. ولي تاكيد در هر مرحله متفاوت است. مثلا در مرحله شناخت اوليه بر مدلسازي كاري (جاري) تاكيد زياد و بر پياده سازي تاكيد كم است. براي تعيين دامنه پروژه بايد Actorها يا بازيگرهاي سيستم را مشخص نمود.Actor كاربر سيستم است و ممكن است فرد خارج از سيستم يا فردي از داخل سيستم باشد.

اسلاید 44: شناخت اوليه در محيط رشنال رز تصوير مربوط به اكتور به اين صورت است : اگر اكتور سيستم جاري باشد بايد مشخص كرد كه هر Actor چگونه با سيستم در ارتباط قرارمي گيرد. اين ارتباط را در قالب مورداستفاده يا UseCase مشخص مي كنند. درواقع مشخص مي كنند كه چه كساني چه استفاده هايي از سيستم مي برند.

اسلاید 45: شناخت اوليه در محيط رشنال رز تصوير مربوط به UseCase (مورداستفاده) به اين صورت است : معمولاً براي هر مورداستفاده شرحي نيز تعيين مي گردداگر UseCase سيستم جاري باشد

اسلاید 46: شناخت اوليه بطور خلاصه اهداف مرحله مدلسازي كاري عبارتند از: تعيين حوزه عملكرد يا دامنه مسئله تعيين مدلهاي استفاده از سيستم تعيين ساختار كلي سيستمبرنامه ريزي پروژه شامل زمانبندي وتجزيه ها تعيين ميزان ريسك براي انجام پروژه

اسلاید 47: شناخت اوليه بنابراين مي توان گفت خروجيهاي اين قسمت نيز عبارتند از: مستندات Vision مدل موردهاي استفاده از سيستمUseCase Model لغت نامه يا توضيح اصطلاحات گزارش سيستم كنوني برنامه ريزي پروژه

اسلاید 48: پايان جلسه چهارم خسته نباشيد... پـرواز را به خاطر بسپار، پـرنـده مردنـي سـت ...

اسلاید 49: مدلسازي سيستم جاري مدلسازي سيستم جاري شامل دو بخش است : Business process modeling (مدلسازي فرآيند كاري) Business object modeling (مدلسازي اشياء كاري) ابتدا بايد واحدهاي سازماني مشخص گردد يا به عبارت ديگر چارت عملياتي و چارت سازماني مشخص گردد. اما براي تعيين چارت سازماني بايد واحدهاي سازماني مشخص شوند.

اسلاید 50: مدلسازي سيستم جاري براي Business Object Modeling مي بايست Business Worker ها مشخص شوند. Business worker = نقش كاربرها براي تعيين Business worker ها بايد Business usecase ها مشخص شوند.Business usecase ها (موردهاي استفاده كاري) عملياتي است كه مي بايست براي سرويس دهي به سايرين به انجام رسد.

اسلاید 51: مدلسازي سيستم جاري براي مثال :در سيستم آموزش دانشگاه؛ مورد استفاده (UseCase)  ثبت نام Actor  دانشجوBusiness Worker  مسئول ثبت نام Business Entity  تعرفه ثبت نام ، پرونده دانشجو و ...

اسلاید 52: براي اينكه بصورت سازمان يافته عمل كنيم ، مراحل كار به شرح زير است : تعيين واحدهاي عملياتي تعيين مسئوليتها يا نقشهاي كاري (Business workers) تعيين مستندات يا موجوديتهاي كاري (Business entities) تعيين روش انجام موردهاي استفاده ساختن مدل ارتباطي اشياء كاري ارزيابي نتايج مدلسازي سيستم جاري

اسلاید 53: مدلسازي سيستم جاري شكل واحد سازماني  بعد از تعيين واحدهاي سازماني (كه براساس چارت عملياتي است) مي بايست Business Worker ها مشخص شوند. در واقع Business Workerها دست به دست هم مي دهندو همكاري مي كنند تا Business Usecaseها را عملي كنند.

اسلاید 54: تعيين موردهاي استفاده يك مورداستفاده درواقع شاخص سرويسي است كه سيستم براي Actor هاي خود فراهم مي كند. مثال سيستم آموزش دانشگاه : هر سرويس را يك مورداستفاده actor يا يك UseCase مي نامند. عملكرد سيستم براساس سرويسهايي كه فراهم مي كند، مشخص مي گردد. سيستم آموزش دانشگاه آموزش مركزي آموزش دانشكده

اسلاید 55: تعيين موردهاي استفاده دياگرام موردهاي استفاده كاري (آموزش دانشكده) :ثبت نام حذف و اخذ صدور كارنامه تعيين برنامه آموزشي دانشجو مديريت دانشكده استادآموزش مركزي

اسلاید 56: تعيين موردهاي استفاده اكتورها مي توانند از همديگر به ارث ببرند...متقاضي برنامه هاي آموزشي مدير دانشكده استادآموزش مركزي

اسلاید 57: توصيف موردهاي استفاده اصولاً يك مورداستفاده كاري شاخص يك وظيفه است كه بوسيله يك يا چند Business worker به انجام مي رسد. پس مورداستفاده كاري نمايانگر مورداستفاده اي است كه توسط يك Business worker مورداستفاده قرارمي گيرد. براي انجام هر وظيفه ، شرح وظيفه اي وجود دارد كه مراحل انجام كار را مشخص مي كند. پس براي انجام Usecaseهاي كاري مي توا از شرح وظايف استفاده كرد.

اسلاید 58: توصيف موردهاي استفاده براي نمونه درموردثبت نام، وظيفه يا مورداستفاده به شرح زير توصيف مي گردد: مسئول ثبت نام تعرفه را از متقاضي ثبت نام (دانشجو) دريافت مي كند. مسئول ثبت نام تعرفه را جهت بررسي به مسئول پرونده هاي دانشجويي مي دهد.مسئول پرونده دانشجويي وضعيت درسي، پيش نيازها و غيره را براساس تعرفه كنترل مي نمايد.

اسلاید 59: توصيف موردهاي استفاده كنترل كننده پس از تاييد و رد دروس يا به عبارت ديگر اصلاح تعرفه ، آن را به كنترل كننده كلاسها تحويل مي دهد.كنترل كننده با درنظر گرفتن ظرفيت دانشجو را ثبت نام مي نمايد.كنترل كننده فرم تكميل شده ثبت نام را تاييد و به مسئول ثبت نام تحويل مي دهد.مسئول ثبت نام فرم را به دانشجو تحويل مي دهد. در اين توصيف، Business workerها شامل مسئول ثبت نام، كنترل كننده ثبت نام، كنترل كننده كلاسها ممكن است همگي يك فرد باشند.

اسلاید 60: توصيف موردهاي استفاده مي بايست نوع همكاري در بين Business worker ها و عملكرد آنها بر روي Business entity ها مشخص گردد.  در اين رابطه مدل ارتباطي اشياء كاري كه درواقع همان business workerها و Business entity ها هستند، مطرح مي باشد. دو مفهوم : ABA is part of BABA is kind of B

اسلاید 61: توصيف موردهاي استفاده دانشجومسئول ثبت نامكنترل كننده Business Object Model : ارائه تعرفهتقاضاي كنترلمشاهدهتقاضاي تعرفهاصلاح كنترلتعرفه ثبت نامثبت كنندهظرفيت كلاسهاليست دروسپرونده دانشجوريزنمرات دانشجودانشجومسئول ثبت نامكنترل كنندهارائه تعرفهتقاضاي كنترلمشاهدهتقاضاي تعرفهاصلاح كنترل

اسلاید 62: توصيف موردهاي استفاده معمولاً در كامپيوتر ، Business workerها تبديل به كلاسهاي كنترلي مي شوند كه به شكل زير هستند: كلاسهاي كنترلي وظيفه كنترل عمليات را برعهده دارند.Business Entity ها تبديل به كلاسهاي از نوع Entity مي شوند كه به شكل زير هستند: Business entityها مبنايي براي ايجاد Tableها و بانك اطلاعاتي سيستم هستند.

اسلاید 63: توصيف موردهاي استفاده در اين راستا، Business Actorها تبديل به كلاسهاي از نوع Actor مي شوند كه به شكل زير هستند: در سيستمهاي كامپيوتري، نوع ديگري از كلاسها تحت عنوان Boundary classها مطرح هستند كه به شكل زير مي باشند: اين كلاسها شاخص فرمهاي ورودي – خروجي و رابطها مي باشند.

اسلاید 64: توصيف موردهاي استفاده هر زيرسيستم ممكن است شامل چند UseCase باشد. ممكن است يك Business Usecase مستقيماً تبديل به يك Usecase كامپيوتري شود. Business Unitها معمولاً با Packageها يا بسته هاي نرم افزاري جايگزين مي شوند. در دسته بندي كلاسها به جاي اتلاق اصطلاح type به آنها، stereotype را بكارخواهيم برد.

اسلاید 65: پايان جلسه پنجم خسته نباشيد... انسان هرگز نمي افتد مگر به چيزي تكيه كرده باشد...

اسلاید 66: نكات مدلسازي اشياء Usecaseها نبايد در ارتباط مستقيم با يكديگر قرارگيرند. ارتباط بين Usecaseها معمولاً ازطريق يك بانك اطلاعاتي صورت مي گيرد كه در مدل Usecase Diagram مشخص نمي گردد. دو سرويس ازطريق مستندات (بانك اطلاعاتي) باهم ارتباط برقرار مي كنند. اما در طرح جامع سيستمها عمليات مشترك را مي بايست مشخص و از تكرار آن جلوگيري كرد. در اين صورت عمليات مشترك را در داخل يك usecase تعيين و در رابطه include با usecase قبلي قرارمي دهيم.

اسلاید 67: نكات مدلسازي اشياء علاوه بر رابطه include ، رابطه ديگري بنام extend وجود دارد كه نشان مي دهد درحالت استثنايي عمليات usecase توسط usecase ديگر توسعه داده مي شود.سفارش دهندهثبت سفارشتاييد مديرتهيه صورتحسابسفارش كالا<<include>><<extend>>سفارش دهندهثبت سفارشتاييد مديرتهيه صورتحسابسفارش كالا<<include>><<extend>>

اسلاید 68: نكات مدلسازي اشياء هر واحد عملياتي به عنوان Actor براي واحد عملياتي ديگر در نظر گرفته مي شود. توصيف عملكرد با Activity Diagram بيان مي شود. براي رسم دياگرامهاي مختلف بايد سناريو مشخص گردد. براي هر usecase يك سناريو مي نويسيم. براي اينكه Business workerها كاملاً مشخص شوند، بايد شرح وظايف افراد مشخص گردد.

اسلاید 69: سناريو سناريو براي usecase مدل جاري (كنوني) : نام مورداستفاده جاري : ثبت نام شرح مختصر : دانشجو بايد تعرفه خود را ارائه دهد، پس از بررسي فرم تاييديه ثبت نام به او داده مي شود. كارايي موردنظر : هدف : ارائه حداكثر دروس بدون تلاقي به دانشجو است.

اسلاید 70: سناريو گردش كار اصلي : سيستم جاري اكتور2. مسئول ثبت نام تعرفه را كنترل مي كند.1. دانشجو تعرفه خود را جهت ثبت نام به مسئول ثبت نام ارائه مي دهد. 3. مسئول ثبت نام از مسئول پرونده ها تقاضاي كنترل شرايط دانشجو را مي كند.4. مسئول پرونده ها معدل كل دانشجو را از كارنامه وي مشخص مي كند.5. دروس پيشنياز از كاتالوگ دروس براي هر درس درون تعرفه مشخص مي شود.6. مسئول پرونده تعرفه را تاييد مي نمايد.

اسلاید 71: سناريو گردش كار اصلي : سيستم جاري اكتور7. مسئول پرونده ها از مسئول كنترل كننده كلاسها تقاضاي تعيين كلاس براي دانشجو را مي كند.8. بر اساس ظرفيت كلاسها و برنامه هفتگي، فرم ثبت نام ايجادمي شود.9. مسئول ثبت نام فرم را به دانشجو تحويل مي دهد.

اسلاید 72: پايان جلسه ششم خسته نباشيد... بينديش ...........

اسلاید 73: Use case Realization Use case Realization  به تحقق پيوستن موردهاي استفاده براي به واقعيت پيوستن موردهاي استفاده، مي بايست تعدادي object با يكديگر همكاري كنندو درنتيجه همكاري اينها نهايتاً سرويس موردنظر براي Actor فراهم گردد. objectها در قالب Business worker و Business entity مشخص شدند. محاوره(Interaction) اين objectها با يكديگر در قالب Interaction Diagram ميسر مي گردد.

اسلاید 74: Use case Realization سازماندهي اين objectها در قالب object model يا «مدل ارتباطي كلاسها» مشخص مي گردد. براي تشخيص عملكرد use case از دياگرام فعاليت يا activity Diagram استفاده مي شود. مدل ارتباطي كلاسها : همانور كه قبلاً در مدل ارتباطي اشياء ملاحظه نموديد، در اين مدل نيز انواع كلاسهاي مختلف با همديگر ارتباط برقرار مي كنند ولي در اينجا كلاسها مربوط به objectهاي سيستم كامپيوتري (سيستم آتي) هستند.

اسلاید 75: مدل ارتباطي كلاسها رابطه بين كلاسها : در حالت كلي رابطه بين دو كلاس را association يا اجتماع بين دو كلاس مي نامند. رابطه بين دو object را link (پيوند) بين اشياء مي نامند. association : در اين ارتباط اجتماعي از كلاسها وجود دارد. هر اجتماع داراي يك نام است. براي مثال مسئول ثبت نام در ارتباط كنترل با تعرفه ثبت نام قراردارد. پس نام ارتباط كنترل است.

اسلاید 76: مدل ارتباطي كلاسها association : براي هر اجتماع نقش (role) تعيين مي كنيم. مسئول ثبت نام در نقش كنترل كننده و تعرفه ثبت نام در نقش كنترل شونده قراردارد. براي هر اجتماع تعداد را نيز مشخص مي كنيم. براي نمونه يك كنترل كننده ممكن است چند تعرفه ثبت نام را كنترل نمايد. در اجتماع، جهت آن نيز مهم است. براي مثال از طرف كنترل كننده به طرف تعرفه ثبت نام.

اسلاید 77: مدل ارتباطي كلاسها انواع association : is a kind of : نوعي است از. مثلاً انسان نوعي حيوان است. is a part of : قسمتي است از. مثلاً موتور قسمتي از اتومبيل است. dependency : وابستگي. وجود كلاسي وابسته به كلاس ديگر است.انسان حيوان موتوراتومبيل

اسلاید 78: پايان جلسه هفتم خسته نباشيد... چشمها را بايد شست ...

اسلاید 79: دياگرامها دياگرامهاي محاوره اي (Interaction Diagram) : اين دياگرام نشان مي دهد كه هر object كدام مقدار را فراخواني تا يك use case به تحقق بپيوندد. اين دياگرامها شاخص دنباله اي از پيامها يا (deployment يا message) مي باشند. اين دياگرامها بر دو نوعند: دياگرامهاي همكاري(Collaboration Diagram ) دياگرامهاي توالي (Sequence Diagram)

اسلاید 80: دياگرام توالي اين دياگرام دنباله اي از فراخوانيهايي است كه از طريق آنها، use case به تحقق مي پيوندد.خواندن دادهكنترل دادهارسال دادهجزئيات بازيگرفرم رابطمركز كنترلپروندهدياگرام توالي نمونه (حالت كلي)تقاضاي نمايش دادهخواندن دادهخواندن دادهكنترل دادهارسال دادهجزئيات

اسلاید 81: دياگرام توالي شكل بيانگر اينست كه : دياگرام مربوط به نمايش جزئيات يك پرونده است. همانطور كه مشاهده كرديد، كاربر در مقابل كامپيوتر قرارمي گيرد. فرم رابط كه كلاسي از نوع Boundary class است، براي وي نمايش داده مي شود. كاربر تقاضاي نمايش داده را بصورت انتخاب يك گزينه از فرم به كلاس فرم ارسال مي كند.در دنياي واقعي عمل كنترل عمليات يا انجام آنها برعهده كاركنان است ولي در دنياي كامپيوتري اين نقشها برعهده «كلاسهاي كنترلي» است. لذا درخواست خواندن داده به مركزكنترل داده مي شود. و مركز كنترل درخواست را براي پرونده موردنظر ارسال مي كند.

اسلاید 82: دياگرام توالي sequence diagram معمولاًدوبار كشيده مي شود. يك بار بصورت فارسي و مفهومي و بار دوم با اسم واقعي توابع فراخواني شده. براي ديدن مثال ديگري از sequence diagram مي توانيد به ص 457 شكل 4-4 كتاب مهندسي نرم افزار تاليف دكتر سعيد پارسا مراجعه نماييد. actor در سيستم كامپيوتري معمولاً در خارج سيستم قراردارد. مثلاً مسئول ثبت نام كه در خارج سيستم كامپيوتري است، به عنوان actor درنظرگرفته مي شود. درحاليكه در سيستم جاري اين فرد در داخل سيستم بود و actor محسوب نمي شد.

اسلاید 83: دياگرام توالي براي مثال فراخواني توابع در ص 458 شكل 5-4 بدين صورت است : () show . منوانتخاب گزينه ايجاد سفارش () show . فرم درج جزئيات سفارش() save . فرم() save . مدير() create . سفارش() setinfo . سفارش() save . قلم

اسلاید 84: تا كنون .... تعيين چارت سازماني و چارت عملياتيتعيين هدف، شرح مسئلهتعيين نيازهاي عملياتي و كيفي براي هر واحد عملياتيتعيين Business Actor ها؛ كساني كه قراراست در خارج سيستم از آن استفاده كنند. هر زيرسيستم يا واحد عملياتي بعنوان يك actor براي واحد عملياتي ديگر درنظر گرفته مي شود. Business use case ها مشخص مي گردد. براي هر Business use case يك سناريو در داخل يك فايل word نوشته مي شود.

اسلاید 85: تا كنون .... use caseهاي متعلق به يك واحد عملياتي همگي در زير package مربوط به آن واحد عملياتي قرارمي گيرند.درLogical View تحت Business Object Model ، Business Unit ها مشخص مي شوند. داخل هرbusiness unit مدل ارتباطي اشياء كشيده مي شود. حال مرحله شناخت اوليه (Inception) تمام ميشود و مرحله Elaboration (تشريح) با آناليز شناخت آغاز مي گردد. با توجه به اينكه با شناخت سيستم جاري(موجود) مي توان به عقب برگشت و نيازهاي كيفي و عملياتي را تكميل نمود.

اسلاید 86: تا كنون .... اكنون مطالب گردآوري شده موردتحليل قرارمي گيرد تا بتوان براساس تحليل خود براي سيستم آتي موردهاي استفاده را مشخص نموده و براي هر مورداستفاده براساس دياگرام توالي عمليات را مشخص كرد. تحت Analysis Model و use case realization Package بايد تعيين شود كه هر use case سيستم كامپيوتري، كدام use case از سيستم موجود را به واقعيت نزديك مي كند يا محقق مي نمايد يا realize مي كند.

اسلاید 87: پايان جلسه هشتم خسته نباشيد... اگر تنهاترين تنها شوم، بازهم خدا هست...

اسلاید 88: سيستم آتي در سيستم كامپيوتري (آتي) معمولاً تعداد use case ها بيشتر مي شود.در اينصورت است كه بررسي مي كنيم چه use case هايي از سيستم جديد موجب به تحقق پيوستن use caseهاي سيستم موجود مي شوند. براي مشاهده مثالي درباره realize، مي توانيد در دايركتوري زير جستجو نمائيد: Cd3completedparsaumldocs t tutorial module 6acompletedCd3 سومين cd ارائه شده توسط دكتر پارسا در كلاس مهندسي نرم افزار است.

اسلاید 89: سيستم آتي عمل realize در قسمت analysis model انجام مي شود. use caseهايي كه با خط پر نشان داده مي شوند، use case هايي هستند كه realize مي شوند (use case هاي سيستم آتي) . Use caseهاي realize شونده با خط چين نمايش داده مي شوند. (use caseهاي سيستم موجود). انجام عمليات مربوطه در Rational Rose مدل ارتباطي در Logical view‌ كشيده مي شود، سپس از Browser در داخل package اِ use case model انداخته مي شود (Drag & Drop) .

اسلاید 90: پايان جلسه نهمخسته نباشيد... لطف خدا بيشتر از جرم ماست....

اسلاید 91: عمليات مربوط به انجام كار هرگاه object اي متدي از خودش را فراخواني كند، آنگاه از در دياگرام توالي استفاده مي كنيم. لازم و ضروري نيست كه براي هر Table يك كلاس اضافه شود.سلسله مراتب انجام عمليات مربوط به پروژه :Business object model (مدل سيستم كاري در حالت جاري).تهيه Documentاي بنام vision براساس نيازهاي سيستم جاري. در داخل vision :

اسلاید 92: عمليات مربوط به انجام كار 2-1 . مستند نيازها ، نياز2-2 . قابليت سيستم جديد، يعني قابليتهاي سيستم را بيان مي كند(پاسخ نياز).2-3 . بعد از Business model، requirement analysis (ليست نيازها).بعد از ايجاد مستندات use case هاي سيستم آتي را مشخص مي كنيم. Use case هاي سيستم آتي كاملاً با use caseهاي سيستم جاري (موجود) متفاوت است. به اين ترتيب use case view تمام مي شود.

اسلاید 93: عمليات مربوط به انجام كار سيستمي را كه در حال حاضر موجود بوده و استفاده مي شود را در داخل Business use case و سيستم جديدي را كه قرار است طراحي شود در داخل use case مورد بررسي قرار مي دهيم. پس اولين كار Business modeling است. بر اين اساس featureها را تعيين مي كنيم(تعيين نيازها با vision). مثلاً درمورد ثبت نام، نياز ثبت نام اينست كه ازطريق وب انجام شود. و اين يك قابليت براي سيستم جديد مي باشد. هدفuse case view اينست كه مشخص كند ما چه عملياتي از سيستم جديد مي خواهيم.

اسلاید 94: مستندات چشم انداز هنگام ورود به فاز طراحي ، قسمت use case realization انجام مي شود.مستندات چشم انداز يا vision : كليه نيازها و پاسخ به نيازها يعني قابليتهاي سيستم مكانيزه در مستندات چشم انداز سيستم گنجانده مي شوند. در چشم انداز شرح مسئله يا problem statement گنجانده مي شود. منظور از Business opportunity امكانات جديد كاري است كه سيستم كامپيوتري براي مشتري ايجادخواهدكرد.

اسلاید 95: مستندات چشم انداز براي مثال فروش دو برابر خواهدشد، يا اينكه فروش را مي توانيم با وجود سيستم كامپيوتري در سراسر كشور امكان پذير كنيم. در اين مستند؛ كاربرها در قالب stakeholder و user ها مشخص مي شوند.Stakeholder : فردي است كه براي سازمان موردنظر كارمي كند.User : فردي است كه از سيستم كامپيوتري استفاده خواهدكرد. در قسمت product view چشم اندازي از ديد نرم افزاري مهيا مي شود.

اسلاید 96: مستندات چشم انداز در چشم انداز تعيين مي كنيم سيستم آتي چه امكاناتي براي سيستم جاري خواهد داشت. در اينجا What مطرح است نه How. در چشم انداز مشخص مي شود كه سيستم چه كاري بايد انجام دهد؛ چگونگي در قسمت طراحي مطرح است. چشم انداز شامل summery of capability و تعيين هزينه ها ست. براي هر يك از قابليتها بطور مجزا هزينه ها مشخص مي شود. قابليتها پاسخي به نيازها هستند. نيازها بعد از قابليتها مشخص مي شوند. (شايد بهتر بود قبل از آن باشد).

اسلاید 97: مستندات چشم انداز در اين قسمت ارجاعي به راهنماي user و راهنماي نصب كه در انتهاي پروژه به كاربر تحويل مي شود، ارائه مي گردد. پس نتيجه مي شود مي توان مستندات vision را با در دست داشتن نيازها تكميل نمود. بعد از تعيين نيازها و قابليتها، use case view با ايجاد use case model كامل مي شود.مي توان گفت use case model ورودي مرحله تحليل و طراحي است. بر مبناي use case model كار تحليل و طراحي آغاز مي شود.

اسلاید 98: تحليل و طراحي use case model نشان مي دهد كه سيستم آتي چه function ها يا عملياتي بايد انجام دهد. حال use caseهاي آتي در مرحله design بايد realize شوند. ممكن است يك use case در مرحله آناليز مثلاً با سه يا چهار use case جايگزين شود. بعد از كشيدن use case view وارد logical view شده و مستندات را در اين قسمت وارد مي كنيم. در مرحله طراحي بايد مشخص شود كه چه use case هايي مي بايست مورد پياده سازي قرارگيرند. براي اين منظور بايد....

اسلاید 99: تحليل و طراحي ... بايد با استفاده از Sequence Diagram و مدل ارتباطي كلاسها مشخص شود كه هر use case چگونه پياده سازي خواهدشد.البته پيش رفتن با اين روند، كار را بسيار طولاني خواهدكرد. شايد عمل منطقي تر اين باشد كه كه ابتدا مشخص شود كه چه قابليتهايي بايد وجود داشته باشد . اين قابليتها نهايتاً در قالب use case model مشخص شده و سپس به چگونگي اين كار پرداخت. چگونگي در قالب تحليل و طراحي سيستم تعيين مي گردد. traceability يا قابليت رديابي خطا را نيز بايد درنظر داشت. (اگر نيازي مطرح شده، اكنون به چه كدام مرحله رسيده است.)

اسلاید 100: پايان جلسه دهمخسته نباشيد... الهي تو آني ، تواني ، جهاني ، به فاني ، كشاني.

اسلاید 101: نتيجه مستندات چشم انداز Business Modelingتعيين ليست نيازمنديها بر اساس سيستم جاري Use caseهاي آتي كامل شدن نيازمنديها بر مبناي اين دو كاتالوگ use case view (چه استفاده هايي از سيستم كامپيوتري مي شود)

اسلاید 102: معماري packageها (subsystemها) به طريقي به هم متصلند. pipeline : اين نوع معماري، امكاني ايجاد كرده است كه يك قسمت به جاي اينكه ورودي را از keyboard بگيرد، از خروجي قسمت ديگر مي گيرد. 3لايه : اين معماري از سه لايه user interface، application و بانك اطلاعاتي تشكيل مي شود. هرلايه مستقل از لايه بالايي ساخته مي شود. در اينجا patternها مطرح مي شوند. مثلاً الگوي observer .

اسلاید 103: معماري مثال براي observer pattern : بطور نمونه اگر مدير مي خواهد اطلاعاتي را كه مشاهده مي كند در قالب چارت باشد، پس بايد لايه interface جدا از لايه زيرين باشد، تا اين كار به آساني صورت گرفته و بتوان اطلاعات آماري را سريع و آسان به چارت تبديل نمود. تهيه اطلاعات مربوط به لايه application است. Application اين اطلاعات را بايد از بانكهاي اطلاعاتي مختلف بدست آورد. مزيت : هر زمان كه بخواهيم، مي توانيم بدون تغيير برنامه، تنها در لايه مربوطه تغييرات را اعمال نماييم.

اسلاید 104: مدل ارتباطي كلاسها مدل ارتباطي كلاسها را قبلاً در قالب مدل ارتباطي اشياء كاري مشاهده نموديد. در اينجا درصدد پاسخ به سؤالات زير برخواهيم آمد: مدل ارتباطي كلاسها چيست؟ چرا مدل ارتباطي كلاسها مطرح است؟ چگونه مدل ارتباطي كلاسها را ايجاد مي كنند؟ مدل ارتباطي كلاسها ساختار برنامه شيءگرا را مشخص مي كند. نشان مي دهد كه به جاي افراد چه كساني يا چه كلاسهايي در سيستم وجود دارند.

اسلاید 105: مدل ارتباطي كلاسها براي كلاسها نيز درست مثل هر پست سازماني شرح وظايف تعيين مي شود. شرح وظايف را در قالب متدهاي كلاس پياده سازي مي كنند. كلاسي كه بدون پياده سازي بوده و تنها متدهاي آن تعيين شده باشد، بنام Abstract class معرفي مي شود. در دنياي واقعي چارت سازماني و در دنياي شيءگرا مدل ارتباطي كلاسها مطرح است. كلاسها چگونه مشخص مي شوند؟ use case سرويسي است كه قراراست به كاربر ارائه شود. اين سرويس لازمه اش تعدادي كلاس است.

اسلاید 106: مدل ارتباطي كلاسها در صورت نيازBusiness worker ها تبديل به كلاسهاي كنترلي مي شوند Business entity ها تبديل به Entity class مي شوند. بطوركلي منظور اينست كه از شرح سناريو اسامي را استخراج مي كنيم. معمولاً اسامي درواقع همان اسامي كلاسها مي شوند. درواقع اين كلاسها هستند كه باهم همكاري مي كنند تا use case چه جاري و چه آتي وظيفه اش را انجام دهد. در ص 431 در بخش دوم كتاب مهندسي نرم افزار، شرح سناريو براي صندوق فروشگاه مشخص شده است و كلاسها از داخل شرح سناريو استخراج شده اند.

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

اسلاید 108: كلاسها براي نمونه فرمهايي با عنوان CRC (Class Responsibility Collaboration) آماده مي شود و بصورت زير مسئوليتهاي class و همكارهاي وي مشخص مي شوند.مسئوليتها همكارهانگهداري اطلاعات نسخه ها در امانت عضو دريافت تقاضاي برگشت يا امانت نسخه هانسخه عضو كتابخانهCRC Card (1)

اسلاید 109: كلاسهامسئوليتها همكارهانگهداري اطلاعات يك نسخه از كتاب اطلاع امانت يا برگشت نسخه به كتابكتابنسخهCRC Card (3)مسئوليتها همكارهانگهداري اطلاعات يك كتاب آگاهي از وجود نسخه قابل امانتعضوكتابCRC Card (2)

اسلاید 110: پايان جلسه يازدهمخسته نباشيد... ............... سكوت سرشار از ناگفته هاست ...............

اسلاید 111: كلاسها منظور از بدست آوردن مدل ارتباطي كلاسها، اينست كه سيستم را سازماندهي كنيم. به عبارتي چه كساني چه وظايفي دارند و چه ارتباطي باهم دارند. حتماً براي هر كلاس بايد وظايف كلاس مشخص شوند. كلاسها در حالت كلي به سه دسته كلاسهاي : كنترلي Entity سرحدي (Boundary) تقسيم مي شوند. (Stereotype كلاس )

اسلاید 112: كلاسها اگر نياز باشد به ازاء هر use case يك package تعيين مي شود و به ازاء آن package كلاسها مشخص مي شوند. اين كلاسها هستند كه با كمك همديگر use case را به واقعيت مي رسانند. براي اضافه كردن پارامترهاي ورودي و خروجي به متد كلاس، بايد روي Operation Tab كليك شود. سپس روي متد كليك و مقدار بازگشتي و نوع آن را تعيين كرد. بعد روي Detail كليك كرده و مقدار ورودي را مشخص نمود. آنگاه Double click نموده و نوع آن را انتخاب كرد.

اسلاید 113: كلاسها مدل ارتباطي كلاسها را علاوه بر كارتهاي CRC مي توان مستقيماً از Sequence Diagram استخراج كرد. اگر در داخل كارتهاي CRC كلاس A همكاري بنام كلاس B دارد، در مدل ارتباطي كلاسها تحت Logical View ، مي بايست يك خط ارتباط دهنده بين كلاس A و كلاس B ترسيم شود. به همين ترتيب از روي Sequence Diagram، اگر يك Object از داخل كلاس A متدي از يك Object از نوع كلاس B را فراخواني كند، بين اين دو كلاس يك خط واصل ارتباطي ترسيم مي شود. براي هر use case براساس Sequence Diagram مي توان مدل ارتباطي كلاسها را ايجادكرد.

اسلاید 114: كلاسها براي نمونه به دياگرام توالي : ص 384 كتاب توجه نمائيد.در اين دياگرام توالي براي مثال كلاس TorderForm در ارتباط با كلاس Tcostumer قراردارد. تابع Find از كلاس Tcostumer ازطريق متد show() از كلاس TorderForm فراخواني مي شود. بدين ترتيب مشاهده مي كنيد كه دو كلاس در يك ارتباط قراردارند. ارتباط بين دو كلاس Find است. همانطور كه مي دانيد، ارتباط بين دو كلاس را Association يا اجتماع كلاسها نيز مي نامند.

اسلاید 115: كلاسها با توجه به دياگرام توالي : The Orderform: TorderFormThe Costumer: TcostumerFind (integer)Show customer

اسلاید 116: كلاسها مدل ارتباطي بين كلاسهاي حاصل از Sequence Diagram فوق به صورت زير است : مي خواهيم ازطريق كلاس TorderForm، متد Find از كلاس TCostumer را فراخواني كنيم. كلاس TorderForm داراي Attribute هاي زير است:No ; Data ; Supplier ; Total TorderFormTCostumerFind()

اسلاید 117: كلاسها براي اينكه بتوانيم متد Find() را فراخواني كنيم، نياز به يك object از نوع TCostumer داريم. لذا درهنگام توليد كد، رشنال رز بطور اتوماتيك فيلد زير را به Attributeهاي كلاس TorderForm اضافه مي كند. Dim theCostumer As TCustomer بدين ترتيب هنگامي كه مي خواهيم داخل متد Show() از كلاس TorderForm متد Find() را فراخواني كنيم، دستورزير را مي نويسيم:  theCostumer.Find(Cno)

اسلاید 118: كلاسها بطور خلاصه : اگر داشته باشيم كلاس A در ارتباط با B است و فيلدهاي A به ترتيب A1,A2,A3,theB باشند، در هنگام توليد كد، مولد كد فيلد theB از جنس B را به فيلدهاي كلاس A اضافه مي كند. به اين ترتيب فيلد theB ي كلاس A به اين صورت خواهدشد: Dim theB As B در شكل فوق ارتباط بين دو كلاس يك به يك است. در هر اجتماع هر كلاس داراي يك نقش مي تواند باشد. براي مثال رل A بايد مشخص شود.يا براي كلاسهاي قبلي :TCostumer : يابنده ي جزئياتTorderForm : نمايش دهنده ي جزئياتAB

اسلاید 119: كلاسها مي توان پس از كليك برروي خط واصل بين دو كلاس Multiplicity يا درجه ارتباط را براي هر كلاس مشخص كرد. براي نمونه : در شكل فوق يك شيء از جنس A درارتباط با چند (n) شيء از جنس B است. بدين ترتيب هنگام توليد كد مشاهده مي شود كه در داخل كلاس A فيلد زير اضافه شده است :  theB Array[1..n] of B اگر رابطه چند به چند باشد، [1..n] تبديل به [m..n] خواهدشد.AB11..n

اسلاید 120: كلاسها همانطور كه قبلاً نيز اشاره شد، اجتماع بين دو كلاس مي تواند از نوع is apart of يا is a kind of باشد كه آنها را مجتمع مي نامند. براي مثال : رابطه ي فوق تجمع و ماشين مجتمع است.ماشينموتورشاسي بدنه دياگرام همكاري يا collaboration diagram زماني مطرح مي شود كه همكاري بين كلاسها مدنظر است.

اسلاید 121: پايان جلسه دوازدهمخسته نباشيد... آدام گدر، آد قالار٭ ياخجي پيسدن آغيزدا بير داد قالار

اسلاید 122: روابط بين كلاسها اصولاً دو نوع رابطه تجمع وجود دارد. يكي رابطه ظرف و مظروف و دومي رابطه Part Assembly . كلاً رابطه تجمع را «رابطه كل به جزء» يا All Parts مي نامند. براي نمونه به مثالهاي زير توجه كنيد.يا در رابطه part assembly شيء كل حتماً از شيء جزء تشكيل مي گردد .دستانگشتماشينموتورشاسي بدنهتوپر

اسلاید 123: روابط بين كلاسها در «ظرف و مظروف» لازم نيست حتماً شيء جزء تشكيل دهنده شيء كل باشد. مانند:صندوق پست نامه بدون نامه هم صندوق پست به تنهايي وجود خواهد داشت.توخالي حال اگر مثلث را يك Graphical Object درنظر بگيريم، آن يك Supper Class خواهدبود كه Point (نقطه)آن را Extend مي كند.مثلثنقطه11..n

اسلاید 124: روابط بين كلاسها نوع ديگري از روابط ، روابط is a kind of (رابطه انسان نوعي حيوان است) و is a part of (كارنامه قسمتي از پرونده دانشجو است) مي باشند كه قبلاً توضيح داده شد. پس از اينكه مدل ارتباطي كلاسها را مشخص كرديم، آنگاه مي بايست براي اينكه مدل ارتباطي كلاسها گوياتر شود، مشتركات بين كلاسها يا جنس كلاسها را در قالب Supper Class مشخص مي كنيم. توجه كنيد كه كلاس مافوق بايد بيانگر جنس يا ذات زيركلاسها باشد و هر مشتركاتي را نمي توان به عنوان Supper class درنظرگرفت.Association ارتباط بين دو كلاس = Link ارتباط بين دو شيء =

اسلاید 125: Data Model مدل بانك اطلاعاتي را مي توان از Entity Classها استخراج نمود. Entity classها كلاسهايي بودند كه داده هاي (ويژگيهاي) آنها بايد در داخل يك فايل ذخيره شود. مدل بانك اطلاعاتي مي تواند Relational يا Object Oriented يا هر مدلي باشد. و ارتباطي به روش تجزي و تحليل ندارد. يك Entity يا موجوديت به آن چيزي اتلاق مي شود كه داده اي را در خود نگهداري مي كند. به عبارت ديگر يك entity بيانگر ساختار يك Table است. كه بايد: داراي هويت يگانه باشد. تعدادي صفت يا ويژگي داشته باشد. صفتها و ويژگيها در قالب فيلدهاي Table مشخص مي شوند.

اسلاید 126: Data Model اصولاً براي يك Table كليد دسترسي يا Primary Key است كه Unique مي باشد و يا Secondary Key است كه Unique نيست. يا ممكن است كليد، Foreign Key باشد كه كليد اصلي براي يك Table ديگر است و در اين Table به آن ارجاع مي شود. براي مثال؛ در جدول اطلاعات دانشجو نام دانشجو كليد ثانويه است. شماره دانشجويي كليد اصلي است و كد دانشكده كليد خارجي است. از طريق كليد خارجي ارتباط بين موجوديتها برقرارمي گردد.

اسلاید 127: Data Model بطور خلاصه هر مديريت داراي مشخصات زير است: (دانشجو يك مديريت است) تعدادي صفت يا ويژگي دارد. يك هويت يگانه مي باشد. داراي تكرار است و يكي نمي باشد. مثلاً صفات دانشجو عبارتست از : شماره دانشجويي، نام، نام خانوادگي، كد دانشكده و آدرس است. دانشجو داراي تكرار است. كد دانشجويي باعث مي شود هويت يگانه داشته باشد.

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

اسلاید 129: هر برگ سفارش ممكن است داراي صفر يا بيشتر صورتحساب باشد.رابطه بين موجوديتها سفارش : كد سفارش+كد سفارش دهنده+نام سفارش دهنده+تلفن+تاريخ+{صورتحساب : كد صورتحساب + تاريخ +كد مأمورخريد+نام مأمورخريد+كد سفارش دهنده+نام سفارش دهنده+{كد كالا+نام كالا+ واحد شمارش+قيمت كل+توضيحات}+مبلغ كل صورتحساب}سفارش صورتحسابصفات برگ سفارشقسمتهاي تكراري

اسلاید 130: Data Modelبرگ صورتحسابمبلغ كل صورتحساب : .................كد كالانام كالاواحدشمارشتعدادقيمت واحدقيمت كلتوضيحاتكد صورتحساب :كد مأمور خريد :تاريخ :نام مأمور خريد :كد سفارش :نام سفارش دهنده :

اسلاید 131: Data Model رابطه يك به چند از طريق كليد خارجي كدسفارش ايجاد مي گردد. كد صورتحساب براي برگ صورتحساب، كليد اصلي (primary) است اما در برگ سفارش يك كليد خارجي براي مراجعه به صورتحساب است.سفارش صورتحساب هر صورتحساب بايد براي يك يا چند برگ سفارش باشد....سفارش صورتحساب صورتحسابي است كه داراي برگ سفارش نيست...

اسلاید 132: Data Model رابطه يك به چند بين سفارش و صورتحساب را ازطريق درج كد سفارش در فايل صورتحساب امكان پذير نموديم. اما رابطه يك به چند صورتحساب و سفارش چگونه پياده سازي خواهدشد؟! نمي توان مثل حالت قبل عمل نمود. يعني در داخل هر سفارش، كد صورتحساب را قراردهيم. البته در اين صورت مشخص مي شود كه هر سفارش متعلق به كدام صورتحساب است. يعني رابطه يك به چند بين صورتحساب و سفارش مشخص مي شود. اما مشكل اينجاست كه هر سفارش چند صورتحساب دارد. براي رفع مشكل از يك موجوديت جديد استفاده مي كنيم.

اسلاید 133: Data Model موجوديت مشترك در اينجا موجوديت خريد خواهدبود. كليد اصلي خريد : كدسفارش + كد صورتحساب سفارش صورتحسابخريد

اسلاید 134: Data Model به اين ترتيب اگر بخواهيم كليه صورتحسابهاي مربوط به سفارش با كد 25 را بدست آوريم، به صورت زير عمل مي كنيم : Select * Fromخريد  Select * from خريد Where 25=كد سفارش Where 46= كد صورتحسابكد صورتحسابكد سفارش462517251825كد صورتحسابكد سفارش462546344680

اسلاید 135: Data Model بطوركلي چنانچه موجوديت A با موجوديت B درارتباط قرارداشته باشد، ارتباط مي تواند چند به چند ، يك به يك ، يك به چند يا چند به يك باشد. A Bxy هر A ممكن است x اِ صفر يا چند B باشد. هر B بايد y اٍ يك A باشد. در حالت كلي رابطه چند به چند بين دو موجوديت A و B بصورت زير تبديل مي شود.10AB11A B

اسلاید 136: بنابراين رابطه چند به چند تبديل به دو رابطه يك به چند مي شود. چنانچه كليداصلي A، a1 و كليداصلي B، b1 باشد، آنگاه كليداصلي AB يك كليد تركيبي يا Composite key است كه از تركيب a1 + b1 ايجادمي شود.نرماليزه كردن اين صورتحسابها همگي بصورت برگه هاي مجزا در پرونده اي بنام صورتحساب نگهداري مي شوند. اگر بخواهيم پرونده صورتحساب را به همان شكلي كه در واقعيت وجود دارد، در داخل كامپيوتر ذخيره كنيم، افزونگي بسياري در داده هاي ذخيره شده وجود خواهدداشت.

اسلاید 137: همانطو كه مشاهده نموديد، فيلدهاي صورتحساب عبارتند از:رابطه بين موجوديتها صورتحساب : كد صورتحساب + تاريخ +كد مأمورخريد + نام مأمورخريد +كد سفارش دهنده+ نام سفارش دهنده+{كد كالا+نام كالا+ واحد شمارش + قيمت كل + توضيحات}+ مبلغ كل صورتحساب مي بايست فيلدهاي فوق، فيلدهاي يك ركورد از فايل صورتحساب باشند. بواسطه اينكه تعداد اقلام كالا در صورتحسابهاي مختلف متفاوت است، طول اين ركوردها متغيير مي باشد. به عبارت ديگر ممكن است در يك ركورد از صورتحساب، 50قلم كالا و در ركورد ديگر 1 قلم كالا وجود داشته باشد. نرماليزه كردن مطرح ميشود.

اسلاید 138: مرحله 1 نرماليزه كردن : كليد اصلي براي موجوديت اگر وجود ندارد، ايجادمي شود. بخش تكراري مشخص شود.در اينجا بخش تكراري قلم صورتحساب(قلم كالا) است. براي بخش تكراري كليد اصلي مشخص شود. در اينجا كد كالا است. بخش تكراري از بخش غيرتكراري خذف شود و به عنوان يك موجوديت جديد مشخص گردد. در اينجا قلم صورتحساب (قلم كالا) از موجوديت صورتحساب حذف شده و موجوديت جديد بنام قلم كالا ايجاد مي شود. كليد بخش جداشونده(بخش تكراري) كليدي تركيبي است. تركيب كليدبخش غيرتكراري + كليد بخش تكراري.رابطه بين موجوديتها

اسلاید 139: مرحله 2 نرماليزه كردن : كليه فيلدهايي كه وابسته به يك بخش از كليد تركيبي هستند، حذف مي شوند. براي مثال نام كالا در قلم صورتحساب فقط وابسته به كد كالاست اما تعداد هم وابسته به صورتحساب است هم وابسته به كالا. كالا = كدكالا + نام كالا + واحد + موجودي اول هر ماهرابطه بين موجوديتهاصورتحساب كالا قلم صورتحساب كالا هر كالا ممكن است مورد يك قلم صورتحساب باشد. هر قلم صورتحساب بايد براي خريد يك كالا باشد.موردبراي خريدمتعلق بهداراي

اسلاید 140: مرحله3 نرماليزه كردن : كليه فيلدهايي كه ازطريق فيلدهاي ديگر قابل دسترسي يا محاسبه هستند، حذف مي گردند. به اين ترتيب جمع كل از صورتحساب حذف مي گردد. قيمت كل از قلم صورتحساب حذف مي شود. نام مأمور خريد كه از طريق كد مأمور خريد قابل دسترسي است، حذف مي گردد. رابطه بين موجوديتهاصورتحساب كالا كارمندمأمور خريدداراي

اسلاید 141: پايان جلسه سيزدهمخسته نباشيد... وقتي تو سكوت كني، جهان به صدا درخواهدآمد...

اسلاید 142: رفتار چيست ؟ چگونه مي توان رفتار را در زبانهاي برنامه سازي پياده سازي نمود؟مدلسازي رفتاري رفتار شبكه اي است از حالات. رويدادها موجب گذر بين حالات هستند. رفتار واكنش در مقابل رويداد است. Objectها تبديل به كلاس باشعور مي شوند. كلاسها علاوه بر method و صفت، يكسري event دارند كه در مقابل آنها واكنش مي دهند.

اسلاید 143: مدلسازي رفتاري واكنش Object در مقابل event وابسته به كلاس نيست. اصولاً شعور، واكنشي است در مقابل رويداد. يك انسان باشعور درمقابل رويدادها واكنش صحيح را انجام مي دهد. واكنش انسان با فراخواني يك متد صورت مي گيرد. حال سؤال اينجاست كه چگونه در زبانهاي برنامه سازي رفتار را مدل مي كنند. يك Object اٍ باشعور درمقابل event ها از خود واكنش نشان مي دهد. واكنش Object به چه صورت است ؟

اسلاید 144: مدلسازي رفتاري اين واكنش در قالب فراخواني يك متد صورت مي گيرد. اصولاً رويدادها به دو دسته تقسيم مي شوند : يك دسته توسط سيستم مشخص مي شوند. دسته ديگر توسط برنامه نويس توليد مي شوند. مثال ( در زبان Delphi) :Click eventاي كه سيستم تشخيص مي دهد.OnHighPress(بالا رفتن دماي مشخص) event اي كه برنامه تشخيص مي دهد. و بايد يك Procedure براي آن نوشته شود.

اسلاید 145: مدلسازي رفتاري براي مثال يكPushButton را در نظر بگيريد. در مثال زير براي يك PushBotton با نام Command1 براي event هاي Click و MouseMove واكنش Object مشخص شده است. واكنش بصورت دو تابع زير مشخص گرديده است : Private sub Command1_MouseMove(Button1) command1.Backcolor = “RED” End SubPrivate Sub Command1_Click() command1.Caption= “CANCEL” End SubVBدر زبان

اسلاید 146: مدلسازي رفتاري واما در زبان Vb اين امكان وجود دارد كه برنامه نويس خود وابسته به شرايط رويدادي را ايجاد يا در اصطلاح « Raise » نمايد. Destructor : TerminateConstructor : Initialize در VB مي توان آرايه را خالي گذاشت و بعد با Redirection پر كرد.Private WithEvents Triangle as class1 زبان VB را درنظر بگيريد كه مي خواهيم كلاسي بنام Stack تعريف كنيم.

اسلاید 147: مدلسازي رفتاري ... به قسمي كه اگر درهنگام Push كردن مقدار Stack پرشود، رويداد OverFlow اتفاق مي افتد. براي اين منظور، در داخل كلاس Stack يك event بنام OverFlow تعريف مي كنيم : Public event overflow() اكنون براي تعريف متغيرها از نوع Stack مي بايست نوشت : Private withevents S1 As class1Private withevents S2 As class2

اسلاید 148: مدلسازي رفتاري حال براي استفاده مي نويسيم :Private Sub Form_Load() S1.Size=10 S2.Size=100 End SubPublic Sub S1_overflow() MsgBox “سرريز” End SubPublic Sub S2_overflow() MsgBox “سرريز” End Sub

اسلاید 149: مدلسازي رفتاري در كد فوق چنانچه براي مثال S1.push را اجرا كنيم، و overflow اتفاق بيفتد، تابع مربوط به overflow اجرامي شود. هنگام اجراي دستورالعمل Push ، تابع push بواسطه پربودن Stack، RaiseEvent مي نمايد (RaiseEvent Overflow را ايجاد مي نمايد) و همين امر موجب مي شود تا تابع S1_overflow فعال شود. در واقع S1_Overflow موجب مي شود كه واكنش شيء S1 درمقابل رويداد overflow مشخص گردد و براي S2 نيز به همين ترتيب. حال مسئله اينجاست كه چگونه درهنگام مدلسازي بتوانيم اين رويدادها و واكنش درمقابل رويدادها را مشخص كنيم؟

اسلاید 150: مدلسازي رفتاري براي اين منظور، از دياگرامهاي توالي استفاده مي شود. هر رويداد درواقع يك فراخواني است كه به يك object يا كلاس object وارد مي شود و واكنش object متدي است كه فراخواني مي گردد. براي مثال : در Sequence Diagram شكل ص 464كتاب ؛ Boundary Obj اي بنام « بيرون محوطه » از جنس « چشم الكتريكي » نزديك شدن اتومبيل را تشخيص مي دهد. بلافاصله در داخل متد « نزديك شدن » از اين Obj (()نزديك شدن.بيرون محوطه) كه از پورت «چشم الكتريكي» يكسره درحال خواندن مقدار پورت مي باشد، از داخل حلقه خارج مي شود.....

اسلاید 151: مدلسازي رفتاري ... و متد (()تشخيص اتومبيل.دروازه ورودي) را فراخواني مي كند. در داخل متد تشخيص اتومبيل بلافاصله متد (()تشخيص كارت.كارتخوان) فراخواني مي شود. اين متد در داخل يك حلقه پورت مربوط به كارتخوان را آنقدر مي خواند تا اينكه عددي كه نشانگر تاييد كارت توسط كارتخوان است، در اين پورت ظاهرشود. حال اين متد به فراخواننده خود يعني «تشخيص اتومبيل» Return مي كند و بلافاصله متد « باز شدن در» از شيء « در» فراخواني مي گردد. شيء «در» نيز يك boundary obj است. چرا كه در ارتباط با پورت مربوط به «در» قراردارد.

اسلاید 152: مدلسازي رفتاري زيرا كه شيء «در» در ارتباط با پورت مربوط به «در» قرارداردو اين تابع در پورت مربوط به « در» هر عددي را قرارمي دهد كه موجب مي شود دستگاه مربوطه فعال گردد و درب ورودي باز شود. به اين ترتيب كار در قسمت اول خاتمه مي يابد. با دورشدن از دروازه، تابع دورشدن از دروازه از شيء داخل محوطه موقعيت را تشخيص داده و عمليات مطابق دياگرام فوق ادامه مي يابد. همانطور كه مي دانيد، واردشدن رويداد به اشياء موجب تغيير حالت آنها مي گردد. در اينجا دو رويداد به « شيء دروازه » وارد مي شوند.

اسلاید 153: مدلسازي رفتاري رويدادهاي ورودي به « دروازه » : MyStack : Stack push S1_Overflow() دروازه : دروازه ورودي () تشخيص اتومبيل . 2 () حركت . 6 [ Stack is full ] در مورد شيء « Stack » رويداد push اتفاق مي افتاد.شرط S1 يا

اسلاید 154: مدلسازي رفتاري در مورد Stack : با اجراي push چنانچه شرط [Stack is full] برقرارباشد، تابع S1_Overflow كه درواقع S1 همان MyStack است، فعال مي گردد. بنابراين در اينجا : رويداد = push شرط = [ Stack is full ] رخداد = RaiseOverflow واكنش درمقابل رخداد = اجراء MyStack.Overflow يا S1.Overflow

اسلاید 155: مدلسازي رفتاري حال دوباره مثال قبل را در نظر بگيريد: مدل رفتاري براي كلاس دروازه، با استخراج اين كلاس از داخل دياگرام توالي مشخص شده است. دو رويداد، موجب دو تغيير حالت گرديده است.بيكارزنگ خطربستن درصدور مجوزOn Entry : فرمان كنترل كارتDo : انتظار پاسخ On Exit : فرمان بازكردن درتشخيص اتومبيلتشخيص حركت اتومبيل(درج كارت نامعتبر)

اسلاید 156: مدلسازي رفتاري شكل صفحه قبل را در نظر بگيريد: رويداد تشخيص اتومبيل موجب شده كه اين كلاس از حالت بيكار به حالت « صدور مجوز» واردشود. در اين حالت سه فعاليت مشخص گرديده اند: On Entry (به مفهوم « با ورود به حالت ») Do ( به مفهوم « در داخل حالت ») On Exit ( به مفهوم « خروج از حالت ») اينها سه لغت كليدي كليدي در رشنال رز مي باشند و هنگام تعريف State مي توان آنها را با استفاده از امكانات رشنال رز مشخص نمود.

اسلاید 157: مدلسازي رفتاري با On Entry ؛ فعاليت فرمان كنترل كارت انجام مي شود. اگر به دياگرام توالي توجه كنيد، در داخل متد تشخيص اتومبيل بلافاصله متد « () تشخيص كارت.كارتخوان » فراخواني مي گردد. اين فراخواني بصورت فرمان كنترل كارت : On Entry مشخص گرديده است. مسلماً دراينجا مي بايست در «انتظار پاسخ» از دستگاه كارتخوان بمانيم. لذا اين انتظار در دو حالت صورت مي گيرد و به صورت انتظار پاسخ : Do درداخل حالت مشخص شده است. اگر به دياگرام توالي بازگرديم، مشاهده مي كنيم كه با حركت اتومبيل، پيام بستن در با فرمان «بستن درب.درب» به انجام مي رسد كه اين رويداد حركت (پيام حركت) نيز موجب مي شود كه به حالت جديد «بستن در» واردشويم.

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

اسلاید 159: مدلسازي رفتاري با توجه به دياگرام ص 466 كتاب شكل 4-14 مشاهده مي نماييد كه : در ابتداي كار، كتاب در وضعيت « در قفسه » قراردارد. با رويداد borrow (تقاضاي امانت)، نسخه كتاب (A copy) در حالت «در امانت» قرارمي گيرد و بلافاصله نسخه تتا از شيء كتاب در خواست مي كند كه اين نسخه را جزو تعداد نسخه هاي درامانت قراردهد. توجه داشته باشيد كه از كتاب مهندسي نرم افزار 5نسخه (كپي) ممكن است در كتابخانه موجود باشد. در اينجا شئ كتاب، شاخص كتاب مهندسي نرم افزار است و شيء كپي شاخص نسخه هاي كتاب است كه بطور فيزيكي در كتابخانه موجود هستند.

اسلاید 160: مدلسازي رفتاري اگر به شكل دقت كنيد؛ABEvent [Condition] / Activity بر روي خط واصل، فعاليتي است كه موجب مي شود نسخه كتاب از حالت « در قفسه » به حالت « در امانت » واردشود. فعاليت؛ book.Borrow است. معمولاً در حالت كلي برروي خطوط ارتباطي در دياگرام حالت، event و درصورت وجود، /activity و در صورت وجود شرايط؛ [condition] قرارمي گيرد.

اسلاید 161: مدلسازي رفتاري در دياگرام توالي كه در شكل 4-1 از فصل 1 كتاب ص 384 مشخص شده، فرم سفارش «orderform» با پيام Show() به نمايش درمي آيد (orderform.show()) . اين رويداد موجب مي شود كه orderform در حالت دريافت مشخصات مشتري، يافتن مشخصات در پرونده مشتريان (CustomerFind(Cno)) و سرانجام درج جزئيات كلي سفارش ؛ در پرونده سفارش قرارگيرد. شيء order پس از اينكه جزئيات كلي سفارش را در پرونده سفارش درج نمود، تابع getArtical() را از orderform فراخواني مي كند. در اينجا نيز سر فلش به سمت كلاس TOrderform است.

اسلاید 162: مدلسازي رفتاري بدين ترتيب دو رويداد به اين كلاس وارد مي شوند. يكي تقاضاي نمايش (show() ) ديگري تقاضاي دريافت جزئيات قلم سفارش (getArticles() ) getArticles رويداد دومي است كه موجب تغييرحالت اين كلاس مي گردد. بنابراين بصورت زير دو رويداد ورودي مشخص مي شوند.Orderform : TOrderformShow()GetArticle (Article info)

اسلاید 163: مدلسازي رفتاري دياگرام حالت يا State diagram آن بدينصورت خواهدبود : Show ()getArticle ()تاييد سفارش دهندهدريافت جزئيات سفارششروعخاتمه هر متد واردشونده به كلاس، موجب تغيير حالت آن مي گردد.

اسلاید 164: Component View در Component view قطعات برنامه مشخص مي شوند. بدين ترتيب كه مشخص مي كنيم يك پروژه از چه فايلهايي تشكيل شده است. براي مثال : زبان پاسكال را در نظر بگيريد. يك پروژه (prj) پاسكال از تعدادي unit باضافه يك Main Program تشكيل مي شود.معمولاً براي هر كاربر يك برنامه مستقل نصب مي شود و همه كاربرها ازطريق يك بانك اطلاعاتي مشترك با يكديگر داده رد و بدل مي كنند.

اسلاید 165: Component View برنامه ها در اينجا مجزا هستند. هر كدام بصورت يك Project. براي نمونه « در سيستم كارت ساعت » سه زيرسيستم : Guard Modules (پيمانه نگهباني) Employment Modules (پيمانه كارگزيني) Employs Modules (پيمانه واحدهاي كارمندي) مشخص شده است. براي Employment Module ، پيمانه ها به شكل صفحه بعد مشخص مي گردند. پيمانه ها را مي توانيد در ص 256 كتاب بيابيد.

اسلاید 166: Component View ما در اصل فايلهاي برنامه را مشخص مي كنيم. در هر فايل، يك Component به عنوان « برنامه اصلي » مشخص مي شود. شكل برنامه اصلي بدين صورت است :قطعه معمولي به اين صورت است : نوع ديگر از قطعات Task ها هستند :

اسلاید 167: Component View Task ها قطعاتي هستند كه بصورت يك Trend به موازات برنامه اصلي به اجرا در مي آيند. در اين مرحله هر قطعه يك فايل برنامه مي باشد. براي آن مي بايست اولاً زبان برنامه سازي را مشخص نمود. براي نمونه، براي سيستم « ثبت سفارش » : همانگونه كه در كتاب مشخص شد، يك Component بنام OrderSubSystem مشخص گرديده است. با click روي آن، يك فرم باز مي شود. در داخل آن مي توانيد زبان برنامه سازي را تعيين كنيد.

اسلاید 168: Component View براي مثال : اگر زبان برنامه نويسي را VB انتخاب كنيد، تحت گزينه اي بنام Realize ليست تمامي كلاسها نمايان مي گردد. با R_click بر روي هر كلاس، مي توانيد آن را به component ، Assign كنيد. در اصل برنامه شيء گرا به ما مي گويد كه هر Module (پيمانه يا قطعه) شامل تعدادي كلاس است. براي هر قطعه كلاسهايي را انتخاب مي كنيم كه در ارتباط تنگاتنگ با يكديگر باشند. براي مثال، « پيمانه امور آموزش » داراي Objectهايي است كه بسيار يكديگر را فراخواني مي كنند.

اسلاید 169: Component View پس معيار Assignكردن كلاسها به يك قطعه، ميزان همكاري كلاسها با يكديگر است. براي مثال، در « سيستم آموزش» قطعه ثبت نام شامل كليه كلاسهايي است كه كه در ارتباط تنگاتنگ براي عمل ثبت نام هستند. بعداز اينكه به كليه قطعه ها، كلاسها تخصيص شد، مرحله Forward Engineering يا مهندسي روبه جلو براي توليد كد از مدل آغاز مي شود. توجه كنيد بايد كليه كلاسها، متدها فيلدهاي كلاس، پارامترهاي ورودي و خروجي متدها قبلاً به زبان فارسي كاملاً توضيح داده شده باشد.

اسلاید 170: Component View براي مثال : اگر كلاسي بنام Order داريد، بايد بر روي كلاس click كرده و شرحي براي كلاس بنويسيد. براي هر Attribute (فيلد كلاس) مثل Number يا تاريخ توضيح داده باشيد. تمام اين Comment ها درهنگام Code Generation در كد مثلاً VB گنجانده مي شوند. براي توليد كد، از منوي Tools گزينه VB و سپس گزينه Update Code را انتخاب نماييد. به اين ترتيب سيستم شروع به توليد كد VB مي نمايد.

اسلاید 171: پايان جلسه آخر يا حق ... يك عمر طول كشيد تا بفهمم لازم نيست همه چيز را بفهمم...

اسلاید 172: Rosegroup_Shabestarبه پايان آمد اين دفتر حكايت همچنان باقيست...كار ما نيست شناسايي راز گل سرخ ...كار ما نيست شناسايي راز گل سرخ ...كار ما نيست شناسايي راز گل سرخ ...كار ما نيست شناسايي راز گل سرخ ...كار ما نيست شناسايي راز گل سرخ ...