Software Engineering

Software Engineering
Lecture 2
ASPI8-4
Anders P. Ravn, Feb. 2004
Your Report - 2!
1. Requirements Specification
1.1 System Definition
1.2 Problem Domain Structure
1.3 Application Domain Structure
1.3.1 Use Cases
1.3.2 Functions
1.3.3 Interfaces
1.4 Acceptance Test Specification
2. Architecture
2.1 Criteria
2.X Module Interfaces
2.T Integration Test Specification
Overview
•
•
Software Requirements
OAD in Application Domain Analysis
1. Usage
2. Functions
3. Interfaces
Architecture for Embedded Systems
Activities: application domain analysis
System
definition
and Problem
Domain
models
Interfaces
Usage
Functions
Application
Domain
Model
and
Software
Requirements
Use Case
<<actor>>
name
<<actor>>
name
name
<<actor>>
name
Activities: use case analysis
System definition
Use cases
Evaluate
systematically
Analyse
work tasks
Structure
the use
cases
Find actors and
use cases
Example:
Start tool use
<<actor>>
TractorOperator
<<actor>>
RowWeeder
start_tracking
Each use case is described textually
and/or by a behaviour diagram
Actor stereotype
start_tracking
TractorOperator
<<actor>>
RowWeeder
Functions
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
Signal
<<actor>>
System
Interfaces
Update/
Read/
Compute
Signal
IPanel
<<Interface>>
Alarm
System
Example: User Interface
Example: 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:
Application Domain Analysis
• Use Cases
• Functions
• Interfaces
Your Report - 3!
1. Requirements Specification
1.1 System Definition
1.2 Problem Domain Structure
1.3 Application Domain Structure
1.3.1 Use Cases
1.3.2 Functions
1.3.3 Interfaces
1.4 Acceptance Test Specification
2. Architecture
2.1 Criteria
2.X Module Interfaces
2.T Integration Test Specification
Design criteria
•
•
•
•
•
•
•
•
•
•
•
•
Usable
Secure
Efficient
Correct
Reliable
Maintainable
Testable
Flexible
Comprehensible
Reusable
Portable
Interoperable
Architecture
Interface Class and Dependency
Segmentation
PositionUpdate
IRow
use
<<interface>>
IRow
realise
use
Package
name
related classes
Active Class
name
Processes
• Method in passive class - called from main
• Method in passive class - linked to an Event
• Method run in active class – explicit start
Specified in UML by Statechart Diagram
Signals and Events
• Signals are asynchronous events
• A Signal or Event is a Class
• A method may have a send dependency
on a Signal
• A method that recieves a Signal
has a use dependency
Sensors, Actuators and Control
Architecture for Embedded Systems
• Sensors have passive interfaces with event
methods
• Actuators have passive interfaces with event
methods
• Control is active and uses sensors and
actuators
Your Report - 4!
1. Requirements Specification
2. Architecture
2.1 Criteria
2.X Module Interfaces
2.T Integration Test Specification
3. Modules
3.X.1 Module Interface
3.X.2 Module Design
3.X.3 Module Test Specification
4. Implementation
5. Test