Downloaded 25 times
Uploaded byMajong DevJfu
06 styles and_greenfield_design
The document discusses several techniques for developing software architectures when no existing architecture exists to build upon. It describes strategies like analogy searching, brainstorming, literature searching, and morphological charts that can be used to generate novel ideas for the architecture. It also emphasizes controlling the design strategy through techniques like identifying critical decisions, relating costs to risks, and continually re-evaluating requirements and implementation constraints.
More Related Content
Similar to 06 styles and_greenfield_design
06 styles and_greenfield_design
- 1. Styles and Greenfield Design Software Architecture Lecture 6
- 2. Heterogeneous Styles Morecomplex styles created through composition of simpler styles REST (from the first lecture) Complex history presented later in course C2 Implicit invocation + Layering + other constraints Distributed objects OO + client-server network style CORBA
- 3. C2 Style Anindirect invocation style in which independent components communicate exclusively through message routing connectors. Strict rules on connections between components and connectors induce layering.
- 4. C2 Style (cont’d)Components: Independent, potentially concurrent message generators and/or consumers Connectors: Message routers that may filter, translate, and broadcast messages of two kinds: notifications and requests. Data Elements: Messages – data sent as first-class entities over the connectors. Notification messages announce changes of state. Request messages request performance of an action. Topology: Layers of components and connectors, with a defined “top” and “bottom”, wherein notifications flow downwards and requests upwards.
- 5. C2 LL SoftwareArchitecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
- 6. KLAX Software Architecture:Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
- 7. KLAX in C2 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
- 8. Distributed Objects: CORBA “ Objects” (coarse- or fine-grained) run on heterogeneous hosts, written in heterogeneous languages. Objects provide services through well-defined interfaces. Objects invoke methods across host, process, and language boundaries via remote procedure calls (RPCs). Components: Objects (software components exposing services through well-defined provided interfaces) Connector: (Remote) Method invocation Data Elements: Arguments to methods, return values, and exceptions Topology: General graph of objects from callers to callees. Additional constraints imposed: Data passed in remote procedure calls must be serializable. Callers must deal with exceptions that can arise due to network or process faults. Location, platform, and language “transparency”. CAUTION
- 9. CORBA Concept andImplementation Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
- 10. CORBA LL SoftwareArchitecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
- 11. Observations Different stylesresult in Different architectures Architectures with greatly differing properties A style does not fully determine resulting architecture A single style can result in different architectures Considerable room for Individual judgment Variations among architects A style defines domain of discourse About problem (domain) About resulting system
- 12.
- 13.
- 14.
- 15.
- 16. Design Recovery What happens if a system is already implemented but has no recorded architecture? The task of design recovery is examining the existing code base determining what the system’s components, connectors, and overall topology are. A common approach to architectural recovery is clustering of the implementation-level entities into architectural elements. Syntactic clustering Semantic clustering
- 17. Syntactic Clustering Focuses exclusively on the static relationships among code-level entities Can be performed without executing the system Embodies inter-component (a.k.a. coupling) and intra-component (a.k.a. cohesion) connectivity May ignore or misinterpret many subtle relationships, because dynamic information is missing
- 18. Semantic Clustering Includes all aspects of a system’s domain knowledge and information about the behavioral similarity of its entities. Requires interpreting the system entities’ meaning, and possibly executing the system on a representative set of inputs. Difficult to automate May also be difficult to avail oneself of it
- 19. When There’s NoExperience to Go On… The first effort a designer should make in addressing a novel design challenge is to attempt to determine that it is genuinely a novel problem. Basic Strategy Divergence – shake off inadequate prior approaches and discover or admit a variety of new ideas Transformation – combination of analysis and selection Convergence – selecting and further refining ideas Repeatedly cycling through the basic steps until a feasible solution emerges.
- 20. Analogy Searching Examine other fields and disciplines unrelated to the target problem for approaches and ideas that are analogous to the problem. Formulate a solution strategy based upon that analogy. A common “unrelated domain” that has yielded a variety of solutions is nature, especially the biological sciences. E.g., Neural Networks
- 21. Brainstorming Techniqueof rapidly generating a wide set of ideas and thoughts pertaining to a design problem without (initially) devoting effort to assessing the feasibility. Brainstorming can be done by an individual or, more commonly, by a group. Problem: A brainstorming session can generate a large number of ideas… all of which might be low-quality. The chief value of brainstorming is in identifying categories of possible designs, not any specific design solution suggested during a session. After brainstorm the design process may proceed to the Transformation and Convergence steps.
- 22. “ Literature” Searching Examining published information to identify material that can be used to guide or inspire designers Many historically useful ways of searching “literature” are available Digital library collections make searching extraordinarily faster and more effective IEEE Xplore ACM Digital Library Google Scholar The availability of free and open-source software adds special value to this technique.
- 23. Morphological Charts The essential idea: identify all the primary functions to be performed by the desired system for each function identify a means of performing that function attempt to choose one means for each function such that the collection of means performs all the required functions in a compatible manner. The technique does not demand that the functions be shown to be independent when starting out. Sub-solutions to a given problem do not need to be compatible with all the sub-solutions to other functions in the beginning.
- 24. Removing Mental Blocks If you can’t solve the problem, change the problem to one you can solve. If the new problem is “close enough” to what is needed, then closure is reached. If it is not close enough, the solution to the revised problem may suggest new venues for attacking the original.
- 25. Controlling the DesignStrategy The potentially chaotic nature of exploring diverse approaches to the problem demands that some care be used in managing the activity Identify and review critical decisions Relate the costs of research and design to the penalty for taking wrong decisions Insulate uncertain decisions Continually re-evaluate system “requirements” in light of what the design exploration yields
- 26. Insights from Requirements In many cases new architectures can be created based upon experience with and improvement to pre-existing architectures. Requirements can use a vocabulary of known architectural choices and therefore reflect experience. The interaction between past design and new requirements means that many critical decisions for a new design can be identified or made as a requirement
- 27. Insights from Implementation Constraints on the implementation activity may help shape the design. Externally motivated constraints might dictate Use of a middleware Use of a particular programming language Software reuse Design and implementation may proceed cooperatively and contemporaneously Initial partial implementation activities may yield critical performance or feasibility information