کارگاه مدلسازی

1. کارگاه مدلسازی استاد : مهندس رضایی دانشگاه جامع علمی کاربردی نیمسال اول 91-90

2. فصل 1

3. مبانی و دلایل ساخت مدلها • مدل نما یا تجسمی از یک واقعیت است. • 1دلیل برای مدلسازی • مدل را می سازیم تا درک بهتری از سیستمی که قصد ساخت آن را داریم داشته باشیم.(ساخت سیستم با کیفیت بهتر) • اهداف مدلسازی • مدلها به ما کمک می کنند تا یک سیستم را آنطور که هست و یا آنطور که می خواهیم باشد، مشاهده کنیم. • مدلها به ما امکان مشخص کردن رفتار و ساختار یک سیستم را می دهند.(منظور از رفتار خدمتی است که سیستم قرار است ارائه دهد و منظور از ساختار این است که سیستم از چه اجزایی ساخته شده و این اجزا به چه صورت به هم مرتبط شده اند. • مدلها به ما یک قالبی رائه می دهند که توسط آن قالب می توانیم محصول را بهتر بسازیم. • مدلها تصمیماتی را که ما می گیریم مستند می کنند.

4. *نکته: • ما برای سیستم های پیچیده مدل می سازیم چرا که درک و پیاده سازی تمام پیچیدگی های آن برای ما کار مشکلی است. • * انتخاب مدلهایی که برای ساخت یک محصول استفاده می شوند، کاملاً با نحوه ی ساخت محصول مرتبط است. • هر مدل می تواند در سطوح دقت مختلفی ساخته شود. • معمولاً در مراحل اولیه، مدلها به صورت کلی ساخته می شوند و سپس بر مبنای آنها طی مراحلی مدلهای تفصیلی ایجاد می شوند. • مدلهای مناسب، مدلهایی هستند که تطابق کامل با واقعیت دارند.(تطابق مدل با سیستمی که در نهایت تولید می شود.) • هیچ مدلی به تنهایی غالباً برای ساخت یک محصول کفایت نمی کند و در اکثر اوقات، ما مجبوریم مدلهای مختلفی را ایجاد کنیم.(مجموعه ای از مدلهای مختلف برای بخشهای مختلف سیستم)

5. در نرم افزار دو الگوی عمده برای ساخت مدل و جود دارد که عبارتند از : • Structural ساختاری • Objet Oriented شیء گرایی • در مدل ساختاری(ساخت یافته) نرم افزار از عناصر ریشه ای به نام procedure (ماژول یا function) ساخته می شود و تمرکز اصلی در این نوع مدلسازی بر مبنای جریان داده ها می باشد و مشکل این روش این است که در هنگام تغییرات نیازمندیها و بزرگ شدن سیستم پشتیبانی و نگهداری سیستم بسیار مشکل می شود و از طرف دیگر به دلیل عدم وجود قطعات پایه ای قابل استفاده مجدد یا classها و componentها فرآیند تولید، کندتر می باشد و مدلسازی شیءگرا، تأکید بر روی classها و رفتار آنهاست و تولید نرم افزار با استفاده از این نوع مدلسازی سریعتر و باکیفیت مناسب تری انجام می شود. • زبان UML زبانی است برای ساخت مدلهای رفتاری و ساختاری شیءگرا که عمدتاً در مدلسازی نرم افزار استفاده شده ، اما بعضاً می تواند در مدلسازی سایر محصولات نیز به کار گرفته شود.

6. فصل 2

7. مروری بر زبان UML • UML زبانی است که از آن برای مدلسازی استفاده می شود و جزئی از روال تولید یا process تولید نرم افزار است. زبان UML با processهای متفاوتی از قبیل فرآیند RUP و تا حدّی XP همگونی دارد و به عبارت کلی وابسته به یک فرآیند خاص نیست اما اگر بخواهیم در رابطه با تطابق UML با پروسس ها یا فرآیندهای تولید نرم افزار نکته ای را یادآوری کنیم، این مورد است که UML بیشترین همگونی را با processهای usecase driven (usecaseمحور) معماری محور، تکراری و افزونه ، بیشترین تطابق را دارد. • (UML با waterfall استفاده نمی شود.)

8. UML زبانی است برای مشاهده، مشخص کردن، ساختن و مستندسازی سیستم های مختلف بخصوص سیستم های نرم افزاری. • عناصر سازنده ی زبان UML : • Things (مؤلفه ها یا اشیاء) • Relationships (ارتباطات) • Diagrams (نمودارها) • Things به چهار دسته تفکیک می شود: • 1. Structural Things اشیاء ساختاری • 2. Behavioral Things اشیاء رفتاری • 3. Grouping Things اشیاء گروه بندی شده • 4. Annotation Things اشیاء آگاه کننده

9. Structural Things • اشیاء ساختاری همانند اسامی در مدلهای UML هستند. یعنی آنها غالباً قسمت ایستای(static) مدل ما را می سازند. • مدل پویا (dynamic) می تواند بسته به نوع نقش یا رفتار actorها تغییر کند. این پویایی مدل را می رساند. در زبان UML، هفت نوع مختلف اشیاء ساختاری وجود دارند که به ترتیب عبارتند از : • Class • Interface • Collaboration • Use cases • active classes • components • nodes • Structural Things • Structural things are the nouns of UML models. These include classes, interfaces, collaborations,use cases, active classes, components, and nodes.

10. Class • Class توصیفی از مجموعه ای از اشیاء است که دارای ویژگی ها، عملگرها، ارتباطات و مفاهیم یکسان هستند. • یک Class می تواند یک یا بیش از یک interface (رابطه) را پیاده سازی نماید. از لحاظ گرافیکی نمایش یک Class به صورت زیر است که در آن از یک BOX که به قسمتهای مختلفی تفکیک شده استفاده می کند. بالاترین قسمت Box نشان دهنده ی نام Class، قسمت بعدی نشان دهنده ی attributeها یا ویژگی های Class و قسمت بعد نشان دهنده ی رفتارها و توابع Class می باشد.

11. 2. Interface (واسط) • مجموعه ای از عملیاتی است که مشخص کننده ی سرویسی از یک class یا componentمی باشد. نمایش interface در زبان UML با یک دایره می باشد که در زیر آن نام interfaceذکر می شود. • 3. Collaboration (همکاری) • مجموعه ای از نقش ها و سایر اجزاست که با کمک یکدیگر و در کنار هم رفتاری را انجام می دهند که کاملتر و یا جامعتر از رفتار تک تک آن اجزاست. نمایش Collaborationدر زبان UML با یک بیضی نقطه چین همانند مثال زیر است.

12. 4. Usecase: • Usecaseها توصیف مجموعه ای از عملیات هستند که سیستم برای رسیدن به یک نتیجه ی مشخص و در ارتباط با actorهای خاصی انجام می دهد. • از Usecaseها برای نشاند دادن ساختار اشیاء رفتاری در یک مدل استفاده می کنیم. منظور این است که Usecase نشان دهنده ی نحوه ی انجام رفتارهای مهم در حوزه ی مورد نظر می باشد. نمایش Usecase با یک بیضی است که در داخل آن نام Usecase ثبت می شود.

13. سه مؤلفه بعدی عبارتند از : • Active classe کلاسهای فعال • Components مؤلفه ها • Nodes نودها • که هر سه آنها از لحاظ شکل شبیه classها بوده و در زیر به شرح آنها می پردازیم. • 5. Active classe کلاسهای فعال : • Class ماهیت اجرایی ندارد.(abstract مجرد است.) • Class,Active classeی است که objectهایی از آن کلاس وجود دارد که یک یا بیش از یک Process و یا thread از آنها در حال اجرا می باشد. کلاس اکتیو همانند classe با یک box نشان داده می شود که خطوط مرزی آن قطورتر رسم می شود.

14. 6. Components (مؤلفه ها): • یک component ، یک جزء فیزیکی و قابل تعویض از یک سیستم است که مجموعه ای از سرویس ها را ارائه می دهد. • Component ماهیت اجرایی دارد و می تواند خود شامل مجموعه ای از classها باشد. در زبان UML ، component را با شکل زیر نمایش می دهند.

15. 7. Node • Node یک مؤلفه ی فیزیکی بوده که در هنگام اجرای یک سیستم وجود دارد و حاوی عناصر سخت افزاری لازم برای محاسبه از قبیل cpuو memory می باشد. • Computer و router هر کدام یک نود هستند.(سخت افزارهایی که نرم افزارها روی آنها اجرا می شوند نود هستند.) نمایش نود با یک مکعب مربع می باشد که نام نود در آن ذکر می گردد.

16. مؤلفه های رفتاری • اشیاء رفتاری جزء پویا (Dynamic) زبان UML بوده و در حقیقت نشان دهنده ی افعال مدل ما می باشد و بیانگر رفتار در زمان و مکان مشخصی هستند. دو نوع اساسی از اشیاء رفتاری وجود دارند که عبارتند از : • 1. Interaction (فعل و انفعال، تبادل) • یک رفتاری است که شامل مجموعه ای از message هاست که بین مجموعه ای از اشیاء برای رسیدن به یک هدف مشخص ردّ و بدل می شود. نمایش Interactionتوسط یک پیکان توپر می باشد.

17. 2. ماشین وضعیت یا state machine : • یک ماشین وضعیت، رفتاری است که نشان دهنده ی مجموعه ای از حالتهاست که یک شیء و یا یک فعل و انفعال در سیر زندگی خود، در پاسخگویی به وقایع محیط بیرونی می تواند داشته باشد. • نمایش یک state machineبا یک box با گوشه های خمیده می باشد.

18. 3. Grouping Things (اشیاء دسته بندی): • از این دسته برای قرار دادن اجزای مختلف در یک قالب استفاده می کنیم و در زبان UML، تنها یک نوع از آنها وجود دارد که بسته یا package نام دارد. بسته یا package عبارت است از یک مکانیسم عمومی برای سازماندهی اشیاء در داخل گروهها. این اشیاء می توانند اشیاء ساختاری و یا رفتاری باشند. نمایش packageدر زبان UML به شکل زیر است:

19. 4. Annotation Things(اشیاء توصیفی): • اشیاء توصیفی قسمت شرح دهنده در زبان UML بوده و از آنها برای توضیح یا شرح بیشتر اشیاء استفاده می کنیم. یک شیء توصیفی اصلی در زبان UML به نام Note وجود دارد که با شکل گرافیکی زیر نشان داده می شود و در داخل آن هرگونه شرح یا توضیحی که کمک به شفاف شدن مدل کند، می توان ارائه داد.

20. جزء دوم از زبان UML، relationship(ارتباطات) است. • در زبان UML ، 4 نوع ارتباط به شرح زیر وجود دارد: • Dependency • Association • Generalization • Realization • این ارتباطات برای برقراری وابستگی بین قسمتهای مختلف زبان UML مورد استفاده قرار می گیرند که در زیر به شرح آنها می پردازیم. • 1. Dependency (وابستگی) : • وابستگی یک ارتباط بین دو مؤلفه یا دو چیز است که در آن اعمال تغییر بر روی یکی از آنها منجر به تغییر در دیگری می شود و آن را با نماد زیر(پیکان خط چین دار) نشان می دهیم.

21. 2. Association (همکاری): • Association یک ارتباط ساختاری می باشد که با یک link یا اتصال نشان داده شده و برای بیان ارتباط بین اشیاء مناسب است. • از لحاظ گرافیکی آن را با یک خط راست نشان می دهیم و تعداد کمیت هر شیء را نیز می توانیم ذکر کنیم. • 3. Generalization • که در آن ارتباط بین اشیائ را در حالتی نشان می دهد که یک شیء (فرزند) نمونه ی خاصی از شیء دیگری(والد) می باشد. • مثلاً انسان نمونه ای از یک جاندار است.

22. 4. Realization • که از آن برای برقراری ارتباط بین مجموعه ای از classifierها استفاده می کنیم. به طور کلی از این نوع ارتباط برای مقاصد زیر استفاده می کنیم: • برای نشان دادن ارتباط بین classها یا componentها با interfaceها • برای نشان دادن ارتباط بین Usecseها با collaborationها • جزء سوم و بسیار مهم زبان UML نمودارها هستند که در فصل آتی با تک تک آنها آشنا می شویم.

23. Usecase مشخص کننده ی رفتاری از سیستم و یا بخشی از سیستم است و شامل مجموعه ای از عملیات است که سیستم برای رسیدن به یک نتیجه ی خاص و ارائه ی آن نتیجه به یک actor انجام می دهد. • Actorها در خارج از سیستم قرار دارند و با سیستم در ارتباطند سرویسی ارائه داده یا سرویسی می گیرند . • از Usecaseها برای نشان دادن رفتار سیستم بدون در نظر گرفتن چگونگی آن رفتار استفاده می کنیم. • در Usecaseها نگرش ما با نگرش پیاده سازی فاصله دارد و در آن اصلاً به پیاده سازی و چگونگی آن رفتار فکر نمی شود. • Usecaseها به تولیدکنندگان و استفاده کنندگان از نرم افزار دید واحد و مشترکی در رابطه با امکانات نرم افزاری که قرار است ساخته شود می دهد. • یک Usecase شامل مجموعه ی فعل و انفعالاتی است که بین سیستم و محیط بیرونی آن(actorها) انجام می شود. • عوامل بیرونی(actorها) می توانند انسان ، سیستم های نرم افزاری، سخت افزاری و حتی زمان هم باشد. یک Usecase نشان دهنده ی حجم مشخصی از کارهایی است که یک سیستم انجام می دهد.

24. Actorها و usecaseها :

25. Ac tor : • Actorها معرّف نقشهایی هستند که این نقشها می توانند با سیستم ارتباط برقرار کنند. به صورت نمونه ، Actorها شامل انسان ها،سایر سیستم های نرم افزاری و یا سخت افزاری می باشند و نکته ی بسیار مهم در ارتباط با آنها این است که آنها در خارج از سیستم زندگی می کنند.(Actor موجودیتی است در خارج از سیستم که با عناصر سیستم ارتباط برقرار می کند. • برای معرفی Actorها از نماد آدمک استفاده می کنیم و بین Actorها می تواند ارتباطی از جنس generation(ارث بری) وجود داشته باشد. • ارتباط بین Actorها و usecaceها توسط ارتباطی است به نام association یعنی بین Actor و usecase وابستگی وجود ندارد بلکه تنها می توانند با هم ارتباط برقرار کنند. • (با هم مرتبطند ولی به هم وابسته نیستند.)

26. Usecaseها و جریان های وقایع: • یک usecase نشان می دهد که یک سیستم یا زیرسیستم یا interface چه کاری انجام می دهد بدون آنکه وارد جزئیات تفصیلی آن شود.(usecase می تواند در سطوح abstraction ، سیستم ،زیرسیستم یا interface اجرا شود.) • یعنی یک شمای کلی از سرویس قابل ارائه توسط آن سیستم را به نمایش می گذارد و وارد جزئیات آن نمی شود. • در کنار یک نمودار usecase نیاز داریم شرح یا توضیح اضافه ای داشته باشیم که عملکرد usecase را به شفافی نشان می دهد.(عملیات ذکر شده را به صورت ریزتر و جزئی تر بیان کند.) • با ذکر جریان های اطلاعاتی می توان عملیات یک usecase را تشریح کرد. • هر usecase دارای یک جریان اصلی و احتمالاً تعدادی جریان فرعی می باشد. • جریان اصلی انجام کلیه ی فرایندها در داخل usecase به صورت ایده آل می باشد. • جریان فرعی : جریانی است که به هر علت نحوه ی انجام کار یا رفتار سیستم را از حالت ایده آل یا صحیح خارج می کند.

27. برای بیان یا نشان دادن جریان ها در ساده ترین حالت می توان از متون(context) استفاده کرد. جریان اصلی برداشت پول از سیستم ATM: • کاربر کارت را وارد دستگاه ATM می نماید. • پیغام خوش آمد ظاهر می شود. • انتخاب زبان مورد نظر . • صفحه ی ورود رمز ظاهر می شود. • کاربر رمز را وارد می کند. • رمز به سرور ارسال شده و پیغام خوش آمد ورود به سیستم ظاهر می شود. • کاربر عملیات مورد درخواست خود را انتخاب کرده و مبلغ مورد نظر را انتخاب می کند. • مبلغ درخواستی با موجودی چک می شود. • مبلغ درخواستی از موجودی کسر می شود. • ATM پول را به کاربر پرداخت کرده و رسید ارائه می دهد. • ATM کارت را به کاربر برمی گرداند.

28. هر گونه اتفاقی که سیستم را از روال صحیح انجام آن رفتار بازدارد جریان فرعی است مثل صحیح نبودن رمز ،عدم اتصال به سیستم شتاب، کسر موجودی. • برای بیان جریان اصلی یا جریانات فرعی می توان از شبه کد(sudeo code) هم استفاده کرد. • ترتیب توالی جریانات می تواند در کیفیت سیستم تأثیرگذار باشد. • مراحل مدل کردن رفتار یک سیستم(سیستم،زیرسیستم،class ، interface) : • مدل کردن (business model ، requirement) • 1. مشخص کردن actorهایی که با آن عنصر (سیستم،زیرسیستم،actor،interface) ارتباط برقرار می کند. Actorهای نمونه می تواند شامل گروهی باشد که نیاز به برقراری ارتباط متقابل با سیستم برای ارائه ی سرویس های سیستم دارد. • Actorها و سیستم نیاز متقابل یا دوطرفه به هم دارند. • 2. سازماندهی actorها با مشخص کردن نقش های عمومی و نقش های خاص (admin و user که admin خود نوعی از نوعی از user است.) • باعث می شود ارث بری درست پیاده سازی شود.

29. دیدن وراثت باعث می شود حجم کدی که تولید می شود کم شود.(user پودمانی و user ترمی ثبت نام یکسان و انتخاب واحد جداگانه دارند. می توان از یک کد ثبت نام برای هر دو استفاده کرد به جای تکرار کد.) • 3. برای هر actor، راه هایی که آن actor با آن جزء یا قسمت ارتباط برقرار می کند را مشخص می کنیم و ارتباطاتی که باعث تغییر حالت آن عنصر یا جزء می شود را می بینیم. و یا ارتباطاتی که در پاسخ به وقایع خارجی می تواند اتفاق بیفتد را نیز در نظر می گیریم. (ورود به یک سیستم با لاگین user یا admin) • 4. علاوه بر این راه های خاصی که actor با آن جزء ارتباط برقرار می کند را در صورت لزوم در نظر می گیرد.(مثال یک actorی به نام user قصد login شدن به سیستم را دارد راه اول ورود username و password است . راه دیگر استفاده از اثرانگشت و راه دیگر استفاده از سیستم تشخیص چهره می باشد. • Actor دانشجو و usecase انتخاب واحد: • انتخاب واحد اینترنتی • انتخاب واحد دستی • واگذاری آن به مدتی بعدهمه ی آنها باید به طور همزمان دیده شوند.

30. سازمان دهی رفتارها به صورت usecaseها و برقراری ارتباطات بین usecase ها که عمدتاً شامل ارتباطات include و extend هستند. • به طور خلاصه در ارتباط include ما انجام یک رفتار را در داخل رفتارهای دیگر تکرار می شود را شناخته و آن را بصورت یک رفتار مجزّا انتخاب می کند و در ارتباط extend حالتهای مختلفی که یک رفتار می تواند صورت پذیرد را بررسی می کنیم. • Extend(خرید کالا یا خودمان برای خرید کالا برویم یا سفارش بدهیم کالای مورد نظرمان را با پیک به ما برسانند. عمل خریدن در هر دو مورد اتفاق میفتد اما به طرق مختلف.)