Object-Oriented Design & Methodology CS 312 OO Modeling CS 214 Fall 2011

1. Object-Oriented Design & Methodology CS 312 OO Modeling CS 214 Fall 2011

2. There will be a two hours lab. • We will work on Rational Rose software. It is recommended to install it in your machine.

3. Introduction: form UML and C++: A Practical Guide To O-O Development Richard C. Lee

4. Currently: • Software projects costs are going up and hardware • costs are going down • Software development time is getting longer and • maintenance costs are getting higher • Software error getting more frequent while hardware • errors becomes almost rare. • Software is developed using a rigid structured • process that is inflexible.

5. Software project costs by development phase Work step % Requirements 3 Design 8 Programming 7 Testing 15 Maintenance 67

6. Modern Corporations are headed toward disaster Any corporation decisions based on the output of incorrect software can threaten the ability of a business to be financially strong tomorrow

7. Success 16.2% Challenged 52.7% Impaired 31.1% Projects

8. Successfulprojects deliver full functionality on-time and on-budget

9. Challenged projects deliver, but less than full functionality, over-budget, and late

10. Impairedare cancelled during development

11. For 1995, the cost of challenged and impaired projects was $1400 billion in USA

12. Many projects are started with the wrong goals and find themselves having to start over again from the beginning. • Starting over does not support delivering at the original deliver date. • Standish Group found that for every 100 Projects that start, there are 94 restarts.

13. Approximately 28% of projects exhibit cost overruns of 150% to 200% of their original cost estimate.

14. A common joke about delivering software: Do you want it on time or fully functional

15. What does the customer want • A customer wants a solution that: • Meets functional requirements • Adapts to the rapidly changing business environment. • Fits the run time (time/Space) constrains

16. A customer wants a software that is: • Maintainable • Developed within budgeted resources ( time/ space / people ) • Designed with appropriate longevity in mind

17. Classical (structured, data modeling, ad hoc, etc ) Development Object-Oriented

18. A Student Guide Object-Oriented Development Carol Britton & Jill Doake

19. Course Aim To look at how a software system is developed using an object orientated approach

20. System Life Cycle – Why? • Need an agreed framework for the development • Identify milestones • Structure activities • Monitoring deliverables

21. System Life Cycle – Why? • Advantages of agreed framework • An overall picture of the development process • A basis for development • Consistency in approach • Ensures quality • Structure for planning, monitoring and controlling the development process

22. Traditional High Level System Life Cycle Note - Stage names reflect activities carried out at each stage

23. Problems with Traditional Approach • Functional Decomposition • Functions and data separated • Data accessible by several processes Major problem - data not protected • Poor modularity • Data versus function

24. Problems with Traditional Approach • Functional Decomposition • Poor modularity • Ideally modules should be self-contained • Have well defined purpose • Be independent Major problem – interdependency between modules • Data versus function

25. Problems with Traditional Approach • Functional Decomposition • Poor modularity • Data versus function • System functionality is more likely to change than the data • Over time the functionality is more unstable than the data

26. The Object-Orientated Approach Phases (stages) of Development • Inception • Elaboration • Construction • Transition These indicate the state of the system at each phase NOT the activities involved at that point in development

27. The Object-Orientated Approach Phases (stages) of Development • Inception – the initial work required to set up and agree terms for the project. Includes establishing the business case • Feasibility • Basic risk assessment • Scope of the system to be delivered

28. The Object-Orientated Approach Phases (stages) of Development • Inception • Elaboration – deals with putting the basic architecture of the system in place • All main project risks are identified • Construction • Transition

29. The Object-Orientated Approach Phases (stages) of Development • Inception • Elaboration • Construction – involves bulk of work on building the system • Ends with beta-release of system • Transition

30. The Object-Orientated Approach Phases (stages) of Development • Inception • Elaboration • Construction • Transition – process involved in transferring the system to the clients and users

31. Workflows • The activities implied by the stages in a traditional structured modelling approach are referred to as Workflows in the object-orientated approach • Workflows - • Requirements • Analysis • Design • Implementation • Testing

32. PHASES WORKFLOWS Requirements Inception Analysis Elaboration Design Construction Implementation Transition Workflows - activities

33. The Object-Orientated Approach Iterative Process - • Workflows may be carried out during any phase of development • In each phase a range of workflows (activities) may be carried out several times before moving on to the next phase

34. The Object-Orientated Approach Requirements Analysis Design Implementation Testing A range of workflows (activities) take place during the development of a system

35. I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n The Object-Orientated Approach An iterative process. The ellipses represent iterations of workflows (requirements, analysis, design, implementation, testing)

36. The Object-Orientated Approach A seamless Development Process • Phases less distinct than in a structured approach • Difficult to say when one phase ends and another begins • Driven by a single unifying idea – the object

37. The Object • Basic building block • Objects in the real world translate into objects in the software system • Physical (customers, products) • Conceptual (orders, reservations • Organisation (companies, departments) • Implementation (GUI Windows)

38. The Object-Orientated Approach • The foundation of all development work is the object • No new system models introduced at different stages • Early models developed and refined through the development process • An iterative design process

39. Modelling • To capture the whole of a system we need to view it from different aspects • Each diagram provides some but not all of the information – abstraction • Each model is an abstraction of the complete system • System is broken down into small workable chunks - decomposition

40. Unified Modelling Language - UML • A notation or language for development • Not a development method • Set of diagrammatic techniques • Industry standard for modelling OO systems • UML Creators – Ivar Jacobson, Grady Booch, James Rumbaugh

41. Principal UML Models

42. State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams Class Diagrams Object Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Use Case Diagrams Activity Diagrams Collaboration Diagrams Sequence Diagrams Model Deployment Diagram The UML Provides Standardized Diagrams

43. Unified Modeling Language (UML) “A graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system.” [Booch]

44. UML in One Sentence The UML is a graphical language for • visualizing • specifying • constructing • documenting artifacts of a software-intensive system.

45. Visualizing • explicit model facilitates communication • some structures transcend (pass or more) what can be represented in programming language • each symbol has well-defined semantics behind it

46. Specifying The UML addresses the specification of all important analysis, design, and implementation decisions.

47. Constructing • Forward engineering: generation of code from model into programming language • Reverse engineering: reconstructing model from implementation • Round-trip engineering: going both ways

48. UML and Blueprints The UML provides a standard way to write a system’s “blueprints” to account for • conceptual things (business processes, system functions) • concrete things (C++/Java classes, database schemas, reusable software components)

49. In UML, we have a state diagram for • dynamic behavior. The state diagram • shows: • State • Transition • Event • Condition • Action

50. Structural Modeling: Core Elements