Benefits of ATAM

•Sensitivity – A property of a component that is critical to success of system.

–The number of simultaneous database clients will affect the number of transaction a database can process per second. This assignment is a sensitivity point for the performance

–Keeping a backup database affects reliability

–Power of encryption (Security) sensitive to number of bits of the key

•Tradeoff point- A property that affects more than one attribute or sensitivity point.

–In order to achieve the required level of performance in the discrete event generation component, assembly language had to be used thereby reducing the portability of this component.

–Keeping the backup database affects performance also so it’s a trade-off between reliability and performance

•Risk

–The decision to keep backup is a risk if the performance cost is excessive

–Rules for writing business logic modules in the second tier of your 3-tier style are not clearly articulated. This could result in replication of functionality thereby compromising modifiability of the third tier.

•Non Risk

–The decision to keep backup is a non-risk if the performance cost is not excessive

–Assuming message arrival rates of once per second, a processing time of less than 30 ms, and the existence of one higher priority process, a 1 second soft deadline seems reasonable Performance.

Common application architecture

Enterprise Architecture and System Architecture

What we Hear in Industry?

? How do I use these architecture methods in my organization (with our processes)?
? What do I do with a software architecture once I create it?
? So I have all these quality attribute scenarios – now what?
? How is software architecture different from EA, DoDAF, C4ISR, or system architecture? Do I need all of them? How (or can they) work together?
? When do I design my architecture?
? When am I done architecting?
? How/when do I evaluate my architecture?

? How do I use the output of an architecture evaluation?
? How is architecture different from the UML designs I have now?
? Can I design an architecture and still be agile?
? Can I use architecture concepts, methods, and techniques in my small teams and small projects?
? Can I design an architecture if I develop my products iteratively?
? How much requirements work do I need to do before I begin architecture design?
? How and when do I get architecture requirements?

The Architecture Tradeoff Analysis Initiative at the Carnegie Mellon Software Engineering Institute (SEI) has developed a number of architecture-centric methods currently in use including the SEISM Architecture Tradeoff Analysis Method (ATAM), the SEI Quality Attribute Workshop (QAW), the SEI Cost Benefit Analysis Method (CBAM), SEI Active Reviews for Intermediate Designs (ARID), and the SEI Attribute-Driven Design (ADD) method.

Architecture-centric development involves iteratively
• creating the business case for the system
• understanding the requirements
• creating or selecting the software architecture
• documenting and communicating the software architecture
• analyzing or evaluating the software architecture
• implementing the system based on the software architecture
• ensuring that the implementation conforms to the software architecture

Enhancing the ATAM: ATAM Steps & Enhancements

Step 1 – Present the ATAM: Add information such as multiple response measures for scenarios and tactics used to achieve a desired quality attribute response.
Step 2 – Present business drivers: Elicit additional information on business goals: rationale, barriers, enablers, and schedule and cost constraints.
Step 3 – Present architecture: Elicit additional information on the architecture, for example, architectural elements, relations, and their properties, and design rationale.
Step 4 – Identify architectural approaches: Cross reference approaches listed with supplementary architectural information.
Step 5 – Generate quality attribute utility tree:
Step 6 – Analyze architectural approaches: Supplement scenario refinement by eliciting worst-case and best-case response measures. Systematically elicit alternative architectural approaches for dealing with scenarios. Explicitly document suggested alternative architectural approaches for dealing with scenarios.
Step 7 – Brainstorm and prioritize scenarios
Step 8 – Analyze architectural approaches: Supplement scenario refinement by eliciting worst-case and best-case response measures. Refine the top one-third but analyze a handful of the highest priority scenarios. Systematically elicit alternative architectural approaches for dealing with scenarios. Explicitly document suggested alternative architectural approaches for dealing with scenarios.
Step 9 – Present results:  Include information about alternative architectural approaches generated during the evaluation.

Business Drivers Presentation

(~ 12 slides; 45 minutes)
Description of the business environment, history, market differentiators, driving requirements, stakeholders, current need, and how the proposed system will meet those needs/requirements
Description of business constraints (e.g., time to market, customer demands, standards, costs)
Description of the technical constraints (e.g., commercial off-the-shelf [COTS] products, interoperation with other systems, required hardware or software platform, reuse of legacy code)
Quality attribute requirements and the business needs from which they are derived

The CBAM requires additional business information to be elicited during this step, including

• the rationale for each business goal
• the dependencies among and priorities of the business goals
• barriers to adopting the business goals and strategies for overcoming them
• enablers of adopting the business goals and strategies for exploiting them
• schedule and cost constraints from the business side; for example, time to market as a business goal
• the relationship between business goals and quality goals

