Software Architecture Design and Analysis



|Software Architecture Design and Analysis |

|Software Architecture Course |

| |

| |

| |

| |

|[18-04-2009] |

| |

| |

| |

| |

1. Introduction

Software architecture is the study of large software systems, from the perspective of their structure. This is in contrast to traditional computer science approaches to the design and creation of software systems, which emphasize data structures and algorithms over structure. It concerns itself with achieving non-functional qualities (portability, scalability, performance, modifiability, inerrability, etc.) in large systems.

2. Representations (methodologies):

1. ADD method

2. ATAM method

1. ADD method:

1. What is ADD?

It is Attribute-Driven Design, a method for designing the software architecture of a system or collection of systems based on an explicit articulation of the quality attribute goals for the system(s). The method is appropriate for any quality attributes but has been particularly elaborated for the attributes of performance, modifiability, security, reliability/availability and usability. The method has been used for designing the software architecture of products ranging from embedded to information systems.

The ADD method is an approach to defining a software architecture in which the design process is based on the software’s quality attribute requirements. ADD follows a recursive design process that decomposes a system or system element by applying architectural tactics and patterns that satisfy its driving requirements. Its architecture design is developed by taking sets of quality attribute scenario inputs and using knowledge of relationship between quality attribute access and architecture. This method is based on understanding the relationship between software qualities and the architecture mechanisms used to achieve these qualities.

ADD essentially follows a “Plan, Do, and Check” cycle:

• Plan: Quality attributes and design constraints are considered to select which types of elements will be used in the architecture.

• Do: Elements are instantiated to satisfy quality attribute requirements as well as functional requirements.

• Check: The resulting design is analyzed to determine if the requirements are met.

2. ADD Goals:

The ADD method is designed to achieve two major goals:

• Supporting the earliest stages of the design process where the ability to achieve desired quality attributes is determined.

• Allowing design to begin early enough in the life cycle to support modern time-to-market requirements.

This process is repeated until all architecturally significant requirements are met.

3. ADD Steps:

[pic]

Figure 1: ADD Steps

Step 1: Confirm there is sufficient requirements information.

Step 2: Choose an element of the system to decompose. (The first time, this will likely be the entire system itself.)

Step 3: Identify candidate architectural drivers, thats to identify architecturally significant requirements that apply to the element being designed. The architecturally significant requirements are the combination of quality, business, and functional goals that apply to the element being designed and that will have the biggest impact on its architecture.

Step 4: Choose a design concept that satisfies the architectural drivers, thats to choose patterns and tactics to satisfy the architectural drivers. There are known patterns to achieve various qualities and functionality. Choose the solutions that are most appropriate for the high priority architectural drivers.

Steps 5 and 6: Instantiate architectural elements and allocate responsibilities and Define interfaces for insatantiated elements, that's to instantiate the pattern and tactics to create new design elements within the element. The new elements will be of the types dictated by the chosen pattern and tactics. Assign each new element its functionality and sketch an interface for it showing information flow.

Step 7: Verify and refine requirements and make them constraints for instantiated elements, that to refine the quality, business, and functional goals and constraints and allocate them to the newly created design elements, which will be the subject of future iterations.

Then repeat steps 1-7 until all of the drivers have been satisfied.

1 Architecture Tradeoff Analysis Method [ATAM]:

1. What is ATAM?

In software engineering, Architecture Tradeoff Analysis Method (ATAM) is a risk-mitigation process used early in the software development life cycle. It is the leading method in the area of software architecture evaluation. An evaluation using the ATAM typically takes three to four days and gathers together a trained evaluation team, architects, and representatives of the architecture's various stakeholders.

2. Proven benefits of the ATAM include:

• clarified quality attribute requirements.

• improved architecture documentation.

• documented basis for architectural decisions.

• identified risks early in the life-cycle .

• increased communication among stakeholders.

3. The following diagram displays a conceptual flow of the ATAM:

[pic]

Figure 2: The conceptual flow of ATAM

The ATAM process consists of gathering stakeholders together to analyze business drivers and from these drivers extract quality attributes that are used to create scenarios. These scenarios are then used in conjunction with architectural approaches and architectural decisions to create an analysis of trade-offs, sensitivity points, and risks (or non-risks). This analysis can be converted to risk themes and their impacts whereupon the process can be repeated.

4. Steps of the ATAM Process:

1. Present ATAM - Present the concept of ATAM to the stakeholders, and answer any questions about the process.

2. Present Business Drivers - Everyone in the process presents and evaluates the business drivers for the system in question.

3. Present the Architecture - The architect presents the high level architecture to the team, with an 'appropriate level of detail.

4. Identify Architectural Approaches - Different architectural approaches to the system are presented by the team, and discussed.

5. Generate Quality Attribute Utility Tree - Define the core business and technical requirements of the system, and map them to an appropriate architectural property. Present a scenario for this given requirement.

6. Analyze architectural approaches - Analyze each scenario, rating them by priority. The architecture is then evaluated against each scenario.

7. Brainstorm and prioritize scenarios - among the larger stakeholder group, present the current scenarios, and expand.

8. Analyze architectural approaches - Perform step 6 again with the added knowledge of the larger stakeholder community.

9. Present results - provide all documentation to the stakeholders.

2. Styles

1. Definition:

Style of software architecture is an established pattern of components with a name, such as client-server architecture. It provides a framework on which to base design.

2. Styles Types:

1. Pipe-and-Filter

• In a pipe-and-filter system the data flow in the system is in focus. There are a number of computational components, where output from one component forms the input to the next.

