Your SlideShare is downloading. ×
SOFTWARE ARCHITECTURES (MODULE VIEWS AND STYLES)                                        INAM SOOMROGENERALIZATION STYLE   ...
Shape is a more general type, Circle or polygon or any other shape that satisfy the shape        criteria can be inherited...
support portability, scalability and modifiability, it promote reuse and addresses separation ofconcern. Layers may also d...
implementation of a concern is dependent if its code is intermixed with code that implements otherconcerns. The module in ...
References    Documenting Software Architectures: Views and Beyond     By: Paul Clements; Felix Bachmann; Len Bass; David...
Upcoming SlideShare
Loading in...5
×

Software architecture

918

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
918
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Software architecture"

  1. 1. SOFTWARE ARCHITECTURES (MODULE VIEWS AND STYLES) INAM SOOMROGENERALIZATION 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. 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 thatthey 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 layeris 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 tocommunicate 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 relationin 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 architectmust provide the description of the exceptions in the layering style, if any, to the usage rules impliedby the geometry. Layering style has evolved from time to time and contains different styles that willbe discussed below.ELEMENTS, RELATION AND P ROPERTIES Layers: A cohesive collection of modules. A module can be a web service, a routine in assemblylanguage. 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 aresupposed 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 downwardunidirectional style.Constraints: Allowed to use must satisfy the layering definition criteria and there are supposed tobe at least two or more layers, it must not contain any loopholes or backward flows.What Is It forLayers are a principal way of information hiding, a change to a lower layer, can be hidden behind itsinterface and cannot impact the upper layer. Layering approach has been successfully used to
  3. 3. support portability, scalability and modifiability, it promote reuse and addresses separation ofconcern. Layers may also define the task assignment within the development teams, for example, themodules with presentation, business logic and model layers can be assigned to frontend developersand backend developers respectively. Organizing the modules into layers with interfaces is animportant 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 STYLEAn 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. Crosscutting 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 duplicationand dependencies between different modules, resulting in loss of modularity. During softwaredevelopment, 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. 4. implementation of a concern is dependent if its code is intermixed with code that implements otherconcerns. The module in which duplication occurs is not cohesive. For example, in a bankingManagement System, the modules can be Account, Customer and Bank Employee, the accountmodule 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 suchas security, transaction management, and logging. Logging exemplifies a crosscutting concernbecause logging affects every logged part of the system. Logging in that way crosscuts all loggedclasses and methods. The purpose of Aspect-Oriented design is to provide a systematic means to modularize componentsby allowing separation of crosscutting concerns. The modules are called aspects. The aspects viewcontains the information to wire each aspect module to other modules. The goal of applying aspectsstyle is to allow separation of cross cutting concerns to improve the modifiability of modules thatdeals with business domain functionality. Thus logging, security and transaction managementconcerns can be easily implemented without cluttering the business logic code with details of thecrosscutting concerns.ELEMENTS, RELATION AND PROPERTIESElements: Aspect modules are the elements of Aspects Style which is a special type of moduleintroduced in Aspect Oriented Programming.Relation: The relation in Aspect Oriented Paradigm is considerably is crosscuts. An aspect crosscutsa module if it contains crosscutting functionality.Properties: Pointcut, point of execution in the application at which cross-cutting concern needs tobe applied. Pointcuts are used primarily by advice (additional code that we want to apply to ourexisting model).What Is It forAspects style is used to address the implementation of crosscutting concerns; it promotes modularityand achieves modularity by allowing separation of concerns. It avoids tangling and scattering of codebetween the modules.NOTATIONS FOR ASPECTS STYLEUML: UML does not have any syntactical elements to represent aspects, but aspects types aresymbolized in UML as classes with stereotypes because aspects are similar to classes and they maycontain attribute, operations and inheritance hierarchy. Crosscut relation can also be represented asa stereotyped dependency to the modules it crosscut. Drawing a line for crosscut is impractical andwould clutter the diagrams, instead of drawing a line from each aspect to every module it crosscutssimply add comment box that characterizes what other modules will be crosscut.
  5. 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

×