Software Architecture Validation Checklist

J.E.D.I

4.2.4 Software Architecture Validation Checklist

Like any other work product, the software architecture should be validated. Use the following list questions as the checklist. Layers 1. For smaller systems, are there more than four layers? 2. For larger systems, are there more than seven layers? Subsystems and Interfaces 1. Are the subsystems partitioning done in a logically consistent way across the architecture? 2. Is the name of the interface depict the role of the subsystem within the entire system? 3. Is the interface description concise and clear? 4. Are all operations that the subsystem needs to perform identified? Are there any missing operations? Packages 1. Are the name of the packages descriptive? 2. Does the package description match the responsibilities? Software Engineering 138 Figure 4.11 Club Membership Maintenance Layering Decision J.E.D.I

4.3 Design Patterns

A design pattern describes a proven solution to a problems that keep recurring. It leverages the knowledge and insights of other developers. They are reusable solutions to common problems. It addresses individual problems but can be combined in different ways to achieve an integrated solution for an entire system. Design patterns are not frameworks. Frameworks are partially completed software systems that may be targeted at a specific type of application. An application system can be customized to an organizations needs by completing the unfinished elements and adding application specific elements. It would involved specialization of classes and the implementation of some operations. It is essentially a reusable mini-architecture that provides structure and behavior common to all applications of this type. Design patterns, on the other hand, are more abstract and general than frameworks. It is a description of the way that a problem can be solved but it is not, by itself, is a solution. It cannot be directly implemented; a successful implementation is an example of a design pattern. It is more primitive than a framework. A framework can use several patterns; a pattern cannot incorporate a framework. Patterns may be documented using one of several alternative templates. The pattern template determines the style and structure of the pattern description, and these vary in the emphasis they place on different aspects of the pattern. In general, a pattern description includes the following elements:

1. Name. The name of the pattern should be meaningful and reflects the

knowledge embodied by the pattern. This may be a single word or a short phrase.

2. Context. The context of the pattern represents the circumstances or pre-

conditions under which it can occur. It should be detailed enough to allow the applicability of the pattern to be determined.

3. Problem. It should provide a description of the problem that the pattern

addresses. It should identify and describe the objectives to be achieved within a specific context and constraining forces.

4. Solution. It is a description of the static and dynamic relationships among the

components of the pattern. The structure, the participants and their collaborations are all described. A solution should resolve all the forces in the given context. A solution that does not solve all the forces fails. The use of design patterns requires careful analysis of the problem that is to be addressed and the context in which it occurs. All members of the development team should receive proper training. When a designer is contemplating the use of design patterns, issues should be considered. The following questions provide a guideline to resolve these issues. 1. Is there a pattern that addresses a similar problem? 2. Does the pattern trigger an alternative solution that may be more acceptable? 3. Is there another simple solution? Patterns should not be used just for the sake of it? 4. Is the context of the pattern consistent with that of the problem? 5. Are the consequences of using the pattern acceptable? 6. Are constraints imposed by the software environment that would conflict with Software Engineering 139