Chapter 6
Design Model
Design Model (DM)

Guiding principles





All classes should be specified to the level of detail
that they represent implementation classes.
A sequence diagram should be defined for each flow
of events in each use case.
All messages in sequence diagrams should
represent actual operations of participating objects
You should avoid representing in the diagram the
classes of the underlying technological framework
(e.g., classes in Java packages)
Achieve class cohesiveness, minimizing
communication between classes.
DM: Guiding principles -temp

Domain entities:


Classes, objects, and packages that are found from
the use cases to specify system functions
Entities of this type at the design model are basically
a copy of those in the analysis model by adding


Operations and attributes
Implementation-level entities:


Classes, objects, and packages that are identified by
the designer to support the implementation of the
system.
Examples includes list, database tables, Java beans
DM: Model structure


The same analysis packages are also design packages
Each design package is structured into three layers:




Each design package has subpackages for the
realization of the use case in the package


Presentation layer
Business layer
Data access layer
Use elements in the three layers to realize each use case in the
package
At the business layer of each package there is an entity
manager that manages all elements/entities of the
package at the data access layer.
Design model structure
Figure 6-2
DM: Model structure
Business package i
Presentation
Business
Data access
Wrappers
Data Access
Data Types
U
s
e
c
a
s
e
r
e
a
li
z
a
ti
o
n
s
DM: Data Access Layer - 1



Although entities are managed by different
managers, but each use case may need,
normally does, entities from other packages to
be realized.
Create a data model for the whole system
When an entity (A) has an association with
another entity (B) which is managed by a
different entity manager, then the manager of A
must request services from the manager of B in
order to make changes or retrieve info of B.
DM: Data Access Layer - 2

The data access layer may be further
divided into:
Data Type classes: the data itself (stored in
DB).
 Wrapper classes: the data and getters and
setters.
 Data Access Layer classes: that define a set
of operations for the specific needs of our
solution

 CRUD:
create, retrieve, update, and delete
DM: Data Access Layer - 3
Data Access Layer
and Wrapper classes
<Wrapper>>
<Wrapper>>
Student
SSN, name,
Address, DOB
Getters()
Setters()
Major
StudentDAL
MajorDAL
Id, Name,
hostCollege
Getters()
Setters()
create()
findStudent(id)
findStudents(major)
Update()
Delete()
create()
findMajor(id)
Update()
Delete()
Data Type Classes
MajorInfo
Id
Name
Host college
StudentInfo
ssn
Name
Address
DOB
RegisterInfo
StudentSSN
SectionNo
grade
DM: Data Access Layer - 4




Data Type classes are mapped to relations (tables) in
relational database.
Each M:N relationship between data type classes is
mapped to a table (called association table). (e.g., table
register in next slide)
When an M:N relationship spans two entities managers,
the association table belongs to both managers (e.g.,
table register on next slide).
The database model can be traced back to the
managed entities diagram in the Analysis Model (see
Managed Entity Diagram slide)
DM: Data Access Layer - 5
Database Model
Note: Arrows show foreign keys.
<<table>>
<<table>>
<<table>>
MajorInfo
StudentInfo
RegisterInfo
Id
Name
Host college
ssn
Name
Address
DOB
majorID
StudentSSN
SectionNo
grade
<<table>>
<<table>>
<<table>>
<<table>>
CourseInfo
SectionInfo
FacultyInfo
DeptInfo
CourseID
Title
Credits
sectionNo
location
courseID
Instructor
ssn
Name
Office
department
deptID
Name
mainOffice
DM: Data Access Layer - 6
StudentDAL
+create(Student s): int
+findBySSN(string ssn): Student
+findByMajor(mid): List<Student>
+update(Student s): int
+delete(string ssn): int
+getMajor(string ssn): int
+getTranscript(string ssn): List<crsId, grd>;
<<Wrapper>>
Student
-ssn: string
-Name: string
-Address: string
-DOB: Date
-majorID: int
+get/setSSN(ssn);
+get/setName(name);
+get/setAddr(addr);
+get/setDOB(date)
+get/setMajor(int mid)
<<table>>
<<table>>
RegisterInfo
StudentInfo
StudentSSN
SectionNo
grade
RDBMS
ssn: char(9);
name: varchar(20)
address:
DOB: char(8);
majorID: int
DM: Data Access Layer - 8
A Look Ahead to deployment
Web Server: Node
<<Wrapper>>
Major
DB Server: Node
…
RDBMS
<<table>>
RegisterInfo
Intranet
MajorDAL
<<driver>>
JDBC
<<driver>>
JDBC
<<table>>
StudentInfo
StudentDAL
<<table>>
<<Wrapper>>
Student
MajorInfo
…
DM: Presentation layer

Three diagrams are defined for each business package:

Boundary traceability (Mapping): traces each XyzView back to
the boundary classes


Control traceability (mapping): trace dispatcher classes back to
dispatcher classes in analysis model


