OOAD using UML-Part II

1. OOAD using UML-Part II

2. Design principles • Design principle is a basic technique that can be applied to a design to make it more maintainable, flexible and extensible.

3. Design principles • Don’t repeat yourself (DRY) • Single responsibility principle (SRP) • Liskov substitution principle (LSP) • Encapsulate what varies • Program to the interface not to an implementation

4. Don’t repeat yourself (DRY)

5. DRY • Avoid duplicate code by abstracting things that are common and placing them in a single location

6. DRY

7. Single responsibility principle (SRP) • A class should have only one reason to change • Also known as high cohesion

8. Spotting multiple responsibilities

9. SRP

10. Liskov substitution principle (LSP) • Sub types must be substitutable for their base types. • Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing them.

11. Improper Inheritance • Registered customer cannot be substituted to Customer. Method calls will result in calling base class implementation.

12. Encapsulate what varies • What you hide you can change. • Minimize the impact what varies -- what changes. • By identifying what varies and hiding it (its implementation) behind an interface, then you can change its implementation without violating its contract

13. public class Class1 { public int x; } public class Client { private Class1 myClass1 = new Class1(); public int process(){ int intialValue = myClass1.x; return initialValue * 4; } }

14. public class Class1 { private int x; public int GetX() { return x; } public void SetX(int anInt) { x = anInt; } } public class Client { private Class1 myClass1 = new Class1(); public int process(){ int intialValue = myClass1.GetX(); return initialValue * 4; } }

