Transcript Lecture 1 for Chapter 5, Analysis

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Requirements Analysis
(Part 1 – Object Modeling)
Requirements Analysis


Formalization of requirements elicited from users
Analysis models
 Functional model (use cases)
 Analysis object model (class diagrams)
 Dynamic model (statechart and sequence diagrams)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
Object Models

Analysis Object Model
 Classes and objects that describe the application domain
 Part of the Requirements Analysis Document (RAD)
 Examples: BoardGame, Watch

Solution Object Model
 Classes and objects that are used to solve the problem
 Part of the Object Design Document (ODD)
 Examples: Tree, Hashtable, Widget

During Requirements Analysis, we focus on building the
Analysis Object Model
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
Object Models and Dynamic Models

Object model
 Focuses on individual concepts manipulated by system
 Class diagrams represent relationships between classes and objects
and properties of those classes and relationships

Dynamic model
 Focuses on behavior of the system
 Sequence diagrams represent interactions between objects within a
single use case
 Statecharts represent behavior within a single object
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Analysis Activities











Identifying entity objects
Object Modeling
Identifying boundary objects
Identifying control objects
Mapping use cases to objects with sequence diagrams
Modeling interactions among objects with CRC cards
Identifying associations
Dynamic Modeling
Identifying aggregates
Identifying attributes
Modeling state-dependent behavior of individual objects
Modeling inheritance relationships between objects
Reviewing the analysis model
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
Activities during Object Modeling


Main goal: Find the important abstractions
What happens if we find the wrong abstractions?
 Iterate and correct the model

Steps during object modeling
 1. Class identification

Based on the fundamental assumption that we can find abstractions
 2. Find the attributes
 3. Find the methods
 4. Find the associations between classes

Order of steps
 Goal: get the desired abstractions
 Order of steps secondary, only a heuristic
 Iteration is important
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Class Identification




Identify the boundaries of the system
Identify the important entities in the system
Class identification is crucial to object-oriented modeling
Basic assumption:
 1. We can find the classes for a new software system (Forward
Engineering)
 2. We can identify the classes in an existing system (Reverse
Engineering)

Depending on the purpose of the system different objects might
be found
 How can we identify the purpose of a system?
 Scenarios and use cases
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Pieces of an Object Model


Classes
Associations (Relations)
 Generic associations
 Canonical associations



Attributes





Part of- Hierarchy (Aggregation)
Kind of-Hierarchy (Generalization)
Detection of attributes
Application specific
Attributes in one system can be classes in another system
Turning attributes to classes
Operations
 Detection of operations
 Generic operations: Get/Set, General world knowledge, design patterns
 Domain operations: Dynamic model, Functional model
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Object vs Class



Object (instance): Exactly one thing
Class: describes a group of objects with similar properties
Object diagram: A graphic notation for modeling objects, classes
and their relationships ("associations"):
 Class diagram: Template for describing many instances of data. Useful for
taxonomies, patters, schemata...
 Instance diagram: A particular set of objects relating to each other. Useful
for discussing scenarios, test cases and examples
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
Mapping parts of speech to object model components
[Abbott, 1983]
Part of speech
Model component
Example
Proper noun
object
Jim Smith
Improper noun
class
Toy, doll
Doing verb
method
Buy, recommend
being verb
inheritance
is-a (kind-of)
having verb
aggregation
has an
modal verb
constraint
must be
adjective
attribute
3 years old
transitive verb
method
enter
intransitive verb
method (event)
depends on
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
Object Types

Entity Objects
 Represent the persistent information tracked by the system
(Application domain objects, “Business objects”)

Boundary Objects
 Represent the interaction between the user and the system

Control Objects:
 Represent the control tasks performed by the system

Having three types of objects leads to models that are more
resilient to change.
 The interface of a system changes more likely than the control
 The control of the system change more likely than the application
domain

Object types originated in Smalltalk:
 Model, View, Controller (MVC)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Example: 2BWatch Objects