Architecture Presentation

(~ 20 slides; 60 minutes)
Driving architectural requirements, the measurable quantities you associate with them and any existing standards/models/approaches for meeting them
Important architectural information: context diagram, module or layer view, component-andconnector view, deployment view
Architectural approaches, patterns, or tactics employed, including which quality attributes they address and a description of how the approaches address them
• use of COTS products and how they are chosen/integrated
• trace of 1 to 3 of the most important use case scenarios
• trace of 1 to 3 of the most important change scenarios
• architectural issues/risks with respect to meeting the driving architectural requirements
• glossary

Enhancing the CBAM: CBAM Steps & Enhancements

Step 1 – Collate scenarios: Completed during the ATAM evaluation
Step 2 – Refine scenarios: Partially completed during the ATAM evaluation when the desired-case, best-case, and worst-case response
measures for the scenarios were elicited from the stakeholders. The architect completes this step by determining the current-case response measures for the scenarios carried forward.
Step 3 – Prioritize scenarios: Enhanced business goals and traceability from scenarios to quality attributes to business goals gathered during the ATAM evaluation help guide this step.
Step 4 – Assign intra-scenario utility: Enhanced business goals gathered during the ATAM evaluation help guide this step.
Step 5 – Develop architectural strategies and determine quality attribute response levels: Some architectural approaches may have been identified during the ATAM evaluation. New ones can be added prior to or during this step, using activities from the ADD method. When the expected-case response measure is being determined, the ATAM analysis template might be used to record risks.
Step 6 – Determine the utility of the expected quality attribute response levels by interpolation
Step 7 – Calculate the total benefit obtained from an architectural strategy: Risks from the ATAM evaluation provide input into variations in benefits.
Step 8 – Choose architectural strategies based on the ROI: Enhanced business goals about cost and schedule constraints gathered during the ATAM evaluation help guide this step. Risks from the ATAM evaluation provide input into variations in costs.
Step 9 – Confirm results with intuition: The association of business goals to quality attributes to scenarios to architectural decisions helps confirm that the
selected architectural decisions best meet the business goals.

• Separation of concerns. Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap.
• Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.
• Principle of Least Knowledge (also known as the Law of Demeter or LoD). A component or object should not know about internal details of other components or objects.
• Don’t repeat yourself (DRY). You should only need to specify intent in one place. For example, in terms of application design, specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.
• Minimize upfront design. Only design what is necessary. In some cases, you may require upfront comprehensive design and testing if the cost of development or a failure in the design is very high. In other cases, especially for agile development, you can avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This principle is sometimes known as YAGNI (“You ain’t gonna need it”).

• Determine the Application Type
• Determine the Deployment Strategy
• Determine the Appropriate Technologies
• Determine the Quality Attributes
• Determine the Crosscutting Concerns

Design Practices

• Keep design patterns consistent within each layer. Within a logical layer, where possible, the design of components should be consistent for a particular operation. For example, if you choose to use the Table Data Gateway pattern to create an object that acts as a gateway to tables or views in a database, you should not include another pattern such as Repository, which uses a different paradigm for accessing data and initializing business entities. However, you may need to use different patterns for tasks in a layer that have a large variation in requirements, such as an application that contains business transaction and reporting functionality.
• Do not duplicate functionality within an application. There should be only one component providing a specific functionality—this functionality should not be duplicated in any other component. This makes your components cohesive and makes it easier to optimize the components if a specific feature or functionality changes. Duplication of functionality within an application can make it difficult to implement changes, decrease clarity, and introduce potential inconsistencies.
• Prefer composition to inheritance. Wherever possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of child classes. This also reduces the inheritance hierarchies, which can become very difficult to deal with.
• Establish a coding style and naming convention for development. Check to see if the organization has established coding style and naming standards. If not, you should establish common standards. This provides a consistent model that makes it easier for team members to review code they did not write, which leads to better maintainability.
• Maintain system quality using automated QA techniques during development. Use unit testing and other automated Quality Analysis techniques, such as dependency analysis and static code analysis, during development. Define clear behavioral and performance metrics for components and sub-systems, and use automated QA tools during the build process to ensure that local design or implementation decisions do not adversely affect the overall system quality.
• Consider the operation of your application. Determine what metrics and operational data are required by the IT infrastructure to ensure the efficient deployment and operation of your application. Designing your application’s components and sub-systems with a clear understanding of their individual operational requirements will significantly ease overall deployment and operation. Use automated QA tools during development to ensure that the correct operational data is provided by your application’s components and sub-systems.

