1 / 29

Object-Oriented Software Engineering U sing UML, Patterns and Java

Object-Oriented Software Engineering U sing UML, Patterns and Java. Software & Classical Vs Object oriented Software Eng. The Nature of Software. Software is intangible Hard to understand development effort Software is easy to reproduce Cost is in its development

nuwa
Download Presentation

Object-Oriented Software Engineering U sing UML, Patterns and Java

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 EngineeringUsing UML, Patterns and Java Software & Classical Vs Object oriented Software Eng.

  2. The Nature of Software... Software is intangible • Hard to understand development effort Software is easy to reproduce • Cost is in its development • in other engineering products, manufacturing is the costly stage The industry is labor-intensive • Hard to automate

  3. The Nature of Software ... Untrained people can hack something together • Quality problems are hard to notice Software is easy to modify • People make changes without fully understanding it Software does not ‘wear out’ • It deteriorates by having its design changed: • erroneously, or • in ways that were not anticipated, thus making it complex

  4. The Nature of Software Conclusions • Much software has poor design and is getting worse • Demand for software is high and rising • We are in a perpetual ‘software crisis’ • We have to learn to ‘engineer’ software

  5. Types of Software... Custom • For a specific customer Generic • Sold on open market • Often called • COTS (Commercial Off The Shelf) • Shrink-wrapped Embedded • Built into hardware • Hard to change

  6. Types of Software Differences among custom, generic and embedded software

  7. Types of Software Real time software • E.g. control and monitoring systems • Must react immediately • Safety often a concern Data processing software • Used to run businesses • Accuracy and security of data are key Some software has both aspects

  8. Short Term Vs. Long Term Quality Short term: • Does the software meet the customer’s immediate needs? • Is it sufficiently efficient for the volume of data we have today? Long term: • Maintainability • Customer’s future needs • Scalability: Can the software handle larger volumes of data?

  9. The Object-Oriented Paradigm

  10. The Object-Oriented Paradigm The structured paradigm was successful initially • It started to fail with larger products (> 50,000 LOC) Postdelivery maintenance problems (today, 70 to 80 percent of total effort) Reason: Structured methods are • Action oriented (e.g., finite state machines, data flow diagrams); or • Data oriented (e.g., entity-relationship diagrams, Jackson’s method); • But not both

  11. The Object-Oriented Paradigm (contd) Both data and actions are of equal importance Object: • A software component that incorporates both data and the actions that are performed on that data Example: • Bank account • Data: account balance • Actions: deposit, withdraw, determine balance

  12. Structured versus Object-Oriented Paradigm Information hiding Responsibility-driven design Impact on maintenance, development

  13. Strengths of the Object-Oriented Paradigm (contd) Well-designed objects are independent units • Everything that relates to the real-world object being modeled is in the object—encapsulation • Communication is by sending messages • This independence is enhanced by responsibility-driven design (see later)

  14. Strengths of the Object-Oriented Paradigm (contd) A classical product conceptually consists of a single unit (although it is implemented as a set of modules) • The object-oriented paradigm reduces complexity because the product generally consists of independent units The object-oriented paradigm promotes reuse • Objects are independent entities

  15. Responsibility-Driven Design Also called design by contract Send flowers to your father in America • Call 1-800-flowers • Where is 1-800-flowers? • Which American florist does the delivery? • Information hiding • Send a message to a method [action] of an object without knowing the internal structure of the object

  16. Classical Phases vs Object-Oriented Workflows

  17. Analysis/Design “Hump” Structured paradigm: • There is a loose binding between analysis (what) and design (how) Object-oriented paradigm: • Objects enter from the very beginning

  18. Analysis/Design “Hump” (contd) In the classical paradigm • Classical analysis • Determine what has to be done • Design • Determine how to do it • Architectural design — determine the modules • Detailed design — design each module

  19. Removing the “Hump” In the object-oriented paradigm • Object-oriented analysis • Determine what has to be done • Determine the objects • Object-oriented design • Determine how to do it • Design the objects The difference between the two paradigms is shown on the next slide

  20. In More Detail Objects enter here

  21. Object-Oriented Paradigm Modules (objects) are introduced as early as the object-oriented analysis workflow • This ensures a smooth transition from the analysis workflow to the design workflow The objects are then coded during the implementation workflow • Again, the transition is smooth

  22. The Object-Oriented Paradigm in Perspective The object-oriented paradigm has to be used correctly • All paradigms are easy to misuse When used correctly, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm

  23. The Object-Oriented Paradigm in Perspective (contd) The object-oriented paradigm has problems of its own The object-oriented paradigm is the best alternative available today • However, it is certain to be superceded by something better in the future

  24. Terminology (To what these refer) Cohesion vs. Coupling Client, developer, user Internal software Contract software Commercial off-the-shelf (COTS) software Open-source software • Linus’s Law

  25. Terminology (contd) Software Program, system, product  Methodology, paradigm • Object-oriented paradigm • Classical (traditional) paradigm Technique

  26. Terminology (contd) Mistake, fault, failure, error Defect Bug  • “A bug  crept into the code” instead of • “I made a mistake”

  27. Object-Oriented Terminology Data component of an object • State variable • Instance variable (Java) • Field (C++) • Attribute (generic) Action component of an object • Member function (C++) • Method (generic)

  28. Object-Oriented Terminology (contd) C++: A member is either an • Attribute (“field”), or a • Method (“member function”) Java: A field is either an • Attribute (“instance variable”), or a • Method

  29. Thank You.

More Related