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

Slides:



Advertisements
Similar presentations
Object-Oriented Analysis and Design
Advertisements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Object Design Examples with GRASP
ZEIT2301 Design of Information Systems Behavioural Design: State Machines School of Engineering and Information Technology Dr Kathryn Merrick.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Object-Oriented Analysis and Design CHAPTERS 12-14: INTRODUCTION TO DESIGN 1.
Feb R. McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Software Engineering I Object-Oriented Design
© Copyright Eliyahu Brutman Programming Techniques Course.
Object-Oriented Analysis and Design
GRASP : Designing Objects with Responsibilities
Objectives Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop interaction diagrams based on the principles.
Fall 2009ACS-3913 Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Date: 1753 an interpretation.
Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative Development Part III Elaboration Iteration I – Basic1.
Object-Oriented Design. From Analysis to Design Analysis Artifacts –Essential use cases What are the problem domain processes? –Conceptual Model What.
Objectives Design Class Diagrams Issues in system design Generalization Review UML papers.
The Design Discipline.
Systems Analysis and Design in a Changing World, Fifth Edition
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after identifying requirements, create domain model, define responsiblities.
1 Chapter 17 GRASP Design Patterns: Designing Objects with Responsibilities.
1 SAD2 - UML 2 nd Lecture Sequence Diagram and other dynamic views Lecturer: Dr Dimitrios Makris
Systems Analysis and Design in a Changing World, 6th Edition
12 Systems Analysis and Design in a Changing World, Fifth Edition.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Architecture GRASP Realization of use cases in interaction diagrams Design class diagram Design ( how )
Object-Oriented Analysis and Design An Introduction.
INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker.
BTS430 Systems Analysis and Design using UML Design Patterns.
GRASP: Designing Objects With Responsibilities
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
11 Partnership for Performance How to hear this lecture Click on the icon: to hear the narration for each slide.
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Design Patterns. Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Copyright © Craig Larman All Rights Reserved Responsibility-Driven Design with the GRASP Patterns.
Systems Analysis and Design in a Changing World, 3rd Edition
GRASP: Designing Objects with Responsibilities
© 2005 Prentice Hall9-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
♦ Use Case Model  Detailled use case - Important  Use case diagram- Refactoring Use case diagram  > 1 Last Lectures.
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Object Design and Use- Case Realizations with GRASP Patterns.
What to remember from Chap 13 (Logical architecture)
Object Oriented Design Jerry KotubaSYST Object Oriented Methodologies1.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
Introduction to OOAD and the UML
Patterns Roberto Damiani Mendes. Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP.
Advanced Object-Oriented Design Patterns and Architectures Part One COEN396A John Xiao
INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker.
SAD2 - UML Lecturer: Dr. Dimitrios Makris 1st Lecture
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
OO Methodology Elaboration Phase Iteration 1- Part 3.
Fusion Design Overview Object Interaction Graph Visibility Graph Class Descriptions Inheritance Graphs Fusion: Design The overall goal of Design is to.
11 Systems Analysis and Design in a Changing World, Fifth Edition.
1 M206 Chapter 31: An Overview of Software Development 1.Defining the problem 2.Analyzing the requirement – constructing initial structural model 3.Analyzing.
Elaboration: Iteration 2. Elaboration: Iteration 2 Basics Iteration 1 ends with : All the software has been tested: The idea in the UP is to do early,
Elaboration popo.
GRASP – Designing Objects with Responsibilities
The Movement To Objects
GRASP: Visibility and Design
GoF Patterns (GoF) popo.
Chapter 12: Collaboration Diagram - PART2
Conception OBJET GRASP Patterns
Chapter 11: Collaboration Diagram - PART1
DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
The Object Oriented Approach to Design
GRASP : Designing Objects with Responsibilities
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Object Oriented System Design Responsibilities
Presentation transcript:

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

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

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

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 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 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 Some GRASP Patterns Expert Creator High Cohesion Low Coupling Law of Demeter Controller Façade Class

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 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 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 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 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 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 Façade Pattern

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

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 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 client application

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

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

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 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: 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 Activity Diagram Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

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

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 Implementation Model (Class Diagram) Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

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 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 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 Test & Party! Inception Phase Elaboration Phase Capture Requirements Model Domain Design Architecture Construction Phase Analysis Design Coding Testing Transition Phase

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 Promote and Sell the System! Inception Phase Elaboration Phase Capture Requirements Model Domain Construction Phase Analysis Design Coding Testing Transition Phase

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 What is next? This week Workshop on Class Diagram (Implementation Model) Next week Feedback on workshop exercises Discuss the assignment