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 UML What is the Unified Modeling Language? A diagram language for specifying/describing many different aspects of a system. Helps in the process of design and implementation. Targeted to software systems, but many aspects are useful for other kinds of engineered systems also. You’ve seen three parts of it: use cases sequence diagrams activity diagrams  all for specifying the required behaviour of a system.  all relevant beyond software systems.  part of the requirements analysis phase.

© Peter Andreae ENGR : 3 A modelling language What is the value of these diagrams? Why is it a “language”? Why is it important to draw the diagrams this way? (a)A language is shared – makes communication easier (b)A language helps you think A2: Amount > limit Eject card Amount <= limit Enter amount

© Peter Andreae ENGR : 4 A modelling language What makes a Language: Simple view: Vocabulary Grammar Rules Three aspects: “syntax” – rules about how to say/write/draw statements. most obvious aspect; least important aspect. “semantics” – how to interpret statements. critical for being precise and for communicating “ontology” – identifies important set of concepts, ideas, relationships makes distinctions that help you think

© Peter Andreae ENGR : 5 Language of Activity Diagrams Ontology: there are activities, actions, and decisions  distinction there are temporal relations between activities and decisions there is a start point, and success and error end points  distinction (and more concepts!) Syntax: labelled rounded boxes, labelled hexagons, diamonds, labelled arrows, filled circles Semantics: how to interpret them A2: Amount > limit Eject card Amount <= limit Enter amount

© Peter Andreae ENGR : 6 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 : 7 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 : 8 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 : 9 OO Design and Class Diagrams How? UML provides a language for this design step: object diagrams class diagrams  most common and most important UML diagram Ontological distinctions: objects attributes of objects associations/relationships between objects behaviour of objects classes of objects  Start by identifying objects.  Work out what we need to know about them.

© Peter Andreae ENGR : 10 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 (just 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 : 11 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

© Peter Andreae ENGR : 12 Object Diagram for FrogGame 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, other attributes nearSide: Lane farSide: Lane

© Peter Andreae ENGR : 13 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 : 14 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 : 15 Object Diagram What are the 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 name, type, other attributes nearSide: Lane lane

© Peter Andreae ENGR : 16 Object Diagram What happens when the problem gets bigger? Gets very messy!!! frog1: Frog lane: 0 status: alive car1: Car lane: 3 direction: east position: 350 car6: Car lane: 3 direction: east position: 30 car3: Car lane: 1 direction: east position: 511 lane1: Lane lane3: Lane lane2: Lane car4: Car lane: 2 direction: west position: 280 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

© Peter Andreae ENGR : 17 Class diagrams Can 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 Frog status lane

© Peter Andreae ENGR : 18 Class Diagrams Describe the categories of the objects, rather than the objects themselves: Frog direction position colour speed Lane lane status Car class name, attributes associations

© Peter Andreae ENGR : 19 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 : 20 What are the objects and classes? Next lecture: techniques, and more details.