UNIVERSITY OFSOUTH ASIA

Lecture 8:

By: Md Rezaul Huda Rezacreativereza@yahoo.com

CSE- 629SOFTWARE QUALITY ASSURANCE(SQA)

CLASSES AND OBJECTS Basis for all OO analysis approaches

The fundamental modelling element

Must understand the difference between classes and objects

Things (OBJECTS) and the generality of things(CLASSES)

REMEMBER… WHAT IS AN OBJECT? Object: a “thing” that is capable of being seen,

touched or sensed and about which users store data and associate behaviour.

BUT WHAT IS A THING? Types of objects may include a person, place, tangible

things or event:

Person objects: student, customer, inspector

Place objects: warehouse, building, room

Things objects: product, vehicle, equipment

Event objects: Order, payment, invoice, reservation, registration, application, contract

These things exist within the system’s environment, and equally within the system.

REMEMBER…AN OBJECT CLASS? An object CLASS is the set of things (objects)

which are of the same type e.g. a set of dogs, a set of cars, a set of orders. THUS of similar properties (attributes), behaviour (operations), relationships and meaning

An object can then be viewed as an INSTANCE of a particular class.

Each class contains attributes that describe its operations (also referred to as methods) that define the behaviour of that class (or the object derive from it).

An operation in an object can be initiated by passing a message to the object.

BASIC OBJECT MODELLING

Class

Dog

Name

AttributesOperations

NameBreed

RunFetch

RoverColleyPatchSebastianDuskConker

Dog

NameBreed

RunFetch

The concept of dog The concept and some dogs

Operations

Attributes

ATTRIBUTES AND OPERATIONS Attributes - data values that all members of the class will

have. Each attribute name may be followed by optional details such as type and default value.

Operations - what objects of the class can do.

What objects of the class will respond to.

Also known as methods or services.

Most common operations in any class are Get (View/Display), Set(Add), Edit, Delete!

Example: Class Door

Attributes: Woodtype, Colour

Operations: Open, Shut, Lock, Unlock

All these behaviours (a door can open, or can lock etc.) are associated with the class door and are accomplished by the door and no other object!!

Important when you are drawing your classes. Methods relevant only to that particular class. NOT AN ERD!

Staff

Staff_name: StringStaff_no: Integer

CLASS AND OBJECT

Book

title: String

author: String

price: float

isbn: String

publisher: String

Get_quantity()

Add_bookDetails()

Edit_bookDetails()

Deletebook()

myBook: Book

title = “Software Engineering”

author = “Pressman

price = 40.00

Isbn = “2-5345-53455-6”

Publisher = “McGraw and Hill”

Get_quantity()

Add_bookDetails()

Edit_bookDetails()

Deletebook()

Instance of a Book

REMEMBER…PRINCIPLES FOR BUILDING OBJECT MODELS Identity - an object knows who it is

Classification - an object knows the class it belongs to

Knows of other objects (to interact with)

Does things (it has a specific behaviour)

To define, ask: “What do I need to know to perform my role?” “Whom do I need to know to perform my role?” “What do I need to do in order to be able to

perform my role?”

REMEMBER…OBJECT-ORIENTED CONCEPTS Abstraction: capture key aspects, ignore irrelevant

detail Information Hiding: a class should hide details of

how they are internally implemented as computer code from other classes.

Encapsulation: combining both attributes and data in a class and hide the non relevant detail at a given scale. Objects are used as building blocks which can be put together to make the system. Main visibility types for attributes and methods public, private. Encapsulation allows for a more robust model, easier to reuse and easier to maintain

Example: Object is like an Egg

With encapsulation and information hiding, the overhead during maintenance is reduced as you are certain that when you are fixing a problem inside a class, only that particular class’s code is affected.

Association: explain events by linking different objects

Yolk

White

Shell

REMEMBER…OBJECT-ORIENTED CONCEPTS (CONT..) Inheritance: generic descriptions of object classes. An object

from a more specific class may inherit the attributes and methods from a more generic class.

Polymorphism – general characteristics of a class can be inherited but overridden if need be. Allowing operations of different object classes to have the same name, whilst the details of the actual operation carried out may be different.

Inheritance and polymorphism may improve reuse. This reduces design, programming and validation costs.

Class: Person (Super type)NameBirth dateGender

Walk()Jump()Talk()Sleep()

Class: Student (Sub type)

GPAClassification

Enroll()DisplayGPA()

Class: Teacher (Sub type)

Rank

Lecture ()

MODELLING A SYSTEM WITH OBJECTS: CONCEPTUAL CLASS DIAGRAM Depict the system’s static structure. To go beyond this

static view we need to develop other formalisms such as the object sequence diagram (OSD) in the next lecture.

Show classes that the system is composed with their attributes, and operations that may be performed upon an object of the class of as well as the relationships between those classes.

Use the classes to build a 'map' or model of the problem domain. What are the classes/objects (things) involved in this

