Object Oriented Modelling

Class & Object Models

Analysis V. Design

• There is no significant distinction between the techniques used during Analysis and those used during Design. The techniques are equally valid during both stages. The principle difference is the level of objects you model with.

• The term “Object Modelling” is sometimes used instead of “Object Analysis” and Object Design”.

Analysis (logical model)

• Object-Oriented Analysis (OOA) aims to model the problem domain, the problem we want to solve by developing an OO system.

• Analysis level objects– Customers, accounts, suppliers, accidents,

invoices– Protocols, motors, sensors, engines, traffic

Design (Physical Model)

• Object-Oriented Design (OOD) is an activity where we are looking for logical solutions to solve a problem.

• Design level objects– User interface (dialogue and presentation

objects)– Objects to manage relationships,

concurrency,– referential integrity, transactions, etc...

Unified Modelling Language (UML)

• UML is a non-proprietary specification language for object modeling.

• UML is a general-purpose modeling language that includes a standardized graphical notation used to create an abstract model of a system, referred to as a UML model.

• UML is not a method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time .– Most well known method using UML is Rational Unified Process

(RUP).

UML Model Types

Static/Structural behaviour– Functional Model

• Showcases the functionality of the system from the user's Point of View. • Includes Use case diagrams.

– Object Model• Showcases the structure and substructure of the system using objects,

attributes, operations, and associations. • Includes Class Diagrams.

Dynamic Behaviour– Dynamic Model

• Showcases the internal behavior of the system. • Includes Sequence Diagrams, Activity Diagrams and State Machine

Diagrams.

There are three prominent parts of a system's model covering two aspects of system behaviour:

UML Views

• Use-Case View: User perception of functionality in domain or system.

• Logical View: Internal representation showing both static structure and time-dependent dynamic behaviour.

• Component View: Showing how a complete system is composed of discrete units.

• Concurrency View: Division of system into separate execution threads - shows communication.

• Deployment View: Represents physical deployment of the various parts (components) of the overall system.

Views provide high level representations of a domain or system. There are several:

UML Models

• Structure Diagrams emphasize what things must be in the system being modeled:

– Class diagram – Component diagram– Composite structure diagram– Deployment diagram – Object diagram – Package diagram

• Behavior Diagrams emphasize what must happen in the system being modeled:

– Activity diagram – State Machine diagram – Use case diagram

• Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

– Collaboration / Communication diagram – Interaction overview diagram– Sequence diagram – UML Timing Diagram

Class Diagram

A class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. (wikipedia)

Class Diagram

• A class is represented by a box – the name of the class in box.– a compartment below the class name can show

the class's attributes (i.e. its properties).• Data• Behaviour (methods).

Bank Account

Account NameAccount NumberAccount Balance

Deposit_MoneyWithdraw_MoneyClose Account

Classes and Objects

Classname

Class Name

Data Attributes

Methods/functions/behaviour

OR

Objectname:Classname

Objectname:Classname

Data Attributes

Methods/functions/behaviour

OR

A class is a specification that an object implements

Identifying Classes

A useful link:http://www.agilemodeling.com/artifacts/classDiagram.htm

Identifying Classes

Natural language - Origins from Abbott 1983

CRC Cards - Beck 1989 - Wirfs-Brock 1990

Natural Language

• Nouns may indicate candidate classes– Some nouns are actually sub-assemblies or aggregates of classes.– Some nouns suggest merely attributes of a class

• When sufficient significance can be assigned to an attribute it may be promoted to a full class.

• Verb phrases suggest class associations or operations– Often operations are tied to relationships

• Adjectives suggest attributes of a class

• Proper nouns suggest objects of a class type– Try not to have too many classes for which there is only ever one

instance created.

Original concept from Abbott 1983

Critique of Natural LanguageAnalysis

• Needs a full and accurate statement of the requirements– Often the lack of clearly defined requirements is the reason why

an OO approach may be being used.

• Nouns and Verbs tend only to help identify tangible things.– Much of design requires thinking about less tangible concepts -

abstractions – Therefore natural language may contribute little to the design

process.– Nevertheless, useful starting point for some analysis work.

see Goldberg and Rubin 1995

Natural Language - Example

• A manager is responsible for a department and must review the staff in that department each year. The manager is also responsible for ordering new equipment (such as PCs) and furniture (such as desks and chairs) as required.

• From time to time John (one of the managers) must also recruit additional staff. This involves placing advertisements and keeping track of all applicants up to the closing date. A short-list of suitable candidates for interview is then composed .

