administrivia today UML start design patterns Tuesday, September 28, 2010

Transcription

1 administrivia Assignment 2? promise to get past assignment 1 back soon exam on monday review slides are posted your responsibility to review covers through last week today UML start design patterns 1

2 Unified Modeling Language common notation not a methodology primarily pictorial very large extensible widely used very different usages UML 2

3 pre-history UML developed by 3 amigos Grady Booch Ivar Jacobsen Jim Rumbaugh each had their own notation Booch method Objectory (use-case based) OMT (Rumbaugh) 3

4 history 3 amigos all now work for Rational IBM bought Rational last year unified their notations classic design by committee everything included now open standard controlled by OMG version 2 released earlier this year will focus on version 1.4 most widely used in practice 4

5 expressive power UML can describe: everything (almost) usually in more than one way often used for class diagrams instance diagrams sometimes used for use cases collaboration diagrams message sequence diagrams state charts 5

6 your goals I want everyone to be able to read UML diagrams write UML-like diagrams not picky about precise notation your diagrams should be understandable by UML-literate software developers 6

7 class diagrams class diagrams most common part of UML show inheritance show packages show associations show attributes show operations (methods/functions) 7

8 class box class is a box with 3 compartments myclass public attr1 : int = 3 private attr2 : String public op(in p1:int, out p2:string) : String class name attributes operations 8

9 class name additional info can go along with class name mostly using stereotypes come before class name describe usage/semantics of class enclosed in <<... >> examples useful for java include <<interface>> <<final>> abstract indicated with trailing {abstract} name usually written in italics as well sometime just use italics 9

