Object ModelingObject Modeling

Preeti MishraCourse Instructor

An overview of OOSE development activities and their products

Requirementselicitation

Analysis

System design

problem statement

functionalmodel

nonfunctionalrequirements

analysis object model dynamic

model

class diagram

use case diagram

statechart diagram

sequence diagram

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.

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.

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.

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

System concepts for Object Modeling

• Objet Oriented Concepts: – Abstraction – Encapsulation– Inheritance– Modularity– Polymorphism

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.

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 attributes3. Find the methods4. 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

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.

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.

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

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.

Relationships Among objects

Relationships Among objects

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

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)

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.

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

Techniques For Implementing A Uses/ Links/ Association

Relationship

Object 1 uses object 21. Object 2 as Arguments2. Creating Your Own objects 23. Third Party object 24. Combining Constructors5. Passing an Argument6. Creating Objects On-The-Fly

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.

Creating Your Own objects

• A second solution is to construct the object2 in the object1 class constructor.

Third Party object

• It assumes that a repository of Customers (CustomerDB) keeps track of all Customer objects

Combining Constructors

• Give the object1 class two constructors and use a no-argument constructor when you want to create a new object1.

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

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.

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

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

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 areinterchangeable

– 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

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 thatcan 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.

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.

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.

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.

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.

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.

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 TV1Connected to

1Remote 1 commands

1

Rakesh Shukla

V. Ramesh

760901-1234

691205-5678

People Tax_files

tax_file

1-1 Association – example

People Tax_files1 1Associated with

Kunti

Bhim

Arjun

Women People

motherOf

Multiple Association – example

motherOf

Yudhistir

motherOf

Women People1 *Mother of

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.

• 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 Courseteaches 1..31

Students takes

1..5

10..300

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).

Multiplicity in Aggregation

Combining them

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.

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.

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

UML Class Representation

• A class represents a set of objects having similar attributes, operations, relationships and behavior.

Windowsize: Sizevisibility: boolean

display()hide()

Class Name

Inline Attributes

Operations

A class can implicitly have a few association attributes

Class ModelingClass Modeling

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.

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

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 aclass 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.

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.

• 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.

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,

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,

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

Class Diagram• Captures the vocabulary of a system

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

Modeling Techniques

• Modeling vocabulary of system• Modeling the Distribution of Responsibilities in a

System• Modeling Non-software Things• Modeling Primitive Types

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 problemdomain or the solution domain.

• Embodies a small, well-defined set of responsibilities and carries them all out very well.

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.

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

Basic Relationship Types

• Association• Dependency• Aggregation• Generalization• Realization

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

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

Relationships: Notation• Association

• Dependency

• Aggregation

• Generalization

• Realizationtype Implementation

class

Subclass

Superclass

AggregatePart

SupplierClient name