Natural Language Example

PCs

DesksStaff

Department

Equipment

Advertisement

Manager

Candidateresponds

reviews Shortlist

orders

places

Examine theModel and

think about whateach of the

Symbols mean

CRC Cards

• Brainstorming tool used to design OO software.• Used when first determining required classes

and how they interact.

• CRC cards are usually created from index cards on which are written:– The class name. – The responsibilities of the class. – The names of other classes that the class will

collaborate with to fulfill its responsibilities.

CRC Cards

Class Name: MANAGER

Responsibilities

Collaborators

Beck & Cunningham 1989

Departmental reviewsStaff salary reviewsOrdering EquipmentStaff recruitment

DepartmentEmployeeApplicant

Class, Responsibility and Collaboration

CRC Cards

Write Class name on a 4” x 6” index card

Write Responsibilities on card Responsibilities identify the problems which the class

must solve. Group responsibilities into contracts.

Identify Collaborator classes on the card Collaborator classes are classes which send messages to,

or receive messages from, the class in question. DIscard classes without collaborations.

Beck & Cunningham 1989

Class Description

End up with a class description, either in textual prose or some more structured form. For example using a company Manager:

Manager - A company employee and departmental controller. A manager is responsible for one or more employees. A manager can: Review staff salaries, order equipment and recruit staff. These activities may all be part of periodic departmental reviews.

Structured Description

Class name: MANAGER

Description: Details of a company MANAGER - a person

Superclass: PERSON

Name: Grade

Description: Details of salary grading

Type: Integer (range 1-5)

Cardinality: One

Name: Manages

Description: Details of employees managed

Type: Employee

Cardinality: Many

Structured Description

• Public methods:

• Name: Review Department• Parameters: New Budget• Description: Used to carry out periodic reviews.

• Private methods:

• Name: Recruit Staff• Parameters: Number of staff, type of staff• Description: Initiated by a Manager as a consequence of various

factors and as a result of a request to Review Department.

Object Relationships

Most OOA&D methods (including UML) model

3 basic kinds of relationship:

Association Aggregation (part_of) Inheritance (is_a)

Object and Class Associations

Links and Associations

Link - A physical or conceptual connection between two objects (instances)

Association - A group of links with a common structure. Associations occur between classes of objects.

Links represent object interactions (dynamic considerations)while associations depict static, structural issues.

Links and Associations

Lecturer Coursetakes

An Association

George:Lecturer

takesM.Sc: Course

A Link

Classdiagram

Object diagramlecture

examine

Participation or Cardinality

While participation is shown on class diagramsit relates to the number of instances of one class that are associated with an instance of theother class.

Class 1 Class 2association name

Class

Class

Class

Class

Class

Exactly one

Many (zero or more)

Optional (zero or one)

One or more

Numerically specified

1..*

2

0..1

0..*

1

role role

Example 1

Lecturer CourseTakes

Joe Bloggs:Lecturer

B.Sc:Course

M.Sc:Course

lecture

examine

0..*1..*

Is taken by

Association Constraints

• You can document any constraints on the association. For example, a person may only drive a car if they have a valid licence:

Person Cardrives 0..*0..*

{person.licence_status = valid)

Handling Link Attributes via an Association Class

• A class may be attached to an association rather than directly to another class. Such a class is called an Association Class. It can have data attributes and behaviour just like any other class

• Used to hold information on each occurrence of a relationship

Supplier PartSupplies

Date

Contract

Instances of the Association Class

B&Q

Texas

Budget

aHammer

aSaw21/12/92

14/2/93

27/4/91

12/5/93

5/9/93

Associations

• There can be more than one association between the same two classes– Person hires car– Person owns car– Person drives car

• Suggests 3 distinct relationships between a Person and a Car– May have different cardinalities

• Person hires many Cars• A Car may be hired by many Persons (Over Time)

Example 2

Person Car

hires

owns1 0..*

0..*0..*

Time Dimension

• Time presents an interesting dimension when applied to associations.

• It often transforms a one:one into a one:many or a many:many.– For example, a Car can only be hired by one person at

a time (Rule). But it may be hired by many people over a period of time.

– The Rules must be identified by the analyst, so the designer can create the appropriate association participation.

Time Dimension

• If an Information System is required to track only details of who currently has a vehicle on hire, then the Car can be modelled in a One:One association with a Person.

• However, if the system must provide a historical log of all customers who hired a particular Car then a Many:Many association will be required.

Time Dimension

