Object-Oriented Analysis and Design

1. Object-Oriented Analysis and Design An Introduction

2. The Need for Software Blueprints • Knowing an object-oriented language and having access to a library is necessary but not sufficient in order to create object software. • Much more than programming involved • Analysis and design provide software “blueprints” • Blueprints are illustrated by modeling language • e.g. Unified Modeling Language (UML). • Tool for thought and a form of communication

3. Object-Oriented Analysis • An investigation of the problem (rather than how a solution is defined) • Emphasis is on finding and describing the objects (or concepts) in the problem domain. • For example, concepts in a Library Information System include Book, and Library.

4. Object-Oriented Design • Emphasis is on conceptual solution that fulfils requirements • Need to define software objects and how they collaborate to fulfill the requirements. • e.g., a Book software object has title attribute and getChapter() method. • Designs then implemented in a programming language • e.g., a Book class written in Java

5. Booktitleprint() From Analysis to Implementation Analysis (investigation of the problem) Design (logical solution) Construction (code) Book (concept) public class Book { public void print(); private String title;} Representation in analysis of concepts Representation in an object–oriented programming language (e.g. Java) Domain concept

6. Applying UML • UML is just a standard diagramming notation. • A tool which helps you communicate visually with others in creating software • Learn Object-Oriented Analysis and Design, not how to draw diagrams.

7. Key Steps and Diagrams • Define Use Cases • Part of Requirements Analysis • Stories or scenarios of application use • Define a Domain Model • Part of Object-oriented Analysis • Identify noteworthy domain concepts, attributes and associations (not software objects) • Called a Conceptual Object Model

8. Key Steps and Diagrams (continued) • Assign Object Responsibilities and Draw Interaction Diagrams • Part of Object-oriented Design • Sequence Diagrams or Communication Diagrams show message flow and method invocation • May define behavior of operations with a contract • Dynamic view of objects • Define Design Class Diagrams • Describe Class definitions including attributes, methods, and relationships • Static view of classes

9. Functional Requirements • Requirements are system capabilities and conditions to which the system must conform. • Functional requirements are Features and capabilities • Recorded in Use Case model • Recorded in systems features list of the Vision artifact.

10. Non-functionalRequirements • Usability (Help, documentation, …), • Reliability (Frequency of failure, recoverability, …), • Performance (Response times, availability, …) • Supportability (Adaptability, maintainability,) • Recorded in the Use Case model or in the Supplementary Specifications artifact.