• This style fits a program analyzing and formatting text or data, but is not so useful for an interactive system. Because data is copied from outputs to inputs, performance is generally decreased.

[pic]

Figure 3: Two pipe-and filter systems, one very simple

Example:

A system needed to count the frequency of different words in a file:

• One approach: first split the file into a sequence of words, sort them, then count the number of occurrences. The architecture of this system can naturally use the pipe and filter style.

[pic]

Figure 4: Example

2. Object-Oriented Architecture

• An object-oriented architecture, the focus is on the different items in the system, modeled as objects, classes etc. Object orientation is one of the most widely spread architectural styles, both in education, industrial practice and science.

3. Layered Architecture

• Layered architecture, focus on the different abstraction levels in a system, such as the software in a personal computer. A stack of boxes or a number of concentric circles is often used to represent a layered architecture graphically. In its pure form, communications between the different layers must only occur in the interfaces between two adjacent layers. The style’s major drawbacks are that it is not always easy to identify the appropriate abstraction levels. It might also be the case that the system must communicate in a more complex way than is implicated by the layering, due to performance considerations.

[pic]

Figure 5: The layered architecture of a personal

4. Blackboard Architecture

• A blackboard (or repository) architecture draws the attention to the data in the system. There is a central data store, the blackboard, and agents writing and reading data. The agents may be implicitly invoked when data changes, or explicitly by some sort of external action such as a user command. Blackboard architecture is described in Figure 3, where the central data store is represented by the rectangle, agents by the ellipses, and the arrows denote requests to read and write data.

[pic]

Figure 6: A blackboard (repository) architecture

Example:

• A student registration system of a university, Repository contains all the data about students, courses, schedules… and accessors like admin, approvals, registration, reports which perform operations on the data.

• Components do not directly communicate with each other. It is easy to extend if a scheduler is needed, it is added as a new accesso , no existing component needs to be changed. Only one connector style in this – read/write

[pic]

Figure 7: Example

5. Client-Server Architecture

• This architecture is especially fit when the hardware is organized as a number of local computers (e.g. personal workstations) and one central resource such as a file tree, database, or a cluster of powerful central calculation computers.

[pic]

Figure 8: A view of a (hardware) client-server system

6. Process Control

• Real-world systems often control a physical reality, such as control systems in a power plant. There are a number of software paradigms for process control. The significant properties are that the software takes its input from sensors (such as a flow sensor), and perform control actions (such as closing a valve). The control loop may be of feedback or feed-forward type.

7. State Machine

• When designing state machine architecture, the states of the program that can be in are identified, together with legal transitions between them. State machines are well known to mathematicians, and can be thoroughly investigated and validated regarding loops, illegal states etc, which makes this style common in safety critical systems. State machines are particularly well suited for graphical description.

[pic]

Figure 9: A state machine

3. Architecture Description Language(ADL)

• An ADL is a language that provides features for modeling a software system’s conceptual architecture, distinguished from the system’s implementation.

1. DAOP-ADL

• It is an architecture description language used to describe components and aspects, together with the composition rules that govern the weaving of components and aspects.

• Architecture descriptions using DAOP-ADL comprises of the two parts: one defines standalone components and aspects, and the second is the composition specification.

• The visual notation of the DAOP-ADL language is CAM (Component-Aspect Model).

[pic]

Figure 10: CAM design of a Chat application

[pic]

Figure 11: DAOP-ADL specification of the components and aspects

[pic]

Figure 12: DAOP-ADL specification of the Composition Rules

2. ACME:

• It is an ADL (Architecture Description Language) that was developed to create a common interchange format in the software engineering community.

• Provides the following key features:

1. An architectural ontology consisting of seven basic architectural design elements.

2. A flexible annotation mechanism supporting association of non-structural information using externally defined sublanguages.

3. A type mechanism for abstracting common, reusable architectural idioms and styles.

4. An open semantic framework for reasoning about architectural descriptions.

• The most basic elements of architectural description are components, connectors, and systems.

➢ Components: the primary computational elements and data stores of a system. Intuitively, they correspond to the boxes in box-and line descriptions of software architectures.

➢ Connectors: represent interactions among components. Computationally speaking, connectors mediate the communication and coordination activities among components. Informally they provide the ''glue'' for architectural designs, and intuitively, they correspond to the lines in box-and-line descriptions.

➢ Systems: represent configurations of components and connectors.

Example:

• A trivial architectural drawing containing a client and server component, connected by an RPC connector.

[pic]

Figure 13 : Simple Client-Server Diagram

• The client component is declared to have a single send-request port, and the server has a single receive-request port. The connector has two roles designated caller and callee. The topology of this system is declared by listing a set of attachments.

[pic]

Figure 14: Simple Client-Server System in Acme

• Acme supports the hierarchical description of architectures any component or connector can be represented by one or more detailed, lower-level descriptions.

[pic]

Figure 15: Representations and Properties of a Component

5. Conclusion:

• Architecture of a software system is its structures comprising of elements, their external properties, and relationships.

• Architecture is a high level design.

• Arch can be analyzed for various non-functional attributes like performance, reliability, security, etc.

• ATAM is one approach for analyzing architectures, which evaluates attributes of interest under different scenarios.

6. Reference:

•

• Rikard Land, älardalen University, Department of Computer Engineering, Brief Survey of Software Architecture.

•

•

•

[pic]

-----------------------

Presented by:

Israa Mostafa Islam

Neveen Adel Mohamed

Omnia Ibrahim Ahmed

Presented to:

Dr. Hany Ammar

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download