Transcript Lecture 1 for Chapter 5, Analysis

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Requirements Analysis
Chapters 5-6
Object-Oriented Software Engineering:
Using UML, Patterns, and Java, 2nd Edition
By B. Bruegge and A. Dutoit
Prentice Hall, 2004.
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 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
3
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
4
Object Models

Analysis Object Model
 Classes and objects that describe the application domain
 Part of the Requirements Document
 Examples: BoardGame, Watch

Solution Object Model
 Classes and objects that are used to solve the problem
 Part of the Design Document
 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
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
6
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
7
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
8
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
9
Finding Participating Objects in Use Cases

Pick a use case and look at its flow of events
 Find terms that developers or users need to clarify in order to
understand the flow of events
 Look for recurring nouns (e.g., Incident),
 Identify real world entities that the system needs to keep track of
(e.g., FieldOfficer, Dispatcher, Resource),
 Identify real world procedures that the system needs to keep track
of (e.g., EmergencyOperationsPlan),
 Identify data sources or sinks (e.g., Printer)
 Identify interface artifacts (e.g., PoliceStation)

Be prepared that some objects are still missing and need to be
found:


Model the flow of events with a sequence diagram
Always use the user’s terms
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
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
11
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 is more likely to change than the control
 The control of the system is more likely to change than the
application domain
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
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
13
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
14
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
15
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
17
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
18
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
19
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
20
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
21
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
22
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
23
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
24
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
25
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
26
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
27
Dynamic Modeling with UML

Diagrams for dynamic modeling
 Interaction diagrams describe the dynamic behavior between objects
 Statecharts describe the dynamic behavior of a single object

Interaction diagrams
 Sequence Diagram:


Dynamic behavior of a set of objects arranged in time sequence.
Good for real-time specifications and complex scenarios
 Collaboration Diagram :


Shows the relationship among objects. Does not show time
State Chart Diagram:
 A state machine that describes the response of an object of a given
class to the receipt of outside stimuli (Events).
 Activity Diagram: A special type of statechart diagram, where all
states are action states (Moore Automaton)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Dynamic Modeling

Definition of dynamic model:
 A collection of multiple state chart diagrams, one state chart
diagram for each class with important dynamic behavior.

Purpose:
 Detect and supply methods for the object model

How do we do this?
 Start with use case or scenario
 Model interaction between objects => sequence diagram
 Model dynamic behavior of a single object => statechart diagram
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
What is an Event?


Something that happens at a point in time
Relation of events to each other:
 Causally related: Before, after,
 Causally unrelated: concurrent


An event sends information from one object to another
Events can be grouped in event classes with a hierarchical
structure. ‘Event’ is often used in two ways:
 Instance of an event class: “Bob calls Janet”.

Event class “New call”, Subclass “Pick up receiver”
 Attribute of an event class

Call(Bob, Janet)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
Sequence Diagram



From the flow of events in the use case or scenario proceed to
the sequence diagram
A sequence diagram is a graphical description of objects
participating in a use case or scenario using a DAG (direct
acyclic graph) notation
Relation to object identification:
 Objects/classes have already been identified during object modeling
 Objects are identified as a result of dynamic modeling

Heuristic:
 A event always has a sender and a receiver.
 The representation of the event is sometimes called a message
 Find them for each event => These are the objects participating in
the use case
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Start with Flow of Events from Use Case

Flow of events from “Dial a Number” Use case:









Caller lifts receiver
Dial tone begins
Caller dials
Phone rings
Callee answers phone
Ringing stops
....
Actors: caller, callee
Objects:
 Caller phone, callee phone, network
 Phone: aggregate of receiver, keypad, ringer, line
 Network: aggregate of switches, trunks, signaling links
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Heuristics for Sequence Diagrams

Layout:
 1st column: Should correspond to the actor who initiated the use case
 2nd column: Should be a boundary object
 3rd column: Should be the control object that manages the rest of the use
case

Creation:
 Control objects are created at the initiation of a use case
 Boundary objects are created by control objects

