A system is a set of elements(components)that are connected to each

other to form a whole

Th ecomponents composition is called system structure

System components interact with each other,these complex interactions are called system
behaviour

The environment provides input to thesystem,and the

system answers with output

Hybrid systems,e.g. a mix between man-made and natural systems

Software is a collection of programs,related data,and related documentation.

Model is a simplified view of the system that focuses on a single

aspect of a system

Advantages of using models:

Detecting errors and omissions early in the life cycle

Examining the relative advantages of different options

Understanding the impact of change

Assisting with project planning

A software architecture is a collection of models of a software system at various abstraction andd

etail levels.

An initial system architecture isdesigned before the actual development of

the system.This architecture governs thesystem development.

The initial system architecture is iteratively updated during the

system development.

When do we need a software architecture? Complex systems

When a software architecture is not needed? We have the experience indeveloping this particular
kind of system,

i.e. we developed many such systems

Common method for software architecture:

Attribute Driven Design(ADD)

Siemens’ 4 Views(S4V) Iterate using views: conceptual, execution, module, and code

Rational Unified Process (RUP) Driven by use-cases, non-functional requirements and risks

Spiral development

Agile development

Evolutionary rapid development

The results of the requirements analysis:

Functional requirements

Non-functional requirements

Contextual requirements

Functional requirements - a technical expression of what a system will do

Approaches

(a) Structured languages: software requirements specification

(b) Formal models: e.g.state-charts

(c) Use cases: structured description of user interactions with the system

(d) User stories, e.g.narratives and personas

(e) Mock-ups,e.g. sketches of the UI

Non-functional requirements - other needs than directly functional or business related (quality
attributes). Constrains and qualities

Contextual requirements

What technologies areavailable?

Expertise of thedevelopment team(and availability of resources)

Organisation of teams,e.g.geographically dispersed

Previous experience of users/customers

Technical,business,market,legal,ethical,...
A narrative is a concrete description of a user’s interaction with the system

System narrative: informal narrative,which describes the system itself

A persona is a fictional character with certain characteristics

Request ≠ requirement

Design is the process of creating models

Two basictypes of architectural models:

Structure and behaviour

Architectural structure is the static model of the system - the components and connectors

Architectural behaviour is the dynamic model of the system - interaction of systeme components

Functionality is what the system can do and behaviour is the activity sequence

To represent behavioural models we use use-case maps

Architectural views:

1.Conceptual: components are set of responsibilities and connectors are flow of information

The conceptual architecture considers the structure of the system in terms of its domain-level
functionality

2.Execution: components are executio nunits(processes) and connectors are messages between
processes

The execution architecture considers the system in terms of its runtime structure

3.Implementation: components are libraries,sourcecode,files,etc and connectors are

protocols,apicalls,etc.

The implementation architecture considersthe system interms of its build-time structure

4.Data/information model describes the data

5.Physical model describes servers,firewalls,workstations,...

6.Deployment model describes the packaging of components

====================================================================
Conceptual Architecture focuses on domain-level responsibilities

Initial architectural design

First response to stakeholder needs

Design by analysing requirements

Contains components and connectors(box-and-line)

Initially, responsibilities arise from functional requirements

Further iterations take into account non-functional requirements

Connectors indicate that connected components exchange information

Arrows indicate information flow

Designing Conceptual Architecture:

1.Identify keyconcepts

Within requirements

Within narratives

2.Assign key concepts to categories

Data, Function, Stakeholder, System, AbstractConcept

Behavioural exploration:

Until now only structural architecture

We need to take into account behaviour of the system

Typically accomplished through usage narratives

Presentation component: interactions withusers

Persistent storage: persistent data or data from external systems

Real-timecomponents: components that handle requests “quickly”

Data models capture the nature of information in the domain

If data exchanged between components is complex we might need to create datamodels

Guidelines for defining components:

Granularity - Amount of functionality assigned to a single component

Cohesion - how well are the responsibilities of a component related to each other

Coupling - degree to which software components depend on each other

Tight Coupling:

If one software component changes,the other (dependant)

components need to be changed as well

API/protocol specific to the needed requirements

Typically it is easier (lesseffort) to create tightly coupled components

Tight coupling will typically improve the achievable performance(and traceability)

Loose Coupling:

Components can be easily exchanged

Components will be better suited to be reused

Components are required to be more generic

use standard protocols instead of custom ones

Will typically require more effort and better design/planning

Loose coupling will typically improve maintainability,evolvability,reusability

===============================================================================
==

Execution architecture focuses on the system runtime structure

Hardware elements, subsystems, processes and threads

Suited for examining quality attributes, most-notablyruntime attributes performance, security,

usability,..., but also scalability

Concurrent components

Connectors indicate that one component calls another

The arrow depicts the call direction

Synchronous communication: the calling components waits for a

response of the calledcomponent

Asynchronous communication: the calling component does not wait

for a response

Callback: The calling component receives a response asynchronously

by setting a means by which the called component can send response later

Execution Architecture Design

Less details: concurrent subsystems,processes

More details: threads

Concurrent subsystems model

A process that has a high degree of internal concurrency (threads)

should be treated as a concurrent subsystem

Created when the systems is started

Closed when the system is shutdown

Process model

You examine each concurrentsubsystem for processes

Such models will be only slightly more detailed than

concurrent subsystem models

Execution stereotypes

1.User-initiated: the component performs action because of user input

This components are always user-interfaces

2.Active: the component generates activity internally

3.Services: the component waits for requests of other componentsand

generates responses for suchrequests