UML part I UML part I 1/41
UML part I 2/41 UML - Unified Modeling Language unified it can be shared among workers modeling it can be used for description of software model language it has defined structure
UML part I 3/41 UML properties Properties of UML: it s a formal language it s concise it s comprehensive it s scalable it s built on lessons learned it s the standard
UML part I 4/41 UML history Three amigos OOAD (Object-Oriented Analysis and Design) Grady Booch OOSE (Object-Oriented Software Engineering) Ivar Jacobson OMT (Object Modeling Technique) James Rumbaugh
UML part I 5/41 UML now OOSE Jacobson Directly Influenced UML 2.0 diagram types Use Case Class OOAD Booch Object OMT Rumbaugh Sequence State Machine Component Activity Brought about by the adoption of best practices across many other approaches Composite Structure Package Interaction Overview Timing Communication Deployment
UML part I 6/41 Degrees of UML Levels: UML as a sketch UML as a blueprint UML as a programming language
UML part I 7/41 Model views Logical View Process View Use Case View Physical View Development View Figure: Philippe Kruchten s 4+1 view model
UML part I 8/41 Components of UML elements relationships diagrams
UML part I 9/41 A First Taste of UML Notes additional comments that aren t captured in your diagrams Stereotypes signify a special use or intent <<actor>> Client Client
UML part I 10/41 Modeling Requirements Use Cases Use Case is a case (or situation) where your system is used to fulfill one or more of your user s requirements is a functional requirement does not specify what the system shall not do
UML part I 11/41 Modeling Requirements Actors Actors don t have to be actual people. should be treated as black boxes must interact with your system
UML part I 12/41 Use Cases Actors Identify a "thing" from your requirements Is a "thing" an actual person interacting with the system? Yes No Is a "thing" something that I can change within the system s design? No Yes A thing is not an actor A thing is an actor
UML part I 13/41 Use Cases Actors The more general "Person" actor Person The Generalization Arrow The more specialized "Student" actor Student Figure: Refining actors
UML part I 14/41 Use Cases Create a new personal Wiki Figure: Notation Use Case from the user s perspective is a complete use of the system consists of interaction with the system, as well as some output from that interaction must have very clear pass/fail criteria
UML part I 15/41 Communication Lines Create a new personal Wiki Administrator Figure: A communication line joins the actor to the use case communication between the actor and the use case an arrow at one end of communication line shows the flow of information between the actor and the use case, or show who starts the use case.
UML part I 16/41 System Boundaries Content Management System Create a new personal Wiki Administrator Figure: The Administrator actor is located outside of the CMS, explicitly showing that the system boundary box use cases must fall within the system boundary box
UML part I 17/41 Use Case Descriptions Use case description detail Related Requirements Goal In Context Preconditions Successful End Condition Failed End Condition Primary Actors Secondary Actors Trigger Main Flow Extensions What the detail means and why it is useful? Some indication as to which requirements this use case partially or completely fulfills. The use case s place within the system and why this use case is important. What needs to happen before the use case can be executed. What the system s condition should be if the use case executes successfully. What the system s condition should be if the use case fails to execute successfully. The main actors that participate in the use case. Often includes the actors that trigger or directly receive information from a use case s execution. Actors that participate but are not the main players in a use case s execution. The event triggered by an actor that causes the use case to execute. The place to describe each of the important steps in a use case s normal execution. A description of any alternative steps from the ones described in the Main Flow.
UML part I 18/41 A complete use case description Use case name Create a new Blog Account Related Requirements Requirement A.1. Goal In Context A new or existing author requests a new blog account from the Administrator. Preconditions The system is limited to recognized authors and so the author needs to have appropriate proof of identity. Successful End Condition A new blog account is created for the author. Failed End Condition The application for a new blog account is rejected. Primary Actors Administrator. Secondary Actors Author Credentials Database. Trigger The Administrator asks the CMS to create a new blog account. Main Flow Step Action 1. The Administrator asks the system to create a new blog account. 2. The Administrator selects an account type. 3. The Administrator enters the author s details. 4. The author s details are verified using the Author Credentials Database. 5. The new blog account is created. 6. A summary of the new blog account s details are emailed to the author. Extensions Step Branching Action 4.1. The Author Credentials Database does not verify the author s details. 4.2. The author s new blog account application is rejected.
UML part I 19/41 Use Case Relationships Content Management System Create a new personal Wiki <<include>> Check Identity Administrator <<include>> Author Credentials Database Create a new Blog Account Figure: The <<include>> relationship supports reuse between use cases
UML part I 20/41 Use Case Relationships Content Management System Create a new personal Wiki <<include>> Check Identity Administrator <<include>> Author Credentials Database Create a new Blog Account Create a new Editorial Blog Account Create a new Regular Blog Account Figure: Two types of blog account, regular and editorial, can be created by the Management System
UML part I 21/41 Use Case Relationships Content Management System Create a new personal Wiki <<include>> <<extend>> Record Application Failure Check Identity Administrator <<extend>> <<include>> Author Credentials Database Create a new Blog Account Create a new Editorial Blog Account Create a new Regular Blog Account Figure: The <<extend>> relationship comes into play to show that both the Create a new Personal Wiki and Create a new Blog Account use cases might occasionally share the application rejection recording behavior
UML part I 22/41 Activity Diagrams they belong to the process view they show high-level actions chained together to represent a process occurring in system simple notation
UML part I 23/41 Activity Diagrams example Ask System to Create new Blog Account Select Account Type Enter the Author s Details Verify the Author s Details [authorized] [not authorized] Create new Blog Account Reject Application Email Blog Account Summary to Author
UML part I 24/41 Activity Diagrams Activity name Action Activity frame Wash car Lather Rinse Dry Initial node Edge Activity final node
Activity Diagrams Figure: decision node Guard conditions: statements that evaluate to true or false examples of guard conditions: [Authorization], [wordcount >= 100], [wordcount > 0 & wordcount < 100] only one condition can evaluate to true UML part I 25/41
UML part I 26/41 Activity Diagrams Prepare Case Install Motherboard Install Drives Install Video Card and other Parts Prepare Motherboard Fork Join Figure: Both outgoing paths are followed at the fork
UML part I 27/41 Objects and pins Receive Order Request Request Approve Payment Submit Order Object node Figure: The Order object node emphasizes that it is important data in this activity and shows which actions interact with it Receive Order Request Order Order Approve Payment Submit Order Output pin Input pin Figure: Pins in this change request approval process allow finer-grained specification of input and output parameters
UML part I 28/41 Activity diagrams Calculate Total Send Request for Credit Card Approval Receive Response Upadate Order Status Send Signal Node Receive Signal Node Figure: Send and receive signal nodes show interactions with external participants
UML part I 29/41 Activity diagrams Other elements partitions (swimlanes) time events Calling Other Activities
UML part I 30/41 Sequence Diagrams logic view show runtime interactions between the parts that make up a system
UML part I 31/41 Sequence Diagrams Participants participant1:participantclass1 participant2:participantclass2 participants lifelines Figure: Participants in a Sequence Diagram
UML part I 32/41 Sequence Diagrams Participants Participant Names Admin :ContentManagementSystem admin:administrator :ContentManagementSystem ref cmsinteraction
UML part I 33/41 Sequence Diagrams Messages The Message Caller The Message Signature The Message Receiver participant1:participantclass1 participant2:participantclass2 message(arguments) Message Caller Activation Bar (optional) Return Arrow (optional) The Message The Message Receiver Activation Bar (optional) Figure: Sending a message
UML part I 34/41 Sequence Diagrams Messages Message Signatures dosomething() dosomething(number1:number, number2:number) dosomething():returnclass myvar = dosomething():returnclass
UML part I 35/41 Sequence Diagrams Messages A Synchronous Message An Asynchronous Message A Return Message <<create>> p1:class A Participant Creation Message <<destroy>> A Participant Destruction Message Figure: Types of message arrow for use on sequence diagram
UML part I 36/41 Sequence Diagrams Example The Create a new Regular Blog Account use case Main Flow Step Action 1. The Administrator asks the system to create a new blog account. 2. The Administrator selects the regular blog account type. 3. The Administrator enters the author s details. 4. The author s details are checked using the Author Credentials Database. 5. The new regular blog account is created. 6. A summary of the new blog account s details are emailed to the author.
UML part I 37/41 Sequence Diagrams Example Figure: The Create a new Regular Blog Account sequence diagram
UML part I 38/41 Sequence Diagrams Example Figure: The Create a new Regular Blog Account sequence diagram with Sequence Fragments
UML part I 39/41 Sequence Diagrams Example Figure: The Create a new Regular Blog Account sequence diagram with Sequence Fragments cont.
UML part I 40/41 Sequence Diagrams Example sd Select Blog Account Type <<actor>> admin:administrator :ContentManagementSystem createnewblogaccount() selectblogaccounttype(type) Figure: The Create a new Regular Blog Account sequence diagram with Sequence Fragments cont.
UML part I 41/41 Bibliography Miles R., Hamilton K.: Learning UML 2.0, Helion, Gliwice 2007