system? How are they (classes) associated? What do they (classes) do? What data do they (classes) hold?Later in development, a shift to a design or an implementation class model

ANALYSIS CLASS STEREOTYPES

Boundary (or interface) classes Model interaction between the system and its actors They are abstract For things that actors directly interact with - for

example a user interface or a data input screen. Their main task is to manage the transfer of

information across system boundaries At the analysis stage we don’t know how the interface

will look like or behave. These are all design decisions (design class diagram)

<<boundary>>User interface: Add

advertUI

Start_interface()createNewAdvert()selectClient()SelectCampaign()

ANALYSIS CLASS STEREOTYPES

Control classes Represent the control of the internal logic of the

system for a use case. Represent coordination, sequencing, transactions and

control of other objects Represent the calculation and scheduling aspects of

the logic of their use cases – those parts are not specific to the behaviour of a particular class, but are specific to the use case.

<<control>>Control: Add advert

Show_client campaign()createNewAdvert()showCampaignAdverts()

ANALYSIS CLASS STEREOTYPES

Entity or Business classes Model information and associated behaviour of some

phenomenon or concept such as an individual, a real- life object or a real-life event.

For relevant things in the domain of the system (e.g. students, books, publishers, reviewers)

These are the main type of classes found in a conceptual class diagram

<<entity>>Student

NameEmailBirth Date

Add_student()Delete_student()Edit_details()

IDENTIFYING CLASSES Classes - various kinds of things within the

problem scenario.

External things (e.g. another system that produces or consumes information to be used by the system to be developedThings (e.g. reports) that are part of the information domain for the problemOccurrences or events (e.g. property transfer) that are part of the information domain for the problem.Roles (e.g. managers,students) played by people who interact with the systemOrganisational units (e.g. working teams) that are relevant to the system under developmentPlaces(e.g. a manufacturing floor) that establish the context of the problem and the overall function of the systemStructures (e.g. four-wheeled vehicles) that define a classUser interfaces such as buttons, sliders, pages.

IDENTIFYING CLASSES (CONT…)

From the application domain – use case diagrams From the requirements From observation, from thought From role playing and CRC cards

Look for: Nouns = classes; Adjectives = Attributes; Verbs = Operations

IDENTIFYING CLASSES (CONT…)

From use case diagrams: Use cases are the best place to look for entity

classes/objects. Think about interactions between objects that support the

use case. Draw upon the use case diagram and use case

scenario descriptions in order to find a set of classes that can interact to realise the use case.

Review each use case to find “nouns” that correspond to business events. Nouns correspond to classes, Verbs offer clues about the operations/methods.

E.g. Place new member order Nouns: member, order Verbs: place_order()

Place new

member order

GUIDELINES TO HELP YOU PRUNE OUT UNSUITABLE CANDIDATE CLASSES1)Is it beyond the scope of the system? people, things

or concepts that are not strictly necessary to describe the application domain investigated

2) Does it refer to the system as a whole? it is not necessary for a model to contain a class that represents the entire system (include only items that refer to the system you are modeling)

3)Does it duplicate another class? remove synonyms

4)Is it too vague? remove potential classes for which you are unable to write a clear description

5)Is it too specific? model classes rather than instances e.g. a company may have only one supplier tempting you to model only that supplier. But a supplier may be replaced tomorrow A class name supplier would be unaffected by this, whereas one modeled too closely on the specific company might require modification

GUIDELINES TO HELP YOU PRUNE OUT UNSUITABLE CANDIDATE CLASSES1)Is it really an attribute? An attribute is a characteristic of

a class. Sometimes confusing because e.g. an item is an attribute in one domain but may be a class in another, depending on the requirements.

2) Is it really an operation? An operation is an action, a responsibility of a class. This can be confusing as some actions may be better modeled as classes.

3) Is it really an association? Again confusing as some relationships might be classes.

In general, If an attribute, operation or association is something that we need to describe in terms of further characteristics – if it is apparent that is has attributes of its own – then it should be modeled as a class.

RELATIONSHIPS BETWEEN CLASSES – ASSOCIATIONS (1) How classes are related to each other

The determination of associations is somewhat related to the creation of ERDs --- BUT REMEMBER, objects are active things which interact –-- not just passive data stores like entities in ERDs.

To identify look the textual description of the problem domain (or the use case scenario descriptions) and identify any verbs that might describe relevant relationships between classes.

Associations may represent (Pressman 2000):

Physical location (e.g. next to, part of)

Some communication (e.g. transmits to)

Ownership (e.g. has)

Satisfaction of a condition (e.g. manages, taught by)

RELATIONSHIPS BETWEEN CLASSES – ASSOCIATIONS (2)

Within UML, associations are represented graphically by linking classes with labelled relationships lines as with ERDs.

Each end of a link can be labelled with the cardinality (MULTIPLICITY) of the association (e.g. an association can be one-to-one relationship, a one-to-many relationship, or a many-to-many relationship – good practice to break many-to-many down).

Examples: A teacher might teach many courses although a course can

