Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

4a domain model

2,129 views

Published on

Published in: Technology, Design
  • Login to see the comments

4a domain model

  1. 1. Domain Model
  2. 2. Tiếp cận xây dựng lược đồ lớp phân tích <ul><li>Hai tiếp cận chính để xây dựng lược đồ lớp: </li></ul><ul><li>Domain Model: iterative ‘traditional’ approach: </li></ul><ul><ul><li>Xây dựng lược đồ lớp từ tri thức về miền ứng dụng </li></ul></ul><ul><ul><li>Mô hình các khái niệm, sự vật quan trọng trong miền ứng dụng và quan hệ ràng buộc giữa chúng </li></ul></ul><ul><li>Use-case analysis: Use case driven approach </li></ul><ul><ul><li>Identify boundary, control, entity classes needed for each use case </li></ul></ul><ul><ul><li>Consolidate into analysis model for application as a whole </li></ul></ul>
  3. 3. Domain Model (Mô hình miền) <ul><li>Phân hoạch và mô tả các sự vật và các khái niệm quan trọng trong miền ứng dụng. </li></ul><ul><li>Hoạt động phân tích hướng đối tượng cổ điển. </li></ul><ul><li>Mô hình lớp phân tích độc lập với các use case cụ thể </li></ul><ul><ul><li>Không biểu diễn các đối tượng phần mềm mà là tự điển trực quan về các khái niệm quan trọng của miền. </li></ul></ul>
  4. 4. UML Class Diagram <ul><li>Là mô hình chính để phân tích yêu cầu </li></ul>CloseRegistrationForm + open() + close registration() Student + get tuition() + add schedule() + get schedule() + delete schedule() + has pre-requisites() Schedule - semester + commit() + select alternate() + remove offering() + level() + cancel() + get cost() + delete() + submit() + save() + any conflicts?() + create with offerings() + update with new selections() Professor - name - employeeID : UniqueId - hireDate - status - discipline - maxLoad + submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass() CloseRegistrationController + is registration open?() + close registration()
  5. 5. Class Diagram Usage <ul><li>When modeling the static view of a system, class diagrams are typically used in one of three ways, to model: </li></ul><ul><ul><li>The vocabulary of a system </li></ul></ul><ul><ul><li>Collaborations </li></ul></ul><ul><ul><li>A logical database schema </li></ul></ul>
  6. 6. Review: Class <ul><li>A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. </li></ul><ul><ul><li>An object is an instance of a class. </li></ul></ul><ul><li>A class is an abstraction in that it </li></ul><ul><ul><li>Emphasizes relevant characteristics. </li></ul></ul><ul><ul><li>Suppresses other characteristics. </li></ul></ul>
  7. 7. Representing Classes and Objects in the UML Professor - name - employeeID : UniqueId - hireDate - status - discipline - maxLoad + submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass() class name attributes operations Class J Clark : Professor : Professor Named Object Anonymous Object Object
  8. 8. Review: What Is an Attribute? <ul><li>An attribute is a named property of a class that describes the range of values that instances of the property may hold. </li></ul><ul><ul><li>A class may have any number of attributes or no attributes at all. </li></ul></ul>Attributes Student - name - address - studentID - dateOfBirth
  9. 9. Attributes in Classes and Objects Class Objects Student - name - address - studentID - dateOfBirth :Student - name = “M. Modano” - address = “123 Main St.” - studentID = 9 - dateOfBirth = “03/10/1967” :Student - name = “D. Hatcher” - address = “456 Oak Ln.” - studentID = 2 - dateOfBirth = “12/11/1969”
  10. 10. What Is an Operation? <ul><li>Ứng xử chung chia sẻ cho tất cả các đối tượng của lớp </li></ul><ul><ul><li>Dịch vụ mà các đối tượng có thể cung cấp cho đối tượng khác </li></ul></ul><ul><ul><li>Hành động mà một đối tượng có thể thực hiện: </li></ul></ul><ul><ul><ul><li>Đọc hay ghi các giá trị thuộc tính </li></ul></ul></ul><ul><ul><ul><li>Thực hiện các tính toán </li></ul></ul></ul><ul><ul><ul><li>Gởi messages tới đối tượng khác </li></ul></ul></ul><ul><ul><ul><li>Tạo hoặc hủy các liên kết với đối tượng khác </li></ul></ul></ul>Student + get tuition() + add schedule() + get schedule() + delete schedule() + has prerequisites()
  11. 11. What Is an Association? <ul><li>The semantic relationship between two or more classifiers that specifies connections among their instances </li></ul><ul><li>A structural relationship, specifying that objects of one thing are connected to objects of another </li></ul>Course require Course CourseOffering has
  12. 12. Link - kết nối giữa các đối tượng <ul><li>Là một thể hiện của một association giữa các lớp. </li></ul><ul><ul><li>Nếu 2 đối tượng có liên kết thì các lớp tương ứng của chúng sẽ có mối kết hợp </li></ul></ul><ul><li>Kết nối nhằm tạo dễ dàng cho việc truyền message </li></ul>net1_05:CourseOffering net2_05:CourseOffering dat_05:CourseOffering Network Basic:Course Database:Course
  13. 13. What Are Roles? <ul><li>The “face” that a class plays in the association </li></ul>Department Professor departmenthead CourseOffering instructor Course preRequisites Role name
  14. 14. Multiplicity <ul><li>Multiplicity is the number of instances one class relates to one instance of another class. </li></ul><ul><ul><li>Thể hiện các qui định nghiệp vụ (business rule). </li></ul></ul><ul><li>For each association, there are two multiplicity decisions to make, one for each end of the association. </li></ul><ul><li>For example: </li></ul><ul><ul><li>For each instance of Professor, many Course Offerings may be taught. </li></ul></ul><ul><ul><li>For each instance of Course Offering, there may be either one or zero Professor as the instructor. </li></ul></ul>Professor CourseOffering 0..1 0..* instructor
  15. 15. Multiplicity Indicators 2..4 0..1 1..* 0..* 1 * 2, 4..6 Unspecified Exactly One Zero or More Zero or More Zero or One ( optional value ) One or More Specified Range Multiple, Disjoint Ranges
  16. 16. What Does Multiplicity Mean? <ul><li>Multiplicity answers two questions: </li></ul><ul><ul><li>Is the association mandatory or optional? </li></ul></ul><ul><ul><li>What is the minimum and maximum number of instances that can be linked to one instance? </li></ul></ul>CourseOffering <<entity>> Course <<entity>> 1 0..* 1 0..* 0..3 0..* preRequisites 0..3 0..*
  17. 17. Example: Multiplicity RegisterForCoursesForm CourseOffering Schedule 0..4 0..* Student 0..* 1 RegistrationController 1 1 1 1 0..1 0..1 0..1
  18. 18. Example: Multiple Associations Multiple associations must reflect multiple roles. CourseOffering Schedule 0..* 0..2 alternateCourses primaryCourses 0..* 0..4 CourseOffering Schedule add student to remove student from
  19. 19. Navigability <ul><li>Possible to navigate from an associating class to the target class – indicated by arrow which is placed on the target end of the association line next to the target class (the one being navigated to). </li></ul><ul><ul><li>Associations are bi-directional by default – suppress arrows. </li></ul></ul><ul><ul><li>Arrows only drawn for associations with one-way navigability. </li></ul></ul>Navigability is inherently a design and implementation property. In analysis, associations are usually bi-directional; in design, we really check this. Bi-directional Class1 Class2 Uni-directional Class1 Class2
  20. 20. Association Class <ul><li>A class “attached” to an association </li></ul><ul><li>Contains properties of the relationship </li></ul><ul><li>One instance per link </li></ul><ul><li>Allows you to store information about the relationship itself, where the info is not appropriate (does not belong to) within the classes at either end of the relationship. </li></ul>Schedule CourseOffering 0..4 0..* 0..* 0..4 primaryCourses PrimaryScheduleOfferingInfo - grade
  21. 21. Domain Modeling Phát hiện lớp miền
  22. 22. Phát hiện lớp miền (Key Abstraction) <ul><li>Từ các danh từ trong phát biểu bài toán </li></ul><ul><ul><li>T ài liệu yêu cầu phải đầy đủ và đúng. </li></ul></ul><ul><li>Là một phát biểu có mục đích </li></ul><ul><li>Miêu tả cho một tập các đối tượng (nhiều hơn 1) </li></ul><ul><ul><li>Không xét các lớp chỉ có một thể hiện (Singleton) </li></ul></ul><ul><li>Sở hữu một tập các thuộc tính </li></ul><ul><ul><li>Thuộc tính định danh: chỉ xem xét nếu có ý nghĩa thực tế. </li></ul></ul><ul><li>Sở hữu một tập các phép toán </li></ul><ul><ul><li>Phép toán có thể nhận diện sau </li></ul></ul>
  23. 23. Kiểm tra tính hợp lý của các lớp ứng viên <ul><li>Nó có nằm ngoài phạm vi của hệ thống không? </li></ul><ul><li>Nó có ám chỉ tới toàn bộ hệ thống không? </li></ul><ul><li>Nó có lập lại một lớp khác không? </li></ul><ul><li>Nó có quá mơ hồ không? </li></ul><ul><li>Nó có buộc quá chặt với inputs và outputs vật lý không? </li></ul><ul><li>Nó có là một thuộc tính hay không? </li></ul><ul><li>Nó có là một mối kết hợp hay không? </li></ul><ul><li>Nếu câu trả lời là &quot;Yes&quot;, </li></ul><ul><ul><li>Mô hình lớp theo một cách khác hoặc loại bỏ lớp đó </li></ul></ul>
  24. 24. Nhận diện quan hệ <ul><li>Từ các động từ biểu diễn các quy định nghiệp vụ (business rules) trong phát biểu bài toán </li></ul><ul><li>Tránh các chu trình trong quan hệ </li></ul><ul><ul><li>có thể có ý nghĩa giống nhau </li></ul></ul>Schedule Student 0..* 1 CourseOffering 0..4 0..* primaryCourses 0..* 0..* register
  25. 25. Ví dụ: Hệ thống đăng ký học phần Course - credits - name - curriculum - description - number 0..n 0..n preRequisites 0..n 0..n Professor - professorId - name CourseOffering - number - startTime - endTime - days /- numStudents Schedule - semester 0..n 0..2 0..n alternateCourses 0..2 Student - name - address - studentID 0..n 0..4 0..n primaryCourses 0..4 PrimaryScheduleOfferingInfob - grade 0..n 1 0..n 1 offer 0..1 0..n instructor 0..1 0..n teach 0..n 1 0..n 1 has
  26. 26. Analysis Patterns: Definition <ul><li>“ A pattern is an idea that... </li></ul><ul><ul><li>has been useful in one practical context... </li></ul></ul><ul><ul><li>and will probably be useful in others” </li></ul></ul><ul><li>“ Analysis patterns… </li></ul><ul><ul><li>are groups of concepts… </li></ul></ul><ul><ul><li>that represent a common construction in business modelling... </li></ul></ul><ul><ul><li>may be relevant to only one domain, or may span many domains” </li></ul></ul><ul><li>(Fowler, 1997) </li></ul>
  27. 27. Transaction-TransactionLineItem Pattern <ul><li>This is Coad’s pattern </li></ul><ul><li>Very common in business documents </li></ul><ul><li>Always look for the suggested attributes and operations - e.g. calcForMe for line items </li></ul>Transaction number date calcOverLineItems() TransactionLine number calcForMe() 1..* 1 1 1..*
  28. 28. Examples Order Example Bank Account Statement Example Order orderNumber accountNumber customerName orderDate calcGoodsValue() calcDeliveryCharge() calcVAT() calcAmountDue() OrderLine catalogueCode quantityDespatched itemDescription unitPrice VATCode calcLineTotal() 1..* 1 1 1..* AccountStatement branchNumber accountNumber customerName statementDate calcTotalWithdrawn() calcTotalPaidIn() calcBalanceCF() StatementLine transactionDate itemDetails itemAmount calcCurrentBalance() 1..* 1 1 1..*
  29. 29. The Abstraction-Occurrence Pattern <ul><li>Context: </li></ul><ul><ul><li>Often in a domain model you find a set of related objects ( occurrences). </li></ul></ul><ul><ul><li>The members of such a set share common information </li></ul></ul><ul><ul><ul><li>but also differ from each other in important ways. </li></ul></ul></ul><ul><li>Problem: </li></ul><ul><ul><li>What is the best way to represent such sets of occurrences in a class diagram? </li></ul></ul><ul><li>  Forces: </li></ul><ul><ul><li>You want to represent the members of each set of occurrences without duplicating the common information </li></ul></ul>
  30. 30. Abstraction-Occurrence Solution: Examples Abstraction Occurrence * 1 * 1 Title name author isbn publisher publicationDate LibraryItem barCodeNumber * 1 1 * Video title actorName Copy barCodeNumber dateOfPurchase * 1 1 *
  31. 31. Abstraction-Occurrence Examples CourseOffering offeringCode schedule proffesorName Course courseId name credite 1 0..* 1 0..* Tour tourId description days price TourOffer beginDate * 1 1 *
  32. 32. Abstraction-Occurrence <ul><li>Antipatterns : </li></ul>
  33. 33. The Player-Role Pattern <ul><li>Context: </li></ul><ul><ul><li>A role is a particular set of properties associated with an object in a particular context. </li></ul></ul><ul><ul><li>An object may play different roles in different contexts. </li></ul></ul><ul><li>Problem: </li></ul><ul><ul><li>How do you best model players and roles so that a player can change roles or possess multiple roles? </li></ul></ul>
  34. 34. Player-Role <ul><li>Forces: </li></ul><ul><ul><li>It is desirable to improve encapsulation by capturing the information associated with each separate role in a class . </li></ul></ul><ul><ul><li>You want to avoid multiple inheritance. </li></ul></ul><ul><ul><li>You cannot allow an instance to change class </li></ul></ul><ul><li>Solution: </li></ul>
  35. 35. Example Player-Role
  36. 36. Organisation Hierarchies Patterns <ul><li>Another application for patterns </li></ul><ul><li>Consider an organisation that is divided into </li></ul><ul><ul><li>Operating Units... </li></ul></ul><ul><ul><li>which are divided into regions... </li></ul></ul><ul><ul><li>which are divided into divisions... </li></ul></ul><ul><ul><li>which are divided into sales offices… </li></ul></ul><ul><li>Draw a class diagram to represent this </li></ul>
  37. 37. First Solution <ul><li>This describes the reality but is difficult to modify </li></ul><ul><li>Removal of a region would force a significant change to the model </li></ul><ul><li>A more flexible structure can be based on a reflexive (self) association </li></ul>Operating Unit Region Division Sales Office
  38. 38. Single Reflexive Hierarchy <ul><li>This model has further weaknesses </li></ul><ul><li>As it stands, it would permit a division to be part of a sales office </li></ul><ul><li>This could be overcome by introducing constraints at subclass level </li></ul>OperatingUnit Region Division SalesOffice Organisation 1 parent subsidiary *
  39. 39. Modified Single Reflexive Hierarchy UML’s Object Constraint Language (OCL) expresses constraints like these more formally. E.g: {self.parent.oclType=division} {parent must be a division} {parent must be an operating unit} {parent must be a region} UML Constraints * OperatingUnit Region Division SalesOffice Organisation 1 parent subsidiary
  40. 40. Two Hierarchies <ul><li>Now imagine each sales office has a “Product Service Team” </li></ul><ul><li>Product Service Teams report to both: </li></ul><ul><ul><li>their sales office, and </li></ul></ul><ul><ul><li>their product division </li></ul></ul><ul><li>I.e. there are two separate hierarchies </li></ul>Organisation * 1 sales parent sales subsidiary 1 product parent product subsidiary *
  41. 41. Two Hierarchies <ul><li>Again this works, but further constraints would need to be modeled </li></ul><ul><li>The practical limit of modelling is two hierarchies </li></ul><ul><li>More, and the structure becomes totally unwieldy </li></ul><ul><li>The next model provides greater flexibility </li></ul>
  42. 42. OperatingUnit Region Division SalesOffice Organisation OrganisationStructure OrganisationStructureType TimePeriod Rule 1 Constrains 1 ExampleOf 1 AppliesTo 1 ParentOf 1 SubsidiaryOf * * * * *
  43. 43. Multiple Hierarchies <ul><li>This pattern is now truly generic </li></ul><ul><li>The class Organisation Structure Type permits an arbitrary number of hierarchies </li></ul><ul><li>The class Rule accommodates any necessary constraints </li></ul><ul><li>The class Time Period allows a structure to be valid for a defined period of time </li></ul>

×