SOFTWARE ARCHITECTURES (MODULE VIEWS AND STYLES)

INAM SOOMRO

GENERALIZATION STYLE

The concept of generalization arises when a relationship between a set of similar entities

conceptualizing the common properties and attributes from other entities are used. It

emphasizes on “IS- A” relationship between the entities. The “IS- A” relationship is a powerful

mechanism that helps to reduce the complexity of models and redundancy in specifications

and allows reuse of software components. The generalization style is an abstraction principle

which software architects use for the development and extension of the architecture and

individual components. The components capture the commonalities and variations in the

generalization style. When the module has generalization relationship, the type is more

general or parent type and all the extending types are its subtypes or children and are

considered to be the specialization of the parent type. A parent module contains all the

commonalities while the children manifest the variations. Changes made to the parent will

reflect automatically to all the children that inherit from it. Architecture defines sharing and

reusing on interface, not on implementation.

- ELEMENTS , RELATIONS AND PROPERTIES

Module: Generally an abstract and independent unit that can be used to construct more

complex units. Abstract Modules may provide a little implementation but the child that

extends abstract module must provide the implementation of the parent module or they

should be abstract as well. Children and parents are often referred to

as derived and base modules or descendent and ancestor, respectively. A module cannot be

a descendent or ancestor to itself.

Relations: The relation between the modules is “generalization” which is specialization of

“IS- A” relation. The relation can be specified as class inheritance, interface inheritance, or

interface realization.

Constraints: In generalizing the modules, one module can have more than one parent,

means it support the idea of multiple inheritances but it is considered to be an evil design

decision and can lead to the ambiguity of deadly diamond of death. A child module cannot

be a generalization of its parent.

Generalization in software architectures is used for:

- Object Oriented Design

- Extension

- Local Change and Variation

- Reuse

NOTATION FOR THE GENERALIZATION STYLE

- UML: In UML modules are typically shown as classes or interfaces. Class and interface

inheritance is represented as a solid line with a closed hollow arrowhead. For example,

Shape is a more general type, Circle or polygon or any other shape that satisfy the shape

criteria can be inherited from the shape where arrow points towards the more general type.

Interface realization is also a kind of generalization and in UML it is represented as a dashed

line with a closed hollow arrowhead pointing towards the interface it realizes, it can also be

expressed with a lollipop interface connected towards the module that implements it.

- SEI Architecture Expert(ArchE) is a tool and method for architects to define the

architectural design of the system from new requirements and already existing piece of

components. It is an approach to defining software architectures by constructing the design

process on the architecture’s quality attribute requirements. It follows a recursive

decomposition process where, at each stage in the decomposition, tactics and architectural

patterns are chosen to satisfy a set of quality attribute scenarios.

LAYERED STYLE

Layer is an architectural design pattern that helps to construct software applications so that

they can be decomposed into subgroups so that each subgroup is at a particular level of abstraction.

In this case subgroups are also layers where each layer provides a cohesive set of services. One layer

is linked to other layer with the constraint of “allowed to use” in unidirectional top to down way.

Layered architectures provide modifiability and portability.

Layers have been a source of ambiguity because the architects allow the lower layers to

communicate with layers in upward direction while the usage usually flows in downward direction.

Systems with the upward direction are not strictly according to the definition, layered. The relation

in layers is “allowed to use”. For example, layer A and B are said to be in a relation “allowed to use”

when implementation of layer A is allowed to use the services provided by layer B. Software architect

must provide the description of the exceptions in the layering style, if any, to the usage rules implied

by the geometry. Layering style has evolved from time to time and contains different styles that will

be discussed below.

ELEMENTS, RELATION AND PROPERTIES

Layers: A cohesive collection of modules. A module can be a web service, a routine in assembly language. A module needs to provide an interface from where the services can be invoked. Elements: The modules that a layer contains are said to be the elements of a layer. Architects are supposed to provide the description and guideline of the contents and implementation of layers. Relation: The relation is “allowed to use” where a layer can use the other layer in downward unidirectional style. Constraints: Allowed to use must satisfy the layering definition criteria and there are supposed to be at least two or more layers, it must not contain any loopholes or backward flows.

What Is It for

Layers are a principal way of information hiding, a change to a lower layer, can be hidden behind its

interface and cannot impact the upper layer. Layering approach has been successfully used to

support portability, scalability and modifiability, it promote reuse and addresses separation of

concern. Layers may also define the task assignment within the development teams, for example, the

modules with presentation, business logic and model layers can be assigned to frontend developers

