Object-Oriented Analysis and Design

• Analysis focuses on investigating the problem and its requirements before devising a solution.
• Design focuses on creating a conceptual solution that meets the requirements rather than focusing on implementation details.
• Useful analysis and design can be summed up as "do the right thing" for analysis, that is "do the analysis right", and "do the thing right" for design,.

Object-Oriented Analysis and Design (OOAD)

• OOAD is a method used for the software development lifecycle, particularly during the analysis and design phases.
• During the Object-Oriented Analysis (OOA) stage common questions asked to define the objective are "What will my program need to do?", “What will the classes in my program be?" and “What will each class be responsible for?"
• The OOA phase investigates the problem and requirements before finding a solution.
• During the Object-Oriented Design (OOD) phase common questions asked are “How will this class handle its responsibilities?", “How to ensure that this class knows all the information it needs?" and “How will classes in the design communicate?”
• The OOD deals with finding a conceptual solution to the problem which is about fulfilling the requirements.
• During object-oriented analysis (OOA), there is an emphasis on identifying and describing the objects or concepts within the problem domain.
• During object-oriented design (OOD), there is an emphasis on defining software objects and how they collaborate to fulfill requirements.
• OOD involves understanding the application domain and building an object model, it is a style of design showing the process of object oriented decomposition
• Object-oriented design is a method encompassing the process of object-oriented decomposition and a notation for depicting logical and physical models of a system.
• During system implementation phase, object-oriented programming (OOP) is a method of implementation where programs are collections of objects, each representing a class instance, with classes organized in a hierarchy.
• OOP supports data abstractions with named operations and a hidden local state.
• Objects have an associated class type and classes inherit attributes from supertypes to subtypes.

Analysis Vs. Design - Classes

• In analysis you identify who a class is, what is the same or different, and what does it contain.
• While in design you determine what states the class has and what behaviors is should imlement.

Analysis Vs. Design - Attributes

• In analysis you need to identify what a class needs to know.
• While in design you add implementation-specific components, human interaction, data management and other implementation areas.

Analysis Vs. Design - Behaviors

• In analysis you identify what can a class do.
• While in design you add implementation-specific components, human interaction, data management and other implementation areas.

Analysis Vs. Design - Collaborations

• In analysis you identify what help is needed, and also who needs help.
• While in design you add implementation-specific components, human interaction, data management and other implementation areas.

OOA, OOD, and OOP Relationship

• The product of OOA serves as models to start an OOD which can then be used for implementing a system using OOP methods.
• OOA develops an object model of the application domain
• OOD develops an object-oriented system model to implement requirements
• OOP realizes an OOD using a programming language like Java or C++.

Steps for Object-Oriented Analysis

• Analyze the domain problem and describe the process of systems.
• Identify the objects and specify attributes.
• Define operations.
• Define and establish Inter-object Communication mechanism.

Steps for Object-Oriented Analysis - Generic Steps

• Elicit customer requirements for the system and identify scenarios for use-cases.
• Select classes and objects and identify attributes and operations for each system object.
• Define structures and hierarchies that organize classes and build an object-behavior model.
• Review the OO analysis model against use cases or scenarios.

Identifying Objects

• When identifying objects consider: individuals, organizations, machines, units of information, images, whatever makes sense.
• When identifying objects consider: external entities, things, places, organizational units, and transactions.
• When rejecting candidate objects consider: duplicates, objects which exists in the problem domain but what are not intended (irrelevant), objects which do not have a clear meaning (vague).
• Common rejection reasons include: being too general, existing as an attribute of an object, actually be existing as a relationship between objects, just describing the role the object plays.

Candidate objects example

• The text provides an example of a candidate object model for car park access, and rejection rules.

Object Oriented Analysis Approaches

• During Domain Analysis one identifies classes that are common to all applications in a specific domain.
• This methodology relies on the fact that there are very few truly unique kinds of software systems.
  • Survey the architecture of existing systems in that domain.
  • Define key abstractions and mechanisms and evaluate which can be used in the new system.
• During Scenario Planning/Use-Case Analysis identify operations patterns by users starting some sequence of interrelated events.
• Key is to group the primary function points of the system based on related behavior or hierarchy.
• CRC (Class-Responsibility-Collaboration) cards are simple index cards with class names and columns for responsibilities and collaborations.
• Informal English involves identifying key concepts from the textual description of the problem.

Object-Oriented Design (OOD)

• OOD transforms the analysis model created using OOA into a design model that is the blueprint for software construction.
• Subsystems are major system components while objects are data and operations.
• Four important software design concepts are: Abstraction, Information Hiding, Functional Independence, Modularity.
• Analysis studies a problem domain, leading to a specification of externally observable behavior.
• Analysis is the "what" or the problem phase, design is the "how" or the solution phase.
• OOD expands the requirements model to account for the complexities introduced in selecting a particular implementation, including human interaction, data management and other implementation areas.
• Designing can be integrated with the analysis phase in a highly incremental nature.

Process Considerations

