33
Addressing design Goals We decompose the system to address complexity Assigning each subsystem to team to work on But we also need to address system wide issues

Addressing design Goals We decompose the system to address complexity Assigning each subsystem to team to work on But we also need to address system

Embed Size (px)

Citation preview

Addressing design Goals

We decompose the system to address complexity

Assigning each subsystem to team to work on

But we also need to address system wide issues

Hardware /Software Mapping

What is the Hw configuration of the system?

Which node is responsible for which functionality?

How nodes communicate?

This leads for adding new subsystems

Components should be encapsulated to minimize dependency

Data management

Which data should be persistent? How they are accessed?

This is very important

Most systems need access their data This should be fast

What DBMS we need?

Access Control

Who can access which data?

Can we change it dynamically?

It should be consistent

Control Flow

How does the system sequence operations?

More than one user at same time?

Event driven?

Boundary Conditions

How the system is initialized?

How it is shut down?

How are exceptional cases detected and handled?

UML Deployment Diagrams

Depicts the relationship between run-time components and HW

Component are self contained entities that provide services to other components

Example: web server provides service to web browser

Web browser provides service to user

A distributed system can be composed of many interacting run-time components

In UML deployment diagrams: Nodes are represented by boxes

containing components

Dependencies are dashed arrows

A component can be refined to present interfaces and its classes

Mapping subsystems to HW:selecting a HW configuration Many systems run on many computers Connect using internet

This is good choice for high performance

And serving distributed users

We need to decide on: Allocation of subsystems to computers Communication support

We also need select virtual machines OSs DBMS Communication package

MyTrip Remember: two subsystems

PlanningSubsystem RoutingSubsystem

Clearly they run on two different machines WebServer OnBoardComputer

What about virtual machines? Unix Safari IExplorer

Allocating objects and subsystems to nodes This triggers new objects and

subsystems

RoutingSubsystem and PlanningSubsystem need to communicate..!!!

So we introduce new subsystem: CommunicationSubsystem

We also notice that only segments need to be stored at RoutingSubsystem

So we need another object called proxy

We add SegmentProxy and TripProxy

Draw the revised design pattern

Identifying persistent data

We need to store data

Remember a special subsystem for storage in repository model

In MyTrip

We need to store trip information in OnBoardcomputer Car

In case of system shutdown during trip

We will use file storage

Most efficient choice

What about PlanningSubsytem? We need to store:

Maps Trips

We will choose database coz: Complex queries Multiple users

So we add two subsystems TripFileStoreSubsystem MapDBStoreSubsystem

Identifying persistent objects Entity objects But not all of them, example:

Location Direction

All objects that must survive shutdown

Selecting a storage management Flat files RDBMS

Concurrency Recovery Access control Large quantities of data Complx queries

Object-Oriented Databases Stores data as objects and associations Slower than RDB in typical queries

Providing access control In my trip, storing maps and trips

brings up security concerns So here what we do:

Introduce new class: Drive

PlanningSubsystem is responsible for authentication

CommunicationSubsystem encrypt data

What about multi-user environment We need Access Matrix

Rows are actors

Columns are controlled objects

Entry: access right has list of operations

How do represent Access Matrix? Global Access table:

Actor + class + operation tuple Slow Requires space

Access control list: Associates (actor, operation) with class Like guest list

Capability association Associates (class, operation) with actor

Use of FireWalls Protect services located on intranets

from other hosts

According host, port,

They allow or deny packets to reach their destinations

Firewalls access is specified using list of rules

Searched sequentially As in table 7-3

Access matrix is static access control

But consider a bank IS, a broker is assigned a set of portfolios…..dynamically

Broker should access his own portfolios

So we should model access rights dynamically

Dynamic access control We use proxy design patter

Access

isAccessable(op)

Broker

PortfolioProxy

Buy()Sell()Estimate)(

Use of proxy For each portfolio we create a proxy To

protect that portfolio

Authentication: the process of identifying the association between actor and system

Sometimes we use username and passwords

Sometimes we need more than that.

Some systems use cards = passwords

As in picti

We usually encrypt password

Make them expire

We also use encryption

Control Flow It is the sequence of actions in a

system

Which operations should be executed and in which order

1- Procedure driven control-- as in legacy systems

2- event driven

3- threads--problems in debugging --problems in testing

Boundary conditions

We need to decide on how the systems Starts Shutdown Managed And how to deal with failure (Exception

Management)

Refining System Analysis for MyTrip