UML Overview 1 UNIFIED Modeling Language OMG adopted

  • Slides: 52
Download presentation
UML Overview 1

UML Overview 1

UNIFIED Modeling Language OMG adopted UML in November 1997 as the standard for object-oriented

UNIFIED Modeling Language OMG adopted UML in November 1997 as the standard for object-oriented modeling m Combines commonly accepted concepts from many OO methods m m Seamless from requirements to deployment m Applicable to any domain m m Language and platform independent Usable with any development process UML Overview 2

Unified MODELING Language All engineering disciplines have adopted modeling techniques m Allows to capture

Unified MODELING Language All engineering disciplines have adopted modeling techniques m Allows to capture the important aspects of a system while omiting the rest m m Model is easier to use than final system Help all software systems stakeholders understand what the system will be and what are the possible options available m UML Overview 3

Unified Modeling LANGUAGE Language for: Visualizing: Graphical models with precise semantics Specifying: Models are

Unified Modeling LANGUAGE Language for: Visualizing: Graphical models with precise semantics Specifying: Models are precise, unambigous and complete to capture all important Analysis, Design, and Implementation decisions. Constructing: Models can be directly connected to programming languages, allowing forward and reverse engineering Documenting: Diagrams capture all pieces of information collected by development team, allowing to share and communicate the embedded knowledge. UML Overview 4

UML Bird’s Eye View • Building Blocks: m Things: abstractions, main concepts in a

UML Bird’s Eye View • Building Blocks: m Things: abstractions, main concepts in a model m Relationships: tie things together m Diagrams: group interesting collections of things UML Overview 5

UML in a Nutshell m Static Structure m Dynamic Behavior m Model Management m

UML in a Nutshell m Static Structure m Dynamic Behavior m Model Management m Extensibility Constructs UML Overview 6

Diagrams in the UML • • • Class diagram Object diagram Use case diagram

Diagrams in the UML • • • Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram UML Overview 7

Things in the UML • Structural Things (7) static part of a model, conceptual

Things in the UML • Structural Things (7) static part of a model, conceptual or physical elements m nouns of UML Models • Behavioral Things (2) m m dynamic parts of models verb, representing behavior over time and space • Grouping Things (1) m Organizational parts of models, decomposition element • Annotational Things (1) m explanatory parts of models, comments about other elements m UML Overview 8

Behavioral Modeling m m m Use Cases / Use Cases Diagrams Interactions / Interaction

Behavioral Modeling m m m Use Cases / Use Cases Diagrams Interactions / Interaction Diagrams Activity Diagrams UML Overview 9

Use Cases m m Description of a set of sequences of actions, that a

Use Cases m m Description of a set of sequences of actions, that a system performs to yield an observable result to an enduser Categories of interactions between the system to be built and external actors m Identify high-level services provided by the system m Specify the behavior of a system m Popularized by Ivar Jacobson with Objectory m Have been adopted by or have influenced many methods (eg. OMT, Fusion, Booch) UML Overview 10

Use Cases (cont. ) m m m Can be applied to whole system as

Use Cases (cont. ) m m m Can be applied to whole system as well as part of system such as a subsystem or a class Sources of integration tests and system tests May have variants: specialized use cases or extension of use cases. m Do not specify any implementation detail m Main communication tool with end-user m Each use case must have a name (simple or path name) UML Overview 11

Actors m Objects outside the system which play a particular role m Represent the

Actors m Objects outside the system which play a particular role m Represent the user(s) of the system m Interact with the system through use cases m May participate in more than one use case m m May or may not be represented as a class or object in the object model Also known as agents (Jacobson) UML Overview 12

UML Use Case Graphical Representation Storage depot system Delivery Collection Clerk Status Storage Use

UML Use Case Graphical Representation Storage depot system Delivery Collection Clerk Status Storage Use case Manager Actor UML Overview 13

Why Modeling Use Cases m m m Use Case model describes WHAT the system

Why Modeling Use Cases m m m Use Case model describes WHAT the system will do at a high-level User focus - Capture requirements from user's perspective. - Users are involved. Goal is to scope the project and give the application some structure -Use Cases are the unit of estimation -Uses Cases are smallest unit of delivery -One way of estimating the percentage of requirements captured. -Prioritizing use cases for "phased delivery" according to user's immediate needs. -Better way of estimating the percentage of requirements completed during development UML Overview 14

