December 9, 2001Architectural Design, ECEN 50331 Architectural Design Principles & Techniques A Long...

December 9, 2001 Architectural Design, ECEN 5033 1

Architectural Design

Principles & Techniques

A Long Road of History

2Architectural Design, ECEN 5033December 9, 2001

Overview

Design Principles (the long view)

Design Pattern Roots


Fundamental Design Principles

• Abstraction• Structure• Information Hiding• Concurrency• Verification• Aesthetics• Modularity • Business influence & impact


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


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


Three Abstraction Mechanisms

• Functional abstraction– ___– ___

• Data abstraction– ____– ____

• Control abstraction– ____– ____


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


Decomposition Criteria

• Various types of decomposition criteria fall under this structure category– information hiding– low coupling and high cohesion– data encapsulation– see modularization


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


Examples of likely-to-change


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


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


Aesthetics

• Simplicity, elegance, clarity of purpose• Properties that go beyond mere satisfaction of the

requirements• Patterns are helpful in codifying some of these


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


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


Other Criteria for Modularization

• Structuring the system to improve testability• Isolating machine dependencies• Providing general purpose utility functions• Reducing call-return overhead


Architect’s task

• Must weigh modular criteria based on – requirements – including quality requirements and – business requirements


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


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


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


Layers Arch.


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, 2nd ed., 2005, ISBN 0-321-24714-0. Emphasis is on learning to think in patterns.


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, 2nd 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.

December 9, 2001Architectural Design, ECEN 50331 Architectural Design Principles & Techniques A Long...

Documents

Transcript of December 9, 2001Architectural Design, ECEN 50331 Architectural Design Principles & Techniques A Long...