topic 7summer 2003 1 ics 52: introduction to software engineering lecture notes for summer quarter,...

Topic 7 Summer 2003 1

ICS 52: Introduction to Software Engineering

Lecture Notes for Summer Quarter, 2003

Michele RousseauTopic 7

Partially based on lecture notes written by Sommerville, Frost, & Easterbrook. Duplication of course material for any commercial purpose without the written

permission of the lecturers is prohibited


Today’s Lecture

Architecture – the story continues Intro to Design


Model - View - Controller (MVC)

Model - application data and its behavior

Controller - user input

Model

View Controller

Updates Manipulates

User

Sees Uses

View - display of model

One model can beassociated withmultiple views.


Model View Controller

Special case of the Repository Model – the Model is central

3 logical parts The Model

• maintains the domain knowledge A Controller

• which manages the sequences of user interactions The View

• the UI display The View is independent


MVC Pros/Cons

Advantages• Maintains consistency • Multiple views

Disadvantages• Performance bottleneck


Event-driven systems

Driven by externally generated events where the timing of the event is outwith the control of the sub-systems which process the event

Two principal event-driven models• Broadcast models. An event is broadcast to all

sub-systems. Any sub-system which can handle the event may do so

• Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing

Other event driven models include spreadsheets and production systems


Broadcast Model

Examplesdebugging systems (listen for particular

breakpoints)database management systems (for data integrity

checking)graphical user interfaces

broadcastmedium

agent

agent

agent

agent

announceevent

announceevent

listen forevent

listen foreventbroadcast

medium


Broadcast model

Effective in integrating sub-systems on different computers in a network

Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event

Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them

However, sub-systems don’t know if or when an event will be handled


Broadcast Pros/Cons

Interesting properties (Pros)announcers of events don’t need to know

who will handle the eventSupports re-use, and evolution of systems

(add new agents easily)

DisadvantagesComponents have no control over ordering

of computations


Selective broadcasting

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


Interrupt-driven control

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

Interrupts have handler’s memory location


Interrupt-driven systems

Used in real-time systems • fast response to an event is essential

There are known interrupt types with a handler defined for each type

Each type is associated with a memory location and a hardware switch causes transfer to its handler

Allows fast response but complex to program and difficult to validate


Interrupt Driven (Pros/Cons)

Pros• Very Fast Responses

Cons• Complex to program• Difficult to validate• Difficult to change• # of interrupts limited by hardware

constraints» However can map several events into 1

interrupt


Modular decomposition

Breaking it down…• Smaller than subsystems

Another structural level where sub-systems are decomposed into modules

Two modular decomposition models covered• data-flow model (pipe & filter)

» decomposed into functional modules which transform inputs to outputs

• object model» decomposed into interacting objects

If possible, decisions about concurrency should be delayed until modules are implemented


Pipe & Filter (Data Flow Model)

Example:Compilers:

Lexical Analysis -> parsing -> semantic analysis -> code generation

filter

filterfilter

filter

filter

filter

pipe

pipe

pipe

pipe

pipe

pipe

pipe pipe

pipe


Pipe & Filter

Filters are Subsystems Filters communicate via streaming

data(Pipes)• A filter receives data from its input pipe• processes it • sends it to its output pipe

A pipe essentially connects any one filter output to any other filter input.

Any given filter would only have knowledge of its input data format and not any other filter.

one-way, sequential processing


Pipe & Filter

Interesting properties:• filters don’t need to know anything about

what they are connected to• filters can be implemented in parallel• behavior of the system is the composition

of behavior of the filters» specialized analysis such as throughput and

deadlock analysis is possible Variants of this approach are very

common.» When transformations are sequential, this is a

batch sequential model which is extensively used in data processing systems


Pipes & Filters Pros/Cons

Pros• good for transforming data streams

without user intervention• Intuitive (I/O)

Cons• However, this architecture is not well

suited for a system of complex interactions between components.

• Not really suitable for interactive systems


Invoice processing system

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments

Pipe & Filter Example


Object Models

Data hiding (internal data representations are not visible to clients)

ob

ject

ob

ject

ob

ject

ob

ject

ob

ject

methodinvocation

methodinvocation

methodinvocation method

invocation


Object models

Structure the system into• loosely coupled objects • well-defined interfaces

Objects call on services (methods) from other objects

Object-oriented decomposition is concerned with identifying…• object classes• their attributes• their operations

When implemented, objects are created from these classes and some control model used to coordinate object operations


Invoice processing system

issue ()sendReminder ()acceptPayment ()sendReceipt ()

invoice#dateamountcustomer

Invoice