Benefits of use cases m m m Good way to start identifying objects from

Benefits of use cases m m m Good way to start identifying objects from scenarios. Test plan can be immediately generated based on use cases. Easier user validation. Helps technical writers in structuring the overall work on the users manuals at an early stage. Better traceability throughout the system development process. Quality of the software is improved by identifying the exception scenarios earlier in the development process. UML Overview 15

Problems with use cases m m m What is the right granularity What is

Problems with use cases m m m What is the right granularity What is a correct Use Case Explosion of different scenarios Focus on functions, with potential for functional decomposition Too often too informal UML Overview 16

Use Cases and Scenarios m m Scenario is a specific sequence of actions Scenario

Use Cases and Scenarios m m Scenario is a specific sequence of actions Scenario is one instance of a Use Case Typically many scenarios correspond to one Use Case Example: Use Case = Hire Employee þ Scenarios - Hire at Job Fair - Hire through newspaper ad - Hire from internal promotion - Hire Temp þ UML Overview 17

Use Cases and Collaborations m m m m Use Case captures WHAT the system

Use Cases and Collaborations m m m m Use Case captures WHAT the system does Use Cases do not specifies HOW the System does it Development effort is aimed at implementing the use cases by creating a society of classes working together These interacting classes are modeled using Collaborations A Collaboration is the realization of a Use Case A Collaboration represents how responsibilities are distributed across objects A Collaboration has a Static and a Dynamic aspect UML Overview 18

Organizing Use Cases Relationships: Generalization, Include (Use) and Extend Generalization: Like for Classes –

Organizing Use Cases Relationships: Generalization, Include (Use) and Extend Generalization: Like for Classes – Include: - Use: Contains another complete use-case Extend: - Extends another use-case - used for optional separate flow (exception) Beware: - Over-use of extends = functional decomposition - Rumbaugh says Use = aggregation and Extend = inheritance UML Overview 19

Hints and Tips • • • Each Use Case should represent a single, identifiable

Hints and Tips • • • Each Use Case should represent a single, identifiable and reasonably atomic part of the behavior of the system Factors Common Behavior by pulling such behavior from other use cases that it includes Factors variants by pushing such behavior into other use cases that extend it Describe flow of vents clearly enough for anyone to easily understand it Each Use Case is described by a number of scenarios that specify the normal and variants UML Overview 20

Use Case Diagrams m m m system is represented by a large rectangle uses

Use Case Diagrams m m m system is represented by a large rectangle uses cases are represented as ellipses within the system rectangle actors are represented as stick figure outside the system an arrow connects the initiating actor to the use case (ending at the use case) other participating actors are joined by arrows terminating at the actor UML Overview 21

Banking System Use Case Diagram open_account Customer Cash Dispenser withdraw_cash clear_checks Clerk loan_application Manager

Banking System Use Case Diagram open_account Customer Cash Dispenser withdraw_cash clear_checks Clerk loan_application Manager get_report UML Overview Loan Officer 22

Use Case Identification Steps • Determine the boundary of the system - consider system

Use Case Identification Steps • Determine the boundary of the system - consider system as a single “black box” object • Identify who is going to be using the system directly - e. g. hitting keys on the keyboard. These are the Actors - start by considering physical object - an individual object may play several roles • Choose One of these Actors and determine the fundamental ways in which each actor uses the system - each of these is a use case - must be enumerable - for each of those Use Cases decide on the most usual course when that Actor is using the system. What normally happens. This is the basic course UML Overview 23

Use Case Identification Steps (2) • Describe it as "Actor does something, system does

Use Case Identification Steps (2) • Describe it as "Actor does something, system does something. " but keep it at a high level. do not mention any GUI specifics m only describe things that the system does that the actor would be aware of and conversely you only describe what the actor does that the system would be aware of. m do not worry about the alternate paths (extends) or common courses (uses) - Yet m • Review each Use Case descriptions against the descriptions of the other Use Cases. • Once basic course is OK, consider the alternates and add those as extending use cases. UML Overview 24

Use Case Identification Steps (3) • Good way of getting started with Use Case

Use Case Identification Steps (3) • Good way of getting started with Use Case modelling. • Once started and comfortable with this process, next step: m understand the trade-offs that can be made m simplicity versus "completeness" m putting too much in is the most common mistake. UML Overview 25

