MedTech Chapter 3 – Software Design Specificities UML Modeling

MedTech
Chapter 3 – Software Design
Specificities of the design step, UML modeling
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
MedTech – Mediterranean Institute of Technology
Software Engineering
MedTech

MedTech
INTRODUCTION TO SOFTWARE DESIGN
Design
Dr. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 4

MedTech
Design Specification Models
Dr. Lilia SFAXI
Slide 5
Entity-
Relationship
Diagram
Data Flow
Diagram
State-Transition
Diagram
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. Lilia SFAXI
Slide 6
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. Lilia SFAXI
Slide 7
Entity Relationship Diagram

MedTech
• 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. Lilia SFAXI
Slide 8
Dataflow Diagram

MedTech
• 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. Lilia SFAXI
Slide 9
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. Lilia SFAXI
Slide 10
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. Lilia SFAXI
Slide 11
State Transition Diagram

MedTech
DESIGN FUNDAMENTAL CONCEPTS
Design
Dr. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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 performing
the same task
Dr. Lilia SFAXI
Slide 17
Software Design
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental 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 dependant
in 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. Lilia SFAXI
Slide 18
Software Design
Content
Common
External
Control
Stamp
Data
Uncoupled 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 procedural
details
Dr. Lilia SFAXI
Slide 19
Software Design
Open Door
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move 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. Lilia SFAXI
Slide 20
Software Design

MedTech
VISUAL MODELING WITH UML
Design
Dr. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 23

MedTech
UML Usage
• UML may be used to:
• Display the boundary of a system and its major functions using use cases
and actors
• Illustrate 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. Lilia SFAXI
Slide 24

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. Lilia SFAXI
Slide 25

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. Lilia SFAXI
Slide 26

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. Lilia SFAXI
Slide 27

MedTech
UML DESIGN: USE CASE VIEW
Design
Dr. Lilia SFAXI
Slide 28

MedTech
Use Case View
• Captures the behavior of a system, subsystem, class or coponent, as it
appears 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. Lilia SFAXI
Slide 29
UML Design: Use Case View

MedTech
Actor
• Idealization of a role played by an external person, process or thing
interacting 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. Lilia SFAXI
Slide 30

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 internal
structure 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. Lilia SFAXI
Slide 31

MedTech
Use Case Diagram
Dr. Lilia SFAXI
Slide 32

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. Lilia SFAXI
Slide 33

MedTech
Use Case Relationships: Example
Dr. Lilia SFAXI
Slide 34

MedTech
Use Case Relationships: Example
Dr. Lilia SFAXI
Slide 35

MedTech
Use Case Textual Description
Dr. Lilia SFAXI
Slide 36

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. Lilia SFAXI
Slide 37

MedTech
Use Case View: Proposition of Solution
Dr. Lilia SFAXI
Slide 38

MedTech
UML DESIGN: STATIC VIEW
Design
Dr. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 41

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. Lilia SFAXI
Slide 42

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. Lilia SFAXI
Slide 43

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. Lilia SFAXI
Slide 44

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. Lilia SFAXI
Slide 45

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. Lilia SFAXI
Slide 46

MedTech
Association
Dr. Lilia SFAXI
Slide 47

MedTech
Association Class
Dr. Lilia SFAXI
Slide 48

MedTech
Association: Navigability
Dr. Lilia SFAXI
Slide 49

MedTech
Naming an Association
Dr. Lilia SFAXI
Slide 50

MedTech
Aggregation and Composition
Dr. Lilia SFAXI
Slide 51
• 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. Lilia SFAXI
Slide 52
• 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. Lilia SFAXI
Slide 53
• 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. Lilia SFAXI
Slide 54
• 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. Lilia SFAXI
Slide 55
• 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 travel
agency
• These are the key sentences representing the needs of the business
experts
1. Airline companies offer several flights
2. A flight is open to reservation and closed by the company
3. A client can book one or several flights, for different passengers
4. A reservation concerns a single flight and a single passenger
5. A reservation can be canceled or confirmed
6. A flight has a departure airport and an arrival airport
7. A flight has a date and time of departure, and a date and time of arrival
8. A flight can have stopovers in airports
9. A stopover has an arrival time and a departure time
10. Each airport services one or more towns
Dr. Lilia SFAXI
Slide 56

MedTech
Static View: Proposition of a Solution
Dr. Lilia SFAXI
Slide 57

MedTech
UML DESIGN: INTERACTION VIEW
Design
Dr. Lilia SFAXI
Slide 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
collaboration
• 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. Lilia SFAXI
Slide 59
UML Design: Interaction View