invoice#dateamountcustomer#

Receipt

invoice#dateamountcustomer#

Payment

customer#nameaddresscredit period

Customer


Object Models Pros/Cons

Pros• Can decompose problems into sets of

interacting agents• Easily modified (loose coupling)• Reusability

Cons• objects must know the identity of objects

they wish to interact with• Difficult to represent complex entities as

objects


Domain-specific architectures

Architectural models which are specific to some application domain

Two types of domain-specific model• Generic models

» abstractions from a number of real systems and which encapsulate the principal characteristics of these systems

• Reference models » more abstract, idealised model. Provide a means of

information about that class of system and of comparing different architectures


Domain-specific Architectures

Generic • “Bottom-up” – built from existing systems

Reference• “Top-Down” – Abstract representations

» May not reflect the architecture of existing systems


Generic models

Compiler model is a well-known example although other models exist in more specialised application domains• Lexical analyser – converts input token into internal form

• Symbol table – holds names and types used • Syntax analyser – builds syntax tree

• Syntax tree – internal structure of program

• Semantic analyser – uses info from Symbol table and syntax tree to check semantic correctness

• Code generator – uses syntax tree to generate machine code

Generic compiler model may be organised according to different architectural models


Compiler model

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symboltable


Language processing system

Syntaxanalyser

Lexicalanalyser

Semanticanalyser

Abstractsyntax tree

Grammardefinition

Symboltable

Outputdefinition

Pretty-printer

Editor

Optimizer

Codegenerator

Repository


Reference architectures

Reference models are derived from a study of the application domain rather than from existing systems

May be used ..• As a basis for system implementation • to compare different systems.

It acts as a standard against which systems can be evaluated

OSI (open systems interconnection) model is a layered model for communication systems


OSI reference model

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

Application


Key points

The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model

Large systems rarely conform to a single architectural model

System decomposition models include repository models, client-server models and abstract machine models

Control models include centralised control and event-driven models


Key points

Modular decomposition models include data-flow and object models

Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models


A Professional View

Requirements

CodeArchitecture

Plans, blueprints, detailed drawings, instructions for specialists,time estimates, material requirements estimates, permits, etc.


Architecture, in Software and Building

Requirements: user signs off on the “big picture” and some but, realistically, not all, details.

Implementation plan: time frame, number of workers, their skills and availability.

Detailed cost estimate. Modularize: divide task into smaller parts. Interface with existing buildings / neighborhood

/ related software systems. Important design decisions that are invisible to

the user: type of girders, type of algorithm, language, database system.


Design Fundamentals - Questions

Software is multi-person•How can each programmer work

independently of the others?

Software is multi-version•How can software be designed so that it is

easy to modify?•Planned modifications•Corrective maintenance (fix flaws)•Adaptive maintenance (adjust to changing

world)•Perfective maintenance (add features)


Design Fundamentals - Answers

Modularity, for three reasons:•decompose a complex system into less

complex sub-systems; divide and conquer•(re-)use existing modules•understand the system in pieces

What makes a good module?•High cohesion: all internal parts are closely

related.•Low coupling: modules rely on each other as

little as possible•Each module hides its internal structure.


A Good Design…

…is half the implementation effort!• Rigor ensures all requirements are addressed• Separation of concerns

»Modularity allows work in isolation because components are independent of each other

»Abstraction allows work in isolation because interfaces guarantee that components will work together

• Anticipation of change allows changes to be absorbed seamlessly

• Generality allows components to be reused throughout the system

• Incrementality allows the software to be developed with intermediate working results


A Bad Design…

…will never be implemented!• Lack of rigor leads to missing functionality• Separation of concerns

»Lack of modularity leads to conflicts among developers

»Lack of abstraction leads to massive integration problems (and headaches)

• Lack of anticipation of change leads to redesigns and reimplementations

• Lack of generality leads to “code bloat”• Lack of incrementality leads to a big-bang

approach that is likely to “bomb”


Design

Architectural design• High-level partitioning of a software system

into separate modules (components)• Focus on the interactions among parts

(connections)• Focus on structural properties

(architecture)» “How does it all fit together?”

Module design• Detailed design of a component• Focus on the internals of a component• Focus on computational properties

» “How does it work?”


Architectural Design

A simple diagram is not enough• It is only a start

Additional decisions need to be made• Define the primary purpose of each

component• Define the interface of each component

» Primary methods of access/use» As complete as possible

Always requires multiple iterations• Cannot do it right in one shot• Use the fundamental principles

topic 7summer 2003 1 ics 52: introduction to software engineering lecture notes for summer quarter,...

Documents