Uml Notes

GC22: Software Engineering
Object-Oriented Analysis
Professor David S. Rosenblum Department of Computer Science http://www.cs.ucl.ac.uk/staff/D.Rosenblum/
2007 David S. Rosenblum
Definition
Analysis facilitates the difficult transition between problem domain and solution domain, i.e., between the world and the machine
It attempts to refine and structure requirements in a way

that allows the designer to begin reasoning about the internal workings of the envisaged system It aims to separate concerns (i.e., to delineate the issues to be resolved and the decisions to be taken later on) It assists planning an incremental approach to later workflow activities The result is an initial high-level design model: the analysis model
Software Engineering (GC22)
USDP Context
Elaboration Inception Construction Transition
Requirements
Analysis
Design
Implementation Test
Preliminary iterations iteration iteration iteration iteration iteration iteration #1 #2 #n #n + 1 #n + 2 #m iteration #m + 1
Use Case Models vs. Analysis Models

Jacobson et al., 1999
USE CASE MODELS 1. Described in the language of the customer 2. External view of the system 3. Structured by use cases ANALYSIS MODELS 1. Described in the language of the developer 2. Internal view of the system 3. Structured by stereotypical classes and packages 4. Used primarily by developers to understand how to design & implement the system 5. Should not contain redundancies or inconsistencies amongst requirements 6. Outlines a first-cut design 7. Defines use case realisations (each an analysis of a use case in the use case model)
4. Used primarily as a contract

between customers and developers
5. May contain redundancies and

inconsistencies amongst requirements
6. Captures system functionality 7. Defines use cases that are further

analysed in the analysis model
Analysis Classes
An analysis class abstracts one or more classes and/or
subsystems in the systems design
the class)
Focuses on handling functional requirements Defines responsibilities (cohesive subsets of behaviour defined by Defines attributes Expresses relationships the class is involved in
Three basic kinds (according to Rational Unified Process)

Boundary classes Control classes Entity classes
Approach 1: Data-Driven Design
Identifying Classes
Identify all the data in the system Divide into classes before considering responsibilities Common approach: noun identification
Identify candidate classes by selecting all the nouns and noun
phrases in the requirements document
Discard inappropriate candidates
Redundant or omnipotent entities Vague entities Events or operations Meta-language Entities outside system scope Attributes Verbs and verb phrases highlight candidate operations!
Software Engineering (GC22) 2007 David S. Rosenblum
Exercise
Go back to your requirements document and set of use
cases for the library system
And anything else you might have gathered or created by now
Underline all the nouns and noun phrases Create a list of candidate classes
In examining the discard criteria, you may also identify some
candidate attributes
If so, assign them to classes
Underline all the verbs and verb phrases Create a list of candidate operations and assign them to
the classes
Approach 2: Responsibility-Driven Design
Identifying Classes
Identify all the responsibilities in the system Divide into classes before considering the classes data Common approach: CRC cards
Class, Responsibilities, Collaborations
Example CRC Cards for a Library

Stevens & Pooley, 2000
LibraryMember Responsibilities Maintain data about copies currently borrowed Meet requests to borrow & return copies Copy Responsibilities Maintain data about particular copy of book Inform corresponding Book when borrowed/returned Book Responsibilities Maintain data about one book Know whether there are borrowable copies
Collaborators Copy
Collaborators Book
Collaborators
Exercise
Go back to your requirements document and set of use
cases for the library system
And anything else you might have gathered or created by now
Create a set of CRC cards using post-it notes Information gathering: Use this material as a prompt, but
then brainstorm the things operating in the library system domain
Accept all ideas at this point and write each as a candidate class
on a separate card
Information analysis
Stick all cards on a wall and, as a group, try to determine
responsibilities and collaborators
UML Class Icons

Optional Visibility Adornments
(+public, -private, #protected, ~package)
Class name
(in italics if abstract)
Name compartment Optional attribute compartment Optional operation compartment
} } }
Book #title : String #available : Boolean = true <<constructor>> +create() +copiesOnShelf() : Int +borrow(c:Copy)
Attribute name Attribute type Initial value Operation with class scope and <<stereotype>> Operation signatures
Example UML Class

className
attribute name: type
Polygon
centre : Point vertices: List of Point borderColour: Colour fillColour: Colour display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean
operation name (parameter: type): result type
className
Polygon
Instance Scope versus Class Scope

Instance scope
By default, attributes and operations in a class have instance
scope
Objects have their own copies of attributes, allowing different
objects to have different values
Operations operate on specific instances of classes
Class scope
Attributes with class scope have a single shared value for every
instance of the class
Operations with class scope dont operate on class instances, but
on behalf of the entire class Example: Constructors
What Makes a Good Analysis Class?

Its name reflects its intent It is a crisp abstraction that models one specific element
of the problem domain
It has a small but defined set of responsibilities It has high cohesion It has low coupling with other classes
Example UML Class Diagram
Taken from [Booch 1999]
UML Object Icons

