1. Systems Analysis & Design Methods UML diagrams

2. 2 System Analysis & Design Methods: UML diagrams Books UML for JAVA Programmers UML for JAVA Programmers (Robert C. Martin © Copyright 2003.) A book you should read, even if it is not necessary for this course. UML distilled UML distilled Martin Fowler

3. 3 System Analysis & Design Methods: UML diagrams Contents Normalized data model (not UML) Normalized data model (not UML) Class Model, conceptual (very useful) Class Model, conceptual (very useful) Class Model, design (very useful) Class Model, design (very useful) Object Model (useful) Object Model (useful) Sequence Diagram Sequence Diagram State diagram (very useful) State diagram (very useful) Collaboration diagrams (very useful) Collaboration diagrams (very useful) Using Collaboration diagrams (very useful) Using Collaboration diagrams (very useful)

4. 4 System Analysis & Design Methods: UML diagrams Just to compare with class model: normalized relational database model (Not part of UML) Customer name address CompanyCustomer PrivateCustomer Product name price OrderedItem quantity * 1 Order date * 1 * 1 0..1 1 1 ? PK customer_id FK customer_id PK order_id PK product_id FK order_id FK product_id } PK

5. 5 System Analysis & Design Methods: UML diagrams Remarks I haven’t given the usual ERD diagram notation. I haven’t given the usual ERD diagram notation. Instead, I follow these rules: Arrows start from the foreign key and end with the primary key. Arrows start from the foreign key and end with the primary key. Why ? This way, the databasemodel can be directly compared to the OO class model. It also makes clear that the many-to-one-relations are realized using a field that sits on the many-side and identifies the one side. Not vice-versa.

6. 6 System Analysis & Design Methods: UML diagrams Remarks All my arrows go up All my arrows go up Why ? This way, because the arrows go from the foreign key to the primary key, the many side –if there is one- is always lower than the one-side. Also, the entity/table that is dependend is always lower than the entity/table it depends on. Also, the entity/table that is dependend is always lower than the entity/table it depends on. This way, dependencies and (most) cardinalities can be derived at a glance. -> No arrow-staring nor diagram-deciphering required.

7. 7 System Analysis & Design Methods: UML diagrams Remarks I do not show… I do not show… In order to be able to compare to the UML class model, certain details, that are part of ER-diagrams are not shown: …Relationship-types Identifying Non identifying Informative

8. 8 System Analysis & Design Methods: UML diagrams Differences with Class models at specification/implementaion level Every field is supposed to be persistent. Every field is supposed to be persistent. Pointers/Navigatabilities are always UNIdirectional. Pointers/Navigatabilities are always UNIdirectional. One to many relationships always point to the one-side. One to many relationships always point to the one-side. The other way around would brake first normal form. The other way around would brake first normal form. Normalization demands ‘no data redundancy’ nor calculated fields. (OO specification/implementation level class models would allow private redundant attributes e.g. for cashing) Normalization demands ‘no data redundancy’ nor calculated fields. (OO specification/implementation level class models would allow private redundant attributes e.g. for cashing) E.g. no orderPrice field in order !!! E.g. no orderPrice field in order !!! No process/methods/procedures/functions No process/methods/procedures/functions E.g. no getOrderPrice method !!! E.g. no getOrderPrice method !!! Possible sub-type tables (if allowed) cannot exploit polymorphism Possible sub-type tables (if allowed) cannot exploit polymorphism

9. 9 System Analysis & Design Methods: UML diagrams Class Diagram Class diagrams are static. This means they are independent of the moment in runtime. E.g. even if you might have hundreds of orders for one customer, you would still draw just one class diagram ‘Order’. Class diagrams are static. This means they are independent of the moment in runtime. E.g. even if you might have hundreds of orders for one customer, you would still draw just one class diagram ‘Order’.

10. 10 System Analysis & Design Methods: UML diagrams Class Diagram conceptual level Customer +creditRating:String -name -adress CompanyCustomer +billForMonth(int) PrivateCustomer -contact Product +getPrice():double -name -price OrderedItem +getOrderedItemPrice():double -quantity * 1 Order +getOrderPrice:double -date * 1 * 1 Association Attributes Multiplicity –or- Cardinality Generalization Method

11. 11 System Analysis & Design Methods: UML diagrams Class Diagram specification level Customer +creditRating:String -name -adress CompanyCustomer +billForMonth(int) PrivateCustomer -contact Product +getPrice():double -name -price OrderedItem +getOrderedItemPrice():double -quantity * 1 Order +getOrderPrice:double -date * 1 * 1 * Navigatability

12. 12 System Analysis & Design Methods: UML diagrams Class Diagram specification level ‘Specification’ means ‘Design’ ‘Specification’ means ‘Design’ You make design decisions. The arrowheads show which class has the attribute pointing to the other(s). An association with a navigatability in 1 direction is called: unidirectional association. E.g. A customer points to many orders means: E.g. A customer points to many orders means: Each Customer object will have a List attribute of Order- objects (rather than than each Order-object has a Customer- attribute)

13. 13 System Analysis & Design Methods: UML diagrams Class Diagram specification level OrderedItem +getOrderedItemPrice():double Order +getOrderPrice:double * 1 OrderedItem +getOrderedItemPrice():double Order +getOrderPrice:double * 1 OrderedItem +getOrderedItemPrice():double Order +getOrderPrice:double * 1 - orderedItems: List - order: Order Design solution n° 1 Design solution n° 2 Conceptual