Use Case Textual Descriptions OPEN_ACCOUN T - a clerk requests the system to create

Use Case Textual Descriptions OPEN_ACCOUN T - a clerk requests the system to create a new account WITHDRAW_CASH - a customer requests the system to withdraw a specified amount of money from a specified account CLEAR_CHECKS - a clerk instructs the system to update all accounts according to specified transactions including checks LOAN_APPLICATION - a customer files a loan application GET_REPORT - a manager or loan officer requests a report of the days transactions from the system UML Overview 26

Use Cases Diagram Hint and Tips • • • Put all the Use Cases

Use Cases Diagram Hint and Tips • • • Put all the Use Cases that describe one aspect of the system together Contains only those use cases and actors essential to understanding that aspect Diagram should be named to communicate its purpose Minimize crossing lines Don’t draw too many use cases or too many relationships in one diagram UML Overview 27

UML Basic Structural Modeling UML Overview 28

UML Basic Structural Modeling UML Overview 28

Basic Structural Modeling • Classes m Attributes, Operations, Responsibilities • Relationships Dependency, Generalization, Association,

Basic Structural Modeling • Classes m Attributes, Operations, Responsibilities • Relationships Dependency, Generalization, Association, Role, Multiplicity, Aggregation m • Common Mechanisms Specifications, Adornments, Common Divisions, Extensibility Mechanisms m • Diagrams m Class , Object , Component , Deployment Dagrams UML Overview 29

Classes m Most important building block of any object-oriented system m Description of a

Classes m Most important building block of any object-oriented system m Description of a set of Objects m Implements one or more interfaces m Abstraction of the entities existing in the problem domain Planet Astronaut Shuttle: : Astronaut simple names path names UML Overview 30

Attributes m named properties of classes that describe a range of values m represent

Attributes m named properties of classes that describe a range of values m represent some property of the thing being modeled m each attribute has one value for each object m m listed in the attribute compartment underneath the name box normally no need for an explicit “ID” attribute Mission Shuttle weight : Integer age : Integer status: enum = on-ground start : Date end : Date cost : Dollars UML Overview 31

Operations m m implementation of a service that can be requested from any object

Operations m m implementation of a service that can be requested from any object of the class what you can do to/with an object are listed in an additional box underneath the attribute box SYNTAX- name (arg 1 : type, arg 2 : type. . . ) : result Shuttle start_engines() stop_engines() fuel_level() : integer launch(t: time) UML Overview 32

Organizing Attributes and Operations • Ellided • Empty compartment m drawing an empty compartment

Organizing Attributes and Operations • Ellided • Empty compartment m drawing an empty compartment makes no statement about the absence of attributes or operations • Prefix groups with Stereotypes to m m group together attributes / operations with common characteristics represent a metaclassification of the attributes / operations UML Overview 33

Responsibility • Contract or obligation of a class • Starting point for modeling a

Responsibility • Contract or obligation of a class • Starting point for modeling a class • Responsibilities are translated into a set of attributes and operations • Free-form text, in separate compartment at the bottom of the class Shuttle Responsibilities -- Carry astronauts and payload to low orbit space UML Overview 34

Other Features • When need to separate the implementation of a class from its

Other Features • When need to separate the implementation of a class from its specification, use Interface • Advanced features such as m attribute or operation visibility m language-specific features • Common pre-specified classes modeled with m active classes m components m nodes UML Overview 35

Modeling Classes • What is a Class? • Where do I find Attributes? •

Modeling Classes • What is a Class? • Where do I find Attributes? • What the difference between a Class and an Attribute? • How do I set responsibilities within Classes ? UML Overview 36

Hints and Tips • Classes should map to relevant abstraction in problem (and solution)

Hints and Tips • Classes should map to relevant abstraction in problem (and solution) domain • Embodies small set of well defined responsibilities • Understandable and simple, yet extensible and adaptable • Contain only the relevant properties UML Overview 37

Relationships • • • Connection among things How Classes are related to one another

Relationships • • • Connection among things How Classes are related to one another (Almost) As important as Classes Ways things collaborate Three main type: m Dependencies m Generalizations m Associations UML Overview 38

Dependency • Using Relationships • A Change in one thing may affect the other

