Downloaded 40 times
4a domain model
- 1.
- 2. Tiếp cận xâydựng lược đồ lớp phân tích Hai tiếp cận chính để xây dựng lược đồ lớp: Domain Model: iterative ‘traditional’ approach: Xây dựng lược đồ lớp từ tri thức về miền ứng dụng 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 Use-case analysis: Use case driven approach Identify boundary, control, entity classes needed for each use case Consolidate into analysis model for application as a whole
- 3. Domain Model (Môhình miền) 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. Hoạt động phân tích hướng đối tượng cổ điển. Mô hình lớp phân tích độc lập với các use case cụ thể 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.
- 4. UML Class DiagramLà mô hình chính để phân tích yêu cầu 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. Class Diagram UsageWhen modeling the static view of a system, class diagrams are typically used in one of three ways, to model: The vocabulary of a system Collaborations A logical database schema
- 6. Review: Class Aclass is a description of a set of objects that share the same attributes, operations, relationships, and semantics. An object is an instance of a class. A class is an abstraction in that it Emphasizes relevant characteristics. Suppresses other characteristics.
- 7. Representing Classes andObjects 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. Review: What Isan Attribute? An attribute is a named property of a class that describes the range of values that instances of the property may hold. A class may have any number of attributes or no attributes at all. Attributes Student - name - address - studentID - dateOfBirth
- 9. Attributes in Classesand 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. What Is anOperation? Ứng xử chung chia sẻ cho tất cả các đối tượng của lớp Dịch vụ mà các đối tượng có thể cung cấp cho đối tượng khác Hành động mà một đối tượng có thể thực hiện: Đọc hay ghi các giá trị thuộc tính Thực hiện các tính toán Gởi messages tới đối tượng khác Tạo hoặc hủy các liên kết với đối tượng khác Student + get tuition() + add schedule() + get schedule() + delete schedule() + has prerequisites()
- 11. What Is anAssociation? The semantic relationship between two or more classifiers that specifies connections among their instances A structural relationship, specifying that objects of one thing are connected to objects of another Course require Course CourseOffering has
- 12. Link - kếtnối giữa các đối tượng Là một thể hiện của một association giữa các lớp. 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 Kết nối nhằm tạo dễ dàng cho việc truyền message net1_05:CourseOffering net2_05:CourseOffering dat_05:CourseOffering Network Basic:Course Database:Course
- 13. What Are Roles?The “face” that a class plays in the association Department Professor departmenthead CourseOffering instructor Course preRequisites Role name
- 14. Multiplicity Multiplicity isthe number of instances one class relates to one instance of another class. Thể hiện các qui định nghiệp vụ (business rule). For each association, there are two multiplicity decisions to make, one for each end of the association. For example: For each instance of Professor, many Course Offerings may be taught. For each instance of Course Offering, there may be either one or zero Professor as the instructor. Professor CourseOffering 0..1 0..* instructor
- 15. Multiplicity Indicators 2..40..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. What Does MultiplicityMean? Multiplicity answers two questions: Is the association mandatory or optional? What is the minimum and maximum number of instances that can be linked to one instance? CourseOffering <<entity>> Course <<entity>> 1 0..* 1 0..* 0..3 0..* preRequisites 0..3 0..*
- 17. Example: Multiplicity RegisterForCoursesFormCourseOffering Schedule 0..4 0..* Student 0..* 1 RegistrationController 1 1 1 1 0..1 0..1 0..1
- 18. Example: Multiple AssociationsMultiple associations must reflect multiple roles. CourseOffering Schedule 0..* 0..2 alternateCourses primaryCourses 0..* 0..4 CourseOffering Schedule add student to remove student from
- 19. Navigability Possible tonavigate 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). Associations are bi-directional by default – suppress arrows. Arrows only drawn for associations with one-way navigability. 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. Association Class Aclass “attached” to an association Contains properties of the relationship One instance per link 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. Schedule CourseOffering 0..4 0..* 0..* 0..4 primaryCourses PrimaryScheduleOfferingInfo - grade
- 21. Domain Modeling Pháthiện lớp miền
- 22. Phát hiện lớpmiền (Key Abstraction) Từ các danh từ trong phát biểu bài toán T ài liệu yêu cầu phải đầy đủ và đúng. Là một phát biểu có mục đích Miêu tả cho một tập các đối tượng (nhiều hơn 1) Không xét các lớp chỉ có một thể hiện (Singleton) Sở hữu một tập các thuộc tính Thuộc tính định danh: chỉ xem xét nếu có ý nghĩa thực tế. Sở hữu một tập các phép toán Phép toán có thể nhận diện sau
- 23. Kiểm tra tínhhợp lý của các lớp ứng viên Nó có nằm ngoài phạm vi của hệ thống không? Nó có ám chỉ tới toàn bộ hệ thống không? Nó có lập lại một lớp khác không? Nó có quá mơ hồ không? Nó có buộc quá chặt với inputs và outputs vật lý không? Nó có là một thuộc tính hay không? Nó có là một mối kết hợp hay không? Nếu câu trả lời là "Yes", Mô hình lớp theo một cách khác hoặc loại bỏ lớp đó
- 24. Nhận diện quanhệ 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 Tránh các chu trình trong quan hệ có thể có ý nghĩa giống nhau Schedule Student 0..* 1 CourseOffering 0..4 0..* primaryCourses 0..* 0..* register
- 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. Analysis Patterns: Definition“ A pattern is an idea that... has been useful in one practical context... and will probably be useful in others” “ Analysis patterns… are groups of concepts… that represent a common construction in business modelling... may be relevant to only one domain, or may span many domains” (Fowler, 1997)
- 27. Transaction-TransactionLineItem PatternThis is Coad’s pattern Very common in business documents Always look for the suggested attributes and operations - e.g. calcForMe for line items Transaction number date calcOverLineItems() TransactionLine number calcForMe() 1..* 1 1 1..*
- 28. Examples Order ExampleBank 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. The Abstraction-Occurrence Pattern Context: Often in a domain model you find a set of related objects ( occurrences). The members of such a set share common information but also differ from each other in important ways. Problem: What is the best way to represent such sets of occurrences in a class diagram? Forces: You want to represent the members of each set of occurrences without duplicating the common information
- 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. Abstraction-Occurrence ExamplesCourseOffering offeringCode schedule proffesorName Course courseId name credite 1 0..* 1 0..* Tour tourId description days price TourOffer beginDate * 1 1 *
- 32.
- 33. The Player-Role Pattern Context: A role is a particular set of properties associated with an object in a particular context. An object may play different roles in different contexts. Problem: How do you best model players and roles so that a player can change roles or possess multiple roles?
- 34. Player-Role Forces: It is desirable to improve encapsulation by capturing the information associated with each separate role in a class . You want to avoid multiple inheritance. You cannot allow an instance to change class Solution:
- 35.
- 36. Organisation Hierarchies PatternsAnother application for patterns Consider an organisation that is divided into Operating Units... which are divided into regions... which are divided into divisions... which are divided into sales offices… Draw a class diagram to represent this
- 37. First Solution Thisdescribes the reality but is difficult to modify Removal of a region would force a significant change to the model A more flexible structure can be based on a reflexive (self) association Operating Unit Region Division Sales Office
- 38. Single Reflexive HierarchyThis model has further weaknesses As it stands, it would permit a division to be part of a sales office This could be overcome by introducing constraints at subclass level OperatingUnit Region Division SalesOffice Organisation 1 parent subsidiary *
- 39. Modified Single ReflexiveHierarchy 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. Two Hierarchies Nowimagine each sales office has a “Product Service Team” Product Service Teams report to both: their sales office, and their product division I.e. there are two separate hierarchies Organisation * 1 sales parent sales subsidiary 1 product parent product subsidiary *
- 41. Two Hierarchies Againthis works, but further constraints would need to be modeled The practical limit of modelling is two hierarchies More, and the structure becomes totally unwieldy The next model provides greater flexibility
- 42. OperatingUnit Region DivisionSalesOffice Organisation OrganisationStructure OrganisationStructureType TimePeriod Rule 1 Constrains 1 ExampleOf 1 AppliesTo 1 ParentOf 1 SubsidiaryOf * * * * *
- 43. Multiple Hierarchies Thispattern is now truly generic The class Organisation Structure Type permits an arbitrary number of hierarchies The class Rule accommodates any necessary constraints The class Time Period allows a structure to be valid for a defined period of time
Editor's Notes
- #5 A class diagram shows the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system. Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information. The static view of a system primarily supports the functional requirements of a system. Introduce class diagrams to the students. Interaction diagrams show the dynamic aspects of a system, while class diagrams show the static aspects of a system.
- #6 Class diagrams allow you to model the vocabulary of your system when you determine the abstractions that are part of, or outside of, the boundaries of your system. Class diagrams specify these abstractions and their responsibilities. A collaboration is a grouping of classes and other elements that work together to provide a solution that is bigger than the sum of the elements in the collaboration. No class stands alone, but works in collaboration with other elements to carry out some sort of solution. Class diagrams are one way to model these collaborations. A database schema is similar to the blueprints for the conceptual design of a database. Many of the systems that you’ll design have persistent objects, which means that they have to be stored in a database for later retrieval. You can model schemas for these databases using class diagrams. The UML’s class diagrams are a superset of entity-relationship (E-R) diagrams. However, where typical E-R diagrams focus only on data, class diagrams take it one step further and allow the modeling of behavior, too. Behavior, modeled as operations, are generally turned into triggers or stored procedures on the database. Set the context for this module and present some reasons for using class diagrams. Class diagrams are not entity-relationship diagrams. They go one step further with behavior. The database schema may not always match 1:1 with the class diagram, but they should be fairly close.
- #7 A Class can be defined as: A description of a set of objects that share the same attributes, operations, relationships, and semantics. ( The Unified Modeling Language User Guide , Booch, 1999.) There are many objects identified for any domain. Recognizing the commonalties among the objects and defining classes helps us deal with the potential complexity. The OO principle abstraction helps us deal with complexity. The UML notation for a class permits you to see an abstraction apart from any specific programming language, which lets you emphasize the most important parts about an abstraction – its name, attributes, and operations. Graphically, a class is represented by a rectangle. The UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol. Explain what a class is to the students. Remember, many of your students are not familiar with this term. The course introduces objects before classes because objects are the things that actually do most of the work. Classes are the templates for the objects.
- #8 The UML notation for a class permits you to see an abstraction apart from any specific programming language, which lets you emphasize the most important parts about an abstraction – its name, attributes, and operations. Graphically, a class is represented by a rectangle. The UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol. An object is represented with a rectangle and the name of the class. The name of the object is always underlined. To name an object, place its name before the colon. An object can be either named or anonymous. To remain anonymous, do not include a name. Demonstrate how a class is modeled in UML. Tell them that the UML represents public visibility with a plus (+) symbol and private visibility with a minus (-) symbol. Do not discuss protected visibility.
- #9 An Attribute can be defined as: A named property of a class that describes the range of values that instances of the property may hold. ( The Unified Modeling Language User Guide , Booch, 1999.) A class may have any number of attributes or no attributes at all. At any time, an object of a class has specific values for every one of its class’s attributes. An attribute defined by a class represents a named property of the class or its objects. An attribute defines the type of its instances. An attribute has a type , which tells us what kind of attribute it is. Typical attributes are integer, Boolean, real, and enumeration. These are called primitive types. An attribute does not need to be a primitive type though. Define the term attribute for the students. Remember, there are still operations in this class, but choose to suppress them.
- #10 At the class level, the Student class attributes indicate that the Students have names, addresses, studentIDs, and a date of birth. At the object level, the attributes indicate the values for the name, address, studentID, and date of birth. Only the class instance (objects) should be able to change the value of the attributes. The state of an object is defined by the value of its attributes and the existence of links to other objects. Show that an attribute is defined on a class and instantiated on an object.
- #11 An Operation can be defined as: A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible. The operations in a class describe what the class can do. An operation can either be a command or a question. A question should never change the state of the object. Only a command can change the state of the object. An operation is described with a return-type, name, and zero or more parameters. Together, the return-type, name, and parameters are called the signature of the operation. The outcome of the operation depends on the current state of the object. Often, but not always, invoking an operation on an object changes the object’s data or state. Define the term operation for the students. Point out that these should be called operations. Many people use the term methods instead of operations. In the UML, methods and operations are NOT synonymous and have distinct definitions. An operation is simply the advertisement of a service that is offered by a class. A method is the actual code that realizes that operation.
- #12 Associations represent structural relationships between objects of different classes; they connect instances of two or more classes together for some duration. You can use associations to show that objects know about other objects. Sometimes, objects must hold references to each other to be able to interact; for example, to send messages to each other. Thus, in some cases, associations may follow from interaction patterns in Sequence diagrams or Collaboration diagrams. Most associations are simple (exist between exactly two classes), and are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible. Sometimes a class has an association to itself. This does not necessarily mean that an instance of that class has an association to itself; more often, it means that one instance of the class has associations to other instances of the same class. An association may have a name that is placed on, or adjacent to the association path. The name of the association should reflect the purpose of the relationship and be a verb phrase. The name of an association can be omitted, particularly if role names are used. Avoid names like &quot;has&quot; and &quot;contains,&quot; as they add no information about what the relationships are between the classes. Introduce the concept of association to the students. This is new and may pose trouble for some students. There are also dependency relationships. However, dependencies are beyond the scope of this course since they are contingent on parameter, local variable or global reference. These topics are discussed in the Object-Oriented Analysis and Design course. For the beginner, understanding associations is enough. Draw these examples on the board as objects to help students understand the concept.
- #14 Each end of an association has a role in relationship to the class on the other end of the association. The role specifies the face that a class presents on each side of the association. A role must have a name, and the role names on opposite sides of the association must be unique. The role name should be a noun indicating the associated object's role in relation to the associating object. The use of association names and role names is mutually exclusive: one would not use both an association name and a role name. For each association, decide which conveys more information. The role name is placed next to the end of the association line of the class it describes. In the case of self-associations, role names are essential to distinguish the purpose for the association. In the above example, the Professor participates in two separate association relationships, playing a different role in each.
- #15 Multiplicity can be defined as: The number of instances one class relates to one instance of another class. For each role, you can specify the multiplicity of its class and how many objects of the class can be associated with one object of the other class. Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges. It is important to remember that multiplicity is referring to instances of classes (objects) and their relationships. In this example, a Course Offering object may have either zero or one Professor object related to it. Conversely, a Professor object may have zero or more Course Offering objects related to it. Multiplicity must be defined on both ends of the association. Introduce the concept of multiplicity.
- #16 For each role you can specify the multiplicity of its class. Multiplicity is the number of objects of the class that can be associated with one object of the other class. Multiplicity is indicated by a text expression on the association line. The expression is a comma-separated list of integer ranges. A range is indicated by an integer (the lower value), two dots, and an integer (the upper value). A single integer is a valid range. You may also specify narrower limits such as 2..4. During Analysis, assume a multiplicity of 0..* (zero to many) unless there is some clear evidence of something else. A multiplicity of zero implies that the association is optional. When you use this notation, make sure this is what you mean. If an object might not be there, operations that use the association will have to adjust accordingly. Within multiplicity ranges, probabilities may be specified. Thus, if the multiplicity is 0..*, and is expected to be between 10 and 20 in 85% of the cases, make note of it. This information will be of great importance during Design. For example, if persistent storage is to be implemented using a relational database, narrower limits will help better organize the database tables. Show the valid multiplicity indicators. The use of “N” instead of “*” is Booch, not UML (for example, the use of “0..N” and “N” is not UML). The multiplicity specified for a relationship is for all instances of that relationship, not simply for a particular use-case realization or for a particular point in time.
- #17 Multiplicity lets you know the lower and the upper bound number of relationships that a given object can have with another object. Many times you do not know what the maximum number of instances may be, and you will use the “*” to specify that this number is unknown. The most important question that multiplicity answers: Is the association is mandatory? A lower bound number that is greater than zero indicates that the relationship is mandatory. This example indicates that a course object can be related to zero or more course offerings. You can tell that the relationship is optional because the lower bound number is zero. The upper bound number of the relationship is unknown, as indicated by the “*”. If you read the association the other way, you will see that a given course offering object can be related to only one course. This relationship is mandatory and indicates that it is not possible for a course offering object to exist without an associated course object.
- #18 Describe the following relationships between: RegisterForCoursesForm and RegistrationController; Schedule to CourseOffering; and CourseOffering to Schedule . What is the lower and upper bounds for these relationships? Which relationships are mandatory? What do the mandatory relationships tell you about the different classes? How many course offerings can appear on a Schedule ? How many students are assigned to each Schedule ? Can a Schedule exist without a student? How many schedules can be open on a RegisterForCoursesForm ? Provide the students with an opportunity to see how multiplicity can be interpreted from a class diagram. Here are the answers to the student notes questions. 1. There is an association relationship between each of the classes. RegisterForCoursesForm to RegistrationController has a lower and upper bound of 1. Schedule to CourseOffering is 0 (low) to 4 (high). CourseOffering to Schedule is 0 (low) to many (high). 2. A RegisterForCoursesForm instance is mandatory because it must be associated with exactly one instance of RegistrationController . 3. Zero to four. 4. One. 5. No, a schedule must be associated to one student. 6. For each RegisterForCoursesForm, there is one RegistrationController which has zero or one Schedule .
- #19 There can be multiple associations between the same two classes, but they should represent distinct relationships, and DIFFERENT ROLES; they should not be just for invoking different operations. If there is more than one association between two classes then they MUST be named. It is unusual to find more than one association between the same two classes. Occurrences of multiple associations should be carefully examined. To determine if multiple associations are appropriate, look at instances of the classes. ClassA and ClassB have two associations between them, Assoc1 and Assoc2. If an instance of ClassA has a link with two SEPARATE instances of ClassB, then multiple associations are valid. In the above example, the top diagram is an appropriate use of multiple associations, but the bottom diagram is not. In the valid case, two associations are required between Schedule and CourseOffering, as a Schedule can contain two kind of CourseOfferings, primary and alternate. These must be distinguishable, so two separate associations are used. In the invalid case, the two relationships represent two operations of CourseOffering, not two roles of CourseOffering. Remember, Students and CourseOfferings are related via the Schedule class. Students are enrolled in a CourseOffering if there is a relationship between the Student’s Schedule and the CourseOffering.
- #20 Navigability (at least a first pass) needs to be done in analysis, otherwise, the architectural dependencies are not properly validated. This navigation may be refined in design (specifically, Class Design). Note: Double headed arrows are also valid UML. Rose uses the straight line rather than the double arrows to model bi-directional associations. This means that you cannot distinguish between a bi-directional relationship and a relationship with non-specified navigability.