1. Object-Oriented Analysis and Design Use cases Finding classes Collaboration and Sequence diagrams Associations between classes

2. Object-oriented design so far we have learnt how to implement programs in Java Java syntax for programming fundamentals sequence selection iteration writing and calling methods arrays how to convert a UML class diagram to Java code how to write an application that uses more than one class

3. Object-oriented design today's lecture is about how decide what to implement what do we want the program to do? what classes are needed? how do they interact with each other? will introduce some more UML use case diagrams, collaboration and sequence diagrams

4. School Scenario an application is needed to kept track of the students enrolled in a school the application needs to store the name, program, level and enrolment date of each student each student should be issued with a unique student number when they enrol the system should keep track of the next available student number the system should be able to print a list of all students registered, showing all the information recorded about each student

5. School Scenario the system should be able to find an individual student's record, searching by name, and print it out only current students should be stored in the system they should be deleted when they withdraw or graduate if a student changes their program, their record should be updated at the end of each year, any student who has passed should progress to the next level

6. Requirements gathering where does the scenario come from? a brief from the manager who commissions the system interviews with prospective users analysis of the current system etc. etc. – as you've learned in other modules it may be ambiguous and may not be complete may have to go back for clarification hopefully this scenario is familiar we have been using it throughout this module!

7. What next? construct a Use Case Model this is a UML element that describes what the system does from the user's point of view first decide who the users are these are called actors in UML then examine the scenario to find verbs that describe what the system does each separate piece of functionality is called a use case actors and use cases can be shown compactly on a use case diagram

9. Use case diagram actor shown as a stick man in this case we will assume a school administrator is the only actor in this scenario each use case shown in ellipse with a line to the actor who triggers the use case a use case has a short name which describes what happens from the point of view of the actor doesn't include implementation or system details can provide more details in a use case description

10. Use case description Use case: Enrol student Actor: Administrator Purpose: to enrol a new student onto the school system Steps: 1. The administrator chooses the "Enrol student option" 2. The system prompts for the new student's name and program 3. The administrator enters the information 4. The system enrols the students and displays a confirmation message, or an error message if the school is full

11. Refining use cases after considering the use cases you may want to refine them further printing a student's record, deleting their details, and updating their program or level all involve finding the student's record first we could specify a "find student by name" use case all the above use cases include the "find student by name" use case similarly we could define a "print student details" use case that is included when printing all the student records printing a single student's record

13. Identifying classes next you will need to identify the major classes in the system there are several strategies make a list of the nouns in the scenario and use case descriptions these are possible classes some may be attributes of classes consider classes describing well-known categories physical objects, actors, organisations, specifications, rules and policies, interfaces

14. Possible classes application student(a physical object) school(organisation) name program level enrolment date student number list of students administrator(actor) user interface(most systems require one or more user interface classes)

15. Refining the classes applicationX this is the whole system Student  School  nameX a simple attribute of Student programX a simple attribute of Student levelX a simple attribute of Student enrolment date  an attribute of student, but could represent using a class (Day) student number X a simple attribute of Student list of studentsX  this is the same as School administratorX not necessary to keep any details about the administrator user interface  SchoolApp

16. Class diagram once the classes have been identified, you can draw a class diagram showing how they are associated indicate classes using name only show associations with lines associations can have multiplicity * any number 1 only one 0..* 0 or more 1..* 1 or more

17. Outline class diagram a SchoolApp is the interface for up to one School a School can contain zero to many Student objects each Student object contains one Day object representing the enrolment date

18. Refining the classes once you have identified classes, you need to decide on their attributes and methods we did this in week 3 to find attributes, pick out nouns or facts from the scenario if they are not classes themselves, these are potential attributes of classes decide on a name and type for each associations are implemented using attributes implement 1:1 association between Student and Day by having an attribute of type Day in Student implement 1:0..* association between School and Student by having an array of Students in School

19. Class diagram with attributes

20. Identifying methods pick out actions from the scenario these are potential methods which class do they belong to? one action may be carried out by a chain of methods in several associated classes can show on collaboration or sequence diagrams (next slides) decide on a name for each method do they need information? these are parameters – decide on type do they return a value? if so, what type?

22. Collaboration diagram for enrolling a student

23. Sequence diagram for enrolling a student

24. Sequence and collaboration diagrams way to show interactions between objects by calling each other's methods both diagrams show similar information collaboration diagram emphasises relationships between objects sequence diagrams emphasises time not covered in detail in this course but you may find them useful when designing large systems in future

25. One-way associations the associations shown in the School example are one-way Day does not have any attributes referring to the Student who enrolled on that date there is no need Day was written to be used in many different applications if Day had a reference to Student we could only use it in this application

26. Many-to-many associations many-to-many associations are allowed in object-oriented models this is unlike relational databases if we extended our scenario, we could allow each student to enrol on up to 6 modules each module would have a list of students signed up to it we can implement this using arrays

27. Many-to-many associations a Student can take up to 6 Modules a Module has many enrolled Students

28. BUT!!! often we want to store additional information about the many-to-many association in this example, we might want to store the date the student enrolled on the module and the module mark where could we store this information? not in Module a Module is taken by many Student s in Student ??? would need an array of mark s and enrolmentDate s corresponding to the array of Module s gets messy –what if we sorted the array of Module s? not object-oriented related information should be stored together

29. Association classes often we will need to create an association class to hold the information about a relationship in this case it would describe the relationship between Student and Module call it StudentModule Module could have an array of StudentModule objects representing the students enrolled on it Student could have an array of StudentModule objects representing the modules the student is taking StudentModule will need attributes of type Student and Module to represent the student and module it is linking mark and enrolment date attributes

30. Association classes

31. Using association classes use an association class whenever you need to store information about a relationship most often many-to-many relationship Student:Module marks, enrolmentDate Customer:Product quantity, orderDate could be more than two-way relationship Customer:Product:Order quantity just need one attribute for each class linked

32. Summary have (briefly) covered OO analysis and design from scenario to complete class diagram what does the system do? use cases how should it be constructed? classes, attributes, methods, associations new UML diagrams use case collaboration sequence how to implement associations using attributes situations where an association class is needed