1 / 53

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.

cyrus-ramos
Télécharger la présentation

Chapter 6 Design Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 6Design Model

  2. 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.

  3. 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

  4. 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.

  5. Design model structure Figure 6-2

  6. DM: Model structure Use case realizations Business package i Presentation Business Data access Wrappers Data Access Data Types

  7. 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.

  8. 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

  9. 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

  10. 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)

  11. <<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

  12. <<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

  13. 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 …

  14. 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

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

  16. Mediator - Model Colleague Mediator Colleague_A Colleague_B ConcreteMediator

  17. Mediator Sequence Diagram B: Colleague_B Client :Mediator :Mediator A:Colleague_A C: Colleague_A request() mediate() takeAction_1() takeAction_2() takeAction_3()

  18. 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.

  19. 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

  20. 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.

  21. 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.

  22. 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.

  23. 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.

  24. Managed entities Figure 6-3

  25. Data Access classes for User Account Management Figure 6-4

  26. XML Schema designer in Microsoft Visual Studio .NET, with the definition of a strongly typed DataSet. Figure 6-5

  27. Database model Figure 6-6

  28. Tracing Data Access classes to analysis classes Figure 6-7

  29. Structure detail of the Data Access Layer package Figure 6-8

  30. Structure detail of the Presentation Layer package Figure 6-9

  31. Equivalence of structures between design model and analysis model Figure 6-10

  32. Tracing dispatcher classes to analysis classes Figure 6-11

  33. Tracing Web forms/controls to analysis classes Figure 6-12

  34. Participants in the presentation layer of User Account Management Figure 6-13

  35. Structure detail of the Business Layer package Figure 6-14

  36. Enterprise component interface with associated Data Layer classes Figure 6-15

  37. Tracing enterprise component interface to analysis classes Figure 6-16

  38. Realization of the enterprise component interface Figure 6-17

  39. Class diagram for the enterprise component implementation Figure 6-18

  40. Structure detail of the Use Case Realizations package Figure 6-19

  41. Tracing use case realizations from design to analysis Figure 6-20

  42. Figure 6-22

  43. Sequence diagram for the basic flow of Create Account use case Figure 6-23

  44. Structure detail of the Common package Figure 6-24

  45. Collaboration detail: CreateAccount_Entry validation Figure 6-25

  46. Collaboration detail: Create Account Figure 6-26

  47. Collaboration detail: Adding User to Group Figure 6-27

  48. Role-based security handling: Participants Figure 6-28

  49. Activity graph: submitSignIn in SignInDispatcher class Figure 6-29

  50. Sequence diagram: Set Session Authentication on Sign-In Figure 6-30

More Related