530 likes | 637 Views
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.
E N D
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: • Presentation layer • Business layer • Data access layer • 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 • 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 Use case realizations Business package i Presentation Business Data access Wrappers Data Access Data Types
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
StudentDAL create() findStudent(id) findStudents(major) Update() Delete() StudentInfo ssn Name Address DOB MajorInfo Id Name Host college DM: Data Access Layer - 3 <Wrapper>> Student SSN, name, Address, DOB Getters() Setters() Data Access Layer and Wrapper classes <Wrapper>> Major Id, Name, hostCollege Getters() Setters() MajorDAL create() findMajor(id) Update() Delete() Data Type Classes 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)
<<table>> RegisterInfo StudentSSN SectionNo grade DM: Data Access Layer - 5 Database Model Note: Arrows show foreign keys. <<table>> MajorInfo Id Name Host college <<table>> StudentInfo ssn Name Address DOB majorID <<table>> CourseInfo CourseID Title Credits <<table>> SectionInfo sectionNo location courseID Instructor <<table>> FacultyInfo ssn Name Office department <<table>> DeptInfo deptID Name mainOffice
<<table>> RegisterInfo StudentSSN SectionNo grade <<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) 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>; <<table>> StudentInfo ssn: char(9); name: varchar(20) address: DOB: char(8); majorID: int RDBMS
DM: Data Access Layer - 8 A Look Ahead to deployment Web Server: Node DB Server: Node <<Wrapper>> Major … RDBMS <<table>> RegisterInfo Intranet MajorDAL <<driver>> JDBC <<driver>> JDBC <<table>> StudentInfo StudentDAL <<table>> MajorInfo <<Wrapper>> Student …
DM: Presentation layer • Three diagrams are defined for each business package: • Boundary traceability (Mapping): traces each XyzView back to the boundary classes • Each screen (and its included input forms) is mapped to a XyzView class • Control traceability (mapping): trace dispatcher classes back to dispatcher classes in analysis model • 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 Colleague Mediator Colleague_A Colleague_B ConcreteMediator
Mediator Sequence Diagram B: Colleague_B Client :Mediator :Mediator A:Colleague_A C: Colleague_A request() mediate() takeAction_1() takeAction_2() takeAction_3()
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 CourseInfo dispatcher Entity Manager Subsystem Section SectionDAL dispatcher SectionInfo Classroom ClassroomInfo CroomDAL dispatcher Business Layer Data Access Layer Presentation Layer
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
XML Schema designer in Microsoft Visual Studio .NET, with the definition of a strongly typed DataSet. Figure 6-5
Database model Figure 6-6
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
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