Access:
 Entity objects are accessed by control and boundary objects,
 Entity objects should never call boundary or control objects: This makes it
easier to share entity objects across use cases and makes entity objects
resilient against technology-induced changes in boundary objects.

Use CRC cards as first step in defining complex sequence diagrams
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
CRC Cards

CRC – class, responsibilities, collaborators
 Class – name of class
 Responsibilities – operations the class is responsible for
 Collaborators – other classes it is associated with


CRC cards can be used to clarify the scope of a class
Useful during brainstorming sessions
 Take vertical slice through a scenario
 Identify all classes, write each one on a card
 While examining flow of events, fill in the responsibilities of each
class
 Collaborators are added as dependencies between classes are
identified.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
What else can we get out of sequence diagrams?



Sequence diagrams are derived from the use cases. We
therefore see the structure of the use cases.
The structure of the sequence diagram helps us to determine
how decentralized the system is.
We distinguish two structures for sequence diagrams: Fork and
Stair Diagrams (Ivar Jacobsen)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
Fork Diagram

Much of the dynamic behavior is placed in a single object,
ususally the control object. It knows all the other objects and
often uses them for direct questions and commands.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
36
Stair Diagram

The dynamic behavior is distributed. Each object delegates
some responsibility to other objects. Each object knows only a
few of the other objects and knows which objects can hel with
a specific behavior.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
37
Fork or Stair?


Which of these diagram types should be chosen?
Object-oriented fans claim that the stair structure is better
 The more the responsibility is spread out, the better


However, this is not always true. Better heuristics:
Decentralized control structure
 The operations have a strong connection
 The operations will always be performed in the same order

Centralized control structure (better support of change)
 The operations can change order
 New operations can be inserted as a result of new requirements
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
UML Statechart Diagram Notation
Event trigger
With parameters
State1
Event1(attr) [condition]/action
do/Activity
entry /action
exit/action
Guard
condition
State2
Also: internal transition
and deferred events

Notation based on work by Harel
 Added are a few object-oriented modifications

A UML statechart diagram can be mapped into a finite state machine
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
Statechart Diagrams


Graph whose nodes are states and whose directed arcs are
transitions labeled by event names.
We distinguish between two types of operations in statecharts:
 Activity: Operation that takes time to complete

associated with states
 Action: Instantaneous operation



associated with events
associated with states (reduces drawing complexity): Entry, Exit,
Internal Action
A statechart diagram relates events and states for one class
 An object model with a set of objects has a set of state diagrams
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
State

An abstraction of the attributes of a class
 State is the aggregation of several attributes a class

Basically an equivalence class of all those attribute values and
links that do no need to be distinguished as far as the control
structure of the system is concerned
 Example: State of a bank


A bank is either solvent or insolvent
State has duration
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Nested State Diagram



Activities in states are composite items denoting other lowerlevel state diagrams
A lower-level state diagram corresponds to a sequence of
lower-level states and events that are invisible in the higherlevel diagram.
Sets of substates in a nested state diagram denote a superstate
are enclosed by a large rounded box, also called contour.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
42
Superstates



Goal:
 Avoid spaghetti models
 Reduce the number of lines in a state diagram
Transitions from other states to the superstate enter the first
substate of the superstate.
Transitions to other states from a superstate are inherited by all
the substates (state inheritance)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Modeling Concurrency
Two types of concurrency
1. System concurrency
 State of overall system as the aggregation of state diagrams, one for
each object. Each state diagram is executing concurrently with the
others.
2. Object concurrency
 An object can be partitioned into subsets of states (attributes and
links) such that each of them has its own subdiagram.
 The state of the object consists of a set of states: one state from each
subdiagram.
 State diagrams are divided into subdiagrams by dotted lines.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
Example of Concurrency within an Object
Splitting control
Synchronization
Emitting
Do: Dispense
Cash
Setting
Up
Cash taken
Ready
to reset
Ready
Do: Eject
Card
Card taken
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
45
State Chart Diagram vs Sequence Diagram

State chart diagrams help to identify:
 Changes to an individual object over time

