1 CMPT 275 High Level Design Phase Architecture. Janice Regan, 2008 2 Objectives of Design The design phase takes the results of the requirements analysis

1

CMPT 275

High Level Design Phase Architecture

Janice Regan, 2008 2

Objectives of Design The design phase takes the results of the requirements

analysis phase and evolves these results further

Use cases and use case diagrams

Context diagram, requirements, class diagrams, state diagrams …

The results of the design phase feeds directly into the implementation phase

Requirements analysis → WHAT the system must do

Next Goal: determine HOW the software system is to accomplish what it must do


Map of design phaseDESIGN

HIGH LEVELDESIGN

Modularization

User Interface

Module Interfaces

Data PersistanceSubsystem

User Manual

architecture

LOW LEVELDESIGN

ClassesClass Interfaces

Interaction Diagrams

Implementation

System design or

object design or


System design activities

Analysis

System design

Object design

Functional requirements

Non Functional requirements

Analysis object model

Analysis dynamic model

Design goals

Subsystem decomposition


Objectives of system design Transforms analysis model (from

requirements analysis) into a system design model

System decomposition Identify design goals (choose aspects of the system to

be optimized)

Develop and refine a subsystem decomposition that satisfies the maximum number of design goals and or the most critical design goals

Identify, model system architecture


Some Architectural Styles Data Flow (Pipes and Filters)

Follow the flow of data through the system

Call and Return Single thread of control as a main program

calling subprograms then returning when done

Repository (data-centered) One or more modularized subsystems that

interact only with a central data repository Services divided into layers, communication

between adjacent layers.


Some Architectural Styles Client-server

One or more servers with different purposes, which can be used by a group of clients that need their services. Usually connected by a network.

Layered Services divided into layers, communication

between adjacent layers.

Model / View / Controller Model captures an application specific model An independent controller sequences operations


Pipes and filters: Simplest case Batch sequential

Pipe (line with arrow) represents a data flow in the direction of the arrow

Each filter (oval) represents some kind of manipulation of the data

The output of one filter is used as the input of the next filter

Commonly used model in the UNIX operating system


Pipes and filters Can deal with more complex systems that

have multiple paths through them


Pipes and filters: advantages Can evolve easily by adding new filters

Simple to implement and maintain, Can reuse filters

Intuitive, think of a task in terms of steps

Well suited to systems that apply transformations to a stream of data


Pipes and filters: limitations

Needs a common format for data transfer If formats of output/input of filters vary only

some filters can be paired

Filters in a system must agree on a common data format, individual filters must then translate that format into what they need internally (can be inefficient)

e. g. UNIX uses character strings


Pipes and filters: Invoice processing

Payments

Receipts

Invoices

Reminders

From figure 11.6 Sommerville 2004

Read invoicesIdentify

Payments

Issue ReceiptsIssue Payment

Reminder

Find

Payments Due


Call and Return Hierarchical transfer of control between

processes

Control passes from the calling process to the called, then when the called process is complete, back to the called process

main


Repository Architecture All subsystems interact only with a central data

repository Subsystems will themselves be modularized

A cohesive group of modules are often grouped into a subsystem

An efficient way to store large quantities of data

No need to transmit data directly between subsystems Data used by a subsystem always from the repository

Data produced by a subsystem stored in the repository


Repository Architecture Data is stored with one format

Format must be common to all modules. This enforces compromises on the form of the data which may effect efficiency of some modules

Can be difficult to change (evolve) the format of the data

Some activities are centralized with the repository and must be consistent for all subsystems Access control, Security, Backup


Repository

Project Repository

Subsystem 1 Subsystem 4

Subsystem 2

Subsystem3

Subsystem 5


Repository architecture If the repository is a passive object, it only

interacts with subsystems when the subsystems request it

However, the repository may be an active object that can request actions from the other subsystems in the system.

When the repository initiates actions of the other subsystems then the architectural style is know as a blackboard system.


Example Repository: CASE Tools

Project Repository

Design EditorCode

Generator

Design

Translator

Design

Analyser

Program

editor

Report

Generator


CASE: Computer Aided Software Engineering


Client Server Architecture A set of one or more servers provide services to

other subsystems Print server File server Data base server

A set of clients (often client is a subsystem) use the services provided by the servers.

Concurrent operation of more than one client is possible

The clients and servers are connected by a network (optional can all exist on one host but usually are distributed between several hosts)


Client-server

NETWORK (or IPC on one host)

Client

subsystem 1

Client

subsystem 2Client

subsystem 3

Server subsystem 2Server subsystem 1


Client-server

Internet

Client

subsystem 1

Client

subsystem 2Client

subsystem 3

Video server

Film Clip Files

Catalogue server

Library Catalogue

Web server

Film and photo info

Picture server

Digitized Photos



Client-server

GameClient

GameClient

GameClient

GameServerInternet


Advantages/Disadvantages Well suited for systems that manage large

amounts of data. (distributed or multiprocess)

Can be generalized to a peer-peer architectural style where each subsystem can both provide and request services

Can be seen as a special case of the repository where the central data store is managed by a process Gives more flexibility, subsystems can different access

control, security, backup as controlled by managing process


Layered Architecture Subsystems are seen as layers

Layers can be independently developed, updated, replaced, subdivided.

Each layer implements a set of services not offered by other layers

In a closed layered architecture there is no communication between layers that are not adjacent. So only adjacent layers are effected if the inter subsystem interface changes


Closed Layered Model

Layer 4

t

Layer 3

Layer 2

Layer 1

X NO communications between non-adjacent

layers


Open Layered Model

Layer 4

t

Layer 3

Layer 2

Layer 1

A layer can communicate with any layer below it


The OSI Layers: Layered Model

Expanded from Figure 1.10 Stallings (2000)

Ethernet

TCP/IP

CORBA


Multi TierLayer 4

Presentation client

Layer 3

Presentation server

Layer 2

Applications Logic

Layer 1

Storage

Form

Browser

Connection

query


Model/View/Controller

Model: maintains all domain knowledge

Controller, manages sequence of interaction with the user

View: Display model to user

Controller

Model

View

initiatorrepository

Subscriber

*

1 Notifier


Example

Documents

1 CMPT 275 High Level Design Phase Architecture. Janice Regan, 2008 2 Objectives of Design The design phase takes the results of the requirements analysis