When our company was acquired, tech folks from the holding company insisted we use their framework and architecture for all our future initiatives. This left little bit sour mouth and we wanted to compare, contrast and present merits and downsides of such approach. Architectural tradeoff analysis method (ATAM) came to our rescue in capturing architecture from software quality attributes standpoint. Here are some basics to anyone who intend to put this to use,
Step 1. Present the ATAM
Step 2. Present the business drivers
Step 3. Present the architecture
Step 4. Identify Architectural approaches
Step 5. Generate Quality Attribute utility tree
Step 6. Analyze Architectural approaches
Purpose:
The purpose of the ATAM is to assess the consequences of architectural decision alternatives in light of quality attributes. Choosing and designing an architecture that satisfies functional as well as quality attribute requirements (e.g., availability, security, and performance) is vital to the success of the system.
# risks: alternatives that might create future problems in some quality attribute
# sensitivity points: alternatives for which a slight change makes a significant difference in a quality attribute
# tradeoffs: decisions affecting more than one quality attribute
The ATAM is intended to analyze an architecture with respect to its quality attributes, not its functional correctness. Output from this process are
- Business Drivers:
- Architecture drivers - performance, high availability, time to market (modifiability), or high security.
- Constraints -
Business:
Technical:
More details can be found in http://www.sei.cmu.edu/pub/documents/07.reports/07tr015.pdf
Friday, September 11, 2009
Monday, September 7, 2009
XML Schema Design Styles
When it comes to schema design it can be approached from three different standpoints. Russian Doll, Salami Slice and Venetian Blind.
These first two designs represent opposite ends of the design spectrum.
To understand these designs it may help to think in terms of boxes, where a box represents an element or type:
* The Russian Doll design corresponds to having a single box, and it has nested within it boxes, which in turn have boxes nested within them, and so on. (boxes within boxes, just like a Russian Doll!)
* The Salami Slice design corresponds to having many separate boxes which are assembled together (separate boxes combined together, just like Salami slices brought together in a sandwich!)
Russian doll has following characteristics,
- Opaque content. The content of Book is opaque to other schemas, and to other parts of the same schema. The impact of this is that none of the types or elements within Book are reusable.
- Localized scope. The region of the schema where the Title and Author element declarations are applicable is localized to within the Book element. The impact of this is that if the schema has set elementFormDefault="unqualified" then the namespaces of Title and Author are hidden (localized) within the schema.
- Decoupled. With this design approach each component is self-contained (i.e., they don't interact with other components). Consequently, changes to the components will have limited impact. For example, if the components within Book changes it will have a limited impact since they are not coupled to components outside of Book.
- Cohesive. With this design approach all the related data is grouped together into self-contained components, i.e., the components are cohesive.
Salami has,
- Transparent content. The components which make up Book are visible to other schemas, and to other parts of the same schema. The impact of this is that the types and elements within Book are reusable.
- Global scope. All components have global scope. The impact of this is that, irrespective of the value of elementFormDefault, the namespaces of Title and Author will be exposed in instance documents.
- Verbose. Everything is laid out and clearly visible.
- Coupled. In our example we saw that the Book element depends on the Title and Author elements. If those elements were to change it would impact the Book element. Thus, this design produces a set of interconnected (coupled) components.
- Cohesive. With this design approach all the related data is also grouped together into self-contained components. Thus, the components are cohesive.
The two design approaches differ in a couple of important ways:
* The Russian Doll design facilitates hiding (localizing) namespace complexities. The Salami Slice design does not.
* The Salami Slice design facilitates component reuse. The Russian Doll design does not.
The Venetian provides,
- Maximum reuse. The primary component of reuse are type definitions.
- Maximum namespace hiding. Element declarations are nested within types, thus maximizing the potential for namespace hiding.
- Easy exposure switching. Whether namespaces are hidden (localized) in the schema or exposed in instance documents is controlled by the elementFormDefault switch.
- Coupled. This design generates a set of components which are interconnected (i.e., dependent).
- Cohesive. As with the other designs, the components group together related data. Thus, the components are cohesive.
So which one to choose? You can follow the following practice
[1] The Venetian Blind design is the one to choose where your schemas require the flexibility to turn namespace exposure on or off with a simple switch, and where component reuse is important.
[2] Where your task requires that you make available to instance document authors the option to use element substitution, then use the Salami Slice design.
[3] Where mimimizing size and coupling of components is of utmost concern then use the Russian Doll design.
These first two designs represent opposite ends of the design spectrum.
To understand these designs it may help to think in terms of boxes, where a box represents an element or type:
* The Russian Doll design corresponds to having a single box, and it has nested within it boxes, which in turn have boxes nested within them, and so on. (boxes within boxes, just like a Russian Doll!)
* The Salami Slice design corresponds to having many separate boxes which are assembled together (separate boxes combined together, just like Salami slices brought together in a sandwich!)
Russian doll has following characteristics,
- Opaque content. The content of Book is opaque to other schemas, and to other parts of the same schema. The impact of this is that none of the types or elements within Book are reusable.
- Localized scope. The region of the schema where the Title and Author element declarations are applicable is localized to within the Book element. The impact of this is that if the schema has set elementFormDefault="unqualified" then the namespaces of Title and Author are hidden (localized) within the schema.
- Decoupled. With this design approach each component is self-contained (i.e., they don't interact with other components). Consequently, changes to the components will have limited impact. For example, if the components within Book changes it will have a limited impact since they are not coupled to components outside of Book.
- Cohesive. With this design approach all the related data is grouped together into self-contained components, i.e., the components are cohesive.
Salami has,
- Transparent content. The components which make up Book are visible to other schemas, and to other parts of the same schema. The impact of this is that the types and elements within Book are reusable.
- Global scope. All components have global scope. The impact of this is that, irrespective of the value of elementFormDefault, the namespaces of Title and Author will be exposed in instance documents.
- Verbose. Everything is laid out and clearly visible.
- Coupled. In our example we saw that the Book element depends on the Title and Author elements. If those elements were to change it would impact the Book element. Thus, this design produces a set of interconnected (coupled) components.
- Cohesive. With this design approach all the related data is also grouped together into self-contained components. Thus, the components are cohesive.
The two design approaches differ in a couple of important ways:
* The Russian Doll design facilitates hiding (localizing) namespace complexities. The Salami Slice design does not.
* The Salami Slice design facilitates component reuse. The Russian Doll design does not.
The Venetian provides,
- Maximum reuse. The primary component of reuse are type definitions.
- Maximum namespace hiding. Element declarations are nested within types, thus maximizing the potential for namespace hiding.
- Easy exposure switching. Whether namespaces are hidden (localized) in the schema or exposed in instance documents is controlled by the elementFormDefault switch.
- Coupled. This design generates a set of components which are interconnected (i.e., dependent).
- Cohesive. As with the other designs, the components group together related data. Thus, the components are cohesive.
So which one to choose? You can follow the following practice
[1] The Venetian Blind design is the one to choose where your schemas require the flexibility to turn namespace exposure on or off with a simple switch, and where component reuse is important.
[2] Where your task requires that you make available to instance document authors the option to use element substitution, then use the Salami Slice design.
[3] Where mimimizing size and coupling of components is of utmost concern then use the Russian Doll design.
Subscribe to:
Posts (Atom)