OOAD-summary - Aalborg Universitetpeople.cs.aau.dk/~bnielsen/ITEV-GIS09-sem2/ITEV-miniprojOOAD.pdf · OOAD-summary. Overview • Th d l ... 1.3.3 Interfaces ... 2.1 Criteria 2X2.X

OOAD-summaryOOAD summary

OverviewOverview

Th d l t• The development process• Documents• OAD in Requirements Analysis

1 Problem Domain Anal sis1. Problem Domain Analysis2. System Definition3 Class Association Dependency3. Class, Association, Dependency4. Behaviour, Event

Your Report!Your Report!

1. Requirements Specification1.1 System Definition

1 2 P bl D i St t1.2 Problem Domain Structure

1.3 Application Domain Structure

1.4 Acceptance Test Specificationp p

2. Architecture

3 Modules3. Modules

4. Implementation

5 T t5. Test

Example:Example: Computer Vison based implement guidance in row

cropsp

A rich picture

System Definition

•A concise description of a computerized system •Expressed in natural language

Example:Example:A computer system which guides an implement through crops in rows. The system must not be slower than the traditional guidance methods, and must relieve human operators of local monitoring and control tasksoperators of local monitoring and control tasks.

Example:The prototype softwareExample:The prototype software

FACTOR

A concise description of a computerized system expressed in natural languageFACTOR:FACTOR:•Functionality for end use•Application Domain of end useApplication Domain of end use•Conditions for success•Technology to be usedgy•Object System •Realization conditions

Example: FACTOR

A computer system which guides an implement through crops in rows (Application Domain) Thethrough crops in rows. (Application Domain). The system must not be slower than traditional guidance methods (Conditions), and must relieve human operators of local monitoring and control tasksoperators of local monitoring and control tasks(Functionality).The final system must be implemented on a TriMediaThe final system must be implemented on a TriMediaTRS8XX with a simple display and button userinterface (Technology and Object System)

The system shall be very dependable and inexpensive to produce (Realization Constraints)inexpensive to produce (Realization Constraints).

Problem Domain DescriptionProblem Domain Description

• Class Diagrams (things and their relations)• Selected Behaviours (events and their (

sequence)• Notes - text (interpretation of concepts)( p p )

Example: Problem Domain StructureExample: Problem Domain Structure

Example: Tractor Behaviour

Outside row

In row

Outside rowManual Autostart

stop

Example: Interaction of Tractor and Row Weeder

:Tractor :RowWeeder

lower

engage

no rowno_row

Summary: P bl D i A l iProblem Domain Analysis

• Rich Picture• System definition - FACTOR• Structure - Class Diagrams • Behaviour - Statechart Diagrams• Interaction - Sequence Diagrams• Notes

Your Report - 1!Your Report 1!

1.1. RequirementsRequirements SpecificationSpecification1.1 System Definition1.1 System Definition

1 2 P bl D i1 2 P bl D i St tSt t1.2 Problem Domain 1.2 Problem Domain StructureStructure

1.3 Application Domain Structure

1.4 Acceptance Test Specificationp p

2. Architecture

3 Modules3. Modules

4. Implementation

5 T t5. Test

Your Report - 2!Your Report 2!1.1. RequirementsRequirements SpecificationSpecification1 1 S t D fi iti1 1 S t D fi iti1.1 System Definition1.1 System Definition

1.2 Problem Domain 1.2 Problem Domain StructureStructure

1.3 Application Domain Structure

1.3.1 Use Cases

1.3.2 Functions

1.3.3 Interfaces

1.4 Acceptance Test Specification

2 A hit t2. Architecture2.1 Criteria

2 X Module Interfaces2.X Module Interfaces

2.T Integration Test Specification

OverviewOverview

• Software Requirements• OAD in Application Domain Analysis

1. Usage2. Functions

Architecture for Embedded Systems

3. Interfaces

Architecture for Embedded Systems

Activities: application domain analysis

System

Usage

definitionand Problem

Domainmodels

Interfaces

Usagemodels

Application

Functions

ApplicationDomainModel

andSoftware

Requirements

Use Case

<<actor>> <<actor>>

namename name

<<actor>>name

Activities: use case analysisActivities: use case analysis

System definition Use cases

Evaluate

Analysework tasks

systematically

Str ct rework tasks Structurethe usecases

Find actors and use cases

E lExample:Start tool use

<<actor>> <<actor>>

start_trackingTractorOperator RowWeeder

E h i d ib d t t llEach use case is described textually and/or by a behaviour diagram

Actor stereotype

start_tracking<<actor>>

RowWeederRowWeeder

TractorOperatorTractorOperator

FunctionsFunctions

The actions of actors in use cases:• Update – state change in (internal) model

• Signal – event in (internal) model• Read – (internal) model state inspection

• Compute – (internal) model state summary

Update/Read/

Compute<<actor>>

SystemSignal

System

InterfacesInterfaces

SystemIPanelUpdate/Read/

Compute

<<Interface>>AlarmSignal

Example: User InterfaceExample: User Interface

Example: Camera InterfaceExample: Camera Interface

The camera delivers JPEG compressed images with a frame rate of up to 10 per second.

The resolution is ...

The hardware interface is a DMA ...

The standard software driver is ...

Summary: A li i D i A l iApplication Domain Analysis

• Use CasesF ti• Functions

• Interfaces

Your Report - 3!Your Report 3!1.1. RequirementsRequirements SpecificationSpecification1 1 S t D fi iti1 1 S t D fi iti1.1 System Definition1.1 System Definition

1.2 Problem Domain 1.2 Problem Domain StructureStructure

1.3 Application Domain Structure

1.3.1 Use Cases

1.3.2 Functions

1.3.3 Interfaces

1.4 Acceptance Test Specification

2 A hit t2. Architecture2.1 Criteria

2 X Module Interfaces2.X Module Interfaces

2.T Integration Test Specification

Design criteriaDesign criteria• Usable• Secure• Efficient• Correct• Reliable• Maintainable• Testable• Flexible• Comprehensible• Reusable• Portable• Interoperable

Architecture

Interface Class and Dependency

IRow

Segmentation PositionUpdate

IRowuse

<<interface>>IRow

userealise

PackagePackage

name

related classes

Active ClassActive Class

name

ProcessesProcesses

• Method in passive class - called from main

• Method in passive class - linked to an EventEvent

• Method run in active class – explicit startstart

Specified in UML by Statechart Diagram

Signals and EventsSignals and Events

• Signals are asynchronous eventsSignals are asynchronous events• A Signal or Event is a Class

A th d h d d d• A method may have a send dependencyon a Signal

• A method that recieves a Signalhas a use dependencyhas a use dependency

Sensors, Actuators and ControlControl

Architecture for Embedded Systems

• Sensors have passive interfaces withevent methodsevent methods

• Actuators have passive interfaces withevent methodsevent methods

• Control is active and uses sensors and actuators

Your Report - 4!Your Report 4!1.1. RequirementsRequirements SpecificationSpecification

2. Architecture2.1 Criteria

2.X Module Interfaces

2.T Integration Test Specification

d l3. Modules3.X.1 Module Interface

3 X 2 Module Design3.X.2 Module Design

3.X.3 Module Test Specification

4 Implementation4. Implementation

5. Test