1 / 34

Object Oriented Software Engineering

Object Oriented Software Engineering. Abstraction Phases Lifecycle Models. Abstraction. The OOP Fundamental:. By looking at the problems of software engineering: Low understandability Fragility Redundancy Complexity Unreliability …

fabian
Download Presentation

Object Oriented Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object Oriented Software Engineering Abstraction Phases Lifecycle Models

  2. Abstraction

  3. The OOP Fundamental: By looking at the problems of software engineering: • Low understandability • Fragility • Redundancy • Complexity • Unreliability … We Conclude that the fundamental problem can be described as -- Lack Of Abstraction!

  4. Abstraction: What does it mean? • 1. “Human”-like reasoning • Higher-level concepts • Examples: Vehicle (general), initialization (automatic), modularity (support in logical vs. physical) • … as opposed to Machine concepts: • Memory, pointer, file, B-tree, ... • 2. Distinguish essence from detail • Interface vs. Implementation • What vs. How • Analysis vs. Design

  5. OOP = Abstraction Techniques • Encapsulation • Support logical modularity • Information Hiding • Distinguish interface from implementation • Inheritance • Support hierarchical abstractions • Polymorphism • Same source code applies to many types

  6. Which Abstractions Are Necessary? • Common abstractions • Window • open, move, minimize, close … • A data structure • Insert, remove, find, sort … • File • open, close, read, write, goto-offset(size), … • 3D object • rotate, color, combine … • Processed data report • sort_by_column, column_contents, compute_column, … • …

  7. How to Achieve Abstraction I: Enlarge The Language • Add the abstractions to the language! • Create a version of the language for each domain: • For manipulating GUI • For creating monetary reports • For managing data structures • For manipulating files • … • Drawbacks: • restricted to a specific domain • Inefficient • Reason: Adding words complicates the language!

  8. How to Achieve Abstraction II: Special Purpose Languages • Application generators • Magic • Target-specific languages • GUI generators • GUPTA, Power-Builder, Visual Basic, Magic, ... • Database managers • Arrive along with a database: Access, Oracle, ... • 4th Generation Languages • Specification languages • Z, Larch

  9. How to Achieve Abstraction III: OOP The general solution: A language for generating abstractions! Abstractions In OOP: Human concepts are translated to objects, their relations may stand for relations in the human model

  10. Phases in O-O Software Development Analysis Design Implementation

  11. Activities in Software Evolution • Requirement Specification • Architectural specification • Prototyping • Development • Analysis • Design • Implementation • Coding • Integration • Validation • Testing • Verification • Maintenance • Debugging • Adaptation to clients’ requirements • Adaptation to changes in hardware

  12. Distinguish Analysis from Design!

  13. “The goal of the analysis is to fully specify the problem and the application domain without introducing a bias to any particular implementation.” (Rumbaugh et. at, p.187) Analysis Phase: Purpose

  14. Object Oriented Analysis • Provide a rigorous model of the system’s behavior • Rephrase the requirements using O-O concepts: • Classes • Objects • Inheritance • Composition • etc. Remember: Relate only to the problem domain!

  15. Requirements Specification Object Oriented Design Object Oriented Analysis Method • OOA formalizes the requirements specification into OOP terminology: words, sketches, informal diagrams classes, objects, relations

  16. OO Analysis & Design Techniques • Use Cases • Factoring • “Nouns and Verbs” • CRC Cards • Storyboard Scenario: Example 2 • Data Dictionary

  17. A High Level of Abstraction • Simulate the problem domain • Purpose: Increase understandably and maintainability of the system • Relevant relations and agents must appear in the model • Types and relations are implied by the problem • Examples: student, transaction, engine, abstract data types (list, set, etc.), mathematical expressions • Artifacts of solutions are not allowed! • Examples: OS terms, memory management, interrupts, concrete data structures (linked list, vector, etc.)

  18. OOA: The Advantage As abstraction is the main concern we achieve -- • A better language for modeling the problem domain (the requirements) • Classes, objects, and messages: Close to human concepts • Smooth transition to the implementation • Classes, objects, and message: Supported by the programming language

  19. Object Oriented Design • Design the artifacts required in the implementation of the system • Carry out the analysis • Focus on the solution domain • Produce “complete” specification • Introduce previously ignored considerations of: • Performance • Reliability • Security • Persistence

  20. Products • A complete specification of the system • Architecture: Modules, libraries, directories, … • Software and hardware configuration • Network, protocols, file system, database, … • Finalize development decisions • Development tools and environment • Programming language, compiler, debugger, class libraries • Project management until delivery • E.g., Configuration management • Global design decisions • Exception handling, persistence, built-in quality measures

  21. Directions of Design Progress • “Top Down” • Recursively partition the problem into sub-problems until tractable sub-problems are defined • “Bottom Up” • Begin with known solutions and existing resources and adapt them to match the problems

  22. OOD Techniques • Most of the techniques used for the analysis can be used during the design phase: • Factoring, merging, and splitting classes • CRC specifications • Storyboard scenarios • Sketch Class, object, interaction, and state diagram

  23. Lifecycle Models

  24. The Waterfall Model • W. Royce 1970 • Linear order of phases • For each phase: • Input • Process • Output

  25. The Waterfall Model: Correction • The waterfall model is based on the assumption that humans don’t make mistakes • It designates as an ideal that is never true • Feedback is a must:

  26. Pros of the Waterfall model • Think, then implement: • Analysis • Design • “The only possible model” • All steps are essential • No “documentation step” • Order is the only logical one! • Any reasonable alternative

  27. Cons of the Waterfall model • Changes that go back more than one stage! • E.g., flaws in the requirements can surface during design • Assumes synchronous progress: • The integration nightmare! • No support for continuos maintenance • 60%-80% of software cost • Huge risk factor: code shows up very late • Stubborn bugs • Unexpected performance bottlenecks • Dangerous hidden assumptions in design • Need for unavailable external factors and resources

  28. Design Implementation Analysis Validation The Spiral Model B. Boehm 1988 Multiple iterations • Iterations stand for reduced abstraction • Each iteration: • Analyze results of previous cycle • Determine risk • Build a prototype

  29. Identify classes and objects Specify class/ Identify class/ object interface & object semantics Implementation identify class/ object relationship The “Rational” Model (Booch) Booch 1990 • Macro process • Identical to the Waterfall model • Micro process • Four iterative stages • No “starting point”

  30. OPEN Model Graham I. M. 1995 Develop each component separately • Non-deterministic progression order between activities • Each activity has pre- and post-conditions

  31. OUTCOME: results UNIT: project ECONOMICS: Profit TIME: short-term BRICKS: program elements STRATEGY: Top-down OUTCOME: tools, libraries UNIT: department, company, industry ECONOMICS: investment TIME: long-term BRICKS: software components STRATEGY: bottom-up Project vs. Component Development

  32. Single Product Generalization Implementation Design Analysis Components: Add Generalization Stage • During the generalization stage: • Make it right • Make it fast • Make it small • Make it better • Make it general • Resist the temptation to: • Over specialize • Tweak performance

  33. Component Model: Summary • Pros: • Early feedback to customers • Incremental customer transition to new system • Early integration • Better distribution of testing resources • Improve team morale and motivation: • Working system at hand • Ease integration • Cons: • What is a component?

  34. Feasibility Study ProjectTime Division into Clusters D G A I G D A I D G A I G D A I ProjectTime The Component Life Cycle Model

More Related