Upload
others
View
22
Download
0
Embed Size (px)
Citation preview
UML 2.0
UML 2.0
Scott Uk-Jin Lee
Division of Computer Science, College of ComputingHanyang University ERICA Campus
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Introduction to UML 2.0
UML
Unified Modeling Language
Visual language for specifying, constructing and documenting
Maintained by the OMG (Object Management Group)
http://www.omg.org
Model / View paradigm
Target language independent
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Introduction to UML 2.0
Model / View Paradigm
Each UML diagram = a view of the system model
All diagrams together provides complete blueprint of thesystem
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Introduction to UML 2.0
UML Diagrams
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Introduction to UML 2.0
UML Usage
UML as :
Sketch
Selectivity (abstraction) is the keyno formal semantics are given
Blueprint
Completeness is the key
Programming language
to generate C/Java code from UML diagramsno formal definition exists of how the UML maps to anyparticular programming language
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Use Case Diagram
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Use Case
User Case is behavior or coherent set of behavior triggered byevents sent to the system
events are sent by human user(s), other systems, hardwarecomponents, internal clock
Use Case presents graphical overview on functionality providedby a system in terms of actors and their goals
Each Use Case specifies how to complete a goal or a task
Use Case treats the system as a black box and interactionswith the system are perceived as from outside the system
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Use Case Diagrams
describe WHAT the system will do at a high-level
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Actor
Someone or some thing that must interact with the systemunder development
Users, external systems, devices
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
an Actor is a Role
An actor defines a single role played by users in theirinteractions with the system:
multiple users can play a single rolea single user can play multiple roles
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Identifying Actors
Primary Actor: Who will use the main functionality of thesystem ?
Who will need support from the system to their daily tasks ?
Secondary Actor: Who will need to maintain, administrate,and keep the system working?
Which hardware devices does the system need to handle?
With which other systems does the system need to interact?
Who or what has an interest in the results (the value) thatthe system produces?
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Use Case
Functionality that the system shall offer to an actor
transaction among actors and the subjectinteraction between one or more actors and the system
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Identifying Use Case
Which functions does the actor require from system?
Does the actor need to read, create, modify, or store somekind of information in the system?
Does the actor have to be notified about events in thesystem?
Could the actor’s daily work be simplified or made moreefficient through new functions in the system?
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Subject Symbol
Indicate system boundary
Represent the system beinㅎ developedAll actors who interact with the system are outside of it
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Association
Drawn between an actor and a use case
Represents bi-directional communication between the actorand the system
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Dependency: Include
Represent relationship from a base to an inclusion use case
imply a Use Case calling another Use Caseto reuse behavior common to several Use Cases
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Dependency: Extend
Used when additional behavior should be added
models optional or conditional behaviorshow infrequent events
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Use Case Diagram
Tips for Use Case Modeling
Make sure that each use case describes a significant chunk of systemusage that is understood by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately andconsistently to help objects and messages for interaction diagrams
Factor out common usages that are required by multiple use cases
If the usage is required use <<include>>If the base use case is complete and the usage may beoptional, consider use <<extend>>
A use case diagram should
contain only use cases at the same level of abstractioninclude only actors required
Large numbers of use cases should be organized into packages
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Class Diagram
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Class Diagrams
Description of static structureShowing the types of objects in a system and the relationshipsbetween them
Foundation for the other diagrams
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Classes
Most important building block of any object-oriented system
Description of a set of objects
Abstraction of the entities
Existing in the problem/solution domain
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Attributes & Operations
AttributesRepresent some property of the thing being modeledSyntax: attributeName : Type
OperationsImplement of a service requested from any object of the classSyntax: operationName(param1:type, param2:type, ...) : Result
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Association & Multiplicity
AssociationRelationship between classes that specifies connections amongtheir instances
MultiplicityNumber of instances of one class related to ONE instance ofthe other class
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Aggregation & Composition
Aggregation
Weak “whole-part” relationship between elementse.g., An airport has many airplanes
Composition
Strong “whole-part” relationship between elementse.g., Window ‘contains a’ scrollbar
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Inheritance
Relationship between superclass and subclassesAll attributes and operations of the superclass are part of thesubclasses
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Generalization & Specialization
GeneralizationBuilding a more general class from a set of specific classes
SpecializationCreating specialized classes base on a more general class
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Active vs. Passive Class
Active classOwn a thread control and can initiate control activity- used when asynchronous communication is necessary- typically modeled with a state machine of its behavior- encapsulated with ports and interfaces
Passive classCreated as part of an action by another object- own address space, but not thread of control- executed under a control thread anchored in an active object
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Ports vs. Interfaces
PortsDefine an interaction point on a classifier with externalenvironment
InterfacesDescribe behavior of objects without giving theirimplementation- each class implements the operations found in the interface
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Stereotype in UML
UML extension mechanism
enables users to define the meaning of special modelingelementrepresented with double angle brackets
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Provided & Required Interface
Provided interface
Class provides the services of the interface to outside callersWhat the object can doProvided interface accept incoming signal form outside callers
Required interface
Class uses to implement its internal behaviorWhat the object needs to doOutgoing signal are sent via required interface
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Computer Device Example
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Class Diagram
Tips for Class Modeling
Finding Classes
Do we have things that should be stored or analyzed?
Do we have external system?- external system is modeled as class
Do we have any patterns, class libraries, components, etc?
Are there devices that the system must handle?
Make explicit traceability whenever possible
Try to capture classes/attributes from nouns of use-cases andoperations from verbs of use-cases
Always draw class diagram in conjunction with some form ofbehavioral diagrams
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Sequence Diagram
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Sequence Diagrams
Emphasize on the sequence of communications between parts
Show sequences of messages (“interactions”) betweeninstances in the system
Emphasize time ordering
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Lifelines
Individual participant in the interaction over period timeSubsystem/ object/ classActorExternal system rolesin the interaction
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Messages
Defines an expression of interaction fragments
May have parameters that convey values
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Combined Fragment Frame
One-way communication between two objects
Interaction operators define how contents describe behaviorAlt: each section is one alternative (e.g., alt [a>0])Ref: reference to another Use CaseLoop: specifies a repeated sequence of behavior(e.g., ‘loop [1,5]’, ‘loop [6]’)
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Referencing
Reuse already existing sequence diagrams
Avoid unnecessary duplication
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Sequence Diagram
Tips for Sequence Diagram
Set the context for the interaction
e.g., one use case
Express the flow from left to right and from top to bottom
Put active instances to the left/top and passive ones to theright/bottom
Draw sequence diagrams for each use-case if you want to lookat the behavior of several objects
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
State Machine Diagram
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
State Machine Diagram
Describe the dynamic behavior of objects over time bymodeling the lifecycles of objects of each class
The event that cause a transition from one state to another
The actions that result from a state change
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
State
State: condition or situation during the life of an object
Satisfies some condition, performs some activity or waits forsome event
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
Event & Action
Event
stimulus which causes the object to change state
Action
output of a signal or an operation call
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
Transition
Change state from one to another triggered by an event
Occur only when guard condition is true
Syntax: event(arguments)[condition]/action
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
Internal Activities
States can react to events without transition
putting the event, guard, and activity inside the state boxtwo special activities: the entry and exit activities
Internal activity is similar to self-transition
however, internal activities do not trigger the entry and exitactivities
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
Activity States
Regular activitiesinstantaneous behaviorcannot be interrupted
Do-activitiestakes finite timecan be interrupted
A normal state is quiet and waiting for the next event beforeit does something
Activity state is doing some on-going work
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 State Machine Diagram
Superstates
Several states share common transitions and internal activities
move the shared behavior into a superstatea behavior can be expressed in a modular/hierarchical way
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Deployment Diagram
Deployment Diagram
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Deployment Diagram
Deployment Diagrams
Show runtime architecture of devices, execution environments,and artifacts in architecture
Physical description of system topology- Describe structure of hardware units and software executingon each unit
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Deployment Diagram
Deployment Diagrams
Node
computational resource upon which artifacts may be deployedfor execution
Communication path
show connection between nodesstereotype can be used for communication protocol or networkused
Artifact
specification of a physical piece of information that is used orproduced by a software development process, or by deploymentand operation of a system
e.g. model files, source files, scripts, and binary executable files, atable in a database system, a development deliverable, or aword-processing document, a mail message
Scott Uk-Jin Lee CSE4006 Software Engineering
UML 2.0 Summary
Summary
UML can be used as
sketch levelblue print levelprogramming language level
Use appropriate UML diagrams for different goals
when starting SE projects, start with- use-case diagrams with use-case texts
to look at behavior across many use cases or many threads- activity diagram
to look at behavior of several objects within a single use case- sequence diagram
to look at behavior of a single object across many use cases- state diagram
Scott Uk-Jin Lee CSE4006 Software Engineering