• A Person may Drive a Car for much shorter periods of time. Is a record of all driving periods required?

– Perhaps for a haulage firm with a legal requirement to maintain a driving log for each Driver.

– In another situation it may only be necessary to record information about who is currently driving a particular Car.

Aggregation

Aggregation is the “part-whole” relationship.

It relates classes, representing parts (or

components) to the whole (or assembly)

class.

Aggregation

A tightly coupled form of association with someextra semantics, namely transitivity (if A is apart of B and B is a part of C then A is a part ofC).

Properties of the assembly may propagate tothe components. For example, the speed andlocation of a door is obtained from a fuselagewhich in turn obtains them from a Plane.

Rumbaugh 1991

UML Aggregation

• In UML there are three types of aggregation:

– Normal Aggregation

– Shared Aggregation

– Composition aggregation

Aggregation

Aggregation is most useful when there are common properties of components that can be attached to the assembly as a whole

Or where operations can propagate from container to contained objects

Parts explosions are the most compelling examples of aggregation

Keywords to identify aggregates are: “consists of”, “contains”, or “is part of”.

Represented by as line with a hollow diamond attached to the ‘wholeside’ end of the line.

If in doubt, use ordinary association!

Aggregation

Navy WarshipContains

0..*

Normal Aggregation - Discussion

University

Faculty

School Lecturerworks for

Class diagram

Course

takes

*

*

1 1..*

1..*

1..*

Composition Aggregation

• The ‘whole’ owns the instances of the parts. Those instances cannot belong to any other instance of the whole.

• Composition Aggregation forms a tree structure.

• The lifetime of the whole dictates the lifetime of the constituent parts.

Composition Aggregation Example

Aircraft

Engine Wing Fuselage

Door Landing Gear

2+

21+

Alternative Notation

Aircraft

Engine

Wing

Fuselage

1+

2

Door2+

LandingGear

Shared Aggregation in UML

• With ‘Shared Aggregation’ the parts can be associated with many wholes - for example several instances of a collection class may act as collectors for a given class. To use the example of staff recruitment, a candidate may be associated with an ‘applicants’ whole and at the same time be part of a ‘short-listed’ whole and eventually an ‘offer-made’ whole. Each of these wholes is acting as a collection class for ‘applicants’.

List

Applicant

*

*‘Shared’ aggregation if mutiplicity > 1.

Open diamond symbol for both sharded and ‘normal’ aggregation

Shared Aggregation in UML

• Lifetime of parts is not constrained by the lifetime of the container:

– Parts can exist independently from the whole.

– Much closer to the idea of a 1-many association.

• Shared aggregates form a network of parts rather than a tree structure.

Association represents the ability of one instance to send a message to another instance. This is typically implemented with a pointer or reference instance variable, although it might also be implemented as a method argument, or the creation of a local variable.

In object-oriented analysis and design,  an association represents a certain relationship between objects, but all objects have their own lifecycle and there is no ownership among the objects. For example, multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership among the objects and all have their own lifecycle.

• Aggregation and composition both are specialized form of association. Composition is again specialize form of aggregation.

• An aggregation represents a whole that comprises various parts; so, a Committee is an aggregate of its Members. At implementation time, this relationship is not containment. (A meeting does not contain a room.)

• Similarly, the parts of the aggregate might be doing other things elsewhere in the program, so they might be referenced by several objects. In other words, There's no implementation-level difference between aggregation and a simple "uses" relationship (an "association" line with no diamonds on it at all). In both cases an object has references to other objects.

• Though there's no implementation difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the domain model better, and because there are subtle implementation issues. I might allow tighter coupling relationships in an aggregation than I would with a simple "uses," for example.

• Aggregation is the typical whole/part relationship. Same as an association with the exception that instances cannot have cyclic aggregation relationships (i.e. a part cannot contain its whole).

A whole cannot be its own part

ListA List cannot be part of its own list

PersonChild

Parent

• Composition [...] is exactly like Aggregation except that the lifetime of the 'part' is controlled by the 'whole'.

• Composition involves even tighter coupling than aggregation, and definitely involves containment. The basic requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the "elements"), then the elements will come into existence and also be destroyed as a side effect of creating or destroying the container. It would be rare for an element not to be declared as private.

• Aggregation should be used only in cases where there is a compositional relationship between classes, where one class is composed of other classes, where the "parts" are incomplete outside the context of the whole. Consider the case of an Order: it makes no sense to have an order which is "empty" and consists of "nothing". The same is true for all aggregates: Departments must have Employees, Families must have Family Members, and so on.