and backend developers respectively. Organizing the modules into layers with interfaces is an

important tool for managing complexity and communicating the structure to developers.

NOTATION FOR THE LAYERED STYLE

- Stack: An orderly pile of boxes that is denoted by geometric adjacency with allowed to use

relationship that can only be read unidirectional from top to down. A connection between

the stacks of layers can also be shown symbolically with arrow.

- Segmented Layers: Division of sections inside layers that signify fine-grained aggregation

between modules. It uses the allowed to use relationship with preexistent modules

(imported modules). Architects must specify the description of rules between the segments.

Top layer Segments are not allowed to use each other but the segments in bottom layers

can.

- Rings: Layers are represented as a set of concentric circles where the innermost circle

resembles a lower layer and the outmost layer resembles the top level layer. Ring layers can

be segmented inside the circle but the only difference from the segmented layers is, they are

not permitted to practice “allow to use” relation within the layer.

- Layers with a Sidecar: A layered diagram like stack layered diagram with an exception of

module or layer attached to the side of the diagram. These types of diagram can be read in

two ways. Let A, B, and C be a stacked layered diagram with D layer attached to it as a

sidecar, (i) it may mean that a layers A, B, C are allowed to use the D(sidecar) layer, or (ii) D

can use the layers A, B, and C. Or they can mean both, which is not a good layered

architectural design, architects must specify the rules for such kind of design, and ambiguity

and it must be resolved with annotations. In some cases, layered architecture can be

represented three dimensionally that can be accessible to all other layers. These kinds of

design often represent utility libraries or special platform services like operating system.

- UML: UML do not have the syntactic elements for layering architecture but they can be

expressed by stereotyped package notation with stereotyped allow to use relation to show

the dependency between the layers. Dependencies are not transitive.

ASPECTS STYLE

An architectural style used to isolate the modules that are responsible for crosscutting concerns.

Aspects are modular units that complement objects to modularize the cross cutting concerns. Cross

cutting concerns are aspects or logical parts of a program that crosscut other concerns or modules.

Cross cutting concerns often cannot be clearly decomposed and usually result in code duplication

and dependencies between different modules, resulting in loss of modularity. During software

development, the business logic ends up mingled with code that deals with crosscutting concerns.

The implementation of a concern is duplicated if its code is spread out over multiple modules. The

implementation of a concern is dependent if its code is intermixed with code that implements other

concerns. The module in which duplication occurs is not cohesive. For example, in a banking

Management System, the modules can be Account, Customer and Bank Employee, the account

module will contain the code to deal with account’s business logic related to open/close account,

deposit, transfer and withdraw money, but practically we need to handle crosscutting concerns such

as security, transaction management, and logging. Logging exemplifies a crosscutting concern

because logging affects every logged part of the system. Logging in that way crosscuts all logged

classes and methods.

The purpose of Aspect-Oriented design is to provide a systematic means to modularize components

by allowing separation of crosscutting concerns. The modules are called aspects. The aspects view

contains the information to wire each aspect module to other modules. The goal of applying aspects

style is to allow separation of cross cutting concerns to improve the modifiability of modules that

deals with business domain functionality. Thus logging, security and transaction management

concerns can be easily implemented without cluttering the business logic code with details of the

crosscutting concerns.

ELEMENTS, RELATION AND PROPERTIES

Elements: Aspect modules are the elements of Aspects Style which is a special type of module

introduced in Aspect Oriented Programming.

Relation: The relation in Aspect Oriented Paradigm is considerably is crosscuts. An aspect crosscuts

a module if it contains crosscutting functionality.

Properties: Pointcut, point of execution in the application at which cross-cutting concern needs to

be applied. Pointcuts are used primarily by advice (additional code that we want to apply to our

existing model).

What Is It for

Aspects style is used to address the implementation of crosscutting concerns; it promotes modularity

and achieves modularity by allowing separation of concerns. It avoids tangling and scattering of code

between the modules.

NOTATIONS FOR ASPECTS STYLE

UML: UML does not have any syntactical elements to represent aspects, but aspects types are

symbolized in UML as classes with stereotypes because aspects are similar to classes and they may

contain attribute, operations and inheritance hierarchy. Crosscut relation can also be represented as

a stereotyped dependency to the modules it crosscut. Drawing a line for crosscut is impractical and

would clutter the diagrams, instead of drawing a line from each aspect to every module it crosscuts

simply add comment box that characterizes what other modules will be crosscut.

References

Documenting Software Architectures: Views and Beyond

By: Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Robert Nord;

Judith Stafford