software engineering - chp3- design

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


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.


S l id e 4


MedTech

Design Specification Models


S l id e 5


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.


S l id e 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.


S l id e 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).


S l id e 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).


S l id e 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


S l id e 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 …


S l id e 11


State Transition Diagram

MedTech

DESIGN FUNDAMENTAL CONCEPTSDesign


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


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


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


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


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


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

• …


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


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


S l id e 20

Software Design

MedTech

VISUAL MODELING WITH UMLDesign


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


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


S l id e 23


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


S l id e 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


S l id e 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


S l id e 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


S l id e 27


MedTech

UML DESIGN: USE CASE VIEWDesign


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


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


S l id e 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 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


S l id e 31


MedTech

Use Case Diagram


S l id e 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


S l id e 33


MedTech

Use Case Relationships: Example


S l id e 34


MedTech

Use Case Relationships: Example


S l id e 35


MedTech

Use Case Textual Description


S l id e 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


S l id e 37


MedTech

Use Case View: Proposition of Solution


S l id e 38


MedTech

UML DESIGN: STATIC VIEWDesign


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


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


S l id e 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)


S l id e 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


S l id e 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


S l id e 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


S l id e 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


S l id e 46


MedTech

Association


S l id e 47


MedTech

Association Class


S l id e 48


MedTech

Association: Navigability


S l id e 49


MedTech

Naming an Association


S l id e 50


MedTech

Aggregation and Composition


S l id e 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


S l id e 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


S l id e 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


S l id e 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


S l id e 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 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


S l id e 56


MedTech

Static View: Proposition of a Solution


S l id e 57


MedTech

UML DESIGN: INTERACTION VIEWDesign


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


S l id e 59

UML Design: Interaction View

MedTech

Sequence Diagram vs. Communication Diagram


S l id e 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


S l id e 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


S l id e 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


S l id e 63


MedTech

Sequence Diagram: Messages

• The message name and arguments are written above the arrow


S l id e 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


S l id e 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


S l id e 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]


S l id e 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


S l id e 68


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.


S l id e 69


MedTech

Interaction View: Proposition of a Solution (1)


S l id e 70


MedTech

Interaction View: Proposition of a Solution (2)


S l id e 71


MedTech

UML DESIGN: ACTIVITY VIEWDesign


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


S l id e 73

UML Design: Activity View

MedTech

Activity Diagram


S l id e 74


MedTech

Activity Diagram: Partitions


S l id e 75


• 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


S l id e 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.


S l id e 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.


S l id e 78


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.


S l id e 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.


S l id e 80


1 2

MedTech

Activity View: Concurrent Flows

• Send Signal Action ( ): indicates that a signal or message is sent to otheractivities or processes.


S l id e 81


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.


S l id e 82


MedTech

Activity View: Proposition of a Solution


S l id e 83


MedTech

UML DESIGN: STATE MACHINE VIEWDesign


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


S l id e 85

UML Design: State Machine View

MedTech

State Machine Diagram


S l id e 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


S l id e 87


MedTech

State Machine View : Transition

• Example of a seminar enrollment:trigger-signature [guard]/activity


S l id e 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 samestate


S l id e 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


S l id e 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


S l id e 91


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


S l id e 92


MedTech

State Machine View : Proposition of a (~) Solution


S l id e 93


MedTech

UML DESIGN: OTHER VIEWS…Design


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


S l id e 95

UML Design: Other Views

MedTech

Deployment Diagram


S l id e 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


S l id e 97


MedTech

Package Diagram


S l id e 98


MedTech

References


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