Object name Name compartment Optional attribute compartment Class name
} }
DSRsUMLBook : Book title = Using UML
Attribute name Attribute value Operations and attribute types are not shown on object diagrams!
Example UML Object
objectName: className
attribute name: type = value
triangle1: Polygon
centre = (0,0) vertices = (0,0), (4,0), (4,3) borderColour = black fillColour = white
(same operations for all instances of a class)
display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean
objectName: className
triangle1: Polygon
Example UML Object Diagram
Exercise
Compare the results of using noun identification and CRC
cards for identifying candidate classes in the library system
Construct a class diagram (using the basic notation) to

combine the consolidated results of using the two techniques: a first cut analysis model
Relationships
Relationships are connections between modelling
elements
Improve understanding of the domain, describing how objects
work together
Associations are relationships between classes

Examples Object Object Object Object
Act as a sanity check for good modelling
Links are relationships between objects

Links can be instances of associations
of of of of
class class class class
A A A A
sends a message to object of class B creates an object of class B has attribute whose values are objects of class B receives a message with argument of class B
Allow one object to invoke operations on another object

UML Relationship Notation

bidirectional / binary navigability unidirectional navigability aggregation composition
association name
[+ single directional arrow]
role name multiplicity
role name multiplicity

supplementary characteristics
Links Instantiate Associations
LibraryPatron
borrows
Book
Class and Association Level
<<instantiate>> <<instantiate>> <<instantiate>>
DSR:LibraryPatron
usingUML: Book
Object and Link Level
Multiplicity of an Association
Indicates the number of objects
that can participate in a relationship at any point in time borrows/returns
0..1 0..*
Book is copy of
1 1..*
LibraryPatron
Copy
0..*
0..1
borrows/returns borrows/returns
0..1
MemberOfStaff
0..*
Journal
Some Ways to Specify Multiplicity

Syntax 0..1 1 0..* or * 1..* 1..5 1..n 1..3, 8..10, 15..* Meaning Zero or 1 Exactly 1 Zero or more 1 or more 1 to 5 1 to n 1 to 3 OR 8 to 10 OR 15 to many
Exercise
Using your initial analysis class diagram for the library
Consider the interactions in your earlier use cases Consider the CRC cards you produced and the listed collaborators
system, identify and add associations between the classes
Add associations to your class diagram and provide each

with
a name multiplicity navigability
Your analysis model should now show classes, attributes,

operations, named associations, multiplicity and navigability
Generalisation and Inheritance

A special kind of association Subclass inherits attributes and
operations of superclass
And possibly extends superclass
Book is copy of Copy

0..* 1 1..*
LibraryPatron
Superclass
borrows/returns
0..1 0..*
Subclass
0..1
borrows/returns borrows/returns
0..1
Researcher
0..*
Journal
Another Inheritance Example

Abstract class Staff Member salary: Int increaseSalary(Int)
salary: Int increaseSalary(Int)
Librarian assignSubject(String)
Tutor assignCourse(String)
Researcher beginProject(String)
salary: Int increaseSalary(Int) assignCourse(String) beginProject(String)
Multiple inheritance Professor
Part/Whole Associations
Aggregation: Weak Ownership
The part objects can feature simultaneously in any number of
other whole objects
Course
1..*
5..*
Module
Composition: Strong Ownership

The whole strongly owns its parts, so the parts cannot feature
elsewhere
CheckerBoard
64
Square
NOTE: Not all 1-to-* relationships imply ownership

Derived Associations
Is it necessary to show all associations?
Sometimes associations that are not explicit can be deduced from
the diagram
They can be reprsented explicitly as derived associations,
indicating that they will not be implemented
Student
takes /is taken by
Module
/teaches
/is taught by teaches Lecturer

Association Classes
Used to attach attributes to an association itself rather
than the classes it associates
Class association line must have the same name!

Student is taking
1..* 5
Module
is taking mark : int

Association class
10
Exercise
Examine your updated analysis model (i.e., the one that
shows classes, attributes, operations, named associations, multiplicity and navigability)
Update your model if there is anywhere you can apply

Inheritance Association classes Qualified associations Other dependencies
Architectural Analysis
Architectural analysis involves organising analysis classes
into packages
Analysis classes Use case realisations
Key criterion: Separation of Concerns

High cohesion within packages Low coupling between packages
NOTE: This is a rather inadequate big picture notion of architecture that weakly accounts for system structure
Package Diagrams
Description
Package Diagrams are general purpose mechanisms for

organising model elements into related groups
But they have no realisation in the modelled system
No interfaces, no behaviour (other than those they contain)
Packages primarily serve to provide a namespace

Like Java packages Entities are identified using qualified names
Package name::package element Example (class attribute): Travel Agency::Agent::customerArray Example (operation): Library::BookBorrower::borrow(Copy)
11
Package Diagrams
Example
Library
Book Personnel Librarian
LibrarySearch Title Author <<imports>
BookBorrower
Use Case Realisation

