Software Engineering and Design Pattern

System Design:
Component Design: Model
D r. R u d r a P r a t a p D e b N a t h

Associate Professor
Department of Computer Science and Engineering
University of Chittagong

Email:rudra@cu.ac.bd

5th Semester 2022

DESIGN:
COMPONENT DESIGN.
THE MODEL COMPONENT
2

COMPONENT
DESIGN

2
COMPONENT DESIGN
<<component>> <<component>>
Model Function
Customer Account type Interest admin
•  Component details customer-no.
name
disignation
1..* 1
address
•  Connections between correct data change interest
open account control calc of
components close account
rate
interest
1..* 1 1

•  Designing the 1..* 1..*

1..*
Account
architecture is an account-no.
accountstate
Interest rate
pctproanno

iterative process opendate

closedate
fromdate
todate
register trans

•  Revise the division of add interest

print account

components 1
1..*
•  Influences the process Transaction Value set:
{open, closed}
architecture transtype
date
amount Value set:
{deposit, withdraw,
30/10/14 interest}

3
SU:L10.E14
OVERVIEW OF ‘COMPONENTS’

• To determine an implementation of
Purpose requirements within an architectural
framework.

• Component: A collection of program parts that

constitutes a whole and has well-defined
Concepts responsibilities.
• Connection: The implementation of a
dependency relation.

• Respect the component architecture.

Principles • Adapt component designs to the technical
possibilities.

Results • A description of the system’s components.

4
FROM ARCHITECTURE
TO COMPONENTS
<<component>>
user interface

<<component>>
function

<<component>>
model

Principles:
●  Respect the component
architecture
●  Adapt component designs to the
30/10/14
technical possibilities

5
SU:L10.E14
 ACTIVITIES IN ’COMPONENT
DESIGN’
• How is the model represented as
classes in the system?
Model
component • Model component and attribute
Analyse af
Analyse af
problem-
anvendelses-
område
område

Design af
Model komponenter

• How are the functions

implemented?
Function
component • Function component and operation
Design af
arkitektur

• How are components connected?

• Component and connection
Connect

6
2

MODEL
COMPONENT

7
OVERVIEW OF ‘MODEL
COMPONENT’

Purpose • To represent a model of a problem domain

• Model component: A part of the system that

Concepts implements the problem-domain model.

• Attribute: A descriptive property of a class or an
event.

• Represent events and classes, structures and

Principles attributes.
• Choose the simplest representation of events.

Results • A class diagram of the model component.

8
 RESULT OF MODEL
COMPONENT
Customer
creditapproval
creditapprovaldate
name • Starting point: the
class diagram from
1 1
1..* 1..* the problem domain
Customer address Account
accountnumber
analysis
fromdate accountstate
• Extended to handle
adress opendate
closedate

behavior
1
0..* • Adding new classes
Transaction
• Adding attributes
creditapproval
creditapprovaldate • Adding and revising structures
name

9
ACTIVITIES IN
‘MODEL COMPONENT’

Represent private events

Represent common events
Sequence and
selection Restructure classes
Choose between
Iteration alternatives Generalization
Association
Embedded
iterations

10
FROM OVERVIEW TO
SPECIFICATIONS OF DETAILS
<<component>>
•  Component: user interface

A collection of program
<<component>>
parts that constitutes a function
whole and has well-
defined responsibilities. <<component>>
model

•  Responsibility of the
model component:
maintain an updated
representation of the
problem domain.

11
30/10/14
SU:L10.E14
 ANALYSIS MODEL FOR
BANK SYSTEM
credit approval
(date, name, address)

Approved
Customer
account opened
• Class diagram name
change address
(date, address)
(date)
account closed
(date)
Active
• Event table
1
account account deposit withdraw
opened closed (date, (date,
(date) (date) amount) amount)
Event Customer Account
1..*
Credit approval +
Account
Change adress * accountnumber
account opened
Account opened * + (date)

Account closed * + account closed

(date)
Deposit * * Open

Withdraw * *
deposit withdraw
(date, (date,
amount) amount)

12
REPRESENT PRIVATE events  that  involve  only  one  
problem-­‐domain  object.  
EVENTS
• Sequence and selection
• Represent these events as an attribute in the class described in the
state chart diagram.
• The system assigns a value to the attribute when the event occurs.
• Integrate the attributes of the event in the class.
• Iteration
• Represent these events as a new class, connect it to the class
described in the state chart diagram with an aggregation structure.
• The system generates a new object of the class each time the event
occurs
• Integrate the attributes of the event in the class.

13
REPRESENT PRIVATE Eventç Customer Account

