CS212 Lecture 7 7/14/03 UML (summarized from Liang, Kanim et al, and Riley) (Also from Sams Teach Yourself UML in 24 Hours, by Joseph Schmuller) ------------------------------------------------------------------------------- 0) Announcement - project part 2 due monday, july 21, 11:59pm - A1 solutions up, grades sent out - regrades? - anyone still need partners for part 2? - any questions about part 2? ------------------------------------------------------------------------------- 1) Basics + UML: unified modeling language - graphical way to depict semantics and structure of OO language - allows you to communicate your vision of a system win a visual model - helps to design OO program - very popular! - see links in CS211 Programming Resources and http://www.omg.org/uml/ http://uml.tutorials.trireme.com/ http://www.rational.com/uml/resources/quick/index.jsp?SMSESSION=NO http://argouml.tigris.org/ + WHY UML? - before UML, system analysts would talk to clients and then produce a document that the analyst (but not always client) understood - provides a language that many parties (client, analyst, developer) can understand - Also, developers would often develop from the botton-up, writing necessary code as they go - problem: system not well-planned, could have to overhaul it later - also: each team member must know the overall picture of the system + UML is a language: - tokens: pictures/icons - grammar: rules for writing the diagrams from the icons - model: UML provides ways to represent multiple views of a system. The set of these views is the model + types of diagrams: - class diagrams: OOP - object diagrams: show objects (instances of classes - use-case diagrams: description of a system's behavior from the user's view - sequence diagrams: shows interactions b/n objects in the system over time - collaboration diagrams: - state diagrams: shows state transitions of a system - even more: activity diagrams, collaboration diagrams, component diagrams ------------------------------------------------------------------------------- 2) Object Orientation + OBJECTS - has structure: attributes and operations (in Java: fields and methods) - Classes are templates for making objects - Objects are instances of classes - More complex the structure, the better the object represents reality - but: which attributes and operation do you really need in your system? + ABSTRACTION - fitering out an object's properties and operations until just the ones you need are left + INHERITANCE - object inherits structure of its parent classes - classes can inherit from classes as well (subclasses/superclasses) - can inherit from multiple classes (yes in C++, not in Java) + POLYMORPHISM - operation with the same name in different classes does different things - in Java: could have an abstract class BankAccount with calcInterest() - CheckingAccount class would implement this method differently from SavingsAccount class - always involves calling a function/method - allows models to maintain terminology without having to have unique names + ENCAPSULATION - object hides its workings. You only know how it functions (input and output), but not how the output is created ("Black Box") - why important: by hiding operations, other objects don't depend on the inner workings of the object. Thus is the object malfunctions or a bug is found and fixed, other object probably won't have to be altered\ - example: computer monitor and cpu. CPU doesn't know how monitor displays info. If monitor breaks, just replace it. Don't need to replace CPU as well. + MESSAGE SENDING - object communicate by sending messages: one object send method for another to perform some operation, and the other object performs it - object must have an interface for communication ------------------------------------------------------------------------------- 3) Classes and Objects + CLASS: drawn as a rectangle - name: class name (required) - properties: fields (optional) - operations: methods (optional) - responsibilites: description (optional) + CLASS NAME - can have pathname: : - ex) HouseholdAppliance::WashingMachine + ATRIBUTES/PROPERTIES: - v:T or v:T = initial value (v=var name, T=type) - ex) brandName:String, age:Integer - modifiers: for public (+), private (-), protected (#) - static things are underlined - for final values, append {frozen} + OPERATIONS: - give method name and return type as m:T (m=method name, T=type) - ex) turnOn():Boolean - parameters use v:T format: setName(name:String) - underline static methods - use +/-/# system for modifiers - can leave out names of parameters (just give types) + RESPONSIBILITY - description of what the class does + CONSTRAINT - more formal way to add constraints to an attribute - put in curly braces. ex) {age >= 0}, {capacity = 16 or 18 or 20} + NOTES - a rectangle with a folded corner. Has a text note - attach to a class/attribute/operation with dotted line + STEREOTYPE - allow you to organize your classes. - put inside guillemets. ex) <> - sort of like comments + ABSTRACT CLASS: - italicize class name - italicize entire abstract method heading ex) class WahingMachine { public String brandName; public String modelName; protected final int serialNumber; private int capacity; public void addClothes(String C) {...} public Clothes removeClothes() {...} public void addDetergent(Detergent d) {...} public void turnOn() {...} } (EXAMPLE) + Note: dont always have to show class's attributes and operations - faster to write/draw ------------------------------------------------------------------------------- 4) Objects +OBJECTS - resemble class diagrams - topmost panel has objectname:classname (all underlined) - underlined to indicate an object, not class - also suggests access similar to static - can leave out objectname when no ref var - sometimes list class and instance variables with values - don't usually show methods (EXAMPLE) ------------------------------------------------------------------------------- 5) Class Relationships + association + aggregation + inheritance ------------------------------------------------------------------------------- 6) Associations + ASSOCIATIONS - show logical rel between pairs of classes or objects - connect with lines and optional labels (usually verbs) near center - if you use label, show filled triangle to explain "direction" of association - open arrow -- one-way rel - no arrow -- two-way (classes know about each other) - ends can have roles (general name for what class is) - can also have multiplicities: - number of objects involved in relationship of classes - labels: 1 exactly one 1..n one to n 1..* one or more * zero or more 0,1 zero or one 3,5 three or five - reflexive associations: association between class and itself ex) a CarOccupant class with a driver and 0-4 passengers: - constraints ------------------------------------------------------------------------------- 7) Inheritance + show subclass "pointing" to superclass with "open" arrowhead ------------------------------------------------------------------------------ 8) Aggregations + has-a relationship + use solid line with open diamond at the "whole" end + composition: - "strong form" of aggregation - the part can belong to only one thing - use filled diamond ------------------------------------------------------------------------------- 9) Interfaces + italicize, as with abstract classes + sometimes write <> above interface name (<> called stereotype) + dashed line with open arrow (recall inheritance) for class that implements ("realizes") the interface ------------------------------------------------------------------------------- 11) State Diagrams + describe flow of control of object + elements: - state: rounded rectangle - initial state: small filled circle - solid arrow: state transition ------------------------------------------------------------------------------- 10) Sequence Diagrams + describe object interactions in order of time + basic elements: - class role: role object plays - lifeline: existence of object over period of time - activation: time during which object performs activation - method: communication between objects