Object-Oriented Analysis and Design

An Introduction

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

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.

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

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 conceptRepresentation in analysis of concepts

Representation in an object–oriented programming language (e.g. Java)

Booktitleprint()

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.

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

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

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.

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.