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. 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; } Domain concept Representation in analysis of concepts Representation in an object–oriented programming language (e.g. Java) Book title print()

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 1. Define Use Cases Part of Requirements Analysis Stories or scenarios of application use 2. 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) 3. 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 4. 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-functional Requirements 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.