Peter Andreae Computer Science Victoria University of Wellington Copyright: Peter Andreae, Victoria University of Wellington UML for design: Class Diagrams ENGR 110 #

© Peter Andreae ENGR : 2 Design Requirements analysis treats the system as a black box. Design has to open it up and say what’s inside, and how it will work. COMP 102/112 didn’t talk much about design! we gave you the design of the programs – you just had to turn the design into code why? What does the design of a software system look like? How the system is broken down into components What the components do. COMP102 programs: classes, methods

© Peter Andreae ENGR : 3 Modularity Central problem in most engineering tasks: Complexity Key technique to handle it: Modularity Break the task up into chunks chunks should be as independent as possible solve/design/build each chunk separately assemble them together Used in all branches of engineering

© Peter Andreae ENGR : 4 OO Design and Class Diagrams Key principle in Object Oriented design for software systems: Primary Modularity = objects and classes Given a task, need to identify  the different objects and classes that will make up the system  what is in the objects and what they do  how they are related and how they interact

© Peter Andreae ENGR : 5 OO Design and Class Diagrams UML provides a language for this design step: object diagrams class diagrams  most common and most important UML diagram First step: Domain analysis Working out what are the kinds of things in the domain and what we know about them. Object Diagrams: Start by identifying objects Give them names Work out what types they are Work out what we need to know about them.

© Peter Andreae ENGR : 6 The Frog game The FrogGame class is a simple game that lets a player try to hop their frogs to the other side of a three-lane road without being hit by the cars driving along the road. Frogs start just below the road and have to hop to the far side (past lane 4). Cars drive along the road at different speeds and with different sized gaps. The player has only one frog at a time, and can make it hop forward or back (one lane at a time). If the player gets a frog to the far side of the road, they gain 10 points, the frog hops off into the field, and the player gets another frog. When a frog is hit by a car, it dies, and the player gets a new frog if they have any lives left. The game keeps track of how many lives the player has left (initially 5) and the current score. The game ends when the player has run out of lives.

© Peter Andreae ENGR : 7 Object Diagram for FrogGame What are the objects in the world: frog: Frog car1: Car car2: Car car3: Car lane1: Lane lane3: Lane lane2: Lane name, type,

© Peter Andreae ENGR : 8 Object Diagram: attributes What are their attributes? frog: Frog lane: nearSide status: alive car1: Car lane: 3 direction: east position: 350 car2: Car lane: 2 direction: west position: 230 car3: Car lane: 1 direction: east position: 511 lane2: Lane lane3: Lane lane1: Lane name, type, attributes and types nearSide: Lane farSide: Lane

© Peter Andreae ENGR : 9 Object Diagram for FrogGame What are the associations between objects: frog: Frog status: alive car1: Car direction: east position: 350 car2: Car direction: west position: 230 car3: Car direction: east position: 511 lane2: Lane lane3: Lane lane1: Lane nearSide: Lane lane farSide: Lane

© Peter Andreae ENGR : 10 Object diagrams What is the ontology of Object diagrams? Objects: entities in the world – frogs, buildings, books, people events – enrolment, return, transaction intangible entities – courses, companies, images roles – client, manager, member, surgeon entities that can do stuff – searcher, sorter, components – windows, buttons …. Attributes of objects information/values describing the objects (other than other objects) Associations (relationships) between objects

© Peter Andreae ENGR : 11 Object Diagram What happens when the problem gets bigger? Gets very messy!!! frog1: Frog lane: 0 status: alive car6: Car lane: 3 direction: east position: 30 car1: Car lane: 3 direction: east position: 350 car3: Car lane: 1 direction: east position: 511 lane1: Lane lane3: Lane lane2: Lane car2: Car lane: 2 direction: west position: 230 car5: Car lane:1 direction: east position: 260 car7: Car lane: 3 direction: east position: 300 car8: Car lane: 2 direction: west position: 430 car9: Car lane: 1 direction: east position: 20 frog2: Frog lane: 3 status: dead frog3: Frog lane: 2 status: dead car10: Car lane: 2 direction: west position: 120 car4: Car lane: 2 direction: west position: 280

© Peter Andreae ENGR : 12 Class diagrams More useful for real design Abstract from individual objects to classes of objects. What is the ontology of Class diagrams? Classes: categories of objects all of the same type, with the same behaviour Attributes of the objects in the classes Associations (relationships) between objects in the classes Actions/behaviour of objects in the classes lane Frog status: boolean

© Peter Andreae ENGR : 13 Class Diagrams Describe the categories of the objects, rather than the objects themselves: Notes Associations can have additional information on them Behaviour specifies the actions that can be done on the objects Frog Lane lane status: boolean class name, attributes incl associations behaviour direction: string position: integer colour: Color speed: float Car

© Peter Andreae ENGR : 14 Designing Class Diagrams How do you work out what classes there should be? No mechanical algorithm: it is a design issue Starting point: the nouns/noun phrases in the specification eg, the initial text description, the use cases, etc. note: this is not enough: Some nouns don’t need to be classes Some things classes aren’t

© Peter Andreae ENGR : 15 Lab sign-up system System should allow students to sign up for lab streams for their courses. Each course will have one or more lab streams. Each stream will have a time, duration, lab, and a maximum capacity. A course administrator needs to be able to set up the lab streams for their course. Students should be able to specify the lab streams that they could make, and a preference order. When sufficient students have entered their preferences, the system should show which streams students are likely to be assigned to, along with the likelihood. The course administrator can “commit” to an allocation, at which point, the system will permanently allocate signed up students to streams. Students should be able to withdraw from lab streams, and enter new preferences, but they won’t be actually assigned until the next time the administrator “commits”. Administrators should be able to get lists of students in each stream of their course.

© Peter Andreae ENGR : 16 What are the objects and classes? Next lecture: techniques, and more details.