Each screen (and its included input forms) is mapped to a
XyzView class
Each dispatcher class in analysis model is mapped to a dispatcher
Participants: a class diagram showing the relationship between
classes in the presentation layer (including XyzView classes
and dispatchers)

Show the relationship between View classes and dispatchers
Mediator

Design Purpose


Avoid references between dependent
objects.
Design Pattern Summary

Capture mutual behavior in a separate
class.
Mediator - Model
Mediator
Colleague
Colleague_A
ConcreteMediator
Colleague_B
Mediator Sequence Diagram
B: Colleague_B
Client
:Mediator
:Mediator
request()
A:Colleague_
A
mediate()
takeAction_1()
takeAction_2()
takeAction_3()
C: Colleague_A
DM: Business layer

The entity manager of each business package
is mapped to a subsystem.




A subsystem is an instance of a package
The Interface: the specification of the subsystem,
defines everything a client needs to know in order to
use the subsystem
The realization of the interface: the implementation
of the subsystem, interior structure that implements
the interface.
To start, define one class that implements all the
operations specified in the interface.
AM: Relationship between classes
Business Package i
Course
CourseDAL
dispatcher
Entity
Manager
Subsystem
dispatcher
CourseInfo
Section
SectionDAL
SectionInfo
Classroom
CroomDAL
dispatcher
Presentation Layer
Business
Layer
Data Access Layer
ClassroomInfo
DM: Identify class operations - 1

For Boundary classes (View classes/Web pages):
 Attributes of a screen are mapped to text display
 An input form is mapped to an HTML form
 Attributes of an input form are input fields of the
HTML form
 Operations of a screen may be mapped to
Javascript display function and Web links
 Operations of an input form may be mapped to
HTML form submit buttons.
 The program that processes the HTML form submits
is the dispatcher of the use case.
DM: Identify class operations - 2

Identify operations for control and data access
layer classes



Use sequence diagram to help in identifying class
operations for all control classes (dispatchers and
entity manager) and entity classes (data access
layer classes)
For every scenario of every use case, create a
sequence diagram.
Follow the message in the sequence diagram one by
one to identify the operation the receiving class
should have.
DM: Identify class operations - 3

Each operation identified should be
documented with:






name of the operation
A brief description of the operation’s function
In and out parameters
Return value
Define the skeleton of the operation’s body as
feasible.
Follow the javadoc, cppdoc, and phpdoc format
or a standard.
DM: Summary

For each business package




Each boundary class is mapped to a Web page
The entity manager is mapped to the entity manager
subsystem
Each dispatcher is mapped to a subclass of HTTPServlet
Each entity class is mapped to




A DAL class
A wrapper class (Java Bean)
A data type class (DB table)
Identify operations


Each operation of a boundary class from the user experience
model is mapped to a web link, or an html submit input
For dispatchers, entity manager subsystem (its classes), and
DAL classes

Use sequence diagrams to identify their operations based on the
messages a receiving class receives.
Managed entities
Figure 6-3
Data Access classes for User
Account Management
Figure 6-4
XML Schema designer in Microsoft Visual
Studio .NET, with the definition of a strongly
typed DataSet.
Figure 6-5
Database model
Figure 6-6
Tracing Data Access classes
to analysis classes
Figure 6-7
Structure detail of the Data
Access Layer package
Figure 6-8
Structure detail of the
Presentation Layer package
Figure 6-9
Equivalence of structures between
design model and analysis model
Figure 6-10
Tracing dispatcher classes to
analysis classes
Figure 6-11
Tracing Web forms/controls
to analysis classes
Figure 6-12
Participants in the presentation layer
of User Account Management
Figure 6-13
Structure detail of the
Business Layer package
Figure 6-14
Enterprise component interface with
associated Data Layer classes
Figure 6-15
Tracing enterprise component
interface to analysis classes
Figure 6-16
Realization of the enterprise
component interface
Figure 6-17
Class diagram for the enterprise
component implementation
Figure 6-18
Structure detail of the Use
Case Realizations package
Figure 6-19
Tracing use case realizations
from design to analysis
Figure 6-20
Figure 6-22
Sequence diagram for the basic
flow of Create Account use case
Figure 6-23
Structure detail of the
Common package
Figure 6-24
Collaboration detail:
CreateAccount_Entry validation
Figure 6-25
Collaboration detail: Create
Account
Figure 6-26
Collaboration detail: Adding
User to Group
Figure 6-27
Role-based security handling:
Participants
Figure 6-28
Activity graph: submitSignIn
in SignInDispatcher class
Figure 6-29
Sequence diagram: Set Session
Authentication on Sign-In
Figure 6-30
Declare forms authentication
in Web.config
Figure 6-31
Activity graph:
Application_AuthenticateRequest in
Global class
Figure 6-32
Sequence diagram: Request
authenticated but no role cookie
Figure 6-33