IS 274: OBJECTS AND

CLASSES AND THEIR

RELATIONSHIPS
Dr Salome Maro

2nd May 2022

OBJECTS
 An object exists in the real world (or more precisely, in your understanding of
the real world).
 It can be a part of any type of system, for example, a machine, an organization,
or a business.
 Objects can be derived by analyzing the structure and behavior of objects in
the real world.
CLASSES
 A class describes the properties and behaviour of a type of object. All objects can reflect some
class.
 From a class, a system will create individual instances, or objects. Put another way, objects are
instantiated from a class.
 Examples of classes in business information systems include:
 Customer
 Agreement
 Invoice
 Debt
 Asset
 Quotation
IDENTIFYING CLASSES
 The modeler must use the knowledge of experts in the problem domain along

with an understanding of the user and system creatively to capture the system classes.

 Good classes reflect the problem domain and have real names
IDENTIFYING CLASSES
Questions we can ask:
 What is the information that should be stored or analyzed?
 Are there external systems? -- The external system might be seen as classes that your system
contains or should interact with.
 Are any reusable patterns, class libraries, or components? (Go there to look for class
candidates)
 Are there devices that the system must handle?
 Are there any organizational parts? Representing an organization can be done with classes,
especially in business models.
 Which roles do the actors in the business play? These roles can be seen as classes, such as
user, system operator, customer, and so on.
IDENTIFYING CLASSES
Find concepts from the textual descriptions of the problem domain according to
concept category list.
 Concepts and objects (things) can be divided into different categories
according to their nature of its instances.
 The concept category list given (next slide) has been found useful in
identifying concepts.

This strategy is to create a list of candidate concepts from the client’s

requirements description, initial investigation reports, system functions
definitions, and use cases.
GUIDE TO IDENTIFYING CLASSES FROM
TEXTCategory
physical or tangible objects (or things)
Category Examples
POST, House, Car, Sheep, People, Airplane, ATM
places Store, Office, Airport, PoliceStation
documents, specifications, designs, or ProductSpecification, ModuleDescription,
descriptions of things FlightDescription, JobDescription
transactions Sale, Payment, Reservation
roles of people Cashier, Student, Doctor, Pilot, Interviewee
containers of other things Store, Bin, Library, Airplane
things in a container Item, Book, Passenger
other computers or electro-mechanical CreditCardAuthorizationSystem, Air-TrafficControl
systems external to our system
abstract noun concepts Hunger, Acrophobia
organizations SalesDepartment, Club, ObjectAirline
historic events, incidents Sale, Robbery, Meeting, Flight, Crash, Landing
Processes (often not represented as a SellingAProduct, BookingASeat
concept, but may be)
rules and policies RefundPolicy, CancellationPolicy
catalogs ProductCatalog, PartsCatalog
records of finance, work, contracts, Receipt, Ledger, EmploymentContract,
legal matters MaintenanceLog
financial instruments and services LineOfCredit, Stock
manuals, books EmployeeManual, RepairManual
IDENTIFYING CLASSES
Identify the noun and noun phrases in the textual descriptions of a problem
domain and consider them as candidate classes or attributes.
IDENTIFYING CLASSES
 Looking for classes may well prompt questions that will improve the use case
model or requirements specification.
EXAMPLE
 Consider our OIMS application, we can identify some noun phrases. Some of the noun
phrases in the use case are candidate concepts; some may be attributes of concepts
IDENTIFYING CONCEPTS FOR
THE OIMS
Spe c ializatio nAre a Inte rvie w Inte rvie we e

Inte rvie wQ ue s tio ns Q ue s tio ns Type Applic ant

Q ue s tio ns Ans we rs Q ue s tio ns M arks Inte rvie we r

J o bD e s c riptio n Ve nue T im e S c he dule SuppD o c s

L o c atio n Inte rvie wG rade Sys U s e r Sys Adm in

CV C e rtific a te s
LET US TRY IT
Use Object-Oriented system analysis and design approach with UML to develop
a Dynamic Web-Based Management System for TFF. The system should
provide means of searching information of matches using any criteria. It should
display information on match prices based on playground and stadium stages
available and provide information on payment procedures.
CLASS DIAGRAMS
 A class diagram depicts classes and their interrelationships
 Used for describing structure and behavior in the use cases
 Provide a conceptual model of the system in terms of entities and their relationships
 Used for requirement capture, end-user interaction
 Detailed class diagrams are used for developers
CLASS DIAGRAM
 Each class is represented by a rectangle subdivided into three compartments
 Name
 Attributes
 Operations
CLASS DIAGRAM – NAME
COMPARTMENT
 The top compartment of the class rectangle contains the name of the class
 The name should be derived from the problem domain and should be as unambiguous as
possible
 The class name should be a noun
CLASS DIAGRAM –
ATTRIBUTES COMPARTMENT
 Classes have attributes that describe the characteristics of the objects
 Only the attributes that are interesting within the system being modelled should be included.
CLASS DIAGRAM –
OPERATIONS
 Operations manipulate the attributes or perform other actions.
 Operations are normally called functions, but they are inside a class and can be applied only to
objects of that class.
 An operation is described with a return-type, a name, and zero or more parameters.
VISISBILITY
 Modifiers are used to indicate visibility of attributes and operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (derived)
 ‘-’ is used to denote Private visibility (no one)
RELATIONSHIPS BETWEEN
CLASSES
 The relationships that can be used are:
 associations,
 generalizations,
 dependencies, and
 abstractions/realizations.
 CLASS RELATIONSHIP:
GENERALIZATION
Example:
Supertype Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2

 -Generalization expresses a parent/child relationship among related classes.

 Used for abstracting details in several layers
ASSOCIATION

 Represent relationship between instances of classes/ is a connection between classes

Student enrolls in a course
Courses have students
Courses have exams
Etc.

 Association has two ends

Role names (e.g. enrolls)
Multiplicity (e.g. One course can have many students)
Navigability (unidirectional, bidirectional)
ASSOCIATION MULTIPLICITY
CLASS DIAGRAM

[from UML Distilled Third Edition]

COMPOSITION
Class W Association
Whole Class
Models the part–whole relationship

Composition
Class P2
Also models the part–whole relationship but, in addition, Every
Class P1
part may belong to only one whole, and If the whole is
deleted, so are the parts
Part Classes
[From Dr.David A. Workman]
Example:
Example A number of different chess boards: Each square belongs to only
one board. If a chess board is thrown away, all 64 squares on that
board go as well.

Figure 16.7
The McGraw-Hill Companies, 2005
AGGREGATION
Container Class
Class C
Aggregation:
• expresses a relationship among instances of
AGGREGATION
related classes. It is a specific kind of
Container-Containee relationship.
Class E1 Class E2

• express a more informal relationship than

Containee Classes
composition expresses.
Example
Bag
• Aggregation is appropriate when Container
and Containees have no special access
privileges to each other.
Apples Milk

[From Dr.David A. Workman]

AGGREGATION VS. COMPOSITION
Composition is really a strong form of association
 components have only one owner
 components cannot exist independent of their owner
 components live or die with their owner
 e.g. Each car has an engine that can not be shared with other cars.

Aggregations
 may form "part of" the association but may not be essential to it. They
may also exist independent of the aggregate. e.g., Apples may exist
independent of the bag.
CLASS ACTIVITY
 Think about the current LMS being used at the university. Identify important concepts that can
be represented as classes.
 Draw a class diagram including attributes, operations and relationships
QUESTIONS?