CSC223 2004F, Class 8: The UML 3: Showing Activity Admin: * Missing (Agh!): Zuleta-Benavides (needs a partner), Grey * Questions on Bug World Diagram Assignment? * Purposefully left open-ended * Goal: Static relationships of classes * Office hours switched to 1:30-2:30 (approx), WF this week. * Note: Fowler uses "stick" and "filled" * Question: If Fowler always says "The UML", why isn't this book "The UML Distilled"? * Survey: How is the class going? 1: Much too quickly: 1 2: Slightly too quickly: 6 3: Just right: 3 4: Slightly too slowly: 2 5: Much too slowly: 1 * Quiz! "CS223, Quiz 3: YOUR NAME HERE" a. Explain what a diagram with a solid box and a connected dotted box represents. b. Explain what the specific diagram with Vector in the solid box and Comparable in the dotted box represents. Overview: * Template diagrams * The system in action * Messages * Sequences * Use Cases * State Machines /Quiz and Templates/ a. It's a class template with T as a parameter. I don't really understand templates, because they belong in C++. a. It's a class template with T as a parameter. Java sucks because it doesn't have templates. C++ rules because it does. Is a list in Java 1.4 homogeneous or heterogeneous? * Heterogeneous: It's up to the programmer whether she puts all the same type of object in or different objects. * Homogenous: Lists contain only objects. If we believe that the language should enforce typing, heterogeneous lists are dangerous. Template classes are designed to solve this problem. A Template Class is, as the name suggests, a *template* for a class. It has one or more parameters which you need to fill in. E.g., (fake syntax) public class ListNode { value; ListNode next; public getCar() { return value; } public getCdr() { return next; } } When I create one of these, I specify ListNode cs223 = new ListNode(); // The language now knows that cs223.getCar() returns a Student Why not just have a field that says "the elements in this list are of class C?" * It would work but ... harder and less versatile * Less versatile: If there are lots of parameter classes, life may be complex. * Extends the generality to types that aren't objects. * Harder: You as programmer need to do all the "is the type right?" code. * Annoying: You still have to cast the return values. Why not just create a generalized class and do a global substitution to create the individual classes? * Propagating changes may be harder. * (This is, more or less, what Java 1.5 does.) Detour: Java 1.5 * Adds template classes (syntax *similar to* above) * Automatic boxing and unboxing: Use an int as an Integer and vice versa. * A new control structure for iterators (essentially "for each") * DOES NOT CHANGE JAVA VM! The second diagram is "Vectors of things that can be compared, but which are all of the same type" Why is this useful? * Limits variation * Some data types can't be compared, so we don't want to allow them. * These are things that you sort naturally. * You need compareTo * You need types to be the same so that compareTo is sensible Detour continues To compare two numbers, use "standard numeric ordering" To compare anything to a string, convert that thing to a string and use "standard lexicographic ordering" (Compare the first letter, then compare the second letter, then compare the third letter, ...) Claim: This order is not transitive Transitive: if a < b and b < c then a < c Assignment: Find a, b, and c, such that a < b and b < c, but a > c (using the ordering above) 11 < "2be" < 3 Non-transitive orderings are *bad* for most sorting methods. ---- Diagramming the dynamics of systems Many kinds of dynamics * What the potential calling structure of the program is * Traditional design exercise: CRC cards * Suppose we have a large system with lots and lots of objects * We give each "person" a card representing a class or object * We run through a use case, asking each person what they do next * Non-standard UML: Add arrows to class diagram showing what methods are called * Standard UML: Activity diagram * The state of an object over time: State Diagrams * The relationship between use cases in a system: Use Case Diagrams Bring questions on Friday! Probably no quiz (but only if you bring questions)!