1. Feb 4, 200291.3913 Ron McFadyen1 Design Class Diagrams n Class diagram with – classes – associations – attributes – methods – navigability – (interfaces, attribute types, dependencies too) n we are designing software classes now - no longer conceptual

2. Feb 4, 200291.3913 Ron McFadyen2 analysis design Figure 19.2

3. Feb 4, 200291.3913 Ron McFadyen3 An interaction diagram showing a register sending a makeLineItem message to a sale, implies that the Sale software class must have a makeLineItem method Messages imply Methods (figure 19.4)

4. Feb 4, 200291.3913 Ron McFadyen4 Note that a register creates a sale Navigability

5. Feb 4, 200291.3913 Ron McFadyen5 Figure 19.8 The navigability arrow (also called a navigability adornment) indicates that a Register object is connected uni-directionally to Sale objects … the Register class has an attribute, currentSale, pointing to a Sale object Do we have any interaction diagrams showing a message from a Sale object to a Register object?

6. Feb 4, 200291.3913 Ron McFadyen6 Navigability: in the UML, an association line that has no specific navigation indicated, is considered to be bidirectional. The directed arrow is unidirectional, and shows navigability. The above shows that a register object can navigate to a sale object: I.e. a register needs to know the sale object, but not the other way around. Register can send a message to a sale. In an OO language, Register will have an attribute that references a Sale instance

7. Feb 4, 200291.3913 Ron McFadyen7 In Figure 19.10, we see the result from analyzing all interaction diagrams for navigability.

8. Feb 4, 200291.3913 Ron McFadyen8 In Figure 19.11, we see additional dependencies shown … the dashed arrow line … register and sale have visibility to ProductSpecifications … register knows of a product due to the lookup in the catalogue and a sale receives a product specification in the makeLineItem message

9. Feb 4, 200291.3913 Ron McFadyen9 Dependency relationships Note that a register learns of a ProductSpecification object. It passes that object to the sale.

10. Feb 4, 200291.3913 Ron McFadyen10 A dependency is shown with a dashed directed line: a register has knowledge of a ProductSpecification. The register receives a ProductSpecification object from the ProductCatalog when it “looks in” the catalog for a specific item. The register is not sending a message to the ProductSpecification object; it is just aware of its existence. Dependency relationships Figure 19.11

11. Feb 4, 200291.3913 Ron McFadyen11 Figure 20.6 MultiObjects

12. Feb 4, 200291.3913 Ron McFadyen12 A register needs to learn of the specification for a particular product. ProductCatalog is the container for ProductSpecifications. What methods result from this? MultiObjects

13. Feb 4, 200291.3913 Ron McFadyen13 In the Register Class (P. 314): ProductSpecification spec = catalog.getSpecification( id ); sale.makeLineItem( spec, quantity ); MultiObjects In the ProductCatalog Class (P. 313): private Map ProductSpecifications = new HashMap(); The map here, is a collection of ProductSpecifications. There are special facilities in the language to facilitate access to its members. This method contains “productSpecifications.get”

14. Feb 4, 200291.3913 Ron McFadyen14 A sale contains line items. A sale will create a line item and then add it to its collection. MultiObjects

15. Feb 4, 200291.3913 Ron McFadyen15 The Sale class, page 315: Has a list of line items:”private List lineItems = new ArrayList();” The makeLineItem method contains “lineItems.add( new SalesLineItem…)” MultiObjects

16. Feb 4, 200291.3913 Ron McFadyen16 Registration StudentTermCourse RegGuide CourseOffering Student Course offerings/ sections The registration guide is a collection of course offerings Each student, each term, will have a list of courses he/she has enrolled for Current admitted students Registration is like register in POS, it is controlling the process of a student registering for a collection of courses. StudentTerm Each term a student will register for a number of courses Admitted Course Conceptual Class Diagram - without names, multiplicities, roles 91.3913 February 4, 2002 Assignment 2

17. Feb 4, 200291.3913 Ron McFadyen17 System Operations beginRegistration This operation requires that the Registration object create a new StudentTerm object … this is similar to the top half of Figure 17.3 enterStudent This operation requires a lookup in the collection of admitted students to get the name, year, and faculty information enterCourse The student provides the course offering number. The system must look this up in the Registration Guide to find the description of the offering. Then the system can add the course offering to the student’s load for the term. endRegistration The registration object must disconnect from the current StudentTerm object 91.3913 February 4, 2002 Assignment 2

18. Feb 4, 200291.3913 Ron McFadyen18 :Registration :StudentTerm :RegGuide :CourseOffering:StudentTermCourse enterCourse(id) c:StudentTermCourse The beginnings of the enterCourse interaction diagram 91.3913 February 4, 2002 Assignment 2