DOCSLIB.ORG

Today's Lecture Package Diagrams W

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Today's Lecture Package Diagrams W Today’s Lecture INF 111 / CSE 121: } UML Software Tools and Methods ● Package Diagrams ● State Transition Diagrams ● Activityyg Diagrams Lecture Notes for Summer Quarter, 2008 ● Communication Diagrams Michele Rousseau Set 8 – UML – Part 2 Lecture Notes 8 - UML 4 Announcements Package Diagrams } UML Links: } What is a package? } http://dn.codegear.com/article/31863#us ● A construct that enables you to organize e-case-diagram model elements into groups ● Classes or use cases } A package diagram isadiagramwithis a diagram with packages and their dependencies Lecture Notes 8 - UML 2 Lecture Notes 8 - UML 5 Previously in INF 111/CSE121… Why use package diagrams? } UML } Increases the level of abstraction for ● Class Diagrams complex diagrams ● Use Case Diagrams ● Sequence Diagrams } Depict a high-level overview of your requirements or architecture/design ● A collection of use case or class diagrams } To logically modularize a complex diagram } To organize Java source code Not limited to class and use case diagrams Because diagrams can get messy Lecture Notes 8 - UML 3 Lecture Notes 8 - UML 6 1 Package Diagrams: Notation Class Diagram Example } Represented as tabbed folders } Can use visibility markers + Public -Private # Protected Lecture Notes 8 - UML 7 Lecture Notes 8 - UML 10 Relationships Some Basic Tips on Packages Two Types } } Dependencies Use Simple, Descriptive Names ● Changes to one package } Use when you need to Simplify affects another Diagrams ● Import is one type that grants access } Packages Should be Cohesive ● Represented by a dashed } Avoid Cyclic Dependencies Between arrow Packages } Generalizations ● Represented with an open arrow just like in previously discussed diagrams Lecture Notes 8 - UML 8 Lecture Notes 8 - UML 11 Use Case Example Types of UML Diagrams Structure . Behavior . (6 types) (4 types) } Class diagrams } Activity diagram } } Object diagram Use Case diagram } State machine diagram } Packaggge diagram } Interaction diagrams } Composite structure ● Sequence diagram diagram ● Communication diagram ● Interaction overview } Component diagram diagram } Deployment Diagram ● Timing diagram If the appropriate diagram is not part of UML use it anyways Lecture Notes 8 - UML 9 Lecture Notes 8 - UML 12 2 State Transition Diagrams State Transition EX: } State Transition Diagrams show the dynamic Digital Watch behavior of a class instance or of a whole system } State: the duration of time during which an object is doing an activity. } A state diagram is a graph in which ● nodes correspond to states and ● directed arcs correspond to transitions ● labeled with event names. When to use : Necessary for those objects whose behavior across many use cases needs to be understood Lecture Notes 8 - UML 13 Lecture Notes 8 - UML 16 State Transition Diagrams Actions } A short software process that executes immediately. } An event occurs at a point in time and } A transition may trigger an action. } May be triggered on entry or exit of states (instead of labeling ● transmits information from one object to another each incoming (entry) and outgoing (exit) transition with these actions). } An action occurs in response to an event and } An event may trigger an action without leaving the state, cannot be interrupted ● i.e., without triggering exit and entry actions as a self-transition would do. } An activity is a n ope rat io n wit h ce r tain } AtitiAn action may trigger even ts, usua llithbjtlly in other objects. duration that can be interrupted by another } Actions may take arguments. event } A guard is a logical condition placed before a transition that returns either a true or a false. Lecture Notes 8 - UML 14 Lecture Notes 8 - 17 State Transition Diagrams: Activities Notation } Can take “longer”, State Name ● i.e., they are processes which last as long as an object is in a certain state. } Are interruptible, } State symbol: Do/Activity ● i.e., an event causing a state transition may abort an Entry/Action activity. Exit/Action } May be constructed from a start and a final action. Event [Guard] / Action } Transition Symbol: Lecture Notes 8 - UML 15 Lecture Notes 8 - UML 18 3 Activity Diagrams Activity Diagram: } Describe ATM Ex. ● Procedural logic ● Business process ● Workflow } A flow chart with support for parallel behavior } Branches and Merges model the conditional bhbehav ior } Branch: has a single incoming transition multiple, conditional, outgoing transitions } Merge: where conditional behavior terminates Each branch has a corresponding merge } Represented as a Diamond Lecture Notes 8 - UML 19 Lecture Notes 8 - UML 22 Activity Diagram (2) Conditional Thread } Forks and Joins model parallel behavior There are some exceptions to the each } Fork: has a single incoming transition and fork having a corresponding join: multiple outgoing transitions (exhibiting parallel behavior) } Conditional Thread: A condition on } Join: syypnchronizes the parallel behavior ● All parallel behaviors complete at the join the thread originating from the fork } Represented as a thick line to create an exception for the join rule. Each Fork has generally has a corresponding ● If the condition is false then that condition Join is considered to be complete Lecture Notes 8 - UML 20 Lecture Notes 8 - UML 23 Activity Conditional Thread: Example Diagram: Order Ex. Lecture Notes 8 - UML 21 Lecture Notes 8 - UML 24 4 Superstates Swimlanes } What if you need to decompose your activity diagram? } Superstates ● You can show the superstate with the internal behavior inside or ● You can show these in a parent diagram ● You can also use explicit initial and final states Adv: you can decouple the parent from the subsidiary and use it in other contexts Lecture Notes 8 - UML 25 Lecture Notes 8 - UML 28 Atm Ex. Activity Diagram: Superstate Lecture Notes 8 - UML 26 Lecture Notes 8 - UML 29 Partitioning an Activity Diagram When do you use Activity Diagrams? Activity diagrams tell you what is } Modeling parallel behavior happening, but how do you know who } Analyzing a use case does what? ● Trying to understand what actions need to take (in programming – which class is place responsible for each activity) ● Determine behavioral dependencies } Swimlanes: group related activities into } Understanding workflow one column (usually organizationally) ● Documenting the logic of a business process ● You must arrange your diagram into vertical zones } Describing a complicated sequential separated by lines. algorithm ● Can be difficult with complex diagrams } Dealing with multi-threaded applications ◘ In this case use non-linear zones – better than nothing Lecture Notes 8 - UML 27 Lecture Notes 8 - UML 30 5 Not so good for From Use Cases to Code } Trying to see how objects collaborate ● Use an interaction diagram for that } Trying to see how an object behaves Select a Perform Perform over its life time use case Use Case Use Case Write Code (or scenario) Analysis Design ● Use a state diagram for that Lecture Notes 8 - UML 31 Lecture Notes 8 - UML 34 Communication Diagrams Use Case Analysis } Used to be known as Collaboration Diagrams (UML 1.x) – but modified for 2.0 For each use case in an iteration… } Show interactions between run-time elements 1. Create a use case realization } Similar to sequence diagrams, but ● Focus on objects roles & structure 2. Supplement the Use-Case ● Sequence diagram is better at visualizing processing over descriptions time ◘ if necessary It is an object diagram that shows message passing relationships 3. Find Analysis Classes from Use- Emphasis on the flow of messages among objects, Case Behavior rather than timing and ordering of messages } Sequence Numbers are on arrows rather than 4. Distribute Behavior to Analysis vertical order Classes Lecture Notes 8 - UML 32 Lecture Notes 8 - UML 35 Communication Diagrams: Ex 1. Use-Case Realization A use-case realization is a collection of UML diagrams which together validate that we have ● the classes Æ Class Diagrams (static relationships) ● responsibilities ● object interactions Æ Interaction Diagrams (dynamic relationships) – could be Sequence or Collaboration necessary to provide the behavior in our use case process. Lecture Notes 8 - UML 33 Lecture Notes 8 - UML 36 6 2. Supplement the Use-Case 4. Distribute Behavior to Analysis descriptions (if necessary) Class } Beef up your use-case descriptions } Sequence Diagrams ● Can include internal or non-visible behavior } Activity / State Diagrams of the system ● Do you need to do this for all of them? No! ÆInclude just enough detail to understand the classes you will need Lecture Notes 8 - UML 37 Lecture Notes 8 - UML 40 3. Find Analysis Classes from Next Use-Case Behavior } identify a candidate set of For each resulting analysis class analysis classes Describe the Class's Responsibilities } Analysis Class } Describe the Class's Attributes and Associations ●3 Categories ● Define Class Attributes ◘Entity Æ Business level ● Establish Associations between Analysis • Banking system Æ Customer, account, Classes transaction (e-commerce or old school) ● Describe Event Dependencies between ◘Controller Æ process & sequence aware Analysis Classes • Control & direct the flow of control on an } Establish Traceability execution sequence } Evaluate the Results of Use-Case Analysis ◘Boundary Æ I/O required by the s/w system Lecture Notes 8 - UML 38 Lecture Notes 8 - UML 41 Describe the Class’s Responsibilities Some Notes }Use nouns to determine } Simplify your diagrams using Class Nameclasses Description Responsibilities subsystems Customer Represents the human
Load more

