Post on 09-Apr-2017
transcript
MedTech
Chapter 3 – Software Design
Specificities of the design step, UML modeling
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 1
MedTech – Mediterranean Institute of TechnologySoftware Engineering
MedTech
MedTech
INTRODUCTION TO SOFTWARE DESIGNDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 2
MedTech
Software Design: Definition
• Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software.• A blueprint is a reproduction of a technical drawing,
documenting an architecture or an engineering design
• Initially, the blueprint depicts a holistic view of software.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 3
Introduction to Software Design
MedTech
Process of Design Engineering
• During the design process the software specifications are transformed into design models
• Models describe the details of the data structures, system architecture, interface, and components.
• Each design product is reviewed for quality before moving to the next phase of software development.
• At the end of the design process a design model and specification document is produced.
• This document is composed of the design models that describe the data, architecture, interfaces and components.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 4
Introduction to Software Design
MedTech
Design Specification Models
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 5
Introduction to Software Design
Entity-RelationshipDiagram
Data FlowDiagram
State-TransitionDiagram
Data Dictionary
Process Specification (PSPEC)
Control Specification (CSPEC)
Data Object Description
Data Design
Architectural Design
Interface Design
Procedural Design
THE DESIGN MODELTHE ANALYSIS MODEL
MedTech
Data Design
• Created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software.
• Part of the data design may occur in conjunction with the design of software architecture.
• More detailed data design occurs as each software component is designed.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 6
Introduction to Software Design
Data Dictionary
MedTech
Data Design
• Created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software.
• Part of the data design may occur in conjunction with the design of software architecture.
• More detailed data design occurs as each software component is designed.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 7
Introduction to Software Design
Entity Relationship Diagram
MedTech
Architectural Design
• Defines :• The relationships among the major
structural elements of the software• The “design patterns” than can be
used to achieve the requirements that have been defined for the system
• The constraints that affect the way in which the architectural patterns can be applied.
• It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD).
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 8
Introduction to Software Design
Dataflow Diagram
MedTech
Architectural Design
• Defines :• The relationships among the major
structural elements of the software• The “design patterns” than can be
used to achieve the requirements that have been defined for the system
• The constraints that affect the way in which the architectural patterns can be applied.
• It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD).
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 9
Introduction to Software Design
MVP Design Pattern
MedTech
Interface Design
• Describes how the software elements communicate with each other, with other systems and with human users
• Much of the necessary information required is provided by the data flow and control flow diagrams
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 10
Introduction to Software Design
Control Flow Diagram
MedTech
Procedural/Component-level Design
• Created by transforming the structural elements defined by the software architecture into procedural descriptions of software components
• Uses information obtained from : • Process specification (PSPEC)
• Use cases, FlowCharts, Activity Diagrams…• Control specification (CSPEC)
• State Transition Diagram (STD), Decision tables …
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 11
Introduction to Software Design
State Transition Diagram
MedTech
DESIGN FUNDAMENTAL CONCEPTSDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 12
MedTech
Fundamental Concepts
• Abstraction: Data, procedure, control
• Architecture: Overall structure of the software• Patterns: Convey the essence of a proven design solution
• Modularity: Compartimentalization of data and function• Information Hiding: Controlled interfaces
• Functional Independance: Single-minded function and low coupling
• Refinement: Elaboration of detail for all abstractions• Refactoring: Reorganization technique that simplifies the design
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 13
Software Design
MedTech
Fundamental Concepts
• Abstraction• Allows designers to focus on solving a problem without being concerned
about irrelevant lower level details• Procedural Abstraction: named sequence of events
• Data Abstraction: named collection of data objects
• Refinement• Process of elaboration where the designer provides successively more
details for each design component
• Modularity• Degree to which the software can be understood by examining its
components independently of one another
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 14
Software Design
MedTech
Fundamental Concepts: Patterns
• A common solution to a common problem in a given context• High level patterns for organizing software: architectural styles
• Low level patterns for describing details :• Creational Patterns: Builder, factory, prototype, singleton…• Structural Patterns: Adapter, bridge, composite, façade…
• Behavioral Patterns: Command, interpreter, oterator, mediator...
• Design Patterns• Enable a designer to determine wheter the pattern:
• Is applicable to the current work
• Can be reused
• Can serve as a guide for developing a similar but functionally or structurally different pattern
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 15
Software Design
MedTech
Fundamental Concepts: Information Hiding
• A good split of modules is when modules communicate with one another with only the information necessary to achieve the software function
• Enforces access constraints to• Procedural details with a module• Local data structure used by that module
• Benefits• Reduces the likelihood of “side effects”• Limits the global impact of local design decisions• Emphasizes communication through controlled interfaces• Discourages the use of global data• Leads to encapsulation—an attribute of high quality design• Results in higher quality software
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 16
Software Design
MedTech
Fundamental Concepts: Functional Independence
• Cohesion• Degree to which a module
performs one and only one function
• All elements of component are directed toward performingthe same task
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 17
Software Design
FunctionalSequential
Communicational
ProceduralTemporal
LogicalCoincidental Low Cohesion
High Cohesion
MedTech
Fundamental Concepts: Functional Independence
• Coupling• Degree to which a module is
connected to other modules in the system
• Two components can be dependantin many ways:• References made from one to
another
• Amount of data passed from one to another
• Amount of control one has over the other
• …
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 18
Software Design
ContentCommon
External
ControlStamp
DataUncoupled Low Cohesion
High Cohesion
MedTech
Fundamental Concepts: Refinement
• Refinement is a process of elaboration• It is a top-down design strategy
• A program is developed by successfully refining levels of proceduraldetails
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 19
Software Design
Open Door
walk to door;reach for knob;
open door;
walk through;close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then
take key out;find correct key;insert in lock;
endifpull/push doormove out of way;end repeat
MedTech
Fundamental Concepts: Refactoring
• ”Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure”, M. Fowler
• Refactoring a software means examining the existing design for:• Redundancy• Unused design elements
• Inefficient or unnecessary algorithms
• Poorly constructed or inappropriate data structures
• Any other design failure that can be corrected to yield a better design
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 20
Software Design
MedTech
VISUAL MODELING WITH UMLDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 21
MedTech
Visual Modeling
• Modeling captures essential parts of the system
• Visual modeling is modeling using standard graphical notations• Visual modeling
• Captures business process from user’s perspective
• Is a communication tool between the business domain and the computer domain
• Manages complexity using refinement techniques
• Defines software architecture• Promotes reuse
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 22
Visual Modeling with UML
MedTech
UML
• Unified Modeling Language
• Standard language for visualizing, specifying, constructing and documenting the artifacts of a software system.
• Combines notions from:• Data modeling concepts (entity relationship diagrams)
• Business modeling (workflow)
• Object modeling• Component modeling
• Can be used with all processes, throughout the development lifecycle, and across different implementation technologies
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 23
Visual Modeling with UML
MedTech
UML Usage
• UML may be used to:• Display the boundary of a system and its major functions using use cases
and actors
• I l lustrate use case realizations with interaction diagrams
• Represent a static structure of a system using class diagrams
• Model the behaviour of objects with state transition diagrams
• Reveal the physical implementation architecture with component and deployment diagrams
• Extend the basic functionalities with stereotypes
• UML is NOT:• A programming language
• Highly formal language for theorem proving
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 24
Visual Modeling with UML
MedTech
Why Unified?
• Across historical methods and notations• Combines the commonly accepted concepts from many object-oriented methods
• Across the development lifecycle• Seamless from requirements to deployment
• Across application domains• Models most application domains, including large, complex, real-time,
distributed, data or computation intensive,…
• Across implementation languages and platforms• Usable for systems implemented in various languages and platforms
• Across development processes• Usable as the modeling language underlying mist existing or new development
processes• Supports iterative, incremental, agile,... Models
• Across internal concepts• Represents internal relationships in a broad way applicable to many situations
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 25
Visual Modeling with UML
MedTech
UML Views
• View: A subset of UML modeling constructs that represents one aspect of a system
• Views are divided into areas• Structural classification
• Things in the system and their relationships to other things• Things are modelized using “classifiers” (class, use case, actor, node…)
• Dynamic behavior• Behavior of a system or other classifier over time• Can be described as a series of changes to snapshots of the system drawn from
the static view
• Physical layout• Computational resources in the system and deployment of artifacts on them
• Model management• Organization of the models into hierarchical units
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 26
Visual Modeling with UML
MedTech
UML Views
Area View Diagram
Structural Static View Class Diagram
Design View Internal Structure
Collaboration Diagram
Component Diagram
Use Case View Use Case Diagram
Dynamic State Machine View State Machine Diagram
Activity View Activity Diagram
Interaction View Sequence Diagram
Communication Diagram
Physical Deployment View Deployment Diagram
Model Management Model Management View Package Diagram
Profile Package Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 27
Visual Modeling with UML
MedTech
UML DESIGN: USE CASE VIEWDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 28
MedTech
Use Case View
• Captures the behavior of a system, subsystem, class or coponent, as itappears to an outside user
• Partitions the system’s functionality into transactions meaningful to actors, users of the system• Actors can be human, other computer systems or processes
• The pieces of interactive functionalities are calles use cases• A use case describes an interaction with actors as a sequence of
messages between the system and one or more actors
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 29
UML Design: Use Case View
MedTech
Actor
• Idealization of a role played by an external person, process or thinginteracting with a system, subsystem or class
• Characterizes th interactions that a class of outside user may have with the system
• One physical user may be bound to multiple actors
• Different users may be bound to the same actor definition• Each actor participates in one or more use cases by exchanging
messages
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 30
UML Design: Use Case View
MedTech
Use Case
• Coherent unit of externally visible functionality provided by a classifier (subject), and expressed by sequences of messages exchanged by the subject and one or more actors of the system unit
• Defines a piece of coherent behavior without revealing the internalstructure of the subject
• The execution of each use case is independent of the others• But its implementation may create implicit dependencies among them due
to shared objects
• The dynamics of a use case may be specified by • UML interactions: statechart diagrams, sequence diagrams, communication
diagrams…
• Informal text descriptions
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 31
UML Design: Use Case View
MedTech
Use Case Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 32
UML Design: Use Case View
MedTech
Use Case Relationships
• Association• The communication path between an actor and a use case
that it participates in
• Extension• Relationship from an extension use case to a base use case• Specifies how the behavior defined for the extension use
case can be inserted into that of the base use case
• Inclusion• Relationship from a base use case to an inclusion use case• Specifies that the behavior defined for the inclusion use
case is to be inserted into that of the base use case.
• Use case generalization• Relationship between a general use case and a more
specific use case that inherits and adds features to it
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 33
UML Design: Use Case View
MedTech
Use Case Relationships: Example
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 34
UML Design: Use Case View
MedTech
Use Case Relationships: Example
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 35
UML Design: Use Case View
MedTech
Use Case Textual Description
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 36
UML Design: Use Case View
MedTech
Use Case View: Case Study
• We want to model a simplified system of the automatic teller machine (ATM), offering the following services:
1. Distribution of money to every holder of a smartcard via a card reader and a cash dispenser
2. Consultation of account balance, cash and cheque deposit facilities for bank customers who hold a smartcard from their bank
3. All transactions are made secure
4. It is sometimes necessary to refill the dispenser
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 37
UML Design: Use Case View
MedTech
Use Case View: Proposition of Solution
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 38
UML Design: Use Case View
MedTech
UML DESIGN: STATIC VIEWDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 39
MedTech
Static View
• Foundation of UML• Concepts that are meaningful in an application
• Describes behaviral declarations, such as operations, without the details of their dynamic behaviour (described by the dynamic views)
• Key elements: classifiers and relationships
• Classifier• Modeling element that describes things containing values• Describes identity, state, behaviour, relationships and optionally the
internal structure of the object
• Relationships• Are defined between classifiers to represent associations, dependency,
generalization, realization or usage
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 40
UML Design: Static View
MedTech
Class Diagram
• A picture of:• The classes in an OO system
• Their fields and methods
• Connections between the classes that interact or inherit from one another
• It does NOT represent:• Details of how the classes interact with each other• Algorithmic details: how a particular behavior is implemented
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 41
UML Design: Static View
MedTech
Classifiers
• Class: Main classifier in the static view• Discrete concept within the application being modeled, representing things
of a particular kind: physical, business, logical, application, computer or behavioral
• Defines a set of objects that have state and behavior• State: described by attributes
• Behavior: described by operations (methods)
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 42
UML Design: Static View
MedTech
Classifiers
• Interface• Description of the behavior of objects without giving their implementation
or state
• One or more class or component may realize an interface
• Each class must implement the operations found in the interface
• Data types• A primitive type: description of primitive values that lack identity
(independent existence)
• Include numbers and strings
• Passed by value and immutable entities
• Has no attributes, but may have operations, that do not modify the data values, but may return other values
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 43
UML Design: Static View
MedTech
Class
• Class name in top of the box• Write <<interface>> on top of interfaces’ names• Use italics for an abstract class name
• Attributes (optional)• Should include all fields of the object• visiblity name : type [count] = defaultVal• Visiblity:
• + public• # protected• - private• ~ package (default)• / derived (can be computed from other
attributes)• Static attributes are underlined
• Example• - balance : double = 0.00
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 44
UML Design: Static View
MedTech
Class
• Operations / Methods (optional)• May omit trivial (get/set) methods, but never
omit methods from an interface
• Should not include inherited methods
• visiblity name (param1:type, param2:type ): return_type
• Visiblity:• + public
• # protected
• - private
• ~ package (default)
• Static methods are underlined
• Example:• + distance(p1: Point, p2: Point): double
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 45
UML Design: Static View
MedTech
Relationships
• Association• Description of a connection among instances of classes
• Dependency• Relationship between two model elements
• Generalization• Relationship between a more specific and a more general description
• Used for inheritance and polymorphic type declarations
• Realization• Relationship between a specification and its implementation
• Usage • A situation in which one element requires another for its correct
functioning
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 46
UML Design: Static View
MedTech
Association
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 47
UML Design: Static View
MedTech
Association Class
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 48
UML Design: Static View
MedTech
Association: Navigability
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 49
UML Design: Static View
MedTech
Naming an Association
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 50
UML Design: Static View
MedTech
Aggregation and Composition
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 51
UML Design: Static View
• Aggregation: • Association that represents a part-whole relationship
• Composition: • A stronger form of association • The composite has the sole responsibility for managing its parts • An object may belong to at most one composition
MedTech
Generalization
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 52
UML Design: Static View
• Taxonomic relationship between a more general description (parent) and a more specific description (child), that builds on it and extends it
• Used for all classifiers
• For classes, the terms superclass and subclass are used
MedTech
Realization
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 53
UML Design: Static View
• Connects a model elements (for ex. a class) to another model element (for ex. an interface) that supplies its behavioral specification, but not its structure or implementation
MedTech
Dependency
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 54
UML Design: Static View
• Indicates a semantic relationship between two or more model elements
• Relates the model elements themselves, and doesn’t require a set of instances for its meaning
• Indicates a situation where a change to the supplier element may require a change to the client element
• Association and generalization are specific dependencies
MedTech
Object Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 55
UML Design: Static View
• A diagram of a snapshot, an image of the system at a point in time• Used as an example of the system
MedTech
Static View: Case Study
• We want to model a simplified system of flight reservation for a travelagency
• These are the key sentences representing the needs of the business experts
1. Airline companies offer several flights2. A flight is open to reservation and closed by the company3. A client can book one or several flights, for different passengers4. A reservation concerns a single flight and a single passenger5. A reservation can be canceled or confirmed6. A flight has a departure airport and an arrival airport7. A flight has a date and time of departure, and a date and time of arrival8. A flight can have stopovers in airports9. A stopover has an arrival time and a departure time10. Each airport services one or more towns
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 56
UML Design: Static View
MedTech
Static View: Proposition of a Solution
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 57
UML Design: Static View
MedTech
UML DESIGN: INTERACTION VIEWDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 58
MedTech
Interaction View
• Provides a holistic view of the behavior of an entire system• Describes how groups of objects collaborate in some behavior
• Two kinds of diagrams:• Sequence diagram
• Displays an interaction as a two-dimentional chart• The vertical dimension is the time axis• The horizontal dimension shows the roles that represent individual objects in the
col laboration
• Doesn’t show exact time intervals
• Communication diagram• Shows interactions organized around the parts of a composite structure or the
roles of a collaboration• Explicitly shows the relationships between the elements
• Doesn’t show time as a separate dimension, just with sequence numbers
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 59
UML Design: Interaction View
MedTech
Sequence Diagram vs. Communication Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 60
UML Design: Interaction View
Sequence Diagram
Communication Diagram
MedTech
Sequence Diagram: Key Parts
• Participant • Object or entity that acts in the sequence diagram
• Can be an instance of a class, or an actor
• Message• Communication between participant objects• A sequence diagram can start with an unattached “found message” arrow
• Found message: message where the receiving event occurrence is known, but there is no known sending event occurrence
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 61
UML Design: Interaction View
MedTech
Sequence Diagram: Objects
• Objects are represented using squares with object type (class), optionally preceded by object name and a colon• If you want to write only the class name, without the object name, the
colon is mandatory
• The object’s lifeline is represented by a dashed vertical line
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 62
UML Design: Interaction View
MedTech
Sequence Diagram: Messages
• A message (method call) is indicated by a horizontal arrow to the object• A dashed arrow back indicates a return
• There are different arrow heads for normal / asynchronous methods
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 63
UML Design: Interaction View
MedTech
Sequence Diagram: Messages
• The message name and arguments are written above the arrow
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 64
UML Design: Interaction View
MedTech
Sequence Diagram: Lifetime
• Creation• Arrow with new or create on it
• An object created after the start of the scenario appears lower than the others
• Deletion• An X at the bottom of object’s lifeline
• Either deleted explicitely or implicitely(garbage collected) by the system
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 65
UML Design: Interaction View
MedTech
Sequence Diagram: Activation
• Activation• Thick box over object’s lifeline
• Drawn when the object’s method is on the stack• Either the method is still running, or waiting for a response
• Use nesting to represent recursion
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 66
UML Design: Interaction View
MedTech
Sequence Diagram: Selections and Loops
• Frame: box around part of a sequence diagram to indicate selection or loop• If : (opt) [condition]
• If/else: (alt) [condition], separated by horizontal dashed line
• Loop: (loop) [condition or items to loop over]
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 67
UML Design: Interaction View
MedTech
Sequence Diagram: Linking Diagrams
• If one sequence diagram is too large or refers to another diagram, indicate it with either:• An unfinished arrow and comment
• A ”ref ” frame that names the other diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 68
UML Design: Interaction View
MedTech
Interaction View: Case Study
• We have an order and are going to invoke a command on it to calculateits price.
• To do that, the order needs to look at all the line items on the orderand determine their prices, which are based on the pricing rules of the order line's products.
• Having done that for all the line items, the order then needs to compute an overall discount, which is based on rules tied to the customer.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 69
UML Design: Interaction View
MedTech
Interaction View: Proposition of a Solution (1)
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 70
UML Design: Interaction View
MedTech
Interaction View: Proposition of a Solution (2)
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 71
UML Design: Interaction View
MedTech
UML DESIGN: ACTIVITY VIEWDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 72
MedTech
Activity View
• Activity: Graph of nodes and flows that shows the flow of control and data through the steps of a computation• Steps can be either concurrent or sequential
• Can involve synchronization and branching constructs
• Activity contains:• Activity nodes: a step in the workflow• Nodes are connected by control flows and data flows
• Activity is defined in an activity diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 73
UML Design: Activity View
MedTech
Activity Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 74
UML Design: Activity View
MedTech
Activity Diagram: Partitions
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 75
UML Design: Activity View
• Partitions are usedto organize the activities in a model according to responsibility
• Activities are organized intodistinct regions(partitions or swimlanes) separated by lines
MedTech
Activity View: Control Flow
• Activity Diagrams use: • Actions ( ) : for each major
task performed by a user and/or the system
• Connectors ( ): l ink the actions in sequence
• Decision nodes ( ): indicate a point where the outcome of a decision dictates the next step
• Guards ( ): indicate when eachpath should be taken
• Merge Nodes ( ): bringtogether two or more alternative flows that branchedat a Decision Node
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 76
UML Design: Activity View
1
2
3
4
5
MedTech
Activity View: Data Flow
• You can describe the data passing in and out of an activity in either of two ways:• Use an Object Node. :
• Like a variable in a program.
• Represents something that stores one or more values that are passing from one action to another.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 77
UML Design: Activity View
MedTech
Activity View: Data Flow
• You can describe the data passing in and out of an activity in either of two ways:• Use an Output Pin and an Input Pin
• Pins are like parameters in a program.
• Pins represent ports where objects can enter and leave an action.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 78
UML Design: Activity View
MedTech
Activity View: Sub-Activities
• Describe the detailed behaviorof an action using a separateactivity diagram.
• A called behavior is an activitydiagram that is represented on your main activity diagram by a Call Behavior Action.
• Also used to describe behaviorthat is shared betweendifferent activities so that youdo not have to draw the sub-activity multiple times.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 79
UML Design: Activity View
MedTech
Activity View: Concurrent Flows
• You can use the Fork Node ( ) and the Join Node ( ) to describe two or more threads of activities that can execute at the same time.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 80
UML Design: Activity View
1 2
MedTech
Activity View: Concurrent Flows
• Send Signal Action ( ): indicates that a signal or message is sent to otheractivities or processes.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 81
UML Design: Activity View
3 4
• Accept Event Action ( ): indicates thatthis activitywaits for someexternal eventor incomingmessage.
MedTech
Activity View: Case Study
• Activity is started by a Commuter who needs to buy a ticket.
• Ticket vending machine will request trip information from Commuter. This information will include number and type of tickets, e.g. whetherit is a monthly pass, one way or round ticket, route number, destination or zone number, etc.
• Based on the provided trip info ticket vending machine will calculatepayment due and request payment options. Those options includepayment by cash, or by credit or debit card.
• If payment by card was selected by Commuter, another actor, Bank willparticipate in the activity by authorizing the payment.
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 82
UML Design: Activity View
MedTech
Activity View: Proposition of a Solution
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 83
UML Design: Activity View
MedTech
UML DESIGN: STATE MACHINE VIEWDesign
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 84
MedTech
State Machine View
• State Machine• Models the possible life histories of an object of a class
• Contains states connected by transitions
• State• Models a period of time during the life of an object during which it satisfies
certain conditions
• Transition• Can be fired when an event occurs
• Takes an object to a new state
• When fired, it can execute an effect (action or activity) attached to it
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 85
UML Design: State Machine View
MedTech
State Machine Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 86
UML Design: State Machine View
State machine of a ticket to a performance
MedTech
State Machine View : Transition
• Indicates a movement from one state to another• Each transition has a label that comes in three parts (all optional):
trigger-signature [guard]/activity• trigger-signature: Usually a single event that triggers a potential change of
state• guard: Boolean condition that must be true for the transition to be taken
• activity : Behavior executed during the transition
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 87
UML Design: State Machine View
MedTech
State Machine View : Transition
• Example of a seminar enrollment:trigger-signature [guard]/activity
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 88
UML Design: State Machine View
MedTech
State Machine View : Internal Activities
• States can react to events without transition, using internal activities• Putting the event, guard and activity inside the state box itself
• Similar to a self-transition: transition that loops back to the samestate
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 89
UML Design: State Machine View
Internal activities for the state « Typing » of a text field
MedTech
State Machine View : Activity States
• In some states, the object can do some ongoing work• These are called Activity States
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 90
UML Design: State Machine View
MedTech
State Machine View : Superstates
• Several states can share common transitions and internal activities• Can be represented as substates, with the common behavior moved into a
superstate
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 91
UML Design: State Machine View
MedTech
State Machine View : Case Study
• A student must complete the basic level before entering the advancedlevel
• After both levels, the student has to pass five examinations
• An examination can be retaken at most twice
• After the third attempt, the student’s registration is cancelled
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 92
UML Design: State Machine View
MedTech
State Machine View : Proposition of a (~) Solution
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 93
UML Design: State Machine View
MedTech
UML DESIGN: OTHER VIEWS…Design
Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i
S l id e 94
MedTech
Deployment View
• Represents the deployment of runtime artifacts on nodes
• Artifact• Physical implementation unit (ex. a file)
• Might be executable (.exe, binaries, jar…) or data files, configuration files, HTML documents...
• Node• Runtime resource (ex. a computer, device or memory)
• Listing an artifact into a node means that the artifact is deployed to thatnode
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 95
UML Design: Other Views
MedTech
Deployment Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 96
UML Design: Other Views
MedTech
Model Management View
• Models the organization of the model itself
• Comprises a set of packages that hold model elements, such as classes, state machines and use cases
• Packages may contain other packages
• Model management information is usually shown on package diagrams
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 97
UML Design: Other Views
MedTech
Package Diagram
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 98
UML Design: Other Views
MedTech
References
Dr. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i
S l id e 99
• Syed Muhammad Hammad-ud-Din, Software Design, http://fr.slideshare.net/syedmuhammadhammad/software-design-13430869
• Analysis and design of entreprise with uml, http://fr.slideshare.net/zinebencgist/analysis-and-design-of-entreprise-with-uml
• Microsoft Developer Network, Create UML modeling projects and diagrams, https://msdn.microsoft.com/en-us/library/dd409445.aspx
• Textbooks• J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language
Reference Manual, Second Edition, Addison Wesley, 2004
• M. Fowler, UML Distilled, Third Edition, Addison-Wesley Professional, 2003