Chapter 6 Design Model

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

>

>

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.







MajorInfo

StudentInfo

RegisterInfo

Id Name Host college

ssn Name Address DOB majorID

StudentSSN SectionNo grade









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 +update(Student s): int +delete(string ssn): int +getMajor(string ssn): int +getTranscript(string ssn): List;

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)





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

Major

DB Server: Node …

RDBMS

RegisterInfo

Intranet

MajorDAL

JDBC



JDBC



StudentInfo

StudentDAL



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