Design Class Diagrams

1. Design Class Diagrams http://flic.kr/p/ar9z8F

2. What are you goingto learn about today? • How to go from • Domain Models • to Design Classes • to Implementation Classes • More class diagram notations and conventions • to make your Design Class Diagrams great! http://flic.kr/p/8JpkTg

3. Recall: Iterative development process We are here http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

4. Object-Oriented Design “Define software objects and how they collaborate to satisfy their requirements” • You need to be able to reason about a design • To understand designer’s intent • To critique/improve the design

5. Source code not best medium for reasoning • Lots of redundancy and detail irrelevant for some program understanding tasks • Especially poor at depicting relationships among classes in OO programs Solution: Use abstract, visual representations—for example, Design Class Diagrams (DCDs)

6. Differences between Domain and Design models Attributetypes Navigability Operations compartment

7. Refinement process: Unfolding the design Domain Model refine Design Classes refine public class Register { private int id; private Sale currentSale; ... } public class Sale { private DateTime time; ... } Implementation

8. Refinement isnot mechanical Another possiblerefinement One possiblerefinement class City { ... protected: string cityName; unsigned population; }; class Airport { ... protected: string airportName; CODE airportCode; ZONE timeZone; }; multimap<City*, Airport*> cityServes; multimap<Airport*, City*> airportServes; class City { ... protected: string cityName; unsigned population; vector<Airport*> serves; }; class Airport { ... protected: string airportName; CODE airportCode; ZONE timeZone; vector<City*> serves; };

9. Benefits of refinement process • Postpones design decisions until ready to make them • Manages complexity • Less refined designs more abstract http://flic.kr/p/7WYW68

10. Now, I’m going to introduce a bunch of new class diagram notations and conventions to help you make your DCDs more expressive

11. Full format of attribute notation • visibilityname : typemultiplicity = default {property} • Examples:

12. Visibility • + Public • Any class that can see the containing class can see • - Private • Only containing class can see • # Protected • Only containing class and its descendants can see • ~ Package • Only classes within containing package can see

13. Full format of operation notation • visibilityname (parameters) : return-type {property} • Examples:

14. Modeling attributes and associations public class Register { private int id; private Sale currentSale; ... } public class Sale { private DateTime time; ... }

15. Modeling an ordered list {list} Multiplicity Properties:

16. Distinguish between data typesand non-data types! • Instances of data types are plain old values • Examples: integers, strings, dates, dollar amounts • No need to distinguish between two instances of the same dollar amount • Instances of non-data types have identity • Examples: Sale, Register, Airport, City, Employee • Even if two employees had the same name and salary, they would still be distinct instances • In Design Class Diagrams, model • attributes as data types • associations among non-data types

17. Modeling a method

18. Omit setter and getter operationsfrom design classes • Added noise outweighs value • Assume you have them if you need them

19. Modelingconstructors In a sequence diagram, model as a create message

20. Generalization implies inheritance Objects of subclass have all attributes and methods of superclass

21. Modeling dependencies public class Foo { public void doX() { System.runFinalization(); ... } ... }

22. Modeling interfaces An interface is essentially an abstract class with only abstract, public operations (no attributes and no methods)

23. Three ways to model constraints 1 3 2

24. Modeling hashes with qualified associations • Multiplicities are different than usual: • (catalog, ID) 1 description • description 1 (catalog, ID) • Implies catalog  0..* description Key typeIf numbers, could be itemID : Integer

25. Modeling relationships with association classes

26. Modeling templates Binding notations:

27. User-defined compartments

28. Modeling active objects

29. Relating sequence diagrams to DCDs

30. Creating Design Classes • See the handout… http://flic.kr/p/5dfuqL

31. Summary • Design as refinement process • Too many class diagram notations and conventions to list http://flic.kr/p/YSY3X