10 attributes format of attribute is visibility name [multiplicity] : type = default anything but name can be omitted visibility public (+) /private (-) /protected (#) type any primitive type or class or interface default any value of type other options available 10

11 multiplicity multiplicity indicates how many values appears many places in UML defaults to 1 (one) can be n : any explicit integer or integer expression * : means any number m..n : between m and n values (inclusive) multiplicity, multiplicity : explicitly list options enclosed in [ ] 11

12 operations operations indicate method available syntax is visibility name (params) : return params in comma separated list with each direction name : type = default direction is in/out/inout 12

13 inheritance inheritance shown as line use closed hollow arrow head points from subclass to superclass can inherit from classes and interfaces interfaces can inherit only from interfaces 13

14 inheritance example shape location: Point h: int w: int rectangle circle polygon numsides: int regularpolygon generalpolygon vertices [numsides] : Point 14

15 associations attributes relate simple values to instances associations relate instances to other instances distinction matter of taste at boundaries how do you think about it as a value or as a related instance examples parent/child, husband/wife 15

16 displaying associations associations are lines between classes possibly labeled with name one or both ends (for opposite class) may have multiplicity indicated one or both ends at opposite end 16

17 navigable just because objects are associated may not be possible to get there using what the program knows at least with reasonable performance called navigable if possible efficiently child may store reference to parent without parent storing reference to child indicated by existence of open arrow head double arrow means two-way no arrows means unspecified 17

18 example manages 1..* Employee name: String salary: int 1 Manager title: String 18

19 more complicated example 19

20 aggregation two more kinds of arrows on class diagrams first is aggregation indicates parts on an entity drawn with hollow diamond arrow head e.g., members of a baseball team 20

21 composition composition is similar to aggregation part can only be sub-part of container has no meaningful independent existence drawn with filled diamond arrow head e.g., link elements in a linked list 21

22 example 22

23 collaboration diagram shows sample execution what instances how are they related how do they interact each instance is box Class:name inside :name is optional used to distingush instances all text always underlined 23

24 collaboration example Goalie watches Ball watches watches Forward teammate Forward 24

25 interaction diagrams derived from message sequence charts shows message flow 25

26 design patterns initially developed by gang of four (Gamma, Helms, Johnson, Vlissides) capture experience of class design mostly language independent 30-some patterns defined ongoing development by community hoped to develop common vocabulary limited success thus far 26

27 specification patterns specified with mostly structured text Name Classification below Intent what does it do? what problem does it address? Motivation typically an example 27

28 specification (cntd) Applicability when should this pattern be used Participants what classes participate Collaborations how the participants Diagram OMT or UML diagram of interactions 28

29 specification (cntd) Consequences what are the trade-offs involved Implementation hints for implementing this pattern Sample code example implementations Examples examples of usage in real systems See also closely related patterns alternatives and collaborators 29

30 classification group patterns to ease finding solutions given as jurisdiction X characterization jurisdiction how large of a domain Object, Class, Compound characterization type of activity Creational, Structural, Behavioral 30

31 classification table from the gang of four book Creational Structural Behavioral Object Abstract Factory Prototype Singleton Adapter Bridge Flyweight Chain of Resp. Command Mediator Memento Observer Proxy State, Strategy Composite Composite Decorator Facade Iterator Visitor Class Factory Method Builder Template 31

32 factory - problem want to write code in terms of superclass isolate from knowledge of subclasses one goal of OO design/programming but must know specific class for new often painful to expose correct subclass system dependent classes when private state indicates correct class when possibilities determined at runtime 32

33 factory - example abstract class java.util.calendar is example describes dates actual info/format depends on locality subclass needed depends on implementation what class should be instantiated? Calendar could break encapsulation Calendar could return flag saying what class 33

34 factory - problem both are unfortunate choices first breaks major reason for OO second limits subclasses to fixed set documented third choice is to create instance in method pass in necessary info getcalendar() call in this example 34

35 factory patterns getcalendar called a factory method common pattern often static methods isolates knowledge/choice of subclasses factory classes contain many factory methods may return many different kinds of objects objects will be compatible with each other factory object is instance of factory class methods are not static 35

36 factory - when use factory method when multiple possibilities localize decision process use factory if subclass is hidden part of implementation (iterators) local version platform/internationalization use factory class/object when multiple objects must cooperate / be from same family 36

37 classification table from the gang of four book Creational Structural Behavioral Object Abstract Factory Prototype Singleton Adapter Bridge Flyweight Chain of Resp. Command Mediator Memento Observer Proxy State, Strategy Composite Composite Decorator Facade Iterator Visitor Class Factory Method Builder Template 37

38 flyweight -problem ideally want to treat everything as an object every bit of data objects have a non-trivial overhead especially in memory usage using lots & lots uses lots & lots of memory a traditional complaint about OO too inefficient to use on everything 38

39 flyweight - example problem consider baseball database record every ball put in play want where runners are want count (balls/strikes) at time ideally want count, runners as objects takes way too much space common hack encode data as int count = #balls*4 + #strikes runners 1=first 2=second 4=third (or bits) 39

40 flyweight example ugly design exposed representation hard to add extra data you want to record total pitches really need objects so share them 2-0 count is same object in every case only need 19 count objects, 8 runner positions removes memory consideration 40

41 flyweight pattern flyweight pattern uses this form of sharing called flyweight because incremental cost near 0 just cost of one reference to point to instance about same cost as one int full object for no extra charge need way to get that one instance may need to create if first reference use factory method returns shared instance if existing saves references to each 41

42 flyweight - when flyweight useful whenever many references to relatively few objects at least few objects actually used instances must be immutable otherwise cannot be shared provide operations to find new object Count.ballCalled() returns another count flyweights make equals very cheap 42

43 singleton patten suppose have an index of items insert into it when new item created use it to find existing items better have only one or lookup may fail called singleton class if only one instance can be created may actually allow few instances each with defined role 43

44 singleton pattern make constructor private to enforce limit no one else can create an instance use factory method to instantiate or find closely related to flyweight singleton instances can be mutable want to share changes logically sharing object 44

45 classification table done so far, plus singleton, state to start today Creational Structural Behavioral Object Abstract Factory Prototype Singleton Adapter Bridge Flyweight Chain of Resp. Command Mediator Memento Observer Proxy State, Strategy Composite Composite Decorator Facade Iterator Visitor Class Factory Method Builder Template 45