Architectural Design Principles Outline o Architectural level of

  • Slides: 19
Download presentation
Architectural Design Principles

Architectural Design Principles

Outline o Architectural level of design n The design of the system in terms

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

Architectural Level of Design o Applying design principles n n n Understanding quality attributes

Architectural Level of Design o Applying design principles n n n 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.

Architectural Level of Design (Cont’d) o Applying design principles (cont’d) n The architect can

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

Architectural Level of Design (Cont’d) o Using Systems Thinking n Considering the entire vies

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

Architecting with Design Operators o The application of design operators starts with a representation

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

Common Software Design Operators o Decomposition o Replication o Compression o Abstraction o Resource

Common Software Design Operators o Decomposition o Replication o Compression o Abstraction o Resource sharing

Decomposition o This is the operation of separating distinct functionality into distince components that

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

Decomposition (Cont’d) o Two types of decomposition: n Part/whole n Generalization/specialization o Each application

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

Identifying Functional Components o Components are identified in several ways: n Interfaces – The

Identifying Functional Components o Components are identified in several ways: n 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. n 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.

Identifying Functional Components (Cont’d) o Components are identified in several ways (cont’d): n n

Identifying Functional Components (Cont’d) o Components are identified in several ways (cont’d): n n 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.

Composition/Aggregation o This involves assembling components to form new components. o The new components

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

Component Communication o When a component is divided into two components there is an

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

Compression o This is the opposite of decomposition. o It is the merging of

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

Abstraction o Abstraction hides information by introducing a semantically rich layer of services while

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

Resource Sharing o This is the encapsulating of data or services to share them

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

Replication o This is the operation of duplicating a component in order to enhance

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

Functional Design Strategies o Two strategies for achieving reliability: n Self-Monitoring -- This is

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

Summary o General design methods combined with quality attributes and design principles yields an

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