Recommended publications
  • Uml.Sty, a Package for Writing UML Diagrams in LATEX
    uml.sty, a package for writing UML diagrams in LATEX Ellef Fange Gjelstad March 17, 2010 Contents 1 Syntax for all the commands 5 1.1 Lengths ........................................ 5 1.2 Angles......................................... 5 1.3 Nodenames...................................... 6 1.4 Referencepoints ................................. 6 1.5 Colors ......................................... 6 1.6 Linestyles...................................... 6 2 uml.sty options 6 2.1 debug ......................................... 6 2.2 index.......................................... 6 3 Object-oriented approach 7 3.1 Colors ......................................... 10 3.2 Positions....................................... 10 4 Drawable 12 4.1 Namedoptions .................................... 12 4.1.1 import..................................... 12 5 Element 12 5.1 Namedoptions .................................... 12 5.1.1 Reference ................................... 12 5.1.2 Stereotype................................... 12 5.1.3 Subof ..................................... 13 5.1.4 ImportedFrom ................................ 13 5.1.5 Comment ................................... 13 6 Box 13 6.1 Namedoptionsconcerninglocation . ....... 13 6.2 Boxesintext ..................................... 14 6.3 Named options concerning visual appearance . ......... 14 6.3.1 grayness.................................... 14 6.3.2 border..................................... 14 1 6.3.3 borderLine .................................. 14 6.3.4 innerBorder.................................
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • VI. the Unified Modeling Language UML Diagrams
    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis
    APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Sandeep K. Shukla, Chair Lamine Mili Alireza Haghighat Chao Wang Yi Deng April 3, 2015 Blacksburg, Virginia Keywords: AADL, CPS, Model-based code synthesis, correct-by-construction code synthesis, Polychrony, code generators, OSATE, Ocarina Copyright 2015, Matthew E. Anderson APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson (ABSTRACT) The development of high integrity embedded systems remains an arduous and error-prone task, despite the efforts by researchers in inventing tools and techniques for design automa- tion. Much of the problem arises from the fact that the semantics of the modeling languages for the various tools, are often distinct, and the semantics gaps are often filled manually through the engineer's understanding of one model or an abstraction. This provides an op- portunity for bugs to creep in, other than standardising software engineering errors germane to such complex system engineering. Since embedded systems applications such as avionics, automotive, or industrial automation are safety critical, it is very important to invent tools, and methodologies for safe and reliable system design. Much of the tools, and techniques deal with either the design of embedded platforms (hardware, networking, firmware etc), and software stack separately. The problem of the semantic gap between these two, as well as between models of computation used to capture semantics must be solved in order to design safer embedded systems.
    [Show full text]
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language
    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
    [Show full text]
  • UML Cheatsheet
    UML Cheatsheet Class Diagram Elements dependency multiplicity association Package::AbstractClass -Attribute : Type 1 -ClassAttribute : Type Parent Child parent child* +Operation(Arg:Type):Type #AbstractOperation * role Association generalization Class visibility 0..1 info <<interface>> Note ChildInfo SubClass Interface realizes qualified association dependency T 1 Interface ParameterizedClass Value key Implementor Operation(Arg: T) Operation2(): T Sequence Diagram Elements Object : Class Object2 object creation call(obj) new incoming message Object3 selfCall callback interaction frame return object destruction loop / alt / opt delete frame type {constraint} callUnderConstraint {alternative} callUnderAlternative (cc) 2006 Lou Franco - Some Rights Reserved - Attribution-NonCommercial-ShareAlike 2.5 (cc) 2006 Lou Franco - Some Rights Reserved - Attribution-NonCommercial-ShareAlike 2.5 http://creativecommons.org/licenses/by-nc-sa/2.5/ http://creativecommons.org/licenses/by-nc-sa/2.5/ Package Diagram Elements dependency Data View Model SQLServer Oracle Object Diagram Elements John : Child name = "John" parent: Parent Mary : Child name = "Mary" Use Case Diagram Elements system boundary actor 1 Library checkout 1 Membership <<include>> Common return start : Date Role Use Case Use Case renewal : Date * LendRecord Role Lendable due : Date <<include>> id 1 returned : Boolean newArrival : Boolean * LendRecord(lendable, member, date) calcDueDate(member): Date isDue() : Boolean Use Case Use Case renew(Date) * Role Book CD 1 Role * Member DVD (cc) 2006
    [Show full text]
  • What Is Package Diagram? How to Draw Package Diagram?
    Visual Paradigm Tutorial What is Package Diagram? How to Draw Package Diagram? What is Package Diagram? How to Draw Package Diagram? Written Date : July 29, 2014 At the beginning of the project, you only have a limited number of diagrams and everything is simple and beautiful. However, when time flies, more and more diagrams have been created and they start to become unmanageable. As a result, your project becomes hard to navigate and diagrams become difficult to locate when you want to review or make changes. How can we fix it up? We can make use of the Package Diagram to organize your diagrams into different packages. This helps you in categorizing your diagrams according to their natures, making them easier to be navigated and located. The Package Diagram also serves as a catalog for you to jump to the diagram that you want to look at. In this tutorial, we will show you how this can be done. Create Packages for your diagrams First, we need to have our packages ready. To create packages: 1. To create a Package Diagram, select Diagram > New from the toolbar. 2. In the New Diagram window, select Package Diagram and click Next. https://www.visual-paradigm.com/tutorials/packagediagram.jsp Page 1 of 11 Visual Paradigm Tutorial What is Package Diagram? How to Draw Package Diagram? 3. Enter Racing Game Packages as diagram name and click OK to confirm. 4. Click the Package button in diagram tool bar, then click on the blank area of the diagram to create the package. 5. Name the package as Race.
    [Show full text]
  • Getting Started with Sysml 3 This Chapter Provides an Introduction to Sysml and Guidance on How to Begin Modeling in Sysml
    CHAPTER Getting Started with SysML 3 This chapter provides an introduction to SysML and guidance on how to begin modeling in SysML. The chapter provides a brief overview of SysML, and then introduces a simplified version of the language we refer to as SysML-Lite, along with a simplified example, and tool tips on how to capture the model in a typical modeling tool. This chapter also introduces a simplified model-based systems engineering (MBSE) method that is consistent with the systems engineering process described in Chapter 1, Section 1.2. The chapter finishes by describing some of the challenges involved in learning SysML and MBSE. 3.1 SYSML PURPOSE AND KEY FEATURES SysML1 is a general-purpose graphical modeling language that supports the analysis, specification, design, verification, and validation of complex systems. These systems may include hardware, soft- ware, data, personnel, procedures, facilities, and other elements of man-made and natural systems. The language is intended to help specify and architect systems and specify their components that can then be designed using other domain-specific languages such as UML for software design and VHDL and three-dimensional geometric modeling for hardware design. SysML is intended to facilitate the application of an MBSE approach to create a cohesive and consistent model of the system that yields the benefits described in Chapter 2, Section 2.1.2. SysML can represent the following aspects of systems, components, and other entities: n Structural composition, interconnection, and classification n Function-based, message-based, and state-based behavior n Constraints on the physical and performance properties n Allocations between behavior, structure, and constraints n Requirements and their relationship to other requirements, design elements, and test cases 3.2 SYSML DIAGRAM OVERVIEW SysML includes nine diagrams as shown in the diagram taxonomy in Figure 3.1.
    [Show full text]
  • Standardized Technical Architecture Modeling Conceptual and Design Level
    Standardized Technical Architecture Modeling Conceptual and Design Level Version 1.0 March 2007 Copyright 2007 SAP AG. All Rights Reserved No part of this document may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
    [Show full text]
  • Examples of UML Diagrams
    UML Diagrams Examples Examples by Technology or Application Domain Online shopping UML diagrams Ticket vending machine UML diagrams Bank ATM UML diagrams Hospital management UML diagrams Digital imaging and communications in medicine (DICOM) UML diagrams Java technology UML diagrams Application development for Android UML diagrams Software licensing and protection using SafeNet Sentinel HASP security solution Examples by Types of Diagrams Activity diagram examples Class diagram examples Communication diagram examples Component diagram examples Composite structure diagram examples Deployment diagram examples Information flow diagram example Interaction overview diagram examples Object diagram example Package diagram examples Profile diagram examples http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 1 of 33 Sequence diagram examples State machine diagram examples Timing diagram examples Use case diagram examples Use Case Diagrams Business Use Case Diagrams Airport check-in and security screening business model Restaurant business model System Use Case Diagrams Ticket vending machine http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 2 of 33 Bank ATM UML use case diagrams examples Point of Sales (POS) terminal e-Library online public access catalog (OPAC) http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 3 of 33 Online shopping use case diagrams Credit card processing system Website administration http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 4 of 33 Hospital
    [Show full text]
  • UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process
    VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams – Package, component and Deployment Diagrams. INTRODUCTION TO OOAD ANALYSIS Analysis is a creative activity or an investigation of the problem and requirements. Eg. To develop a Banking system Analysis: How the system will be used? Who are the users? What are its functionalities? DESIGN Design is to provide a conceptual solution that satisfies the requirements of a given problem. Eg. For a Book Bank System Design: Bank(Bank name, No of Members, Address) Student(Membership No,Name,Book Name, Amount Paid) OBJECT ORIENTED ANALYSIS (OOA) Object Oriented Analysis is a process of identifying classes that plays an important role in achieving system goals and requirements. Eg. For a Book Bank System, Classes or Objects identified are Book-details, Student-details, Membership-Details. OBJECT ORIENTED DESIGN (OOD) Object Oriented Design is to design the classes identified during analysis phase and to provide the relationship that exists between them that satisfies the requirements. Eg. Book Bank System Class name Book-Bank (Book-Name, No-of-Members, Address) Student (Name, Membership No, Amount-Paid) OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) • OOAD is a Software Engineering approach that models an application by a set of Software Development Activities. YEAR/SEM: III/V CS6502-OOAD Page 1 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE • OOAD emphasis on identifying, describing and defining the software objects and shows how they collaborate with one another to fulfill the requirements by applying the object oriented paradigm and visual modeling throughout the development life cycles.
    [Show full text]