Chapter 6 Design Model

Design Model (DM) Guiding principles Guiding principles All classes should be specified to the level of detail that they represent implementation classes. 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. 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 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) 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. Achieve class cohesiveness, minimizing communication between classes.

DM: Guiding principles -temp Domain entities: Domain entities: Classes, objects, and packages that are found from the use cases to specify system functions 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 Entities of this type at the design model are basically a copy of those in the analysis model by adding Operations and attributes Operations and attributes Implementation-level entities: Implementation-level entities: Classes, objects, and packages that are identified by the designer to support the implementation of the system. Classes, objects, and packages that are identified by the designer to support the implementation of the system. Examples includes list, database tables, Java beans Examples includes list, database tables, Java beans

DM: Model structure The same analysis packages are also design packages The same analysis packages are also design packages Each design package is structured into three layers: Each design package is structured into three layers: Presentation layer Presentation layer Business layer Business layer Data access layer Data access layer Each design package has subpackages for the realization of the use case in the package Each design package has subpackages for the realization of the use case in the package Use elements in the three layers to realize each use case in the package 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. 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

Data access DM: Model structure Presentation Business U s e c a s e r e a li z a ti o n s Business package i Data Types Wrappers Data Access

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. 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 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. 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: The data access layer may be further divided into: : the data itself (stored in DB). Data Type classes: the data itself (stored in DB). : the data and getters and setters. Wrapper classes: the data and getters and setters. : that define a set of operations for the specific needs of our solution Data Access Layer classes: that define a set of operations for the specific needs of our solution CRUD: create, retrieve, update, and delete CRUD: create, retrieve, update, and delete

DM: Data Access Layer - 3 Data Access Layer and Wrapper classes StudentDAL create() findStudent(id) findStudents(major) Update() Delete() MajorDAL create() findMajor(id) Update() Delete() MajorInfo Id Name Host college StudentInfo ssn Name Address DOB Data Type Classes RegisterInfo StudentSSN SectionNo grade > Major Id, Name, hostCollege Getters() Setters() > Student SSN, name, Address, DOB Getters() Setters()

DM: Data Access Layer - 4 Data Type classes are mapped to relations (tables) in relational database. 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) 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). 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) 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 > StudentInfo ssn Name Address DOB majorID > MajorInfo Id Name Host college Database Model > SectionInfo sectionNo location courseID Instructor > CourseInfo CourseID Title Credits > FacultyInfo ssn Name Office department > DeptInfo deptID Name mainOffice > RegisterInfo StudentSSN SectionNo grade Note: Arrows show foreign keys.

DM: Data Access Layer - 6 > StudentInfo ssn: char(9); name: varchar(20) address: DOB: char(8); majorID: int 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 StudentSSN SectionNo grade RDBMS

DM: Data Access Layer - 8 StudentDAL > Student > StudentInfo > RegisterInfo RDBMS Web Server: Node > JDBC DB Server: Node > JDBC MajorDAL > Major > MajorInfo Intranet … … A Look Ahead to deployment

DM: Presentation layer Three diagrams are defined for each business package: Three diagrams are defined for each business package: traces each XyzView back to the boundary classes Boundary traceability (Mapping): traces each XyzView back to the boundary classes Each screen (and its included input forms) is mapped to a XyzView class Each screen (and its included input forms) is mapped to a XyzView class trace dispatcher classes back to dispatcher classes in analysis model Control traceability (mapping): trace dispatcher classes back to dispatcher classes in analysis model Each dispatcher class in analysis model is mapped to a dispatcher Each dispatcher class in analysis model is mapped to a dispatcher a class diagram showing the relationship between classes in the presentation layer (including XyzView classes and dispatchers) 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 Show the relationship between View classes and dispatchers

Mediator Design Purpose Design Purpose Avoid references between dependent objects. Avoid references between dependent objects. Design Pattern Summary Design Pattern Summary Capture mutual behavior in a separate class. Capture mutual behavior in a separate class.

Mediator - Model MediatorColleague ConcreteMediator Colleague_BColleague_A

Mediator Sequence Diagram ClientA:Colleague_ A :Mediator B: Colleague_B request() takeAction_1() mediate() :MediatorC: Colleague_A takeAction_2() takeAction_3()

DM: Business layer The entity manager of each business package is mapped to a subsystem. The entity manager of each business package is mapped to a subsystem. A subsystem is an instance of a package 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 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. 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. To start, define one class that implements all the operations specified in the interface.

AM: Relationship between classes SectionInfo CourseInfo ClassroomInfo dispatcher Presentation Layer Business Package i Business Layer Data Access Layer Course Section Classroom CourseDAL CroomDAL SectionDAL Entity Manager Subsystem

DM: Identify class operations - 1 For Boundary classes (View classes/Web pages): For Boundary classes (View classes/Web pages): Attributes of a screen are mapped to text display Attributes of a screen are mapped to text display An input form is mapped to an HTML form An input form is mapped to an HTML form Attributes of an input form are input fields of the 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 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. 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. 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 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) 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. 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. 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: Each operation identified should be documented with: name of the operation name of the operation A brief description of the operation’s function A brief description of the operation’s function In and out parameters In and out parameters Return value Return value Define the skeleton of the operation’s body as feasible. Define the skeleton of the operation’s body as feasible. Follow the javadoc, cppdoc, and phpdoc format or a standard. Follow the javadoc, cppdoc, and phpdoc format or a standard.

DM: Summary For each business package For each business package Each boundary class is mapped to a Web page Each boundary class is mapped to a Web page The entity manager is mapped to the entity manager subsystem The entity manager is mapped to the entity manager subsystem Each dispatcher is mapped to a subclass of HTTPServlet Each dispatcher is mapped to a subclass of HTTPServlet Each entity class is mapped to Each entity class is mapped to A DAL class A DAL class A wrapper class (Java Bean) A wrapper class (Java Bean) A data type class (DB table) A data type class (DB table) Identify operations Identify operations Each operation of a boundary class from the user experience model is mapped to a web link, or an html submit input 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 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. 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