![Page 1: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/1.jpg)
1
CMPT 275
High Level Design Phase Architecture
![Page 2: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/2.jpg)
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
![Page 3: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/3.jpg)
Janice Regan, 2008 3
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
![Page 4: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/4.jpg)
Janice Regan, 2008 4
System design activities
Analysis
System design
Object design
Functional requirementsNon Functional requirements
Analysis object modelAnalysis dynamic model
Design goals
Subsystem decomposition
![Page 5: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/5.jpg)
Janice Regan, 2008 5
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
![Page 6: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/6.jpg)
Janice Regan, 2008 6
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.
![Page 7: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/7.jpg)
Janice Regan, 2008 7
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
![Page 8: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/8.jpg)
Janice Regan, 2008 8
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
![Page 9: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/9.jpg)
Janice Regan, 2008 9
Pipes and filters Can deal with more complex systems that
have multiple paths through them
![Page 10: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/10.jpg)
Janice Regan, 2008 10
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
![Page 11: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/11.jpg)
Janice Regan, 2008 11
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
![Page 12: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/12.jpg)
Janice Regan, 2008 12
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
![Page 13: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/13.jpg)
Janice Regan, 2008 13
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
![Page 14: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/14.jpg)
Janice Regan, 2008 14
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
![Page 15: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/15.jpg)
Janice Regan, 2008 15
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
![Page 16: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/16.jpg)
Janice Regan, 2008 16
Repository
Project Repository
Subsystem 1 Subsystem 4
Subsystem 2
Subsystem3
Subsystem 5
![Page 17: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/17.jpg)
Janice Regan, 2008 17
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.
![Page 18: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/18.jpg)
Janice Regan, 2008 18
Example Repository: CASE Tools
Project Repository
Design EditorCode
Generator
Design Translator
Design Analyser
Program editor
Report Generator
From figure 11.2 Sommerville 2004
CASE: Computer Aided Software Engineering
![Page 19: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/19.jpg)
Janice Regan, 2008 19
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)
![Page 20: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/20.jpg)
Janice Regan, 2008 20
Client-server
NETWORK (or IPC on one host)
Client subsystem 1
Client subsystem 2
Client subsystem 3
Server subsystem 2Server subsystem 1
![Page 21: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/21.jpg)
Janice Regan, 2008 21
Client-server
Internet
Client subsystem 1
Client subsystem 2
Client subsystem 3
Video serverFilm Clip Files
Catalogue serverLibrary Catalogue
Web serverFilm and photo info
Picture serverDigitized Photos
From figure 11.3 Sommerville 2004
![Page 22: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/22.jpg)
Janice Regan, 2008 22
Client-server
GameClient
GameClient
GameClient
GameServerInternet
![Page 23: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/23.jpg)
Janice Regan, 2008 23
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
![Page 24: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/24.jpg)
Janice Regan, 2008 24
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
![Page 25: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/25.jpg)
Janice Regan, 2008 25
Closed Layered Model
Layer 4t
Layer 3
Layer 2
Layer 1
X NO communications between non-adjacent
layers
![Page 26: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/26.jpg)
Janice Regan, 2008 26
Open Layered Model
Layer 4t
Layer 3
Layer 2
Layer 1
A layer can communicate with any layer below it
![Page 27: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/27.jpg)
Janice Regan, 2008 27
The OSI Layers: Layered Model
Expanded from Figure 1.10 Stallings (2000)
Ethernet
TCP/IP
CORBA
![Page 28: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/28.jpg)
Janice Regan, 2008 28
Multi TierLayer 4
Presentation client
Layer 3Presentation server
Layer 2Applications Logic
Layer 1Storage
Form
Browser
Connection
query
![Page 29: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/29.jpg)
Janice Regan, 2008 29
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
![Page 30: CMPT 275 High Level Design Phase Architecture](https://reader035.vdocuments.us/reader035/viewer/2022062501/5681661d550346895dd96dce/html5/thumbnails/30.jpg)
Janice Regan, 2008 30
Example