15. public class Class1 { private String x = "0"; // x no longer an int public int GetX() { return Integer.ParseInt(x); // convert when needed } public void SetX(int anInt){ x = new Integer(anInt).ToString(); // convert back } } public class Client { private Class1 myClass1 = new Class1(); public int process() { int intialValue = myClass1.GetX(); // Client stays unchanged return initialValue * 4; } }

16. Program to the interface • Avoid referencing concrete classes, declare interfaces only • Benefits of programming to an interface: • Clients remain unaware of the classes that implement the interface • Greatly reduces implementation dependencies • Don’t declare variables to be instances of concrete classes if possible

17. Understanding Interface and Implementation • Fill the table based on reuse Interface / implementation for each relationship Relationships Interface Implementation Generalization Realization Composition

18. Understanding Interface and Implementation • Generalization • Reuse of interface and implementation • Implementation(+ Interface) Inheritance • Realization • Reuse of only interface • Interface Inheritance • Composition • Reuse of only implementation • Implementation reuse and not the interface

19. Understanding Interface and Implementation • Therefore, it is possible to equate Generalization = Realization + Composition Relationships Interface Implementation Generalization Y Y Realization Y N Composition N Y

20. The Unified Process

21. The Unified Process • Topics • The Software Development Process • What are OO Analysis and OO Design? • Activities of OOA and OOD • Waterfall versus Use Case driven approach • The Unified Process • Phases and activities • Key characteristics of the Unified Process

22. Software development Problems • Symptoms of software development problems • User or business needs not met • Requirements churn • Modules don’t integrate • Hard to maintain • Late discovery of flaws • Poor quality or end-user experience • Poor performance under load • No coordinated team effort

23. Software Development Problems • The root causes to these problems can be traced to faulty processes among other such factors • OO approach requires a very rigorous process to do things rights • The process and the methodology is the key

24. Software development process • A software development process typically consists of • Analysis • Design • Implementation • Testing • Refinement

25. What is OOA and OOD ? • Object Oriented Analysis • A method that examines requirements from the perspective of the classes and objects found in the vocabulary of problem domain • Spend more time on • Requirements gathering • Developing a use-case model • Analysis model • Object Oriented Design • Fulfilling the requirements • Static and dynamic models of the system

26. Primary activities • OO Analysis • Business process modeling • Understanding the business workflow • Activity Diagrams • Business Glossary • Business Requirements Document • Develop Use Cases • Identify users/actors • Who will use the system? • What will the users do with the system? • Use Case Documentation • Functional Specification Document • Supplementary Specification • Analysis Model • Identify ALC (Analysis Level Classes) • Business Objects • Domain Model • Dynamic modeling • Classification • Identify classes, relationships, attributes, and methods

27. Primary Activities • OO Design • Architectural Analysis • High Level Framework Design • Process Diagram • High Level View design • Database Design • High Level Design • Compliance with framework • Decomposition of Analysis classes • Detailed Architecture • Refinement of Classes and relationships • Static modeling • Refine Class Hierarchies • Apply drivers, cohesion, coupling, etc. • Design the access and view layers • Refine classes based on Low Level Design for the technology chosen

28. What How Do It Test Use Classical Waterfall • Delays confirmation of critical risk resolution • Measures progress by assessing work-products that are poor predictors of time-to-completion • Delays and aggregates integration and testing • Precludes early deployment • Conceptually straightforward because it produces a single deliverable • Pushes risk forward in time, where it is costly to undo mistakes from earlier phases • Tends to mask the real risks to a project until it is too late to do anything meaningful about them

29. Build a Use-Case Model Object Analysis Validate / Test Analysis Iteration and Reuse Design classes, define attributes and methods Build object and dynamic model Build user Interface and prototype Using TOOLS CASE and/or OO Programming Languages User satisfaction usability & QA Tests User satisfaction test, usability test, and quality assurance test Design Implementation Use Case driven ‘iterative’ approach • Resolves major risks before making large investments • Enables early user feedback • Makes testing and integration continuous • Focuses project short-term objective milestones • Makes possible deployment of partial implementations

30. Rational Unified Process • A small company is as good as its people, a large company is as good as its processes. • The RUP is a software engineering process that • enhances team productivity • delivers software best practices via guidelines, templates, and tool guidance for all critical software development activities • Combines commonly accepted best practices • Iterative lifecycle • Risk-driven development • Well documented • RUP Best Practices • Develop iteratively • Manage Requirements • Use Component Architectures • Model Visually • Continuously Verify Quality • Control Changes

31. Inception Elaboration Construction Transition Effort ~5 % 20 % 65 % 10% Schedule 10 % 30 % 50 % 10% UP phases • UP consists of 4 phases • Inception • Elaboration • Construction • Transition • Sample effort and schedule distribution

32. UP Phases & Activities • Inception • Approximate vision • Business case • Scope • Vague estimates • Elaboration • Refined vision • Iterative implementation of core architecture • Resolution of high risks • Identification of most requirements • More realistic estimates • Function Points • Use case points • COCOMO • Construction • Iterative implementation of the remaining lower risk and easier elements • Assessment of product releases against acceptance criteria for the vision • Preparation for deployment • Transition • Beta tests • Deployment • User training

33. UP Workflows (disciplines) • In its simplest form, RUP consists of some fundamental workflows: • Business Engineering • Understanding the needs of the business  • Requirements • Translating business need into the behaviors of an automated system • Analysis and Design • Translating requirements into a software architecture • Implementation • Creating software that fits within the architecture and has the required behaviors • Test • Ensuring that the required behaviors are correct, and that all required behaviors are present  • Configuration and change management • Keeping track of all the different versions of all the work products  • Project Management • Managing schedules and resources  • Environment • Setting up and maintaining the development environment • Deployment • Everything needed to roll out the project

34. UP Phases & Workflows (disciplines) • Inception • Not a requirements phase • Just a feasibility phase • Elaboration • Not just the requirements or design phase • A phase where core architecture is iteratively implemented and high risks are mitigated • Key characteristics of the Unified Process: • Iterative and Incremental • Use case-driven • Architecture-centric

35. Inception Elaboration Construction Transition Iteration 1 Iteration 2 Iteration 3 Iteration Planning Rqmts. Capture “Mini-Waterfall” Process Analysis & Design Implementation Test Prepare Release Iterative & incremental • Each iteration is a mini-waterfall • Development is organized into series of short, fixed-length mini-projects called iterations • Typical iteration duration: 2 to 4 weeks • Each iteration includes • Requirements analysis • Design • Implementation • Testing

36. UP Phases & iterations • An iteration is a complete development loop ending in a release of an executable product, an increment of the final product under development. • Key features • Multiple iterations • Cyclic feedback • Adaptation • Each Iteration begins with • Iteration Planning • Selected scenarios • Results of previous iterations • Up-to-date risk assessment • Libraries of models, code and tests • Each iteration ends with • Release • Release description • Updated risk assessment

37. One iteration Iterative Development • No rush to code • No long drawn design process • Result of each iteration is an executable but incomplete system • But not an experimental or throw-away prototype • How many iterations do I need? • On projects taking 18 months or less, 6 to 9 iterations are typical • Are all iterations on a project the same length? • Usually Iteration length may vary by phase. • For example, elaboration iterations may be shorter than construction iterations

38. Risk Profile of an Iterative Development • Constant user-feedback • Key to successful development • Allows lesser speculation • Cannot have the “90% done with 90% remaining” phenomenon • Resolve and prove the risky and critical decisions early rather than late Use Case driven

39. Use Case driven • Requirements analysis • Use cases are used to capture the requirements • Design • Identify classes from the use-cases • Implementation • Implement the use cases • Test • Verify the use cases during test

40. Why Use cases are important? • Use cases help verify that customer needs have been fulfilled. • Use cases provide major input when • Finding classes, subsystems and interfaces. • Finding and specifying test cases. • Planning iterations and system integration.

41. Case study : ATM System

42. Use case model

43. Withdraw Money use case • The sequence of actions for this use case • The bank customer identifies himself or herself. • The bank customer chooses from which account to withdraw money and specifies how much to withdraw. • The system deducts the amount from the account and dispenses the money.

44. Robustness diagram

45. Class Diagram

46. Sequence Diagram

47. RUP is architecture-centric • Architecture is defined at the first iteration itself • Architecture is multi-dimensional

48. You know you didn’t understand the UP when… • You think in terms of a superimposing waterfall on to the UP • Inception = requirements • Elaboration = design • Construction = implementation • You try to define most of the requirements before starting design or implementation • A long time is spent doing requirements or design work before programming starts • You believe that a suitable iteration length is four months long, rather than four weeks long • You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one

49. Case Study • Online Book Store.

50. The goals of the requirements workflow • To establish and maintain agreement with the customers and other stakeholders on what the system should do—and why! • To provide system developers with a better understanding of the system requirements • To provide a basis for planning the technical contents of iterations • To provide a basis for estimating cost and time to develop the system • To define a user interface for the system, focusing on the needs and goals of the users