• The process begins by building an object model based on objects and relationships.
• Then iteratively refine the model, and design and refine classes, attributes, methods, structures and associations.
• Reuse existing classes rather than building new ones and design many simple classes rather than fewer complex ones.

OOAD Design Strategy

• Problem Domain Component: The OOA results are placed here directly, modified based on implementation-specific criteria. Human Interaction Component: Displays and inputs needed for human interaction.
  • The classes vary depending on the user interface, with examples including specializations of Menu, Screen, and Display.
• Data Management Component: Deals with the access and management of persistent data, whether using a flat file, relational, or object-oriented database.
• Problem domain component for implementing customer requirements directly.
• Human interaction component that implements the user interface.
• Task Management Component for controlling and coordinating concurrent tasks.
• Data management component for storage and retrieval of objects.

Object Oriented Development Models

• Object oriented analysis and design models capture class and object hierarchies.
• Booch presents a model that identifies several relevant perspectives for object-oriented development.

Understanding the Models

• A static perspective identifies the structure of classes/objects, their properties, and relationships.
• A dynamic model identifies the dynamic behavior of classes/objects with their valid stats, and the transitions between them.
• Physical models describes how classes are kept in compilable modules, and the process architecture.

Modeling Considerations

When modelling remember that English descriptions are often ambiguous and Mathematical models often frightens developers. Graphical models are a good option. Models of a system provide an overall view of the system.

Business Modelling

• UML is used for modeling business process including expressing the business processes in terms of business activities and collaborative behavior.
• Ensure that customer-oriented solutions are built, must not overlook: the environment, the roles/responsibilities of employees, the "things" that are handled by the business. Key Steps of OOAD include defining:
  • use cases, domain models, interaction diagrams, design class diagrams

Use Cases

• In use cases Requirements analysis may include a description of related domain processes.
• They are simply written stories.
• The steps involved are: Need to identify the users or actors (who), How do they use system.
• Several scenarios needed for different behaviors which are used to analyze system uses, system responsibilities.

How to Write a Use Case

• In Use Cases be sure to specify: Name, Actors and descriptions, entry conditions, flow of events, exit conditions, exceptions, special requirements.

Use Cases - Types

• The most formal are the Fully dressed—most elaborate, include all steps and variations are written in detail.

OOAD - Actors

• Primary actor: has user goals fulfilled through using services of the SuD.
• Supporting actor: provides a service to the SuD
• Offstage actor: has an interest in the behavior of the use case, but is not primary or supporting including a government tax agency.

Relationships in Use Case Diagrams:

• Association, Include, Extends, Generalization
• A «include» relationships are where include: A use cases may contain the functionality of another use case. In general it is assumed that any included use case will be called every time the basic path is run.
• A «Extends» relationship means: While developing your use cases, you may find that certain activities might be performed as part of the use case but are not mandatory for that use case to run successfully.

What is the Unified Modeling Language(UML)?

• The Unified Modeling Language is a language for defining ways to visually represent artifacts from systems.
• UML defines various UML profiles that specialize subsets of the notation for common subject areas.

Perspectives to Apply UML

• UML can be applied from a conceptual perspective which the diagrams are interpreted as describing things in a situation of the real world or domain of interest.
• UML can be applied from a Specification (software) perspective the diagrams (using the same notation as in the conceptual perspective) describe software abstractions or components with specifications and interfaces.
• UML can be applied from an Implementation (software) perspective.

UML diagrams-Classes use

• Conceptual. class in the real world or essential perspective.
• UML for modeling from the real world vs as software
• UML can be used to diagrams to capture the five views of a system: user, structural, behavioral, implementation or environmental.
• UML Structural View is made of object and class.
• Uml Building Blocks are: - Things - Relationships

OO System Development LifeCycle (SDLC):

• Software Development is the process of analysis, design, implementation, testing & refinement to transform users' need into a software solution.
• transformation 1(analysis) - translates user's need into the systems requirements
• transformation 2 design : includes definition on how to build software
• transformation (2 implemtation) - refines design into system deployment.
• Object-oriented development is highly incremental
• In waterfall (or sequential) lifecycle process there is an attempt to define (in detail) all or most of the requirements before programming so there are no unknown elements.

Iterative and Evolutionary Development.

• Iterative development includes its own requirements analysis, design, implementation, and testing activities.
• It is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system.
• It is also known as iterative and incremental development, a feedback and adaptation evolve the specifications and design

Unified Process.

• A software development process describes an approach to building, deploying, and possibly maintaining software.
• The Unified Process has emerged as a popular iterative, incremental, architecture-centric, use-case driven software development process for building object-oriented systems. -Iteravive process, gives example structure on how to ooa/d.

Requirements Process

• Requirements are capabilities and conditions which the system and project must conform. The UP promotes a set of best practices, one of which is manage requirements.
• The goal is to do it iteratively and skillfully, and not being sloppy. A prime challenge of requirements analysis is to find, communicate, and remember.

Categories of Requirements :

• Key types of requirement -Functional, Usability, Reliability, performance, supportability.
• Requirements can be organized via: use case model, supplementary specification.