• If the classes can have independent identity outside the context provided by other classes, if they are not parts of some greater whole, then the association relationship should be used. In addition, when in doubt, an association is more appropriate; aggregations are generally obvious, and choosing aggregation is only done to help clarify. It is not something that is crucial to the success of the modeling effort.

Inheritance

Sometimes called the “is_a” relationship

Provides a way of sharing attributes and methods between subclasses (or child classes) and their superclasses (or parents)

Subclasses can share similarities with common superclasses while preserving their differences

Default types of attributes and logic of methods can be overridden in the subclasses

Inheritance – Abstract & Concrete classes

An abstract class is designed to be a parent class that can not be instantiated.

– Often represents abstract concepts or entities.– Usually has one or more abstract methods

that only have a signature and no implementation.

– Only used to inherit from.

Inheritance – Abstract & Concrete classes

It is possible to instantiate a concrete class (i.e. possible to create object from).

– must provide implementation for all methods.

+drive {abstract}()

Vehicle{abstract}

+drive()

Car

+drive()

Boat

Inheritance Example

Build an inheritance hierarchy using the

following items identified from OO Analysis.

•Student•Qualifications•Salary•Lecturer•Name•Secretary•Lecture

Inheritance sample solution

Employee

•Student•Qualifications•Salary•Lecturer•Name•Secretary•Lecture

Lecturer Secretary

Person

Student

Salary

Name

Lecture

Where does Qualifications

go?

Multiple Inheritance example

Sales Person Manager

Director

Sales Manager

Class hierarchies

Generalisation

Specialisation

Class roles and Inheritance

In a previous slide we looked at class roles:

Lecturer Coursetakes

Admin

1..*

Here, the Person plays the role of a Course Tutor.Often such roles are modelled through inheritance:

Lecturer

Course Tutor

Using Class Hierarchies

Generic class hierarchy

copy

Generic class

Application specific class

Using via sub-classing

Instantiation of a generic class

messages

Using via delegation

Instantiation of an application specific class

Don’t confuse Inheritance and Aggregation!

Plane

Engine Fuselage Wing

* Not intuitive, therefore confusing to someone else. (A Plane is not a kind of Wing...)

Associations and Inheritance

Plane

Commercial PrivateOwns

Crew Member

Pilot

Licence

Licence

is_operated_by

1 1..* 1 0..1

1 0..1

Aggregation versus Inheritance

Aggregation is not the same thing as inheritance

Aggregation relates to Instances

Inheritance relates to Classes

Aggregation and Inheritance

Plane Engine

Fuselage

Wing

Commercial Private Military

1

1+

2

Candidate Classes for a Library

It is important to be aware of the relative stability of the various classes used in yourobject model. Not all classes will exhibit the same potential stability with respect to futurerequired changes.

Component classes are likely to be more stable than container classes

Subclasses representing roles will be less stable than the more fundamental superclass

Fundamental Classes

• Scroll Bars

• Menus

• Cursors

• Lists

Suitable material for inclusion in generic, re-usable class libraries

Composite Classes

• User interface window

MenuIcon

Window

ScrollBarCursor . . . .

Managing the bigger picture

• UML employs the notion of a Package as a mechanism for grouping related model elements. For example, groups of collaborating classes could be called a package. An overall system can then be composed from a number of packages.

A

UML Notation for a Package

UML Component Diagram

• An overall system may consist of a number of physical ‘components’ for example, where various classes are implemented in different code components. The notation is shown below:

Component Name

GUI

User

Room

Booking

UML Deployment Diagram

• Different code components can be distributed amongst a number of processors or nodes in a network. The deployment diagram enables the designer to illustrate this distributed nature:

Deployment diagram for a Room Booking System

GUI: ClientA

Booking:BuildingDiary

User:UserBase<<TCP/IP>>

<<TCP/IP>>

Developing Static Models

Identify the main Use-cases and write down descriptions of these Identify the main elements of information which must be stored. Identify the main actors with which the system must interact. Identify objects and classes Identify associations between classes

– Creating object model segments for each Use-case. Identify attributes for classes Merge the object model segments to create an overall object model

for the system Organise and simplify classes using inheritance Test the object model and it’s relationships by performing walk-

throughs using, for example, UML Sequence diagrams (Dynamic Modelling)

Iterate and refine the models

Class Model Summary

The Class Model is used to identify classes and their inter-relationships. It provides a static, structural view of a system without any

consideration of time sequencing or object

interactions.