Dependency • Using Relationships • A Change in one thing may affect the other thing that uses it. • Most often between a class that uses another clas as a parameter to an operation Shuttle Engine start_engines() stop_engines() fuel_level() : integer launch(t: time) UML Overview 39

Generalization • Relationship which organizes classes based on their similarities and differences • Relationship

Generalization • Relationship which organizes classes based on their similarities and differences • Relationship between a general thing (the superclass) and a more specific thing (the subclass) • sometimes called “is-a-kind-of” or “is-a” relationship • Child is substitutable for the parent • Child inherit properties of parent • corresponds to inheritance in object-oriented languages • NOTATION m an arrow whose head is next to the specialization Spacecraft Shuttle UML Overview 40

Subclasses m m m inherit the attributes, operations and associations of their superclass(es) must

Subclasses m m m inherit the attributes, operations and associations of their superclass(es) must obey all semantic restrictions of their superclass(es) can override the implementation of an operation vehicle size speed water vehicle draft land vehicle wheels UML Overview 41

Ancestors/Descendants m m the terms ancestor and descendant refer to generalization across multiple levels.

Ancestors/Descendants m m the terms ancestor and descendant refer to generalization across multiple levels. an instance of a class is simultaneously an instance (transitively) of all its ancestors fruit . . . apple cox granny smiths UML Overview 42

Associations m describe a group of links with common structure and semantics m are

Associations m describe a group of links with common structure and semantics m are to links what classes are to objects m can have a different name in each direction Person Employs Works-for Organization Works-for Dan Goldin NASA Bill Gates Microsoft John Smith Rockwell . . . UML Overview . . . 43

Associations Continued m defined solely by the classes which they connect m associations are

Associations Continued m defined solely by the classes which they connect m associations are not part of the participating classes m associations should not be modelled by attributes Astronaut Mission assigned_to : string Astronaut Assigned_to full_name : string Mission full_name : string UML Overview WRONG RIGHT 44

Roles m m m correspond to one end of an association each end of

Roles m m m correspond to one end of an association each end of an association may be assigned a role which serves as its unique identifier provide a way of traversing a binary association from one object to a set of related objects m represent a form of specialization m are written next to the association line Astronaut 0. . * conducts 0. . * mission-specialist UML Overview Experiment 45

Multiplicity m m the number of instances of one class that may be related

Multiplicity m m the number of instances of one class that may be related to an instance of another constrains the number of links between objects 1 1. . * Class exactly one 0. . * Class mandatory (one or more) Class many (zero or more) 0. . 1 Class optional (zero or one) 2. . 4, 6. . 8 Class numerically specified UML Overview 46

Aggregation m a special form of association between a whole and its parts m

Aggregation m a special form of association between a whole and its parts m relates an assembly class to its component classes m is transitive but not symmetric (commutative) m depicted by a diamond at the assembly end m two kinds physical - a part cannot be in more than one “whole” catalog - a part can be in several “wholes” UML Overview 47

Aggregation Examples Document Crew 1. . * * 4. . 6 Sentence Space Center

Aggregation Examples Document Crew 1. . * * 4. . 6 Sentence Space Center 1. . * Word Astronaut 2 Shuttle * 3 1. . * Wings Engines Building UML Overview 48

Aggregation Example - Graphical interface Window * Pane Title. Bar 0. . 2 Scroll.

Aggregation Example - Graphical interface Window * Pane Title. Bar 0. . 2 Scroll. Bar Border 2 Close Button Title Arrow UML Overview Indicator 49

Aggregation - Tree-like Notation Window * Pane Title. Bar 0. . 2 Scroll. Bar

Aggregation - Tree-like Notation Window * Pane Title. Bar 0. . 2 Scroll. Bar Border 2 Close Button Title Arrow UML Overview Indicator 50

Lab Work on UML - Part 1 • Review Use Case Development Process from

Lab Work on UML - Part 1 • Review Use Case Development Process from Rational Unified Process m Use Case Finding m Use Case Details • Develop Use Case Model using Rational Rose • Develop Use Case Specification Document UML Overview 51

Lab Work on UML - Part 2 • Review Class Diagram Development Process from

Lab Work on UML - Part 2 • Review Class Diagram Development Process from Rational Unified Process • Develop Class Model using Rational Rose UML Overview 52