PowerPoint Presentation

Architectural Design

Fontys University of Applied Sciences

Group 4

Overview

Introduction

Architectual desicions

System Organisation

Decomposition

Control types

Conclusuion

Introduction

First DesignCommunication with Project team

System analysisPerformance

Access protection

Security

Availability

Maintenance

Architectural desicion

Fundamental questionsIs there already a pattern for that problem?

What architectual styles are suiteable ?

How could we divide in Subsystems and modules ?

Wich strategy is suitable to control the system ?

How could we evaluate our System ?

Architectural decission : Subsystem

Subsytem modelsStatic model

Dynamic process model

Interface model

Relation model

Distribution model

System Organisations Overview

Reflects the basic strategy that is used to structure a system

patterns of system organization

Three popular structuresrepository model

client/server model

layered style model

Maybe more than one structure is used in a software system

described in ADL, UML or Box-diagrams

System Organisation: repository model

Usage of central database

Single database per subsystem (de-central)Sharing data by sending messages

Pros:Large amount of data

Centralised backup, protection, access control, data recovery

Efficient way of sharing data

Cons:Subsystems needs to fit into data save model

Subsystems maybe have other requirements (e.g. other kind of access control)

System Organisation: client/server

System of multiple services and server

Multiple clients are using services

Remote procedure calls (RPC, network communication)

Pros:Shared architecture

Large amount of different services

Increase reliability

Easy to add servers and services

Cons:No combined data model

Subsystems are organising data in different ways

contingency risk

Redundant server management costs

System Organisation: layered style

Divide system into multiple layers

3 tier architecture (client, application-server, data-server)

OSI reference model

Pros:Incremental developing of systems

Easy to extend and to modify

Security

Testability

Cons:Performance, redundancy calls

add overhead and latency to the processing of data

Decomposition

Subsystem vs. ModulSubsystem :Independent System wich operations are not based on other subsystems

Include modules

Interfaces for communication with other subsystems

Modul :Part of a Subsystem ( System component )

Provides services to other components

Normaly not considered as a seperate system

Decomsposition

PartitioningObjectorientedDiffer a System in communicating Objects

Function oriented PipelineDiffer a system in functional modules that receive data and convert it to outputable data ( receive edit output )

Object

Pipeline

Control styles

Are concerned with the control flow between sub-systems. Distinct from the system decomposition model.

Centralised controlOne sub-system has overall responsibility for control and starts and stops other sub-systems.

Control styles

Event-based controlEach sub-system can respond to externally generated events from other sub-systems or the systems environment.

Broadcast model :Event is sent to every subsystem and this is programmed to handle these event

Interrupt-driven model :Extern interrupts are handled by an interrupt handler and this handler send events to other components

Only used in Real-time-environments ( airbag in cars )

Conclusion

Architectural design is important (Root of complex software systems)Structure of your system

Dividing system into multiple subsystems

System analysis and stakeholder communication

Supports models for better re-usability

Supports models for different non-functional requirements

Questions?