14. 14 System Analysis & Design Methods: UML diagrams Class Diagram specification level Navigatablitities are important. With design solution n°2, the functionality of the following code in Order would be hard to write. Thanks to right navigatability, I can delegate to OrderedItem: public class Order{ … public double getOrderPrice(){ public double getOrderPrice(){ double orderPrice = 0; double orderPrice = 0; OrderedItem oItem; OrderedItem oItem; for(int i = 0; i < orderedItems.size(); i++){ for(int i = 0; i < orderedItems.size(); i++){ oItem = (OrderdItem) orderedItems.get(i); oItem = (OrderdItem) orderedItems.get(i); orderPrice += oItem.getOrderedItemPrice(); orderPrice += oItem.getOrderedItemPrice(); } return orderPrice; return orderPrice; } …}

15. 15 System Analysis & Design Methods: UML diagrams Object Diagram Object diagrams are dynamic. This means they depend on the moment of time during the system run. At implementation level, they are a snapshot of memory. E.g. if at a certain moment in time a customer record has 42 orders and you want to model this, you should draw 42 order rectangles. Object diagrams are dynamic. This means they depend on the moment of time during the system run. At implementation level, they are a snapshot of memory. E.g. if at a certain moment in time a customer record has 42 orders and you want to model this, you should draw 42 order rectangles.

16. 16 System Analysis & Design Methods: UML diagrams Object Diagram :PrivateCustomer -name = “Scott” :Order -date = 1/1/2003 :Order -date = 1/5/2003 :Order -date = 20/1/2001 orders.get(0) orders.get(1) orders.get(2) Link :OrderedItem -quantity=2 :OrderedItem -quantity=3 :OrderedItem -quantity=10 :OrderedItem -quantity=250 … orderedItems.get(0) orderedItems.get(1) orderedItems.get(2) orderedItems.get(0) :Product -name= “Dell Dim 2.0” -price = 1000.0 product :Product -name= “Compac X2” -price = 2000.0 product

17. 17 System Analysis & Design Methods: UML diagrams Sequence Diagram : OrderItem time getOrderedItemPrice() : Product getPrice() :double : Order Loop Data token Activation

18. 18 System Analysis & Design Methods: UML diagrams Sequence Diagram (continued) [ topNode==null] [topNode!=null ] :TreeMap add(key,value) Guard

19. 19 System Analysis & Design Methods: UML diagrams Sequence diagram (continued) Sequence diagrams are generally harder to understand than the code they try to model, especially when loops and conditions are involved. Sequence diagrams are generally harder to understand than the code they try to model, especially when loops and conditions are involved.

20. 20 System Analysis & Design Methods: UML diagrams State Diagram (FSM) ReadingNormalCode ReadingString DoubleQuoteEncountered/StartWritingString DoubleQuoteEncountered/SaveWrittenString NonDoubleQuoteEncountered/AppendToString Start NonDoubleQuoteEncountered/AppendToString Event Action State Transition

21. 21 System Analysis & Design Methods: UML diagrams :Button Collaboration diagram :Button send:Button :Dialer:Radio :Screen:Speaker Example taken from UML for Java programmers Robert C. Martin (2003). The letter A means ‘separate process‘ 1*:digit(n) 1.1:displayDigit(n) 1.2:tone(n) 2.1:connect(pno) A1: inUse 2: Send

22. 22 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram Class diagrams can be used as a basis for implementation. We build class diagrams in small steps: Take a part of the problem (e.g. a use case) Take a part of the problem (e.g. a use case) Build a collaboration diagram in a step by step fashion. Build a collaboration diagram in a step by step fashion. Extract a class diagram Extract a class diagram Improve the design (not shown) Improve the design (not shown)

23. 23 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram Example problem: Software that controls a celular phone. Example part of the problem: ‘making the phone call.’ (adapted from UMLFJP R.C. Martin )

24. 24 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram building the diagram How do you start making a phone call ? You press a button with a digit on it. We imagine some controlling piece of machinery capable of dialing, that remembers the digits we entered, say a dialer. :Button :Dialer 1*:digit(n)

25. 25 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram building the diagram Anything else happening when you press a digit button ? Yes. The dialer needs to get the digit to be displayed on screen and maybe a sound to be emitted by a speaker. :Button :Dialer :Screen:Speaker 1*:digit(n) 1.1:displayDigit(n) 1.2:tone(n)

26. 26 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram building the diagram You keep on hitting digit buttons forever ? No. Eventually you press the green phone button, lets say send button. You expect the dialer to do what needs to be done. :Button send:Button :Dialer :Screen:Speaker 1*:digit(n) 1.1:displayDigit(n) 1.2:tone(n) 2: Send

27. 27 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram: building the diagram Lets say the dialer delegates the work of ‘sending the phone number to the network’. It delegates this to a piece called radio. When a connection is finally established, the screen might need to show an ‘in Use’ message. This is beyond the direct control of the cellular phone (different thread). :Button send:Button :Dialer:Radio :Screen:Speaker 1*:digit(n) 1.1:displayDigit(n) 1.2:tone(n) 2.1:connect(pno) A1: inUse 2: Send

28. 28 System Analysis & Design Methods: UML diagrams using a Collaboration Diagram: Deriving an initial class diagram +digit(n:int) +send +tone(n:int) +displayDigit(n:int) +connect(pno:String) Button Speaker Screen Dialer Radio -lastpno:String * Directions of messages becomes navigatabilities Directions of messages becomes navigatabilities Sent messages become methods Sent messages become methods Object counts becomes cardinalities Object counts becomes cardinalities