2. An overview of OOSE development
activities and their products
Requirements
elicitation
Analysis
System design
problem statement
functional
model
nonfunctional
requirements
analysis
object model
dynamic
model
class diagram
use case
diagram
statechart
diagram
sequence diagram
3. An Introduction to Object Modeling
– The approach of using object modeling
during systems analysis and design is
called object-oriented analysis.
• Object-oriented analysis (OOA) techniques
are used to
– (1) study existing objects to see if they can be reused or
adapted for new uses, and to
– (2) define new or modified objects that will be combined
with existing objects into a useful business computing
application.
4. Definition : Object Modeling
– The object-oriented approach is centered
around a technique referred to as object
modeling.
• Object modeling is a technique for identifying
objects within the systems environment, and the
relationships between those objects.
5. Why do we model
• Models help us to visualize a system as it is or as we want it
to be.
• Models permit us to specify the structure or behavior of a
system.
• Models give us a template that guides us in constructing a
system.
• Models document the decisions we have made.
6. System concepts for
Object Modeling
• Object and related concepts
– What is and isn’t an Object
– Attribute, state
– Behavior/ operations
– Roles- responsibilities
– Identity
– Life span
7. System concepts for
Object Modeling
• Objet Oriented Concepts:
– Abstraction
– Encapsulation
– Inheritance
– Modularity
– Polymorphism
8. Principles of Modeling
• The choice of what models to create has a profound
influence on how a problem is attacked and how a solution is
shaped.
• Every model may be expressed at different levels of
precision.
• The best models are connected to reality.
• No single model is sufficient. Every nontrivial system is
best approached through a small set of nearly independent
models.
9. Activities during Object Modeling
Main goal: Find the important abstractions
• 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
– What happens if we find the wrong abstractions?
• We iterate and revise the model
10. Class Identification
Class identification is crucial to object-
oriented modeling
– Helps to identify the important entities of a
system
• Basic assumptions:
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)
• Why can we do this?
– Philosophy, science, experimental evidence.
11. Class Identification
• Approaches
– Application domain approach
• Ask application domain experts to identify relevant
abstractions
– Syntactic approach
• Start with use cases
• Analyze the text to identify the objects
• Extract participating objects from flow of events
– Design patterns approach
• Use reusable design patterns
– Component-based approach
• Identify existing solution classes.
12. Class identification is a
Hard Problem
• One problem: Definition of the system boundary:
– Which abstractions are outside, which abstractions are
inside the system boundary?
• Actors are outside the system
• Classes/Objects are inside the system.
• An other problem: Classes/Objects are not just
found by taking a picture of a scene or domain
– The application domain has to be analyzed
– 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 => Functional model
13. There are different
types of Objects
• Entity Objects
– Represent the persistent information tracked
by the system (Application domain objects, also
called “Business objects”)
• Boundary Objects
– Represent the interaction between the user
and the system
• Control Objects
– Represent the control tasks performed by the
system.
15. Types of Relationships
• Objects contribute to the behavior of a system by
collaborating with one another.
• The relationship between any two objects encompasses
the assumptions that each makes about the other
• two kinds of object hierarchies are of particular
interest in object-oriented analysis and design, namely:
– Links
– Aggregation
– Simple relations
16. Types of Relationships
• Objects can work together in three different
types of relationships:
• Uses(links/ Association): An object can use
another to do some work (association).
• Composition: A complex object may be composed
of several parts (aggregation, containment).
• Simple(links): Two objects may depend on each
other but don’t interact directly (weak
association)
17. Links/ Uses/ Association
• Semantics The term link derives from Rumbaugh, who
defines it as a "physical or conceptual connection between
objects" .
• An object collaborates with other objects through its links
to these objects.
• Stated another way, a link denotes the specific association
through which one object (the client) applies the services
of another object (the supplier), or through which one
object may navigate to another.
• Message passing between two objects is typically
unidirectional, although it may occasionally
• be bidirectional.
18. Objects that Use Objects
(Links/ Uses)
• Whenever one object sends a message to another object
(even if object
• Doesn’t send messages back), a uses relationship is
established them.
• Ex: A SalesInvoice uses a Customer object
• Six different
19. Techniques For Implementing A Uses/
Links/ Association Relationship
Object 1 uses object 2
1. Object 2 as Arguments
2. Creating Your Own objects 2
3. Third Party object 2
4. Combining Constructors
5. Passing an Argument
6. Creating Objects On-The-Fly
20. As argument
• Option would be to pass the object2 as an argument to
the constructor of the object1
• Rule for Using Objects
• You should use an attribute when:
– The obj needs to be directed from several different methods, or
the obj stores persistent state info between method calls.
– The obj you are going to use is used repeatedly.
– The obj is very expensive or time consuming to construct, and you
will use the obj more than once.
21. Creating Your Own objects
• A second solution is to construct the object2 in the object1
class constructor.
22. Third Party object
• It assumes that a repository of Customers
(CustomerDB) keeps track of all Customer objects
23. Combining Constructors
• Give the object1 class two constructors and use a
no-argument constructor when you want to create
a new object1.
24. Passing an Argument
• Sometimes an object may have a very short and
transitory relationship with another object.
• You may need to use an object only during the execution
of a single method.
• In that case, you might choose to have the method take
as an argument an instance of the object it uses
25. This is appropriate when:
• The obj you are going to use will be used in a single method,
and the state of that obj doesn’t need to be retained
between calls.
• The obj you have to use carries with it some immediate state
info thatmust be renewed each time the method is called.
• The obj you’re using is easily constructed outside your class.
If,however, it’s easier for you (using class) to construct the
obj from scratch(because of some special knowledge), use
the objects on-the-fly technique.
26. This is appropriate when:
• If an identical obj is constructed over and over,
or it it’s very time-consuming to construct an obj
and you need to use it more than once,
• you should use a referential attribute to hold a
reference to the obj you’ll use, rather than pass it
as an argument or create it on-the-fly
27. Creating objects
on the fly
• A second way to get an object that will be used in only a
single method is to create it inside the method itself.
• This has the advantage that
– it makes the calling method easier, and that
– the code where the object is created inside the method is
inherently more maintainable.
• This technique is called for when the using object has
special knowledge that required to create the object that
it will use
28.
29. Roles
• As a participant in a link, an object may play one of three
roles:
– Actor An object that can operate upon other objects but is
never operated upon by other objects; in some contexts, the
terms active object and actor are
interchangeable
– Server An object that never operates upon other objects; it is
only operated upon by other objects
– Agent An object that can both operate upon other objects and
be operated upon by other objects; an agent is usually created to
do some work on behalf of an actor or another agent
30. Synchronization
• Synchronization Whenever one object passes a message to
another across a link, the two objects are said to be
synchronized.
• However, in the presence of multiple threads of control,
objects require more sophisticated message passing in
order to deal with the problems of mutual exclusion that
can occur in concurrent systems.
• As we described earlier, active objects embody their own
• thread of control, and so we expect their semantics to be
guaranteed in the presence of other active objects.
31. Approach to Synchronization
• we must choose one of three approaches to
synchronization:
• Sequential :The semantics of the passive object are
guaranteed only in the presence of a single active object at
a time.
• Guarded :The semantics of the passive object are
guaranteed in the presence of multiple threads of control,
but the active clients must collaborate to achieve mutual
exclusion.
• Synchronous: The semantics of the passive object are
guaranteed in the presence of multiple threads of control,
and the supplier guarantees mutual exclusion.
32. Aggregate
• Semantics Whereas links denote peer-to-peer or
client/supplier relationships, aggregation
• denotes a whole/part hierarchy, with the ability to navigate
from the whole (also called the aggregate) to its parts (also
known as its attributes). In this sense, aggregation is a
specialized kind of association.
33. Aggregation
• Aggregation may or may not denote physical containment.
For example, an airplane is
• composed of wings, engines, landing gear, and so on: this is
a case of physical containment.
• On the other hand, the relationship between a shareholder
and her shares is an aggregation
• relationship that does not require physical containment.
34. Aggregation
• There are clear trade-offs between links and aggregation.
Aggregation is sometimes better because it encapsulates
parts as secrets of the whole.
• Links are sometimes better because they permit looser
coupling among objects.
• Intelligent engineering decisions require careful weighing
of these two factors.
• By implication, an object that is an attribute of another
has a link to its aggregate. Across this link, the aggregate
may send messages to its parts.
35. Cardinality/ Multiplicity
• No of participants in a relationships is shown by its
cardinality value
• The Multiplicity of an association indicates with how many
objects the opposing class of an object can be
instantiated.
• When this number is variable, then the bandwidth - or
minimum and maximum - is indicated 3..7 .
• If the minimum is 0, this means that the relationship is
optional (the relationship is still there, only the number of
elements is 0).
• If the minimum is equal to the maximum, only one value is
written.
36. Association – example
• In a home theatre system,
– A TV object has an association with a
VCR object
• It may receive a signal from the VCR
– VCR may be associated with remote
• It may receive a signal (command) to
record
VCR TV
1
Connected to
1
Remote
1
commands
1
39. left right example
1 1 one-to-one person <-> weight
0..1 1
optional on one
side one-to-one
date of death <->
person
0..* or * 0..* or *
optional on both
sides many-to-
many
person <-> book
1 1..* one-to-many
Birth Place <->
person
one (1): Indicates that exactly one entity type instance exists at the
association end.
zero or one (0..1): Indicates that zero or one entity type instances exist
at the association end.
many (*): Indicates that zero, one, or more entity type instances exist at
the association end.
40. • A teacher teaches 1 to 3 courses
(subjects)
• Each course is taught by only one teacher.
• A student can take between 1 to 5 courses.
• A course can have 10 to 300 students.
Association – Multiplicity
Teacher Course
teaches 1..31
Students
takes
1..5
10..300
41. Try them
• 1. These relationships are read in the following way:
– An event has a seating plan.
– A seating plan is allocated to a venue.
• 2. A seating plan has unlimited capacity, but usually only
one seat.
• A seat belongs to one specific seating plan.
• Every seating plan belongs to one specific event.
• An event may contain an unlimited number of seating plans.
• The seating plan can also be assigned to another event
(Aggregation), but must in any case always have one event.
• The seat is part of a seating plan; this relationship can
never be changed (Composition).
46. Class
• A class is a set of objects that share a common structure
and a common behaviour.
• A single object is simply an instance of a class.
47. What isn't a class?
• An object is not a class, although, curiously
• class may be an object. Objects that share no common
structure and behaviour cannot be grouped in a class
because, by definition, they are unrelated except by their
general nature as objects.
48. Template for object creation:
Instantiated into objects
An abstract data type (ADT)
Examples: Employees, Books, etc.
Sometimes not intended to produce
instances:
Abstract classes
Class
49. UML Class Representation
• A class represents a set of objects having similar
attributes, operations, relationships and behavior.
Window
size: Size
visibility: boolean
display()
hide()
Class Name
Inline Attributes
Operations
A class can
implicitly
have a few
association
attributes
51. Terms and Concepts
• A class is a description of a set of objects that share
the same attributes, operations, relationships, and
semantics.
• Graphically, a class is rendered as a rectangle.
52. Class: Name
• Every class must have a name that distinguishes it from
other classes.
• A name is a textual string.
• That name alone is known as a simple name; a path name is
the class name prefixed by the name of the package in
which that class lives.
• A class may be drawn showing only its name
53. Class: Name
• A class name may be text consisting of any number of
letters, numbers, and certain punctuation marks (except
for marks such as the colon, which is used to separate a
class name and the name of its enclosing package)
• Typically, you capitalize the first letter of every word in a
class name, as in Customer or TemperatureSensor.
54. Attribute
• Attributes are related to the semantics of aggregation.
• An attribute is a named property of a class that describes
a range of values that instances of the property may hold.
A class may have any number of attributes or no attributes
at all.
• An attribute represents some property of the thing you
are modeling that is shared by all objects of that class.
• An attribute is therefore an abstraction of the kind of
data or state an object of the class might encompass.
• At a given moment, an object of a class will have specific
values for every one of its class's attributes.
• Graphically, attributes are listed in a compartment just
below the class name.
55. • An attribute name may be text, just like a class
name. In practice, an attribute name is
• a short noun or noun phrase that represents some
property of its enclosing class.
• Typically, you capitalize the first letter of every
word in an attribute name except the
• first letter, as in name or loadBearing.
56.
57. Operation
• An operation is the implementation of a service that can
be requested from any object of the class to affect
behavior.
• A class may have any number of operations or no
operations at all.
• Often (but not always), invoking an operation on an
object changes the object's data or state.
• Graphically, operations are listed in a compartment just
below the class attributes.
• Operations may be drawn showing only their names,
58.
59. Operation
• You can specify an operation by stating its signature,
covering the name, type, and default value of all
parameters and (in the case of functions) a return type,
60. Responsibility
• Responsibility is a contract or an obligation of a class.
When you create a class,
• At a more abstract level, these corresponding attributes
and operations are just the features by which the class's
responsibilities are carried out.
• Graphically, responsibilities can be drawn in a separate
compartment at the bottom of the class icon
62. Other Features
• Sometimes, however, you'll need to visualize or specify
other features, such as the visibility of individual
attributes and operations;
• language-specific features of an operation,
• such as whether it is polymorphic or constant; or even the
exceptions that objects of the class might produce or
handle.
• These and many other features can be expressed in the
UML, but they are treated as advanced concepts
63. Modeling Techniques
• Modeling vocabulary of system
• Modeling the Distribution of Responsibilities in a System
• Modeling Non-software Things
• Modeling Primitive Types
64. Hints and Tips
• When you model classes in the UML, remember that
every class should map to some tangible or conceptual
abstraction in the domain of the end user or the
implementer.
• A well-structured class Provides a crisp abstraction of
something drawn from the vocabulary of the problem
domain or the solution domain.
• Embodies a small, well-defined set of responsibilities and
carries them all out very well.
65. Hints and Tips
• Provides a clear separation of the abstraction's
specification and its implementation.
• Is understandable and simple yet extensible and
adaptable.
• Show only those properties of the class that are
important to understanding the abstraction in its
context.
• Organize long lists of attributes and operations
by grouping them according to their category.
• Show related classes in the same class diagrams.
66. Relationships
• Relationships provide a pathway for communication
between objects
• Sequence and/or collaboration diagrams are
examined to determine what links between objects
need to exist to accomplish the behavior -- if two
objects need to “talk” there must be a link between
them
68. Relationships: Defined
• An association is a bi-directional connection between
classes
– An association is shown as a line connecting the related classes
• An aggregation is a stronger form of relationship where the
relationship is between a whole and its parts
– An aggregation is shown as a line connecting the related classes with a diamond next
to the class representing the whole
• A dependency relationship is a weaker form of relationship
showing a relationship between a client and a supplier where
the client does not have semantic knowledge of the supplier.
– A dependency is shown as a dashed line pointing from the client to the supplier
69. Generalization
(Inheritance)
• A generalization is a relationship between a more
general and a more specific element
– Inheritance is the main property of generalization-
specialization relationships defined between a superclass
and its subclasses
– Common attributes, operations, and/or relationships are
shown at the highest applicable level in the hierarchy
• Realization is a relationship defined between a type
and its implementation classes
70. Relationships: Notation• Association
• Dependency
• Aggregation
• Generalization
• Realization
type Implementation
class
Sub
clas
s
Superclass
AggregatePart
SupplierClient name