EVENTS
Credit approval +
Change adress *
Account opened * +
Account closed * +
• The event ‘credit approval’ is private Deposit * *
to the class customer and is a Withdraw * *
sequence in the state chart diagram
for the class Customer
• Represented as an attribute creditapproval
creditapprovaldate

• The event ‘change adress’ is private

to the class Customer and is an
iteration in the state chart diagram 1
1..*
1
1..*
for the class
Customer address Account
• Represented as a new class
fromdate accountnumber
address

14
REPRESENT COMMON
EVENTS
events  that  involve  two  or  more  
problem-­‐domain  objects.  

• Common events
• Represent the event in relation to one of the objects
• Consider adding structural connections to give the other
objects access to the relevant attributes.
• Represent common events in the way that offers the
simplest structure.

• If the event figures differently in the state chart diagrams, it

is represented in connection to the class, which gives the
simplest representation.
• If the event figures in the same way in the state chart
diagrams, you have to consider the possible representations

15
REPRESENT COMMON EVENTS:
Eventç Customer Account
Credit approval +
CHOOSING A SIMPLE Change adress *

ALTERNATIVE Account opened

Account closed
*
*
+
+
Deposit * *
• The events ‘account opened’ and Withdraw * *
‘account closed’ are interative on
Customer
class Customer and in a
sequence on class Account creditapproval
creditapprovaldate
• The simplest representation is by name
adding attributes to class
Account

Customeraddres Account

fromdate accountnumber
address accountstate
opendate
closedate

16
REPRESENTATION OF
Event Customer Account
Credit approval +
COMMON EVENTS: Change adress *

ITERATIONS SOLUTION A Account opened

Account closed
*
*
+
+
Deposit * *
Withdraw * *
• The events ‘withdraw’
and ‘deposit’ are
iterations on two classes
Customer
• The events can be
represented as new 1
1..*
1
1..*
classes under Account Customer
address Account

1 1
0..* 0..*

Deposit Withdraw

17
REPRESENTATION OF
COMMON EVENTS:
SOLUTION B
• Alternatively: the events • Gives a complex
can be represented as structure (two
new classes under the associations across)
customer class • We would therefore
choose solution A

Customer

1 1 1 1
1..* 1..* 0..* 0..*
Customer 1
Account Deposit Withdraw
address 0..*
1 0..*

18
RESTRUCTURE
CLASSES (1)
Account Account
• The revised class accountnumber
accountstate
accountnumber
accountstate
diagram represents the opendate
closedate
opendate
closedate
information form the
state chart diagrams.
• The class diagram can 1 1 1
0..*
0..* 0..*
often be restructured Withdraw Transaction
Deposit
and simplified without date date transtype
any loss of information: amount amount date
amount

• Generalization
• Association
• Embedded iterations

19
RESTRUCTURE
CLASSES (2)
0..*
Gas station Customer
0..*

The event ‘Fill’ is

0..*
iterative on both
Gas station
0..*
Customer classes
1 1

0..* 0..*
Gas station Customer
Filling
1 1

0..* 0..*

Filling

20
30/10/14
SU:L10.E14
RESTRUCTURE
CLASSES (3)
Person
status
Person date of birth
date of death

1
0..*
1 1 1
0..* 0..* 0..* Hospitalization
status
Hospitalization Treatment Discharge entrydate
exitdate

1
0..*

Does not represent the Treatment

type
association between date
“Treatment”, “Discharge” and
a specific “Hospitalization”

21
30/10/14
SU:L10.E14
GROUP ASSIGNMENT
Complete the activity “Model component” for the cinema example:

0..* rate 0..*

Movie Customer
1 0..*
Cinema
1
0..*
0..* 0..*
Show
view

22
ASSIGNMENT
Represent private events
• Selection/sequence: attribute
• Iteration: class
Movie Movie Represent common events
Movie played rated • Choose between alternatives
(date, time) (rate, date)
Movie Movie
opened closed
(date) Play
(date)
Active planned
Cinema (date, time)
Play Cinema Cinema
planned opened closed
(date, time) (date) (date)
Active

Movie
viewed
Play (date)
Movie Movie Customer Play Cinema
Play planned played Movie opened +
(date, time) (date, time) Movie closed +
Planned
Movie played * +
Play planned * + *
Customer closed +
Movie Movie
viewed rated Customer opened +
Customer (rate, date)
(date) Movie viewed * *
Customer Customer Movie rated * *
opened closed
Cinema opened +

23
(date) (date)
Active Cinema closed +
OVERVIEW OF ‘MODEL
COMPONENT’

Purpose • To represent a model of a problem domain

• Model component: A part of the system that

Concepts implements the problem-domain model.

• Attribute: A descriptive property of a class or an
event.

• Represent events and classes, structures and

Principles attributes.
• Choose the simplest representation of events.

Results • A class diagram of the model component.

24