only be taught by one teacher. Students can attend many courses and a particular course

can be attended by many students.

MULTIPLICITY INDICATORS

Indicator Meaning

0..1 Zero or one

1 One only

0..* Zero or more

1..* One or more

n Only n (where n > 1)

7..9 Specific range1

0…*

places

Order

Customer

Belongs

RELATIONSHIPS BETWEEN CLASSES – AGGREGATION Aggregation (WHOLE/PART) A particular class might consists of a number of components

that represent classes in themselves. ‘has-a’ relationship

an object contains the other object, The contained object may exist by itself.

E.g. A house might consist of a number of rooms E.g. A book might consist of a number of chapters E.g. An order might consist of a number of orderlines.Within UML, aggregations are represented as a line with a diamond at the aggregate end.

Aggregation DOES NOT imply inheritance, in that object B does not inherit behaviour or attributes from object A.

Aggregation relationships propagate behaviour in that behaviour applied to the whole is automatically applied to the parts. For example if I want to send object A to a customer, then object B will be sent also.

RELATIONSHIPS BETWEEN CLASSES – COMPOSITION Composition A stronger form of aggregation where the whole and parts

have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts.

Restricted ‘has-a’ relationship an object contains the other object, the contained object cannot exist without the existence of

container object If the first class is destroyed, normally every instance that it

contains is destroyed as wellWithin UML, aggregations are represented as a line with a SOLID diamond at the aggregate end.

AGGREGATION/ COMPOSITION EXAMPLE

OrderlinePlayer

0…*

0…*

OrderTeam

1

1…*

RELATIONSHIPS BETWEEN CLASSES - GENERALISATION Generalization/Specialization: Represents the idea of inheritance. The super-class is general and contains the common

attributes and behaviours of the hierarchy. The sub-classes are specialized in that they contain

attributes and behaviours unique to the object/class, but they inherit the super-class’ attributes and behaviours also.

Within UML this relationship is represented as an arrow between each sub-class and the super-class.

EXAMPLES: Employee might be a generalisation of the sub-classes

teacher and secretary Product might be a generalisation of the sub-classes Food

and clothing.

GENERALISATION EXAMPLE

Employee

Programmer

projectprogLanguages

Manager

ProjectManager

budgetsControlled

dateAppointed

projects

Dept.Manager

StrategicManager

dept responsibilities

CustomerOrder

Order line

Cash CustomerCredit Customer

Product

1..*

1

1*

1*

A kind ofA kind of

CLASS DIAGRAM EXAMPLE (1)

COUPLING AND COHESION Coupling: is a measure of the strength of the connection

between different modules within the system and it is desirable to maintain a low level coupling.

In OO, coupling refers to the amount of interaction between objects and it is thus a qualitative measure of how many links there are in a class diagram between the classes.

Cohesion: is a measure of the strength of the internal connectivity of an individual module. It is desirable to maintain a high level of cohesion within a module (e.g. to ensure that all components of a module contribute to one single task.)

In OO, cohesion refers to the consistency of the functions within a single class. It is therefore a measure of how focused a class is upon a purpose or task (e.g. the class Customer should only have methods that belong to customer and not methods like “place order()” or “make payment()”.)

CONCEPTUAL CLASS DIAGRAM…SOME TIPS Incremental and iterative development we might not be

able to specify all the attributes or operations of a class in the first round. Conceptual class diagrams might contain classes which do not specify attributes or operations.

Design class diagram during design enriched with more information and more easily can be turned into code. Conceptual class diagram is just the first attempt.

Determining the attributes and operations of a class is also part of the analysis stage. BUT their exact definition is generally postponed until later when designers concentrate on design.

General comment: don’t expect to get things right at the first attempt. You’ll always need to revise your assumptions and models as your understanding grows.

HOW TO BUILT A CLASS DIAGRAM Step 1: Find the potential classes/objects. Review each use

case and its description to find “nouns” that correspond to business events. E.g. Ask Enquiry nouns: enquiry

Step 2: Select the proposed classes/objects. Clean up the list created above by removing nouns that represent synonyms, nouns outside the scope of the system, nouns that are roles without unique behaviour, unclear nouns, nouns that are really methods or attributes

Step 3: Identify associations and multiplicity between the classes.

Step 4: Identify generalisation/specialisation relationships – look for objects that have common attributes and behaviour.

Step 5: Identify aggregation/composition relationships – look for any objects that can be part of the others.

Step 6: Build the class diagram

WRAPPING IT UP!Conceptual Class diagrams: Produced during the analysis phase Include entity classes with their attributes and operations Show associations between classes as well as other

special type relationships such as generalisation and aggregation/composition.

Don’t expect to get things right at the first attempt – ESPECIALLY attributes and methods. (how they work is a part of the design and not analysis.)

You’ll always need to revise your assumptions as your understanding grows.

This is an iterative and incremental process. You need to work on all diagrams in an iterative and incremental fashion rather than in a sequential manner.

Next week:

Using UML notations to create object sequence diagrams