The document discusses two software architecture styles: generalization and layered. Generalization style uses inheritance to capture common properties between similar entities, emphasizing an "is-a" relationship. Modules in this style can inherit properties from parent modules to reduce complexity and enable reuse. Layered style organizes modules into logical groupings or layers that build upon each other. Each layer provides well-defined services to layers above it, with dependencies only flowing downward between layers. This promotes modularity, portability, and information hiding.

1. 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 - Local Change and Variation
- Extension - 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,

2. 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 P ROPERTIES
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

3. 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

4. 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.

5. References
 Documenting Software Architectures: Views and Beyond
By: Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Robert Nord;
Judith Stafford