0% found this document useful (0 votes)
47 views42 pages

OOAD: Data Modeling: Presenter: Dr. Ha Viet Uyen Synh

Class diagrams are central for analysis, design and implementation in object-oriented design (OOAD). They are used to visualize classes and relationships between classes. Key elements of class diagrams include classes, relationships such as associations, aggregations, and generalizations/specializations. Class diagrams can be used at different stages of the software development process, including conceptual modeling, specification modeling, and implementation modeling.

Uploaded by

Sok Vy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
47 views42 pages

OOAD: Data Modeling: Presenter: Dr. Ha Viet Uyen Synh

Class diagrams are central for analysis, design and implementation in object-oriented design (OOAD). They are used to visualize classes and relationships between classes. Key elements of class diagrams include classes, relationships such as associations, aggregations, and generalizations/specializations. Class diagrams can be used at different stages of the software development process, including conceptual modeling, specification modeling, and implementation modeling.

Uploaded by

Sok Vy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 42

OOAD: Data Modeling

Presenter: Dr. Ha Viet Uyen Synh.


Role of Class Diagram

Class diagrams are central for analysis, design and implementation.


Class diagrams are the richest notation in UML
Part I

CLASSES
The nouns and the verbs
Start from the requirements document;
- in function-oriented design you would
concentrate on the verbs, which correspond to actions
("do this");
- in object-oriented design you underline the
nouns, which describe objects

Example:
The elevator will close its door before it moves
to another floor.
Avoiding useless classes
The life time of an object is the most important
criteria to decide if it becomes a class or not.

The nouns of a requirements document will


cover some classes of the final design, but will also
include many "false alarms": concepts that should not
yield classes.

Example:
Door _ the only relevant property of elevator
doors for this system is that they may be opened and
closed.
Floor _ Each floor has a floor number or some
floors may have special access rights defining who can
visit them
GENERAL HEURISTICS FOR
FINDING CLASSES

analysis classes

Class
categories
Implementat-
design classes
ion classes
Example
Analysis classes:
sensors, devices, airplanes, employees,
paychecks, tax returns, paragraphs, functions.

Implementation classes:
stack, queue, …

Design classes:
state, application, command, history-list, …
Part II

RELATIONSHIPS
Types of Relationships

Association Composition

Aggregation
Associations
Associations represent relationships between instances of
classes.

From the conceptual perspective, associations represent


conceptual relationships between classes.

Each association has two roles that may be named with a


label.

Multiplicities indicate how many objects may participate in


a relationship.
Associations: Multiplicities
The * represents the range 0..Infinity.

The 1 stands for 1..1.


“An order must have been placed by exactly one
customer.”

For more general multiplicities you can have


a single number like 11 soccer players,
a range, for example, 2..4 players for a canasta
game,
a discrete set of numbers like 2,4 for doors in a car.
Navigability
To indicate navigability with associations, arrows are added
to the lines.

In a specification view, this would indicate that an order


has a responsibility to tell which customer it is for, but a
customer has no corresponding ability to tell you which
orders it has.
In an implementation view, one would indicate, that order
contains a pointer to customer but customer would not point
to orders.
If a navigability exists in only one direction it is called uni-
directional association, otherwise bi-directional
association.
Aggregation
Aggregation is the part-of relationship.
“A CPU is part of a computer.”
“A car has an engine and doors as its parts.”

Aggregation vs. attributes :


Attributes describe properties of objects, e.g. speed, price, length.
Aggregation describe assemblies of objects.

Aggregation vs. association:


Is a company an aggregation over its employees or is it an
association between its employees?
Composition
Composition is a stronger version of aggregation:
The part object may belong to only one whole.
The parts usually live and die with the whole.

Example:
Aggregation: A company has employees. The
employees may change the company.
Composition: The company has a tax registration.
The tax registration is tied to the company and dies
with it.
Aggregation vs Composition
Some Particular Types of Classes

Generalization
Abstract Class /
Specialization

Association
Interface
Class
Association Classes
Association classes allow you to model associations
by classes, i.e., to add attributes, operations and
other features to associations
Generalization / Specialization
Generalization captures similarities between several
classes in a superclass. Specialization refines and
adds differences in subclasses.
Abstract Class
An abstract class is a class without a (full) implementation.
Some methods are deferred, i.e., they are not implemented.
The deferred methods are implemented by subclasses only.

Example: The window move operation is implemented by using


hide and show methods which are implemented by subclasses.
Interface
An interface is a (abstract) class with no implementation.
An interface is implemented (refined) by (different) classes.
The implementation can be changed without changing the clients.

Example from Java class libraries:


InputStream is an abstract class, i.e., some methods are deferred.
DataInput is an interface, i.e., it implements no methods.
DataInputStream is a subclass of InputStream; it implements the deferred
methods of InputStream, and the methods of the interface DataInput.
OrderReader uses only those methods of DataInputStream that are defined
by the interface DataInput.
Part III