Button
Year
ChangeDate
Month
LCDDisplay
Day
Entity Objects
Modified from originals of Bruegge & Dutoit
Control Objects
Interface Objects
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
Naming of Object Types in UML


UML provides several mechanisms to extend the language
UML provides the stereotype mechanism to present new modeling elements
<<Entity>>
Year
<<Control>>
ChangeDate
<<Entitity>>
Month
<<Boundary>>
LCDDisplay
<<Entity>>
Day
Entity Objects
Modified from originals of Bruegge & Dutoit
<<Boundary>>
Button
Control Objects
Boundary Objects
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Recommended Naming Convention for Object Types

To distinguish the different object types on a syntactical basis, we
recommend suffixes:
Objects ending with the “_Boundary” suffix are boundary objects
Objects ending with the “_Control” suffix are control objects

Entity objects do not have any suffix appended to their name.


Year
Button_Boundary
ChangeDate_
Control
Month
LCDDisplay_Boundary
Day
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
Identifying Entity Objects

Entity objects
 Persistent information tracked by system

Heuristics
 Terms that developers or users need to clarify in order to
understand the use case
 Recurring nouns in the use case
 Real-world entities that the system needs to track
 Real-world activities that the system needs to track
 Data sources or sinks
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Identifying Boundary Objects

Boundary objects
 Interactions between actors and system

Heuristics
 Identify user interface controls that the user needs to initiate the use
case
 Identify forms the user needs to enter data into the system
 Identify notices and messages the system needs to respond to the
user
 Identify actor terminals to refer to the user interface under
consideration
 Do not model the visual aspects of the user interface
 Use end users’ terms
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Identifying Control Objects

Control objects
 Realize use cases, encapsulates the behavior of the use case
 Usually not persistent, exists in the lifetime of the use case
 Helps clarify the entry and exit conditions of the use case

Heuristics
 Identify one control object per use case
 Identify one control object per actor in the use case
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Identifying Associations

Association
 A relationship between two or more classes

Properties
 Name – describes what the relationship is all about
 Role – the function of each class in the association
 Multiplicity – number of possible instances

Heuristics






Examine verb phrases
Name associations and roles precisely
Use qualifiers to identify namespaces and keys
Eliminate associations that can be derived from other associations
Worry about multiplicity later
Minimize the number of associations
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
Qualifiers
Without qualification
Directory
1
*
File
filename
With qualification
Directory

filename
1
0…1
File
Qualifiers can be used to reduce the multiplicity of an
association.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Identifying Aggregates

Aggregate
 An association denoting whole-part relationship

Composition aggregate
 Whole and parts cannot exist without each other
 Denotes is-part-of relationship

Shared aggregate
 Whole and parts can exist independently
 Denotes belongs-to relationship

Heuristics
 1-to-many relationships could potentially be whole-part
relationships
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
Aggregation


An aggregation is a special case of association denoting a “consists of”
hierarchy.
The aggregate is the parent class, the components are the children class.
Exhaust system
Exhaust system
0..2
1
0..2
1
Muffler
Tailpipe
Muffler
Tailpipe
diameter
diameter
diameter
diameter

A solid diamond denotes composition, a strong form of aggregation where
components cannot exist without the aggregate. (Bill of Material)
TicketMachine
3
ZoneButton
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
Identifying Attributes

Attributes
 Properties of individual objects

Properties
 Name
 Type

Heuristics
 Examine possessive phrases
 Represent stored state as an attribute
 Describe each attribute
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
26
Modeling Inheritance Relationships

Generalization
 Identification of abstract concepts from lower-level ones

Specialization
 Identification of more specific concepts from a high-level one

Heuristics
 Look for classes that share similarities
 Look for groups of classes that appear to be a taxonomy
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
A Strategy for Building Object Models




Explicitly schedule meetings for object identification
First just find objects
Then try to differentiate them between entity, interface and
control objects
Find associations and their multiplicity
 Unusual multiplicities usually lead to new objects or categories

Identify Inheritance: Look for a Taxonomy, Categorize
Identify Aggregation

Allow time for brainstorming , Iterate, iterate

Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
33