1. December 9, 2001Architectural Design, ECEN 50331 Architectural Design Principles & Techniques A Long Road of History

2. December 9, 2001Architectural Design, ECEN 50332 Overview Design Principles (the long view) Design Pattern Roots

3. December 9, 2001Architectural Design, ECEN 50333 Fundamental Design Principles Abstraction Structure Information Hiding Concurrency Verification Aesthetics Modularity Business influence & impact

4. December 9, 2001Architectural Design, ECEN 50334 Abstraction Deal with concepts apart from particular instances of the concepts For example, the idea of coupling can be understood at the procedure level, the class level, the subsystem level, the system level (with respect to its environment) Postpone some structural considerations and many algorithmic details Reduces the amount of complexity that must be dealt with at each point

5. December 9, 2001Architectural Design, ECEN 50335 Design as abstraction Architectural design specs are models that emphasize functional and structural system attributes Process of proceeding from abstraction considerations to concrete representations Various models listed in text help to communicate different aspects of the system by masking some of the complexity and revealing some relationships

6. December 9, 2001Architectural Design, ECEN 50336 Three Abstraction Mechanisms Functional abstraction –___ Data abstraction –____ Control abstraction –____

7. December 9, 2001Architectural Design, ECEN 50337 Structure Fundamental concept of software Permits decomposition into smaller, more manageable units with well-defined relationships to other units in the system Most general form is a “network” –directed graph of nodes and arcs –see table from Bass, Clements, Kazman –examples: data flow diagram, “uses” Hierarchical ordering – acyclic, directed

8. December 9, 2001Architectural Design, ECEN 50338 Decomposition Criteria Various types of decomposition criteria fall under this structure category –information hiding –low coupling and high cohesion –data encapsulation –see modularization

9. December 9, 2001Architectural Design, ECEN 50339 Information Hiding Fundamental design concept Each module –hides the internal details of its processing activities –modules communicate only through well-defined interfaces –is therefore a form of abstraction Each module hides difficult design decisions and design decisions that are likely to change

10. December 9, 2001Architectural Design, ECEN 503310 Examples of likely-to-change

11. December 9, 2001Architectural Design, ECEN 503311 Levels of Abstraction – an old idea Levels of Abstraction Dijkstra’s bottom-up technique Each level of abstraction is composed of a group of related functions, –some of which are externally visible, can be invoked by functions on higher levels –some of which are internal to the level –functions on higher levels cannot be used by functions on lower levels –layer performs set of services for layer above –layer has exclusive use of certain resources

12. December 9, 2001Architectural Design, ECEN 503312 Verification Design is the bridge between requirements and an implementation that satisfies them. A design is verifiable if it can be demonstrated that the design will result in an implementation that satisfies the customer’s known requirements. The test plan is a product of the design process One must ensure the system is structured so that the internal states can be observed, tested, and the results related to requirements

13. December 9, 2001Architectural Design, ECEN 503313 Aesthetics Simplicity, elegance, clarity of purpose Properties that go beyond mere satisfaction of the requirements Patterns are helpful in codifying some of these

14. December 9, 2001Architectural Design, ECEN 503314 Modularization Well-defined, manageable units with well-defined interfaces Desirable properties –potentially useful in other applications –single well-defined purpose –manipulates no more than one data structure –functions are encapsulated with the data structure being manipulated

15. December 9, 2001Architectural Design, ECEN 503315 Early Modularization Criteria Oldest – processing steps Information hiding – hides a difficult or changeable design decision from the other modules Data abstraction – hides representation details of a major data structure and its functions Levels of abstraction – modules and collections of modules provide a hierarchical set of increasingly complex services Low coupling, high cohesion

16. December 9, 2001Architectural Design, ECEN 503316 Other Criteria for Modularization Structuring the system to improve testability Isolating machine dependencies Providing general purpose utility functions Reducing call-return overhead

17. December 9, 2001Architectural Design, ECEN 503317 Architect’s task Must weigh modular criteria based on –requirements –including quality requirements and –business requirements

18. December 9, 2001Architectural Design, ECEN 503318 Early contribution: Integrated T-D Integrated Top-Down Development –Worked from top to bottom of “uses chart” –User interface (top) implemented early –Need stubs to test upper part –Was an early form of systematic incremental development Integrated design, implementation, and testing at each level Horizontal triangle, not a vertical slice, –Distributed system integration across life of project –Interfaces are established, coded, and tested as the design progresses –Routines can invoke lower-level routines but cannot invoke routines on a higher level – levels of abstraction

19. December 9, 2001Architectural Design, ECEN 503319 Structured Design Constantine, 1974 –Systematic conversion of data flow diagrams to structure charts – more Fairley excerpts on WebCT in the design section of the lectures Review/refine the dfd Determine if type is transaction-centered or transformation-centered Divide into processing subsystems associated with type Decomposition of each processing subsystem –Low coupling, high cohesion, information hiding criteria

20. December 9, 2001Architectural Design, ECEN 503320 Design Pattern Roots Text describes various arch. patterns as codified learning Older techniques include –Levels of Abstraction –Integrated Top-Down –Information Hiding Overall principles of –abstraction –structure –verification –modularity –business influence and impact -- extensibility

21. December 9, 2001Architectural Design, ECEN 503321 Layers Arch.

22. December 9, 2001Architectural Design, ECEN 503322 Bibliography Object Design, Rebecca Wirfs-Brock, Alan McKean, Addison Wesley, 2003, ISBN 0-201-37943-0 Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, Addison Wesley, ISBN 0-201-19930-0 – includes several case studies and the original chapters on architecture analysis that our text uses in chapter 32. Software Engineering Concepts, Richard Fairley, McGraw- Hill, ISBN 0-07-019902-7 – excellent, compact compendium of historical software engineering. Design Patterns Explained, Alan Shalloway, James R. Trott, Addison Wesley, 2 nd ed., 2005, ISBN 0-321-24714-0. Emphasis is on learning to think in patterns.

23. December 9, 2001Architectural Design, ECEN 503323 Bibliography (cont.) Pattern-Oriented Software Architecture, A System of Patterns, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Wiley & Sons, 1996, ISBN 0 471 95869 7 – often referred to as the POSA book. Object-Oriented Software Construction, 2 nd edition, Bertrand Meyer, Prentice Hall PTR, 1997, ISBN 0-13- 629155-4 – excellent sections on the criteria of object orientation and how to get there; well (and humorously) written and thorough. “Recommended Best Industrial Practice for Software Architecture Evaluation.” G. Abowd, L. Bass, P. Clements, R. Kazman, L. Northrop, and A. Zaremski., SEI, Carnegie Mellon University, Technical Report CMU/SEI- 96-TR-025, 1996.