Sequence diagrams help to identify
 The temporal relationship of between objects over time
 Sequence of operations as a response to one ore more
events
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
Dynamic Modeling of User Interfaces

Statechart diagrams can be used for the design of user interfaces
 Also called Navigation Path

States: Name of screens
 Graphical layout of the screens associated with the states helps when
presenting the dynamic model of a user interface

Activities/actions are shown as bullets under screen name
 Often only the exit action is shown

State transitions: Result of exit action
 Button click
 Menu selection
 Cursor movements

Good for web-based user interface design
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
Navigation Path Example
Diagnostics Menu
•User moves cursor to Control Panel or Graph
Graph
Control panel
• User selects data group and
• User selects functionality of sensors
type of graph
Define
• User defines a sensor event
from a list of events
Enable
• User can enable a
sensor event from a
list of sensor
events
List of events
• User selects event(s)
Modified from originals of Bruegge & Dutoit
Disable
• User can disable a
sensor event from a
list of sensor events
List of sensor events
• User selects sensor
event(s)
Selection
• User selects data group
• Field site
• Car
• Sensor group
• Time range
• User selects type of graph
• time line
• histogram
• pie chart
Visualize
• User views graph
• User can add data groups for
being viewed
Link
• User makes a link (doclink)
Object-Oriented Software Engineering: Using UML, Patterns, and Java
48
Practical Tips for Dynamic Modeling

Construct dynamic models only for classes with significant
dynamic behavior
 Avoid “analysis paralysis”

Consider only relevant attributes
 Use abstraction if necessary


Look at the granularity of the application when deciding on
actions and activities
Reduce notational clutter
 Try to put actions into state boxes (look for identical actions on
events leading to the same state)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
49
Summary: Requirements Analysis
1. What are the transformations?
Functional Modeling
 Create scenarios and use case diagrams
 Talk to client, observe, get historical records, do thought
experiments
2. What is the structure of the system?
Object Modeling
Create class diagrams
Identify objects.
What are the associations between them? What is their multiplicity?
What are the attributes of the objects?
What operations are defined on the objects?

Dynamic Modeling
3. What is its behavior?
Create sequence diagrams
Identify senders and receivers
Show sequence of events exchanged between objects. Identify event
dependencies and event concurrency.
Create state diagrams
Only for the dynamically interesting objects.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Example

Flow of events from “Dial a Number” Use case:









Caller lifts receiver
Dial tone begins
Caller dials
Phone rings
Callee answers phone
Ringing stops
....
Actors: caller, callee
Objects:
 Caller phone, callee phone, network
 Phone: aggregate of receiver, keypad, ringer, line
 Network: aggregate of switches, trunks, signaling links
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
Define Use Case: What is the system boundary?
Network is part of system
Caller
call
Callee
Caller
Callee
originateCall
terminateCall
Network is not part of system
Network
(Exceptions are not shown here)
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Initial Objects
Phone
Receiver
originateCallControl
Keypad
Ringer
terminateCallControl
NetworkInterface
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Sequence Diagram for Call Origination
: Caller
callerPhone :
Phone
liftReceiver()
create()
originatingOffice
: SwitchDB
:
NetworkInterface
: Network
:
originateCallControl
checkAvailableLine()
line(lineno)
playDialtone()
listenDialtone()
dialDigit()
analyzeDigit()
dialDigit()
analyzeDigit()
dialDigit()
analyzeDigit()
dialDigit()
analyzeDigit()
create()
: CallRecord
setupCall()
sendSetupMessage()
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
Updated List of Objects
Phone
Receiver
Keypad
originateCallControl
SwitchDB
Ringer
terminateCallControl
CallRecord
NetworkInterface
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
State Chart for originateCallControl Object
AvailableLin
e
LineNotAvailable
LineIsAvailable
Dialtone
NoDialtone
dialDigit
dialDigit
CollectDigit
s
terminatingLineBusy
terminatingLineIdle
Ringing
Busy
calleeAnswer
Talking
hangUp
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
Modeling Checklist for the Review

Is the model correct?
 A model is correct if it represents the client’s view of the the system:
Everything is the model represents an aspect of reality

Is the model complete?
 Every scenario through the system, including exceptions, is described.

Is the model consistent?
 The model does not have components that contradict themselves (for
example, deliver contradicting results)

Is the model unambiguous?
 The model describes one system (one reality), not many

Is the model realistic?
 The model can be implemented without problems
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
57
Diagram Checklist for the Requirements Document

One problem with modeling:
 We describe a system model with many different views (class diagram,
use cases, sequence diagrams, )state charts)


We need to check the equivalence of these views as well
Syntactical check of the models
 Check for consistent naming of classes, attributes, methods in
different subsystems
 Identify dangling associations (associations pointing to nowhere)
 Identify double- defined classes
 Identify missing classes (mentioned in one model but not defined
anywhere)
 Check for classes with the same name but different meanings
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
58
Additional slides
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
59
When is a model dominant?





Model dominance: One model having significantly higher
importance than the rest
Object model: The system has objects with nontrivial state.
Dynamic model: The model has many different types of events:
Input, output, exceptions, errors, etc.
Functional model: The model performs complicated
transformations (e.g. computations consisting of many steps).
Which of these models is dominant in the following three cases?
 Compiler
 Database system
 Spreadsheet program
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
60
Dominance of models

Compiler:
 The functional model most important. (Why?)
 The dynamic model is trivial because there is only one type input
and only a few outputs.

Database systems:
 The object model most important.
 The functional model is trivial, because the purpose of the
functions is usually to store, organize and retrieve data.

Spreadsheet program:
 The functional model most important.
 The dynamic model is interesting if the program allows
computations on a cell.
 The object model is trivial, because the spreadsheet values are
trivial and cannot be structured further. The only interesting
object is the cell.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
61
Team Analysis




A system is a collection of subsystems providing services
Analysis of services is provided by a set of the teams who
provide the models for their subsystems
Integration of subsystem models into the full system model by
the architecture team
Analysis integration checklist:
 Are all the classes mentioned in the data dictionary?
 Are the names of the methods consistent with the names of
actions, activities, events or processes?
 Check for assumptions made by each of the services


Missing methods, classes
Unmatched associations
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
62
Analysis: UML Activity Diagram
Define
use cases
Define
participating
objects
Define
entity
objects
Define
boundary
objects
Define
control
objects
Define
interactions
Define
efine
Define
n o n t r i v i a la D
associations
behavior ttributes
Consolidate
model
Review
model
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
63
Object Model Integration in a large Project
All Teams
Revised System
Model
Model
Changes
Analysis
Review
Team 1
User Interface
Team
Analysis
Analysis
Integrated
System
Model
User Interface
Modu le 1
Module
Architecture Team
Integration
Module 3
Module 2
Analysis
Analysis
Team 2
Modified from originals of Bruegge & Dutoit
Team 3
Module 4
Analysis
Team 4
Module 5
Analysis
Team 5
Object-Oriented Software Engineering: Using UML, Patterns, and Java
64
Project Agreement


The project agreement represents the acceptance of (parts of)
the analysis model (as documented by the requirements
analysis document) by the client.
The client and the developers converge on a single idea and
agree about the functions and features that the system will
have. In addition, they agree on:




a list of prioritized requirements
a revision process
a list of criteria that will be used to accept or reject the system
a schedule, and a budget
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
65
Prioritizing requirements

High priority (“Core requirements”)
 Must be addressed during analysis, design, and implementation.
 A high-priority feature must be demonstrated successfully during
client acceptance.

Medium priority (“Optional requirements”)
 Must be addressed during analysis and design.
 Usually implemented and demonstrated in the second iteration of
the system development.

Low priority (“Fancy requirements”)
 Must be addressed during analysis (“very visionary scenarios”).
 Illustrates how the system is going to be used in the future if not yet
available technology enablers are available
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
66
Summary


In this lecture, we reviewed the construction of the dynamic
model from use case and object models. In particular, we
described: In particular, we described:
Sequence and statechart diagrams for identifying new classes
and operations.
Modified from originals of Bruegge & Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
67