WHEN TO USE CLASS


DIAGRAMS
Perspectives

Analysis Design

Database Conceptual Model

Software Specification Model


Component
Implementation Model
Database Analysis & Design
Conceptual Model
Conceptual model is used to describe a domain of
concepts

A detailed model that captures the overall structure of


data in an organization

Independent of any database management system


(DBMS) or other implementation considerations

In conceptual model, Entity Relationship Diagram is


replaced by Class Diagram
Conceptual Model Example
Records

Currently-handles

0..1 *
Person Loan

address dueDate
name
0..1
Records-loan-of

1
Librarian Patron
Employs Borrows
1..* 0..1 1
*
1
1
* Resource
Library
1 Lends-resources-to callNumber
* title
Records-storage-of
1
1

Maintains Catalog Book Video


1
ISBN releaseDate
Logical Model
Based upon the Conceptual Model

Logical Model is independent with DBMSs.

In Logical Model, there are some foreign keys.

A Logical Model is a Relational Database.


tblMulti_attr_value
Conceptual attr_id : int
attr_name : varchar(30)
attr_value : varchar(30)
Model tblsku
(*) prd_unit_quantity : int
(*)prd_image : varchar(100)
0..n
tblShopper
(*) prd_unit_price : float
shopper_id : int
(*) prd_sale_price : float
shopper_name : varchar(50)
shopper_email : varchar(50)
shopper_password : varchar(50)
shopper_address : varchar(100)
shopper_phone : int
tblOrder_Detail
1..n shopper_city : varchar(100)
quantity : int
tblProduct 1
prd_id : varchar(10)
prd_name : varchar(30)
prd_short_desc : varchar(200) 1..n
prd_long_desc : varchar(400) tblOrder
(*)prd_unit_price : float ord_id : int tblTax
(*)prd_sale_price : float ord_date : datetime
1..n 0..n tax_id : int
prd_unit : varchar(30) ord_status : bit
tax_name : varchar(50)
(*)prd_unit_quantity : int 0..n receive_name : varchar(50) 1 tax_value : float
prd_image : varchar(100) receive_address : varchar(100)
prd_width : int receive_phone : int
prd_height : int
prd_sale_start : datetime
prd_sale_end : datetime 0..n
(*)prd_sa : varchar(20) prd_prom
discount : float
1..n
0..n
1
tblshipcost tblCity
0..n
ship_id : int 1 city_id : int
0..n ship_cost : float city_name : varchar(30)
tblPromotion
1 1 0..n
prom_id : int
tblDepartment prom_name : varchar(50)
0..n
dept_id : varchar(10) from_date : datetime
dept_name : varchar(30) to_date : datetime
dept_desc : varchar(200)
1
tblTime
time_id : int
time_name : varchar(30)
Logical
Model
Physical Model
Based upon the logical model.

Physical Model depends on a particular DBMS.

A Physical Model is a SQL script file.


Example

Conceptual Model
Logical Model

Physical Model
Notes
1. A conceptual model is not a picture of Software
components or Classes in an object-oriented
programming language. It illustrates real-world
concepts.

2. Each many-to-many relationship have to be modeled


with an association class.

3. Conceptual model need to get the third normal form


(3NF).
Normalizations
The process of converting complex data structures into
simple, stable data structures

First Normal Form (1NF) _ Unique rows, No multivalued


attributes, All relations are in 1NF.

Second Normal Form (2NF) _ Each nonprimary key


attribute is identified by the whole key (called full
functional dependency).

Third Normal Form (3NF) _ Nonprimary key attributes do


not depend on each other (i.e. no transitive
dependencies).
Specification Model vs Implementation Model
Specification Model and Implementation Model are
used to describe software components.

Specification Model describes software abstractions


with specifications and interfaces. It’s independent with
programming languages.

Implementation Model describes software


implementations in a particular programming language.
Specification Model Example
Implementation Model Example
Exercise #1
Build relationships between these classes: Person, Car-
Owner, Car
Exercise #2
Build relationships between these classes:
Employee, Supervisor, Administrator, Engineer,
Permanent, Temporary. If required, you can add a new
class.
Exercise #3
Based on the following description, draw a class diagram of an
information system for a company called North Marina.

The company offers docking spots for the boats. Boat owners rent
docking spots based on an annual agreement for each boat, which can
be renewed. An owner can have several boats, however each boat is
assigned a unique docking spot stated in the agreement.

North Marina also offers boat repair service which requires an owner
to sign a contract with a company representative responsible for
repair. In your class diagram, model the relationships between the
classes: DOCKING SPOT, BOAT, AGREEMENT, OWNER, CONTRACT and
REPRESENTATIVE.

a. Indicate minimum and maximum cardinalities and degree of each


relationship;
b. Show the attributes of each class;
c. If required, present a solution to avoid many-to-many relationships.
Ex. #4
Exercise #5
Any Questions?

 hvusynh@hcmiu.edu.vn

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy