1. Architectural Design Principles

2. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements  Architecting with design operators These are explicit transformations of a design – decomposition, replication, compression, abstraction, and resource sharing.  Functional design strategies Architectural designs can be transformed by applying higher-level “macro” operations such as design patterns and other design strategies.

3. Architectural Level of Design  Applying design principles Understanding quality attributes helps you to reason about specific characteristics Design principles guide the decisions that need to be made during the application of design methods. Systematic variation is a technique that helps the architect discover or create a solution field to a given problem.

4. Architectural Level of Design (Cont’d)  Applying design principles (cont’d) The architect can go down multiple paths forming a solution tree. At any time the architect may apply design evaluation techniques to test the quality attributes of the design. The architect can also apply architecture styles and patterns as operations. Operations are not necessarily transitive; the result may depend on the order applied.

5. Architectural Level of Design (Cont’d)  Using Systems Thinking Considering the entire vies of the problem, not just the subproblems. Systems thinking requires a balance between looking at the big picture and looking at subpictures. Take a two pass approach  On the first pass capture what comes to you and don’t filter it or try to formalize it  On the second and subsequent passes, remove, revise and refine as necessary.

6. Architecting with Design Operators  The application of design operators starts with a representation of the system as a single component that has externally visible characteristics and functions.  The system is initially divided into two components, each with a well-defined purpose and the two components interact by the way of connectors.  The system now appears as two modules that share a set of global design rules, which define the connectors.

7. Common Software Design Operators  Decomposition  Replication  Compression  Abstraction  Resource sharing

8. Decomposition  This is the operation of separating distinct functionality into distince components that have well-defined interfaces.  It is the most important and most used principle in any engineering design field.  It is used to achieve a variety of quality attributes including modifiability, portability, performance, and buildability.

9. Decomposition (Cont’d)  Two types of decomposition: Part/whole Generalization/specialization  Each application of the decomposition operator divides a component into two subcomponents.  The choice of where to draw the line between components is driven by what quality attributes you are trying to emphasize.

10. Identifying Functional Components  Components are identified in several ways: Interfaces – The interfaces between the system and external entities should be associated with components, one per interface (or set of interfaces) but interfaces should not be fragmented across multiple components. Domains – There are two types of domains: application domains and solution domains. Each application domain (e.g., Content Authoring, Publishing, Marketing) may be modeled by a separate domain. Similarly you may identify components like Content Repository, Content Delivery, Project Management, and Royalty Management may be components in the solution domain.

11. Identifying Functional Components (Cont’d)  Components are identified in several ways (cont’d): Functional abstraction layers – These decompose the system into a functional hierarchy. From this hierarchy it is possible to identify common functions that can be represented by shared components. Domain entities – Just as a domain may be represented as a component, it may be useful to represent specific domain entities directly as components. In the publishing domain there is an entity called a Content Reviewer. It may be appropriate to model this entity as a component, or alternatively to model it in some process and not explicitly in the structure of the system.

12. Composition/Aggregation  This involves assembling components to form new components.  The new components have behaviors that are not inherent in the subcomponents individually.  This is not exactly the opposite of decomposition.  The true opposite of decomposition is compression.

13. Component Communication  When a component is divided into two components there is an implied communications channel between them.  It may be asynchronous or synchronous.  Asynchronous communication decouples the processing of the two components which may improve performance and reliability, but it may add complexity.

14. Compression  This is the opposite of decomposition.  It is the merging of components into a single component or removing layers or interfaces between components.  Compression is used to improve performance by eliminating a level of indirection.  For example, a presentation component may interact directly with a database instead of using middle-tier objects.

15. Abstraction  Abstraction hides information by introducing a semantically rich layer of services while hiding implementation details.  Hiding the underlying implementation makes other components portable with respect to the abstracted component.  Abstraction is also referred to as creating a virtual machine.  It can be used to improve adaptability.

16. Resource Sharing  This is the encapsulating of data or services to share them among multiple independent client components.  The result is enhanced integrability, portability, and modularity.  Persistent data (such as that stored in databases) is a common shared resource.  Resource sharing can simplify some aspects of systems configuration and management.

17. Replication  This is the operation of duplicating a component in order to enhance reliability and performance.  There are two flavors of runtime replication: Redundancy – where several identical copies of a component execute simultaneously. N-version programming – where there are several different implementations of the same functionality.  A good design approach to redundancy and backups is to make component switching transparent to the other components that are using it.

18. Functional Design Strategies  Two strategies for achieving reliability: Self-Monitoring -- This is a system that is able to detect certain types of failures and handle them appropriately. There are two approaches:  Process monitoring – a layer “above” the application that watches over the system  Component monitoring – a monitor is established for monitoring each component Recovery – This is a system that is able to restore itself after a failure. Instrumenting – Similar to self-monitoring. A component can be instrumented to measure aspects of the execution.

19. Summary  General design methods combined with quality attributes and design principles yields an architectural design method that is heuristic and participative.