Object Modeling in Practice: Heuristics



Explicitly schedule meetings for object identification
Try to differentiate between entity, boundary and control
objects
Find associations and their multiplicity
 Unusual multiplicities usually lead to new objects or categories

Identify Aggregation
Identify Inheritance: Look for a Taxonomy, Categorize

Allow time for brainstorming , Iterate, iterate

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
1
Software Engineers are not the only System Analysts
7:19 PM
Ontology for 7 Object Modeling
Ontology
Object a nd System b ound ary ide ntifica tion
Phenomenology
Objects are u ser d efin ed
Religion
Ide alis m
Naive Idealism
Objects exist only i n my
ima gina tion . If I clos e my e ye s, they
don 't exist (Berke ley)
Realism
Ma terialism
Critica l Idealism
Reali ty is dete rmine d by
our idea s
(Kant, Hege l,
Sch open haue r)
Dualistic Ide alis m
Ma rx
Ide as a re de termi ned
by th e econo mic
real ity
David Hume
Monistic Idealism
Schopenhauer
Plato
Reali ty ca n ne ve r be
see n on ly its sh adow.
Naive Re alis m
Thi ngs are e xa ctl y
how we experie nce
the m
Goethe
Kant
Ide as a re ma de u p by h uman s
" Ding an sich"
:Reas on for
perception but can never be
see n itself
Steiner
Dialectis m
Ide as a re de termi ned by the
dia log betwee n th e us er an d
real ity
( Sokrate s, Heg el, Ma rx)
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
2
What is a Software Engineer?

From the point of view of phenomenology, Software
Engineers are dialectic monistic idealists:
 Idealists:

They accept that ideas (called requirements or “customer’s
wishlist”) are different from reality.
 They are not realists:

The reality might not yet exist (“Vaporware is always possible ”)
 They are monistic:

They are optimistic that their ideas can describe reality (“das
Ding an sich”).
 Dialectic:

They do this in a dialogue with the customer
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
3
Summary
In this lecture, we reviewed the construction of the object model
from use case model. In particular, we described:
 Identification of objects
 Refinement of objects with attributes and operations
 Generalization of concrete classes
 Identification of associations
 Reduction of multiplicity using qualification.
In the next lecture, we describe the construction of the dynamic
model from the use case and object models.
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
4
The Building Access Control System – Part I





Design of a building access control system [ Wrox Press web site
(http://www.wrox.com), also http://faculty.ed.umuc.edu/~cklein ]
The space to be protected is divided over 4 floors of a building with a total
area of about 5000M2. The building itself is divided into five areas: two
research wings, an experimental wing, an administration wing, and a central
section containing classrooms and the two lecture halls.
The site accommodates about 500 people every day: mostly students,. but
also teachers, researchers, administrative and technical staff, as well as
numerous visitors.
After various items of property started disappearing, it was decided to
restrict access to some of the rooms using doors with automatic
locking. The opening of each door is controlled by a badge reader, located
nearby.
The badges that allow the opening of these doors are only given to the
people that need to access restricted areas in order to perform their
duties. Access rights are distributed among groups of people and groups of
doors. Each person and each door must always belong to a group, even if
they are the only member of that group.
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
5
The Building Access Control System – Part II

A group of doors may consist of doors distributed throughout the building,
but from the point of view of controlling access, only the concept of a group
of doors is important - routes and movement are not controlled. However, a
given door cannot be a member of more than one group of doors. A given
person, on the other hand, may be 'a member of several groups, so that his
or her access rights correspond to the combined rights of each of the groups
he or she belongs to.

Access rights are established by describing, for each group of people, the
various groups of doors that are accessible and under what time
constraints. These rights are contained in a yearly calendar that describes
the schedule a week at a time. Given that there will be a small variation of
rights over time, a calendar may be initialized using 'typical' weeks that
describe a fixed configuration of rights. The supervisor may create as many
'typical' weeks as she wishes, and any subsequent changes made will
automatically be propagated to all the calendars using them. On the other
hand, changes made to a calendar directly - to take vacation days into
consideration, for example - are not affected by the modification of a
'typical' week.
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
6
The Building Access Control System – Part III



The following table [not shown] represents a typical week. The grayed
areas correspond to time periods during which access is not
authorized. [The table shows access allowed from 7 a.m. through 10 p.m.
each weekday].
The access control system must operate as autonomously as possible,
although a supervisor is responsible for the initial configuration and the
updating of the various pieces of information that define the groups of
people and doors. A guard has a control screen, and is informed of any
unsuccessful entry attempts. Alarms are transmitted with a slight delay:
information update on the control screen is performed every minute.
The user interface must help the users to specify their requests
correctly. Legal requests and input values are systematically read from lists
that define the domain of correct values.
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
7
Conquering Complex and Changing Systems
Object-Oriented Software Engineering
Chapter 5, Analysis:
Dynamic Modeling
Outline

Dynamic modeling
 Sequence diagrams
 State diagrams



Using dynamic modeling for the design of user interfaces
Analysis example
Requirements analysis document template
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
9
Example of use case format
Use case name
ReportEmergency
Entry condition
1. The FieldOfficer activates the “Report Emergency” function of her
terminal.
Flow of events
2. FRIEND responds by presenting a form to the officer...
3. The FieldOfficer fills the form....
4. The Dispatcher reviews the information submitted by the
FieldOfficer ...
Exit condition
5. The FieldOfficer receives the acknowledgment and the selected
response.
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
10
How do you find classes?

From previous lectures
 Application domain analysis: Talk to client to identify abstractions
 Apply general world knowledge and intuition
 Scenarios

Natural language formulation of a concrete usage of the system
 Use Cases

Natural language formulation of the functions of the system
 Textual analysis of problem statement (Abbot)

From this lecture
 Dynamic model



Events: Candiates for operations to be offered by classes
Sequence diagrams as sources for objects
From future lectures
 Design Patterns
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
11
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 Charts:
 A state machine that describes the response of an object of a given
class to the receipt of outside stimuli (Events).

Activity Diagram:
 Special type of statechart where all states are action states
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
12
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 single objects => statechart diagram
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems
13