![Tiếp cận xây dựng lược đồ lớp phân tích ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a 4a domain model
Semelhante a 4a domain model (20)
Mais de Châu Thanh Chương
4a domain model
- 1. Domain Model
- 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
- 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”
- 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
- 17. Example: Multiplicity RegisterForCoursesForm CourseOffering Schedule 0..4 0..* Student 0..* 1 RegistrationController 1 1 1 1 0..1 0..1 0..1
- 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
- 21. Domain Modeling Phát hiện lớp miền
- 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
- 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..*
- 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 Examples CourseOffering offeringCode schedule proffesorName Course courseId name credite 1 0..* 1 0..* Tour tourId description days price TourOffer beginDate * 1 1 *
- 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
- 42. OperatingUnit Region Division SalesOffice Organisation OrganisationStructure OrganisationStructureType TimePeriod Rule 1 Constrains 1 ExampleOf 1 AppliesTo 1 ParentOf 1 SubsidiaryOf * * * * *
Notas do Editor
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 "has" and "contains," 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.
- 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.
- 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.
- 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.
- 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.
- 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 .
- 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.
- 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.