Application Layers

• Separate the areas of concern. Break your application into distinct features that overlap in functionality as little as possible. The main benefit of this approach is that a feature or functionality can be optimized independently of other features or functionality. In addition, if one feature fails, it will not cause other features to fail as well, and they can run independently of one another. This approach also helps to make the application easier to understand and design, and facilitates management of complex interdependent systems.
• Be explicit about how layers communicate with each other. Allowing every layer in an application to communicate with or have dependencies upon all of the other layers will result in a solution that is more challenging to understand and manage. Make explicit decisions about the dependencies between layers and the data flow between them.
• Use abstraction to implement loose coupling between layers. This can be accomplished by defining interface components such as a façade with well known inputs and outputs that translate requests into a format understood by components within the layer. In addition, you can also use Interface types or abstract base classes to define a common interface or shared abstraction (dependency inversion) that must be implemented by interface components.
• Do not mix different types of components in the same logical layer. Start by identifying different areas of concern, and then group components associated with each area of concern into logical layers. For example, the UI layer should not contain business processing components, but instead should contain components used to handle user input and process user requests.
• Keep the data format consistent within a layer or component. Mixing data formats will make the application more difficult to implement, extend, and maintain. Every time you need to convert data from one format to another, you are required to implement translation code to perform the operation and incur a processing overhead.

Components, Modules, and Functions

• A component or an object should not rely on internal details of other components or objects. Each component or object should call a method of another object or component, and that method should have information about how to process the request and, if appropriate, how to route it to appropriate subcomponents or other components. This helps to create an application that is more maintainable and adaptable.
• Do not overload the functionality of a component. For example, a UI processing component should not contain data access code or attempt to provide additional functionality. Overloaded components often have many functions and properties providing business functionality mixed with crosscutting functionality such as logging and exception handling. The result is a design that is very error prone and difficult to maintain. Applying the single responsibility and separation of concerns principles will help you to avoid this.
• Understand how components will communicate with each other. This requires an understanding of the deployment scenarios your application must support. You must determine if all components will run within the same process, or if communication across physical or process boundaries must be supported—perhaps by implementing message-based interfaces.
• Keep crosscutting code abstracted from the application business logic as far as possible. Crosscutting code refers to code related to security, communications, or operational management such as logging and instrumentation. Mixing the code that implements these functions with the business logic can lead to a design that is difficult to extend and maintain. Changes to the crosscutting code require touching all of the business logic code that is mixed with the crosscutting code. Consider using frameworks and techniques (such as aspect oriented programming) that can help to manage crosscutting concerns.
• Define a clear contract for components. Components, modules, and functions should define a contract or interface specification that describes their usage and behavior clearly. The contract should describe how other components can access the internal functionality of the component, module, or function; and the behavior of that functionality in terms of pre-conditions, post-conditions, side effects, exceptions, performance characteristics, and other factors.

1. Identify Architecture Objectives. Clear objectives help you to focus on your architecture and on solving the right problems in your design. Precise objectives help you to determine when you have completed the current phase, and when you are ready to move to the next phase.

• Identify your architecture goals at the start. The amount of time you spend in each phase of architecture and design will depend on these goals. For example, are you building a prototype, testing potential paths, or embarking on a long-running architectural process for a new application?
• Identify who will consume your architecture. Determine if your design will be used by other architects, or made available to developers and testers, operations staff, and management. Consider the needs and experience of your audience to make your resulting design more accessible to them.
• Identify your constraints. Understand your technology options and constraints, usage constraints, and deployment constraints. Understand your constraints at the start so that you do not waste time or encounter surprises later in your application development process.

1. Key Scenarios. Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready.
2. Application Overview. Identify your application type, deployment architecture, architecture styles, and technologies in order to connect your design to the real world in which the application will operate.
3. Key Issues. Identify key issues based on quality attributes and crosscutting concerns. These are the areas where mistakes are most often made when designing an application.

• Business Critical. The use case has a high usage level or is particularly important to users or other stakeholders when compared to other features, or it implies high risk.
• High Impact. The use case intersects with both functionality and quality attributes, or represents a crosscutting concern that has an end-to-end impact across the layer and tiers of your application. An example might be a Create, Read, Update, Delete (CRUD) operation that is security-sensitive.

1. Candidate Solutions. Create an architecture spike or prototype that evolves and improves the solution and evaluate it against your key scenarios, issues, and deployment constraints before beginning the next iteration of your architecture.