Software architecture

  1. Introduction

Definition: the fundamental organization of system

Input: Software requirements specification (SRS)

Output: Software design description (SDD)

Architecture Styles

Definition: Abstracts the common properties of a family of similar design, also known as "architecture pattern"

Key components:

Elements: perform functions required by system

Connectors: enable communication among elements

Constraints: define how elements can be integrated

Attributes: advantages & disadvantages of structure

Quality attributes

Sample quality attributes:

Reliability: Continue to keep operating over time not causing exception

Portability: Run on numerous platforms

Usability: How the user use system effectively and the ease of learn

Security: resist or block malicious or unauthorized attempts that affect the system

Testability: How well to perform tests

Maintainability: Easy to maintain and support changes cost-effectively

Availability: Raito of available system time to total working time

Flexibility: Ability of a system to adapt to future changes

Interoperability: Communicate or exchange data with other systems

Scalability: Handle demand for stress caused by increased usage without decreasing perfomance

Performance: response to actions within a period of time

Quality attributes trade-off

  1. Models for Software architecture

UML diagram

View models

Purpose: Visually representing a system along with its elements to better understand, alter, maintain or document about system

2 major categories

Structural (Static): Show the hierarchy or structure of components or module of the system and show how they interact

Behavioral (Dynamic): show the dynamic behavior of the objects in system

Show a set of classes, interfaces and their relationship

Show set of objects and relationships which is the static instances

Show internal structure of a classifier and interaction with environment

Show a set of components and relationship that illustrates the static implementation view of system

Represented by a tabbed folder such as namespace in .NET and packages in Java

Describe the physical configuration of system

An overview of use cases, actors and their communication with system

Representations of workflows of stepwise activities and actions

Event-oriented diagram used for behavior of a part of a designed system through finite state transitions

Time-oriented interaction diagram used for showing the chronological sequence of messages between objects

Describes the control flow of the interaction

Message-oriented diagram summarizes how objects in the system receive and send messages. Equivalent to sequence diagram

Is new in UML 2.0 combining the state diagram and time sequences to show the dynamic view of state change caused by external event over time

A model is a simplified description of a system from a particular perspective or viewpoint

logical view: objects and their interactions

Support by Interaction diagram, Sequence diagram, Communication diagram, State machine diagram & Activity diagram

process view: system activities, their concurrency and synchronization

Support by Activity diagram

physical view: mapping of software into hardware, server and network

Support by Deployment diagram

development view: software static structure within given development environment

Support by Component diagram

scenario view: real world scenario

  1. Object oriented paradigm (method)

OO principles

Encapsulation: Only exposes the selected information

Inheritance: Entities can inherit attributes from other entities

Polymorphism: Entities can have more than one form

Abstraction: Hides complex details to reduce complexity

Static polymorphism: implement multiple method with the same name but different params which called method overloading

Dynamic polymorphism: A subclass can override a method which called method overriding

Relationship among classes

Composition: class 2 lives and dies with class 1 and class 2 cannot stand by itself

Aggregation: class 2 is a part of class 1 but both have a separate life time

  1. Taxonomy of Architectural styles

Data flow architecture

Data centered architecture: A data store will reside at the center of this architecture and is accessed frequently by the other components that update, add, delete or modify the data present within the store

Hierarchical architecture

Implicit Asynchronous communication architecture

Batch Sequential architecture

Pipe and filter architecture

Process control architecture

Applicable domain:

Control flow: The flow of logic determined by the current data status

Suit for large complex information system

Benefits:

Limitations:

Control flow is implicit

Easy to backup & restore

Scalability and reusability of agents (components): easy to add new components

Control flow is explicit

Reduce overhead of transient data between components

Mostly for embedded systems

Data store reliability and availability is very important

High dependency between data store and its agents (components)

Overhead cost of moving data on network on distributed system

Limits

Applicable domain

Data are batched

Each sub-system reads related input files and writes output files

Control flow: Clients control the logic flow

Benefits

Each sub-system can be a stand-alone program working on input data and producing
output data

Simple divisions on sub-systems

Data store is passive

Clients are active

Implementation requires external control

Does no provide interactive interface

Concurrency is not supported and hence throughput remains low

High latency

Applicable domain

Data store is active

Clients are passive

Suitable for solving open-ended and complex problems (AI)

Exhaustive searching is impossible and impractical

Applicable Design Domain

Benefits:

Scalability: easy to add new knowledge source

Whenever the system can be broken into a series of
processing steps over data streams

Whenever the data format on the data streams is
simple and stable
and easy to be adapted if it is necessary.

Concurrency: all knowledge sources can work in parallel

Reusability of knowledge source

Benefits

Concurrency

Reusability

Modifiability

support experimentation for hypotheses

Limitations:

Simplicity

Flexibility

Tight dependency between the blackboard and knowledge source

Limits

Not suitable for dynamic interactions

Difficult to make a decision

Low Common Denominator

Difficult to configure a P&F system dynamically

Synchronization of multiple agents is an issues

Debugging and testing is a challenge

Main subroutine architecture

Buffered

Non buffered

Master-slave architecture

2 partitions:
Event sources
Event listeners

Layered architecture

Virtual machine architecture

Applicable domain

Interactive GUI component communication

Integrated Development Environment (IDE) tools

Applications that require loose coupling between
components

Implementation of state machine

When event handlings in the application are not
predictable.

Benefits

Framework availability

Reusability component

System maintenance and evolution

Independency and flexible connectivity

Possibility of parallel execution of event handlings

Limits

Difficult to test and debug the system

The event trigger cannot determine

Tight coupling between event sources and their listeners

Reliability and overhead of indirect invocations may be an issue

3 partitions:
Message producers
Message consumers
Message service providers

click to edit