به نام خدا مقدمه ای بر Unified Modeling Language علیرضا کاظمی نیا All Models Are Wrong Some Models Are Useful. Origin unknown Today’s Topics • • • • • • • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion UML • در واقع مجموعه ای از زبان ها ( notationها و نمودار ها) است که هر کدام برای منظور خاص در موقعیت های خاص خود به کار گرفته می شوند. • UMLزبان بین املللی مهندس ی نرم افزار است. • UMLبر پایه ی ش ی گرایی می باشد. • ویرایش های مختلف آن از سال 1996تا کنون به وجود آمده اند و هم اکنون ویرایش 2.3آن جدیدترین ویرایش است. UML Diagrams The creators Today’s Topics • • • • • • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion Object Orientation • objectها را همه می شناسند .به اطراف خود نگاه کنید چه اشیایی می بینید؟ Object • اشیا در دنیای واقعی دو خاصیت دارند: Object Class or instance? Message • پیغام ها ،درخواست هایی هستند که در آن ها یک ش ی از یک ش ی دیگر می خواهد که کاری را انجام دهد .این پیغام دهی اغلب دو طرفه است یعنی یک ش ی می تواند هم گیرنده ی پیغام باشد و در جایی دیگر هم فرستنده ی پیغام باشد .این پیغام ها می توانند متد هایی را فراخوانی کنند و این امر در جای خود می تواند به تولید پیغام های جدیدی منجر شود. Encapsulation • encapsulationجزئیات پیاده سازی یک کالس را از اشیایی که به آن پیغام می فرستند پنهان می کند .به این ترتیب اشیا مجبور نیستند که نگران روش پیاده سازی شیی که به آن پیغام می فرستند باشند و این امر به ساده شدن پیاده سازی و تغییر در برنامه می انجامد. !Walk Inheritance • با استفاده از وراثت می تواند به صورت حالت خاص ی از یک کالس کلی تر تعریف شود که تمام حاالت و رفتارهای حالت کلی تر را دارد .به حالت کلی superclassو به حالت خاص subclassمی گویند .وراثت از تلف شدن وقت جلوگیری می کند (چرا؟). Polymorphism • امکان ارسال یک پیغام به چند گیرنده ی انجام شدن درخواست پیغام به روش های مختلف بسته به کالس گیرنده .چه جوری؟ hiss buzz moo miaow Today’s Topics • • • • • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion Class diagram Class Name Dog Attributes name: string color: string breed: string weight: float walk(int) bark() run(int) chase(object) getWeight(): float Operations Dog name: string color: string weight: float walk(int) bark() run(int) chase(object) getWeight(): float Person 1 name: string address: string phone: string weight: float work() Dog name: string weight: float walk(int) bark() run(int) chase(object) getWeight(): float Person 1 * name: string address: string phone: string weight: float work() Color red: int blue: int green: int alpha: int name: string 1 Dog Person … … … … * Collie Bulldog Poodle Color … Today’s Topics • • • • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion Sequence Diagram • کاربرد :توصیف نحوه ی تعامل اشیا با هم بر اساس زمان ،نشان دادن اشیا و lifelineآن ها و انتقال پیام ها بین اشیا. • در یک sequence diagramمی توان موارد زیادی را نشان داد که در زیر به آن ها اشاره می شود. Lifeline • نشان دهنده ی یک شرکت کننده در تعامل بین اشیا است .در واقع می توان گفت نشان دهنده ی یک ش ی یا موجودیت است. • lifelineرا به وسیله ی یک مستطیل که یک خط عمودی به آن متصل است نشان می دهند .در مستطیل نام موجودیت و نوع (کالس) آن مشخص می شود. Message • نشان دهنده ی ارتباط بین دو lifelineکه با فلش از فرستنده به گیرنده نشان داده می شود .این فلش یا باید به صورت مستقیم یا رو به پایین باشد و نمی توان آن را به صورت رو به باال نشان داد (چرا؟) • انواع مختلقی برای پیغام ها می توان در نظر گرفت: – – – – – تماس همگام ()synchronous call تماس ناهمگام ()asynchronous call ایجاد ()create حذف ()delete پاسخ ()reply Synchronous call • synchronous callدرخواست انجام یک عملیات است .پیغام فرستاده می شود و تا زمانی که جواب آن دریافت شود اجرا متوقف می شود. Asynchronous call • پیغام فرستاده می شود ولی اجرا متوقف نمی شود و انتظار برای رسیدن جواب رخ نمی دهد. Create • زمانی که پیغام createبه یک lifelineفرستاده می شود به آن lifelineگفته می شود که خود را ایجاد کند (?)ha • در دنیای واقعی این پیغام به runtime environment فرستاده می شود. Delete • از یک lifelineبه lifelineدیگر فرستاده می شود و نشان دهنده ی پایان عمر lifelineپذیرنده است .این پایان عمر با X نشان دادن می شود .در نسخه های قبلی UMLبه آن Stop گقته می شد. Reply • بدون شرح!!!!! Message by presence of events • بسته به اینکه ارسال و دریافت برای پیغام ها رخ داده باشد می توان آن ها را به 4نوع تقسیم کرد: – – – – پیغام کامل :هم ارسال و هم دریافت برای آن وجود دارد؛ پیغام گم شده :فقط رخداد ارسال برای آن وجود دارد؛ پیغام پیدا شده :فقط رخداد دریافت برای آن وجود دارد؛ پیغام ناشناخته :نه رخداد ارسال و نه رخداد دریافت برای آن وجود دارد؛ Messages by presence of events فرستنده مشخص نیست و فرض می شود خارج از محدوده ی نمودار قرار دارد. گیرنده مشخص نیست و فرض می شود پیغام به مقصد نرسیده است. Interaction fragment 1. Execution Specification • نشان دهنده ی قمستی از دوره ی زندگی یک موجودیت است که در آن مشغول به انجام کاری ،فرستادن سیگنال است یا منتظر پاسخ درخواست خود از یک موجودیت می باشد. Overlapping ES Execution Specification Interaction Specification 2. Destruction Event Interaction Specification 3. State Invariant • نشان دهنده ی یک محدودیت در زمان اجرا است .این محدودیت قبل از اجرای عمل مربوط سنجیده می شود. Combined Fragments Combined Fragments Combined Fragment Combined Fragment Combined Fragment Combined Fragment Combined Fragment Today’s Topics • • • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion Activity diagram Activity diagram Activity diagram elements Activity diagram elements Today’s Topics • • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion Use Case Diagram • کاربرد :توصیف مجموعه ای از اعمال ( )use caseکه یک سیستم ( )subjectمی تواند یا باید بتواند آن ها را در ارتباط با یک یا چند کاربر خارجی آن سیستم ( )actorانجام دهد. • هر use caseباید نتایج قابل مشاهده و با ارزش ی به actorها یا دیگر stakeholderهای سیستم ارائه دهد. Use Case Diagram • از use case diagramبرای بیان موارد زیر استفاده می شود: – نیازمندی های یک سیستم در حال ساخت – کارهایی که یک سیستم موجود می تواند انجام دهد. – چگونگی ارتباط برقرار کردن یک سیستم با محیط خودش • از use case diagramنباید برای نشان دادن حالت های استثایی استفاده کرد. Use Case Diagram • UCDها چهار عنصر اصلی دارند: • actorها که سیستم با آن ها فعل و انفعال دارد (چگونه بایدتشخیص داده شوند؟) • خود سیستم • use caseها یا خدماتی که سیستم می داند چگونه انجام دهد (چگونه باید تشخیص داده شوند؟) • relationshipهای بین عناصر Notations System or Subject Actor Pay Bill Use case Association Use Case Diagram • اگر یک use caseنشان دهنده ی یک سرویس خاص باشد (که جزئیات کمی را نشان می دهد) آنگاه باید این امکان وجود داشته باشد که یک actorتنها همان خدمت را در یک نشست ا ( )sessionاز سیستم درخواست کند مثال: • برای عکس گرفتن باید اول درپوش لنز را برداشت و بعد فالش را امتحان کرد و بعد از عکس اتمام کار درپوش لنز را گذاشت ولی آیا این کارها در یک sessionعکاس ی برای یک عکاس کافی است؟ Use Case Diagram • فعل و انفعال بین actorها را نمی توان در UCDنشان داد: اگر بخواهیم فعل و انفعال بین یک ،serverیک browserو یک کاربر (این فعل و انفعال به چه ترتیب است؟) را به وسیله ی یک UCDنشان دهیم شکل آن چگونه است؟ Use Case Diagram • باید به این نکته توجه داشت که یک UCDبا یک flowchart تفاوت دارد و هدف آن این است که تمامی کارهایی که یک سیستم می تواند یا باید بتواند انجام دهد را در سطح باال ( با جزئیات کم) نشان دهد .فایده ی این کار چیست؟ • با توجه به این هدف و تفاوت موجود نمی توان از UCDبرای نشان داده ترتیب فعالیت ها استفاده نمود. Relationships • • • • Association Generalization/Specialization <<extend>> <<include>> Generalization child use case : بین کالس هاستgeneralization • مثل . را به ارث می بردparent use case تمام خواص و رفتار های ]<<extend>> [3 • این رابطه به این معناست که یک use caseتحت شرایط خاص ی یک use caseدیگر را توسعه می دهد: Use Case Diagram • در توضیح شکل قبل می توان گفت که clientجزئیات حساب خود را می بیند و تحت شرایط خاص ی ممکن است سفارش هایی که به دست او نرسیده اند را نیز ببیند .این شرایط خاص از ا مستندات پروژه به دست می آیند مثال ممکن است در اینجا با کلیک کردن بر روی یک دکمه این کار انجام شود: 1. Client views account details. Extensions: 1a. If client clicks "Open Orders" link Client views open orders 1b. If client clicks "View history" link Client views history ] <<uses>> [1],[2یا >><<include • رابطه ی >> <<includeاز Xبه Yنشان می دهد که انجام X همیشه مستلزم آن است که Yحداقل یک بار انجام شود (ممکن است که Yچند بار انجام شود ولی حداقل یک بار را می توان تضمین کرد). >><<include >><<extend Generalization use caseپایه کامل نیست use case .پایه کامل است use case .پایه می تواند کامل باشد یا نباشد. included use case اجباری است و باید انجام شود. extended use case اختیاری و مکمل است. حداقل یک مکان مکان inclusionمعینی وجود ندارد ولی حداقل در یک extensionمعین وجود دارد. جا inclusionاتفاق می افتد. شرط معینی برای شرط extensionاختیاری است. inclusionوجود ندارد. اگر use caseپایه abstractباشد آنگاه specialized use case اجباری است. مکان معینی برای استفاده از specializationوجود ندارد. شرط معینی برای استفاده از specializationوجود ندارد. Brain buster • سه use caseزیر را با چه نوع ارتباطی باید به هم وصل کرد؟ چرا؟ *Payment *Cash payment * Credit payment ا مثاال خریدار زمانی که می خواهد مبلغ خرید خود را پرداخت کند متوجه می شود که نه به اندازه ی کافی پول نقد دارد و نه در کارت خود پول کافی دارد ولی مجموع پول نفد و موجودی کارت او برای پرداخت مبلغ خرید کافی است. Today’s Topics • Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion • The fundamental reason to use UML involves communication. … Natural language is too imprecise and gets tangled when it comes to complex concepts. Code is precise but too detailed. So I use UML when I want a certain amount of precision but I don't want to get lost in the details." Martin Fowler, Kendall Scott, 2000, UML Distilled: A Brief Guide to the Standard Object Modeling Language • "Different stakeholders are likely to prefer one view over the other. Some will prefer a big picture overview. Your fellow designers may want to examine your design in all its glory - and may not be satisfied with any level of detail you can show using UML. No single picture or diagram can communicate these different perspectives." Rebecca Wirfs-Brock, Alan McKean, 2002, Object Design: Roles, Responsibilities, and Collaborations • "The trouble comes when people feel compelled to convey the whole model or design through UML. A lot of object model diagrams are too complete and, simultaneously, leave too much out. ... Nor is UML a very satisfying programming language." Eric Evans, 2003, Domain-Driven Design: Tackling Complexity in the Heart of Software • "The vocabulary and rules of a language such as UML tell you how to create and read well-formed models, but they don't tell you what models you should build and when you should create them. That's the role of the software development process." Grady Booch, James Rumbaugh, Ivar Jacobson, 2005, The Unified Modeling Language User Guide Today’s Topics Unified Modeling Language introduction Object Oriented Analysis and Design Class Diagrams Sequence Diagrams Activity Diagrams Use Case Diagrams Conclusion