university of toronto at scarborough © kersti wain-bantin cscc40 system architecture 1 after...

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 1

after designing to meet functional requirements,design the system to meet non-functional requirements

identify subsystems and components identify concurrency requirements allocate subsystems to processors select data management strategy select human-computer interface strategy/standards specify code development standards, style guides specify all control aspects set priorities for design tradeoffs identify testing and implementation requirements

system architecture


system architecture design of all system aspects: software, hardware, human ...

software architecture organization of classes into subsystems to satisfy non-functional requirements

physical architecture maps the software onto the hardware components

type of examples of examples of architecture elements relationshipsconceptual components/classes connectorsmodule sub-systems, modules data exports, importscode files, libraries, directories includes, containsexecution object interactions, tasks, uses, calls

threads

architecture


they should have: clearly defined boundaries fully defined interfaces with other subsystems

so that: they can be designed and constructed independently of each other the system complexity is reduced changes are localized during system maintenance afford efficient/effective processor allocation maximize reuse and portability

O-O subsystemsencapsulate a coherent set of responsibilities


<<client>>subsystemA

<<server>>subsystemB

<<peer>>subsystemC

<<peer>>subsystemC

communication between subsystemschanges to the client do notaffect the server if thecommunication remains the same

more tightly coupled and mayrequire both to be changed

divide into subsystems by...layering

separate into different levels of abstraction, layers of servicee.g. database handling VS application logic

partitioningseparate into different types of functionalitye.g. sales VS financial


layer 1

layer 2

layer 3

layer 4

closed architecture open architecture

layer 1

layer 2

layer 3

layer 4

layered subsystems

layer 2 subsystem

layer 3 subsystem

layer 2 uses theservices of layer 3

minimum dependencies between layers reducesthe impact of change

more compact, possiblybetter performance, butchange is more complex


presentation

application logic

domain

database

boundary classes -specific to an application

control classes - specific to an application

entity classes - possibly shared by several applications

DBMS - very often shared by several applications

examples different levels of abstraction

layering options within applications

presentation

business logic

database

commonly used forbusiness-orientedinformation systems


application

presentation

session

transport

network

data link

physical

misc. protocols for common activities

structures information and attaches semantics

dialogue control and synchronization facilities

breaks messages into packets, ensures delivery

selects route from sender to receiver

detects/corrects errors in bit sequences

transmits bits

OSI 7 layer model

covers every aspect of communication between two applications,incl. application processes and network hardware device control

with well-defined interface controls and standards,you can change some layers without affecting others

Open Systems Interconnection


<<application server>><<data server>> <<client>>

<<data server>> <<client>>

data application logic user interface

shared shared

2-tier and 3-tier architecture


customermaintenance

ordermaintenance

shipping

sales domain

sales database

partitions

partitioning and distributing


MVC architecture is the foundation for Mac interfaces, Windows, various Unix-based GUI environments

model-view-controller

model

controller A

view Bview A

controller B

<<propagate>>

<<access>>

<<propagate>>

<<access>>

main/corefunctionality

userinterfaces

manageupdatesto views

supports tailoring to users’ needs


model: central functionality, implement the application logic, aware of dependent view and controller components

view: presentation to user, handles the output, gets data from model, creates associated controller

controller: handles the input, trigger updates to views

propagation mechanism: enables model to inform each viewthat the model data has changed

this MVC separation allows you to plug in different front-end clients and also provides a separation in development

• model is driven by data design• controller is driven by process design• view is driven by screen design

model-view-controller


Model

Relational Database,XML Data Store

ViewHTML, J avaScript,J ava Server Pages,

Servlets

View

Enterprise J ava Beans,Messaging-Oriented

Middleware, J ava

Controller

Reference Framework ArchitectureTechnologies

www.quovera.com/whitepapers/downloads/ JavaOne2002_2645.ppt


(distributed processing)

:Client:ClientSide

Proxy:Broker

:ServerSideProxy

:Server

broker: decouples client and server components, forwards service requests to appropriate servers

proxies: insulate clients and servers from broker

distributed systems


for each thread of control, we need different logical processors

but do we need:• different physical processors• multi-tasking operating systems• a scheduler subsystem to handle constraints in response times• multi-threaded programming language• another solution?

concurrency


consider:• the number or users and their locations• varied needs for operating systems, special servers, special workstations...• Internet, intranet...• processing power needed• concurrency requirements • throughput requirements • response time

processor allocation


your choices are:• file-based with application-controlled storage/retrieval• database management system:

• relational for large data volumes and various access requirements• object-oriented for fast access and complex data structures• object-relational (new!)

data management

• number of users• response time requirements• volumes of data• throughput requirements• etc.

consider:


support:• different views of the data by different users• control of multi-user access to data• distribution of data over different platforms• security• enforcement of integrity constraints• access to data by various applications• data recovery• portability across platforms• data access via query language• query optimization

database management systems

but have significant performance overhead and enforce standard data access mechanisms

university of toronto at scarborough © kersti wain-bantin cscc40 system architecture 1 after...

Documents