1 / 35

Unified Modeling Language (UML)

Unified Modeling Language (UML). CSCI 6050 Software Engineering January 19, 2005 Trentin Bishop Micah Lewis Amit Mathew Rufin Tshinanga Stephen Upchurch. Why do we need models?. To create a simplified representation of a real software system. What is UML?.

Jims
Télécharger la présentation

Unified Modeling Language (UML)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Unified Modeling Language (UML) CSCI 6050 Software Engineering January 19, 2005 Trentin Bishop Micah Lewis Amit Mathew Rufin Tshinanga Stephen Upchurch

  2. Why do we need models? To create a simplified representation of a real software system

  3. What is UML? • A popular, standardized modeling language for object-oriented software • The Object Management Group (OMG) is the group that dictates the UML standard • Created by Grady Booch, James Rumbaugh, and Ivar Jacobson

  4. UML Models • Functional Models • Use case diagrams • Structural Models • Class diagrams • Dynamic/Behavioral Models • Statechart diagrams • Sequence diagrams • Activity diagrams

  5. UML Conventions • Rectangles are classes or instances • Ovals are functions or use cases • Instances are underlined • Types are not underlined

  6. Poseidon for UML • Available from http://www.gentleware.com/ • Get the free Community Edition • Caveat: Slow on older computers, a little sluggish on newer ones

  7. Poseidon for UML demo

  8. Use case diagrams

  9. Use case diagrams • Describes the functional behavior of the system from the user’s point of view • Used during the requirements elicitation stage to represent external behavior • Actor: User, external system, or a physical environment • Use case: a class of functionality provided by the system as an event flow • Has entry and exit conditions, flow of events, and participating actors

  10. Use case diagram symbols Actor Relationships Use case System

  11. Use case example Report location Find arrival times Passenger GPS System Report error

  12. Use case example explanation • Actors don’t have to be people • Shows how actors interact with the system • Three use cases

  13. Class diagrams

  14. UML Class Diagram • Depict the classes within the model • Illustrates the class attributes (member variables), operations (member functions), and relationships with other classes

  15. Class 1 Class 2 Class 1 Class 2 Class 1 Class 2 Class 3 UML Class Diagram Symbols CLASS Class Name Number of links each class object may contain # Composition relationship Class 1 is composed of a Class 2 Aggregation A collection of other classes Inheritance relationship Class 2 and Class 3 derive from Class 1

  16. SimpleWatch 1 1 1 1 2 1 2 1 PushButton Display Battery Time UML Class Diagram Example SimpleWatch class contains 2 PushButtons 1 Display 2 Batteries 1 Time

  17. UML Class Diagram Example http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htm

  18. UML Class Diagram Example The class Order is associated with the class Customer The multiplicity denotes the number of objects For example, Order object can be associated only one customer but a customer can be associated to many orders

  19. Statechart diagrams

  20. UML Statechart Diagram • A statechart diagram shows the behavior of classes in response to external stimuli • This diagram models the dynamic flow of control from state to state within a system.

  21. Basic Statechart Diagram Symbols and Notations • States represent situations during the life of an object • A solid arrow represents the path between different states of an object • A filled circle followed by an arrow represents the object's initial state. • An arrow pointing to a filled circle nested inside another circle represents the object's final state.

  22. State: Display alarm time Display clock time No sound Sound on Buzzing Playing radio Transition: On Off Hold alarm Alarm switch off Change Hrs/Min Radio Activity: Do/wait for clock time to alarm time Description of state chart diagram

  23. Sequence diagrams

  24. Sequence Diagrams • Describe the dynamic behavior between actors and the system and between objects of the system • Used during requirements analysis • To refine use case descriptions • To find additional objects • Used during system design • To refine subsystem interfaces

  25. Sequence diagram notation • Classes are represented by columns • Messages are represented by arrows • Activations represented by narrow rectangles • Lifelines are represented by dashed lines

  26. Example:- sequence diagram for SimpleWatch O - | - :SimpleWatch:Display:Time / \ | | | :WatchUser | | | pressButton1() blinkHours() | ――――――― ―――――――――――― | pressButton1() | blinkMinutes() | | ――――――― ―――――――――――― | | pressButton2() | | | ――――――― | incrementMinutes() | ―――――――――――――――――――――――――――――― | | refresh() pressButton1And2() | ――――――――――――― ――――――― | | commitNewTime() | ――――――――――――――――――――――――――――――― | stopBlinking() ―――――――――――――

  27. Example cont. -The left-most column represents the timeline of the WatchUser who initiates the use case. -The other columns represent the timeline of the objects that participate in this use case. References: Page 33 Object-Oriented Software Engineering Bernd Bruegge, Allen H. Dutoit

  28. Activity diagrams

  29. Activity Diagrams • Used to represent the behavior of a system in terms of activities and their precedence constraints • Compared to flowchart diagrams because … • They can be used to represent control flow (order in which operations occur) • They can be used to represent data flow (objects exchanged among operations) The completion of an activity triggers an outgoing transition which may initiate another activity

  30. Symbols - Synchronization of the control flow - Activities in the system - Transitions between activities

  31. Activity Diagram Example Allocate Resources Open Incident Coordinate Resources Archive Incident Document Incident

  32. Example Explained • The 1st activity initiated is Open Activity. After all the operations in this activity have been executed, the activities Allocate Resources, Coordinate Resources & Document Incident are initiated. (Note: There is a complex transition between Open Activity and the next three activities). • These three activities may occur in sequence or concurrently. • Even if the three activities don’t occur concurrently, Archive Incident is not initiated until all three have been completed.

  33. References • B. Bruegge, A. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns and Java, Second Edition. 2003.

  34. Questions?

More Related