Software architecture
0 likes963 views
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.
Software architecture
- 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