Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris

Similar presentations


Presentation on theme: "1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris"— Presentation transcript:

1 1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris (d.makris@kingston.ac.uk) d.makris@kingston.ac.uk

2 2 Last week Class Diagram Basic Notation Review Some Advanced Notation Other Static Views Package Diagram Workshop: Class Diagram (Conceptual Modelling)

3 3 Summary of this session Class Diagram in Construction Phase Patterns Case Study

4 4 Class Diagrams in Construction phase (Design) Add implementation details Classes, operations, attributes, multiplicity, navigability, visibility, etc. How? Exploit interaction diagrams Use patterns (“GRASP”, “Gang of Fours’s”)

5 5 Exploit Interaction Diagram Collaboration diagram or Sequence diagram? Work in parallel on both Interaction & Class diagrams Identify new classes Add operations Add multiplicity and navigability Enhance attributes Determine visibility

6 6 Patterns Patterns are general solutions to common problems Part of software development method, not part of UML GRASP (General Responsibility Assignment Software Patterns) by Graig Larman Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, “Don’t Talk to Stangers”. Gang of Four’s Patterns by E. Gamma, R. Helm, R. Johnson & J. Vlissides 25 patterns divided in 3 categories according to their purpose (creational, structural, behavioural)

7 7 Some GRASP Patterns Expert Creator High Cohesion Low Coupling Law of Demeter Controller Façade Class

8 8 GRASP: Expert Problem: “Who, in the general case is responsible?” Solution: Assign a responsibility to the information expert -- the class that has the information necessary to fulfill the responsibility. e.g: Assign calculate_total() behaviour

9 9 GRASP: Creator Problem: Who creates? Solution: Assign class B the responsibility to create an instance of class A if one of the following is true: B contains A B aggregates A B has the initializing data for A B records A B closely uses A e.g: New PurchaseOrder has been created. Which class is responsible for creating its order lines?

10 10 GRASP: High Cohesion Problem: How to keep complexity manageable? Solution: Assign responsibilities so that cohesion remains high. e.g: Consider the LiftController class. Is it cohesive?

11 11 GRASP: Low Coupling Problem: How to support low dependency and increased reuse? Solution: Assign responsibilities so that coupling remains low. e.g: What are the disadvantages of this class diagram? How can they be solved?

12 12 Law of Demeter: Don’t Talk to Strangers Use the “Law of Demeter” to reduce coupling. Within a method, messages can only be sent to the following objects: The this object (or self). A parameter of the method An attribute of self. An element of a collection which is an attribute of self. An object created within a method

13 13 GRASP: Controller Problem: Who handles a system event? Solution: Introduce a controller class which will be between the actor and the other classes. E.g: Should “Race” be responsible for displaying its details?

14 14 Façade Pattern

15 15 Case study Let say that we want to develop a email- client program! How will we use the UML diagrams through an iterative-incremental development process?

16 16 Recall the Unified Process Stages Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

17 17 Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase We have already done that by deciding that we will develop an email client application

18 18 Use Case Diagram Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

19 19 Conceptual Model (Class Diagram) Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

20 20 Package Diagram If the scope of the project is large, then we can split it into smaller manageable pieces, using the package diagram Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

21 21 Use Case Full Text Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase Pre-requirements: An Account exists and is selected Post-requirements: Email sent to the SMTP Server, Message copied to the Outbox Folder Main Success Scenario: The User selects “Compose Message”. The user edit the fields “To:”, “Cc:”, “Subject”, “Message”. Then, the user selects “Send Message”. Exceptions: SMTP Server undefined or cannot connect, “To:” undefined Alternative Scenario: The user selects “Send Message Later”, instead of “Send Message”.

22 22 Activity Diagram Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

23 23 Sequence Diagram Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

24 24 Dynamic views in Construction Phase Other Dynamic Views can be used for the Analysis and the Design Step, e.g: Collaboration Diagram (Communication in UML2.0) State Diagram Interaction Overview Diagram Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

25 25 Implementation Model (Class Diagram) Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

26 26 Coding Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase From Class Diagrams to Class Definitions From Dynamic Views to Method Definitions Packages in Java, C++ and C#

27 27 From Class Diagram to Class Definitions public class OrderLine { private int Quantity; private SKU SKUOrdered; public OrderLine(int qty, SKU product); public int GetQuantity(); public int SetQuantity(int qty); public float Subtotal(); }

28 28 From Interactive Diagrams to Method Definitions.. public double GetTotal() { double total=0; OrderLine line; for (int i=0; i<OrderLineList.size(); i++) { line = (OrderLine) OrderLineList.get(i); total+= line.GetSubtotal(); } return total; }

29 29 Test & Party! Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

30 30 Construction Phase iterations Do the same for each Use Case Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

31 31 Promote and Sell the System! Inception Phase Elaboration Phase Capture Requirements Model Domain Construction Phase Analysis Design Coding Testing Transition Phase

32 32 Summary The implementation model is easily derived from the conceptual model and the sequence/collaboration diagrams. Patterns are standardised solutions to common problems A case study illustrated the usage of UML in different steps of the Unified Process.

33 33 What is next? This week Workshop on Class Diagram (Implementation Model) Next week Feedback on workshop exercises Discuss the assignment


Download ppt "1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris"

Similar presentations


Ads by Google