Object oriented Analysis and Design Dr. Onno van Roosmalen L A T - - PowerPoint PPT Presentation

Object oriented Analysis and Design

• Dr. Onno van Roosmalen

L

AT

EX version: Pieter van den Hombergh

Fontys Hogeschool voor Techniek en Logistiek

September 9, 2016

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Contents

Introduction classes, modules, components Design guide lines What guidelines Modularity goals Decomposability Composability Modular understandability Modular continuity Modular protection Modularity and Quality enabling factors Other guide lines Analysis vs Design OO or functional

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 2/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Introduction

It is about Objects, components and modules Design guide lines System analysis versus software design

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 3/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

What is a Module?

A module is a software fragment Characteristics:

Interface announcement Unit of development Separate compilation Unit of reuse

Examples:

C: separate .c files with interface declared in the .h file Turbo Pascal: unit Modula-2: module Java or C#: class file

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 4/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Class = Module?

Classes are the units of development in OO software.

Classes in separate files Classes are separately compiled Classes can be separately deployed

In early OO days they were also considered the elements

• f modular design.

OO design focussed on discovering and describing classes as a consequence focus was on class diagrams

This remains valid to a large extend

• However. . . Classes Are Not Enough!

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 5/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Not only Class = Module!

Classes

are modules and are localities of change NOT the elements of actual reuse

too small granularity

are grouped in packages to keep overview are deployed in components as units of replacement

Package Package Component

Object collaborations

interactions between objects are more important than

• bjects individually

collaborations are reused as a whole, difficult to deploy individually found in libraries (for a particular application aspect, e.g. UI)

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 6/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

What is a Component

A Component is

Subject to composition by third parties

Can be deployed independently “closed” (immutable)

With contractually specified interfaces

“supplied interfaces”

Explicitly specified context dependencies

“required interfaces”

Supplied Required

Component

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 7/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Component based development and OO

Interfaces of components need to be established OO is a good approach for that UML offers all notations to combine OO and CB development UML is neither OO nor CB; it is both

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 8/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Design guide lines

Objects, components and modules Design guide lines Example cases System analysis versus software design

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 9/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity and Quality

Language has Enabling Factors Designer applies Guide Lines Help to achieve Modularity Goals Help to achieve Quality Non-functional requirements

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 10/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity Goals

Required properties resulting from a “modular” design method: Decomposability Composability Understandability Continuity Protection

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 11/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity Goals: Decomposability

Modular decomposability

Break a problem into less complex sub-problems Independent enough to solve separately

Counter-example: include in each software system a global initialization module. (“temporal cohesion”)

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 12/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity Goals: Composability

Modular composability:

Individual production of software elements Which may be freely combined

Example 1: subprogram libraries. Example 2: Unix Shell conventions. Basic Unix command operate on an input viewed as a sequential character stream. Counter-example: preprocessors

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 13/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity Goals: Modular understandability

Modular understandability:

Human reader can understand each module Without having to know the others

Counter-example: sequential dependencies. ( modules which have to be activated in a certain prescribed

• rder: ABC )

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 14/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity Goals: Modular continuity

Modular continuity:

Small change in a problem specification Trigger a change of just one or small number of modules

Example 1: symbolic constants. Example 2: the Uniform Access principle. Counter-example 1: using physical representations. Counter-example 2: static arrays.

Change in program Change in spec

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 15/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity Goals: Modular protection

Modular protection:

Confines the effect of an abnormal conditions to the module Or at worst only a few neighboring modules Example: validating input at the source Counter-example: undisciplined exceptions

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 16/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Language has Enabling Factors Designer applies Guide Lines Help to achieve Modularity Goals Help to achieve Quality Non-functional requirements

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 17/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Enabling Factors

When does a Language enable Modularity? Syntactic units in the programming language Explicit interfaces. Whenever two modules communicate this must be obvious from their text.

No global data.

Information hiding. Every module can make a subset of its properties available to clients.

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 18/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Coupling vs cohesion

Coupling: The degree of independence of modules from each other Cohesion: The degree of the inseparability of the structural and behavioural features of a single module Achieve Weak Coupling Achieve Strong Cohesion

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 19/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Coupling

Coupling: Few Interfaces. Every module should depend

• n as few others as possible

Helps achieve: understandability, composability, protection

Coupling: Direct Mapping.

The modular structure of the software should remain compatible with the modular structure obtained by modeling the problem domain Helps achieve: continuity, decomposability

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 20/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Coupling and interfaces

Coupling: Small Interfaces. If two modules communicate, they should exchange as little information as possible

Helps achieve: understandability, composability, continuity

Coupling: Hierarchical, Non-Cyclic Dependencies. There should be many clusters of modules that are independent, so they can be understood and reused separately

Helps achieve: understandability, decomposability, composability

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 21/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Non functional requirements

Language has Enabling Factors Designer applies Guide Lines Help to achieve Modularity Goals Help to achieve Quality Non-functional requirements

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 22/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Quality/Non-functional requirements

The specifically requested product qualities are expressed directly or indirectly in non-functional requirements Important external quality factors: correctness robustness extendibility reusability compatibility efficiency portability ease of use functionality timeliness

Modularity is a key technique to achieve quality

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 23/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Modularity and Quality

Correctness

modular understandability modular decomposability modular protection

Robustness

modular protection

Extendibility

modular continuity modular composability

Reusability

modular composability

Compatibility

modular composability modular continuity

Efficiency

modular composability

Portability

modular composability

Timeliness

modular composability modular continuity modular protection

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 24/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Analysis vs Design

Focus, first, is on the problem:

During analysis we attempt to model the problem

What is the structure and behavior of the System under Development

Focus, next, is on the software solution

During design we attempt to model the solution

How do we implement that behavior with the Software under Development

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 25/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

The Object-Oriented Paradigm

Object-oriented modeling is a way of decomposing systems

A system is specified using a collection of loosely connected entities, called objects. Each object is responsible for performing specific tasks. Objects can request services (tasks) from each other. System behavior emerges from the chaining of such service requests. Each object has structure and behavior Every object is an instance of some class (i.e. type). The behavior of an object is dictated by this class. All instances of a class will behave in a sufficiently similar fashion in response to a similar request.

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 26/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Causal versus Physical relations

In the physical world:

The furnace does not send a message to its fault indicator The switch does not send a message “on” to the furnace In fact, often a digital control system is an intermediary There is, however, a causal relation in the behavior of these objects

First we need to know the behavior of the system

In terms of cause and effect

independent of how the control physically works

Specification or “analysis”:

describe this behavior using objects with structure as well as behaviour

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 27/28

Object ori- ented Analy- sis and Design ROO,HOM Introduction

classes, modules, components

Design guide lines

What guidelines

Modularity goals

Decomposability Composability Modular understandability Modular continuity Modular protection

Modularity and Quality

enabling factors Other guide lines Analysis vs Design OO or functional

Why not Function Orientation?

Program = Algorithm + Data

Two approaches to structure systems

Function oriented: Algorithm Architecture Object oriented: Algorithm + Data Architecture

Abstract data types offer supertype as additional abstractions

Basis for a rich design pattern language

A system is never one function

No strict stepwise refinement on functions

A system is always one object

An object can be strictly hierarchically decomposed

Objects offer a set of services

ROO,HOM/FHTenL Object oriented Analysis and Design September 9, 2016 28/28