Architectural Design

Common Coupling:

Two modules have write access to the same global data, modules are exposed to more data than necessary

Layered Architecture:

Used for building new facilities on top of existing systems Used to model the interfacing of sub-systems. Organizes the system into a set of layers (or abstract machines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.

Model-View-Controller (MCV) pattern:

Used for web-based application systems, where future requirements and interaction are unknown Separates presentation and interaction from the system data. System is structured into 3 components that interact with each other: Model component manages system data and associated operations View component defines and manages how the data is presented to the user Controller component manages user interaction and passes these to the view and/or model components

Informational Cohesion:

module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure (switch statement)

Functional Cohesion:

module performs exactly one action. more reusable, corrective maintenance is easier, fault isolation, reduced regression faults & easier to extend product

Architectural design decisions:

A creative process which differs from system to system being developed A number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system

4+1 view model of software architecture

A logical view: which shows the key abstractions in the system as objects or object classes. A process view: which shows how, at run-time, the system is composed of interacting processes. A development view: which shows how the software is decomposed for development. A physical view: which shows the system hardware and how software components are distributed across the processors in the system. Related using use cases or scenarios (+1)

Key Points:

A software architecture is a description of how a software system is organized. Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used. Architectures may be documented from several different perspectives or views such as a conceptual view, a logical view, a process view, and a development view. Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages.

Architectural Design:

Concern with understanding how a software system should be organized and designing the overall structure of that system. Critical link between design and requirements engineering; Identifies the main structural components in a system and the relationships between them

Module

Contiguous sequence of program statements, bounded by boundary elements, with aggregate identifier such as Low level: procedures and functions, objects and methods High level: packages, subsystems

Stamp Coupling:

Data structure is passed as parameter, but called module operates on only some of individual components. Passes more data than necessary

Coupling:

Degree of interaction between two modules Five Levels of Coupling: (Best) 5. Data 4. Stamp 3. Control 2. Common 1. Content (Worst)

Cohesion:

Degree of interaction within module Seven levels of cohesion (Best) 7. Functional 6. Informational 5. Communicational 4. Procedural 3. Temporal 2. Logical 1. Coincidental (Worst)

Architectural Views:

Each architectural model only shows one view or perspective of the system; Logical view, Physical view, Development view, Process view

Agility and Architecture:

Early stages of agile processes are to design the overall systems architecture Refactoring the system architecture is expensive

Coincidental Cohesion:

Module performs multiple, completely unrelated acitons, should be broken down into specialized modules to accomplish one task

Procedural Cohesion:

Module performs series of actions related by procedure on multiple data values, these should be BROKEN UP INTO SMALLER SPECIALIZED MODULES!!!

Communicational Cohesion:

Module performs series of actions related by procedure to be followed by product but all actions operate on the same data, BREAK UP!!!!

Temporal Cohesion:

Module performs series of actions related in time, each weakly related to each other- better suited in proper specialized modules

Logical Cohesion:

Module performs series of related actions, one of which is selected by calling module (recursive but not correct recursive)

Good vs Bad in Modules:

Modules themselves are not 'good', they must be designed to interact efficiently and reliably with eachother

Content Coupling:

One module directly references contents of the other. It's bad, because changes to one module requires changes to the other

Control Coupling:

One module passes an element of control to the other, bad because modules are not independent

Architectural patterns:

Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. Patterns should include information about when they are and when the are not useful. Patterns may be represented using tabular and graphical descriptions.

Pipe and filter architecture:

Used in data processing applications, where inputs are processed in separate stages to generate related outputs Functional transformations process their inputs to produce outputs. May be referred to as a pipe and filter model (as in UNIX shell). Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. Not really suitable for interactive systems.

Repository Architecture:

Used when a system with large volumes of information are generated that has to be stored for a long time Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems; Each sub-system maintains its own database and passes data explicitly to other sub-systems. When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an efficient data sharing mechanism.

Client-server architecture:

Used when data in a shared database has to be accessed from a range of locations, or when the load on a system is variable. Distributed system model which shows how data and processing is distributed across a range of components. Can be implemented on a single computer. Set of stand-alone servers which provide specific services such as printing, data management, etc. Set of clients which call on these services. Network which allows clients to access servers.

Data Coupling:

every argument is either a simple argument or a data structure in which all elements are used by the called module GOOD! maintenance is easier; HIGH cohesion, WEAK coupling