Date post: | 28-Nov-2014 |
Category: |
Software |
Upload: | swapnil-kulkarni |
View: | 51 times |
Download: | 1 times |
Software Architecture in Practice
Part Two:Creating an Architecture
Chapter 7:
Designing the Architecture
04/09/23 2
3
Designing the Architecture Architecture in the life cycle Designing the architecture Forming the team structure & its
relationship to the architecture Creating a skeletal system
Evolutionary Delivery Life Cycle
4
5
Architectural Drivers Shaping requirements: functional, quality, &
business requirements Find them by:
1 Identify the highest priority business goals (relatively few).
2 Turn these into quality scenarios or use cases.3 Choose the ones that will have the most
impact on the architecture. These are the architectural drivers & should be <
10.
6
Attribute Driven Design An extension of other methods. Bases the decomposition process on the
quality attributes. Recursive decomposition:
tactics & architectural patterns are chosen to satisfy a set of quality scenarios
functionality is allocated to instantiate the module types
results in course-grained architecture
7
ADD Steps
A. Identify an initial set of architectural driversB. Choose the module to decompose (initially
the entire system)C. Refine the module:
1. Choose the specific architectural drivers2. Choose an architectural pattern that satisfies the
drivers, based on the appropriate tactics. Identify child modules to implement the tactics.
3. Instantiate modules & allocate functionality: draw multiple views.
8
ADD Steps, con’t
4. Define interfaces of the child modules. The decomposition provides modules & constraints on the types of module interactions. Document.
5. Verify & refine use cases & quality scenarios and make them constraints for the child modules. Verification & preparation for more decomposition or implementation.
D. Repeat C for every module that needs further decomposition.
Forming the team structure & its relationship to the architecture Once the first few levels of the architecture's module
decomposition structure are fairly stable, those modules can be allocated to development teams
The impact of an architecture on the development of organizational structure is clear.
Once an architecture for the system under construction has been agreed on, teams are allocated to work on the major modules and a work breakdown structure is created that reflects those teams.
Each team then creates its own internal work practices
04/09/23 9
10
Creating a Skeletal System Provide an underlying capability to implement a
system’s functionality in an effective order: Implement execution & interaction. Install the simplest of functions that instigates
some rote behavior. Result: a running system that sits & hums to
itself. Choose functionality: most problematic;
available staff; initial deliverable. Employ the uses structure to identify additional
software to support chosen functionality.
11
Skeleton, (continued) Benefits:
At no point is the integration & test overwhelming; easy to find incremental source of errors.
Budgets & schedules are more predictable with smaller increments, providing management & marketing with more delivery options.
Stubs adhere to the final version of interfaces: help with understanding & testing interactions producing hardcoded canned output or reading in
output can generate synthetic load that aids early
understanding of performance, including interactions & bottlenecks.
12
Skeleton, (continued) Potential problem:
The first development team to complete a portion of the system gets to define the interfaces for everyone.
This might be too simple, and penalize the complex parts of the system.
The effect would be to make they complex subsystems more complex.
So, first negotiate the interfaces.
13
In Summary Architectural design must follow
requirements analysis, but should begin as soon as the architectural drivers are determined.
When a sufficient portion of the architecture has been designed (but not completed), start building a skeletal framework that is the basis of iterative development.
Chapter 9:
Documenting Software Architectures
04/09/23 23
Documenting Software Architectures Documenting the architecture is the crowning step
to crafting it. Even a perfect architecture is useless if no one
understands it or (perhaps worse) if key stakeholders misunderstand it.
If you go to the trouble of creating a strong architecture, you must describe it in sufficient detail, without ambiguity, and organized in such a way that others can quickly find needed information.
Otherwise, your effort will have been wasted because the architecture will be unusable.
04/09/23 24
Uses of Architectural Documentation Architecture documentation is both
prescriptive and descriptive. It might mean producing different documents
for different stakeholders One of the most fundamental rules for
technical documentation in general, and software architecture documentation in particular, is to write from the point of view of the reader.
04/09/23 25
Views Perhaps the most important concept associated with
software architecture documentation is the view. Recall that we defined a Software Architecture for a
system as :- "the structure or structures of the system, which comprise
elements, the externally visible properties of those elements, and the relationships among them."
A View is a representation of a coherent set of architectural elements, as written by and read by system stakeholders.
A Structure is the set of elements itself, as they exist in software or hardware.
04/09/23 26
Views The basic principle of documenting software
architecture: Documenting an architecture is a matter of
documenting the relevant views and then adding documentation that applies to more than one View.
The above basic principle is useful for:- Choosing the relevant views Documenting a view Documenting information that applies to more than
one view
04/09/23 27
Choosing the Relevant Views A layered view will tell about system's portability. A deployment view will reason about system's
performance and reliability. A simple three-step procedure for choosing the views :-
Produce a candidate view list. Begin by building a stakeholder/view
Combine views. The candidate view list from step 1 is likely to yield an impractically large number of views. To reduce the list to a manageable size, first look for views in the table that require only overview depth or that serve very few stakeholders
Prioritize. Select an appropriate set of views to serve your stakeholder community.
04/09/23 28
The seven parts of a documented view
04/09/23 29
Documenting a View There is no industry-standard template for documenting
a view, but the seven-part standard organization that has worked well in practice are :-1. Primary presentation shows the elements and the
relationships among them that populate the view2. Element catalog details at least those elements and
relations depicted in the primary presentation, and perhaps others. For example, a module decomposition view has
elements that are modules, relations that are a form of "is part of," and properties that define the responsibilities of each module. A process view has elements that are processes, relations
04/09/23 30
Documenting a View3. Context diagram shows how the system depicted in the view
relates to its environment in the vocabulary of the view. For example, in a component-and-connector view you show
which component and connectors interact with external components and connectors, via which interfaces and protocols.
4. Variability guide shows how to exercise any variation points that are a part of the architecture shown in this view. An example of variability is found in software product lines
where the product line architecture is suitable for multiple particular systems
5. Architecture background explains why the design reflected in the view came to be. The goal of this section is to explain to someone why the design is as it is and to provide a convincing argument that it is sound.
04/09/23 31
Documenting a View
6. Glossary of terms used in the views, with a brief description of each.
7. Other information. The precise contents of this section will vary according to the standard practices of the organization. It might include management information such as authorship, configuration control data, and change histories.
04/09/23 32
DOCUMENTING BEHAVIOR Behavior can be documented either about an element or
about an ensemble of elements working in concert. Exactly what to model will depend on the type of system being designed.
For example, if it is a real-time embedded system, you will need to say a lot about
timing properties and the time of events. In a banking system, the sequence of events (e.g., atomic transactions and
rollback procedures) is more important than the actual time of events being considered.
Different modeling techniques and notations are used depending on the type of analysis to be performed.
In UML, sequence diagrams and state charts are examples of behavioral descriptions. These notations are widely used.
04/09/23 33
DOCUMENTING INTERFACES An interface is a boundary across which two
independent entities meet and interact or communicate with each other.
Documenting an interface consists of naming and identifying it and documenting its syntactic and semantic information
04/09/23 34
The nine parts of interface documentation
04/09/23 35
Documentation across Views
04/09/23 36
Unified Modeling Language MODULE VIEWS
04/09/23 37
UML Aggregation
04/09/23 38
UML Dependency
04/09/23 39
COMPONENT-AND-CONNECTOR VIEWS
04/09/23 40
ALLOCATION VIEWS
04/09/23 41
Thank You
04/09/23 42