Description
Analysis not only involves finding analysis classes, but also

finding use case realisations
Use case realisations show how analysis classes
collaborate to realise the behaviour specified by the use case
Each use case has a use case realisation
Use Case Realisation

Description
Analysis class diagrams

Relationships between analysis classes that interact to realise the
use case
Interaction diagrams
Example collaborations between objects realising the use case at
moments in time
Special requirements
Realisation process helps uncover new requirements
Use case refinement

Realisation helps update understanding of original use cases
12
Interaction Diagrams
Description
Interaction diagrams record, in detail, how objects

interact to perform a task
Dynamic views of a system
Mainly used to show how a system realises a use case (or a Two types
particular scenario in a use case)
Collaboration Diagrams
The two types show almost identical information, so

choice depends on modelling perspective
More prominent in UML 1.4 Called Communication Diagrams in UML 2.0 Sequence Diagrams UML 2.0 also introduces Interaction Overview diagrams to show flow relationships between individual interaction diagrams
Interaction Diagrams
Modelling Elements
Collaboration Diagrams
Objects: Computer entities participating in an interaction Actors: Users participating in an interaction Links: Communication paths between objects and actors Messages: Interaction instances between pairs of objects/actors
Sequence Diagrams
Ordered explicitly via message numbering
Objects: Computer entities participating in an interaction Actors: Users participating in an interaction Lifelines: Time-oriented representation of object/actor behaviour Focus of Control: Portion of lifeline having active computation Messages: Interaction instances between pairs of objects/actors
Ordered implicitly in sequence along lifelines

Collaboration Diagram
Example
theBook : Book
aMember : BookBorrower 1: borrow(theCopy) 3.1 :borrowed
theLibraryMember : LibraryMember
theCopy : Copy
3 :borrow 2 :okToBorrow
13
Collaboration Diagram
Example
Exercise
Create collaboration diagrams to illustrate how classes in
your analysis model for the library system support functionality specified in the use cases
Start by selecting a simple use case and, using UML

syntax, create a collaboration diagram to realise it
Update your analysis class diagram accordingly
Sequence Diagram
theLibraryMember : LibraryMember aMember : BookBorrower borrow(theCopy) okToBorrow borrow theCopy : Copy theBook : Book
Example
borrowed
14
Sequence Diagram
Example
Exercise
Take the collaboration diagram you have created for part
of your library system
Turn this diagram into a sequence diagram Then

In turn, take each use case for your library system and create
either a collaboration diagram or sequence diagram that realises the use case Aim to practice both techniques evenly Update your analysis class diagram accordingly
The 4+1 View Model of Architecture

Kruchten, 1995
Class diagrams and interaction diagrams contribute to this
Design view (logical)
Implementation view
Use case view Interaction diagrams contribute to this
Process view
Deployment view
15

Uml Notes

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Uml Notes

Încărcat de

Drepturi de autor:

Formate disponibile

GC22: Software Engineering

Professor David S. Rosenblum Department of Computer Science http://www.cs.ucl.ac.uk/staff/D.Rosenblum/

2007 David S. Rosenblum

It attempts to refine and structure requirements in a way

2007 David S. Rosenblum

Software Engineering (GC22)

2007 David S. Rosenblum

Software Engineering (GC22)

Use Case Models vs. Analysis Models

4. Used primarily as a contract

5. May contain redundancies and

6. Captures system functionality 7. Defines use cases that are further

Software Engineering (GC22)

Three basic kinds (according to Rational Unified Process)

Software Engineering (GC22)

2007 David S. Rosenblum

Approach 1: Data-Driven Design

phrases in the requirements document

Discard inappropriate candidates

Software Engineering (GC22)

If so, assign them to classes

Software Engineering (GC22)

2007 David S. Rosenblum

Approach 2: Responsibility-Driven Design

Software Engineering (GC22)

2007 David S. Rosenblum

Example CRC Cards for a Library

2007 David S. Rosenblum

Software Engineering (GC22)

responsibilities and collaborators

Software Engineering (GC22)

2007 David S. Rosenblum

UML Class Icons

Name compartment Optional attribute compartment Optional operation compartment

Example UML Class

operation name (parameter: type): result type

Software Engineering (GC22)

Instance Scope versus Class Scope

Objects have their own copies of attributes, allowing different

objects to have different values

Operations operate on specific instances of classes

instance of the class

Operations with class scope dont operate on class instances, but

on behalf of the entire class Example: Constructors

Software Engineering (GC22)

2007 David S. Rosenblum

What Makes a Good Analysis Class?

Software Engineering (GC22)

2007 David S. Rosenblum

Example UML Class Diagram

Taken from [Booch 1999]

Software Engineering (GC22)

2007 David S. Rosenblum

Software Engineering (GC22)

UML Object Icons

DSRsUMLBook : Book title = Using UML

Example UML Object

(same operations for all instances of a class)

Example UML Object Diagram

Taken from [Booch 1999]

Software Engineering (GC22)

2007 David S. Rosenblum