MedTech
Sequence Diagram vs. Communication Diagram
Dr. Lilia SFAXI
Slide 60
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. Lilia SFAXI
Slide 61

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. Lilia SFAXI
Slide 62

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. Lilia SFAXI
Slide 63

MedTech
Sequence Diagram: Messages
• The message name and arguments are written above the arrow
Dr. Lilia SFAXI
Slide 64

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. Lilia SFAXI
Slide 65

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. Lilia SFAXI
Slide 66

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. Lilia SFAXI
Slide 67

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. Lilia SFAXI
Slide 68

MedTech
Interaction View: Case Study
• We have an order and are going to invoke a command on it to calculate
its price.
• To do that, the order needs to look at all the line items on the order
and 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. Lilia SFAXI
Slide 69

MedTech
Interaction View: Proposition of a Solution (1)
Dr. Lilia SFAXI
Slide 70

MedTech
Interaction View: Proposition of a Solution (2)
Dr. Lilia SFAXI
Slide 71

MedTech
UML DESIGN: ACTIVITY VIEW
Design
Dr. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 73
UML Design: Activity View

MedTech
Activity Diagram
Dr. Lilia SFAXI
Slide 74

MedTech
Activity Diagram: Partitions
Dr. Lilia SFAXI
Slide 75
• Partitions are used
to organize the
activities in a model
according to
responsibility
• Activities are
organized into
distinct 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 ( ): link the
actions in sequence
• Decision nodes ( ): indicate a
point where the outcome of a
decision dictates the next step
• Guards ( ): indicate when each
path should be taken
• Merge Nodes ( ): bring
together two or more
alternative flows that branched
at a Decision Node
Dr. Lilia SFAXI
Slide 76
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. Lilia SFAXI
Slide 77

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. Lilia SFAXI
Slide 78

MedTech
Activity View: Sub-Activities
• Describe the detailed behavior
of an action using a separate
activity diagram.
• A called behavior is an activity
diagram that is represented on
your main activity diagram by a
Call Behavior Action.
• Also used to describe behavior
that is shared between
different activities so that you
do not have to draw the sub-
activity multiple times.
Dr. Lilia SFAXI
Slide 79

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. Lilia SFAXI
Slide 80
1 2

MedTech
Activity View: Concurrent Flows
• Send Signal
Action ( ):
indicates that a
signal or
message is sent
to other
activities or
processes.
Dr. Lilia SFAXI
Slide 81
3 4
• Accept Event
Action ( ):
indicates that
this activity
waits for some
external event
or incoming
message.

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. whether
it 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 calculate
payment due and request payment options. Those options include
payment by cash, or by credit or debit card.
• If payment by card was selected by Commuter, another actor, Bank will
participate in the activity by authorizing the payment.
Dr. Lilia SFAXI
Slide 82

MedTech
Activity View: Proposition of a Solution
Dr. Lilia SFAXI
Slide 83

MedTech
UML DESIGN: STATE MACHINE VIEW
Design
Dr. Lilia SFAXI
Slide 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. Lilia SFAXI
Slide 85
UML Design: State Machine View

MedTech
State Machine Diagram
Dr. Lilia SFAXI
Slide 86
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. Lilia SFAXI
Slide 87

MedTech
State Machine View : Transition
• Example of a seminar enrollment:
trigger-signature [guard]/activity
Dr. Lilia SFAXI
Slide 88

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 same
state
Dr. Lilia SFAXI
Slide 89
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. Lilia SFAXI
Slide 90

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. Lilia SFAXI
Slide 91

MedTech
State Machine View : Case Study
• A student must complete the basic level before entering the advanced
level
• 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. Lilia SFAXI
Slide 92

MedTech
State Machine View : Proposition of a (~) Solution
Dr. Lilia SFAXI
Slide 93

MedTech
UML DESIGN: OTHER VIEWS…
Design
Dr. Lilia SFAXI
Slide 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 that
node
Dr. Lilia SFAXI
Slide 95
UML Design: Other Views

MedTech
Deployment Diagram
Dr. Lilia SFAXI
Slide 96

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. Lilia SFAXI
Slide 97

MedTech
Package Diagram
Dr. Lilia SFAXI
Slide 98

MedTech
References
Dr. Lilia SFAXI
Slide 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

MedTech Chapter 3 – Software Design Specificities UML Modeling

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a MedTech Chapter 3 – Software Design Specificities UML Modeling

Semelhante a MedTech Chapter 3 – Software Design Specificities UML Modeling (20)

Mais de Lilia Sfaxi

Mais de Lilia Sfaxi (20)

Último

Último (20)

MedTech Chapter 3 – Software Design Specificities UML Modeling