A Brief Taxonomy of Styles and Patterns
14.3.1 A Brief Taxonomy of Styles and Patterns
Although millions of computer-based systems have been created over the past 50 years, the vast majority can be categorized {see [SHA96], {BAS98], BUS96]) into one of a relatively small number of architectural styles:
Data-centered architectures. A data store (e.g., a file or database) resides at the “The use of patterns
center of this architecture and is accessed frequently by other components that and styles of design
update, add, delete, or otherwise modify data within the store. Figure 14.1 illus- is pervasive in
trates a typical data-centered style. Client software accesses a central repository. In engineering
disciplines.” some cases the data repository is passive. That is, client software accesses the data
Mary Shaw and
independent of any changes to the data or the actions of other client software. A
David Garlan
variation on this approach transforms the repository into a “blackboard” that sends notifications to client software when data of interest to the client change.
1 The terms styles and patterns are used interchangeably in this discussion.
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
F I G U R E 14.1
architecture Client Client software
software
Data store
Client software
Client (repository or
Data-centered architectures promote integrability [BAS98]. That is, existing com- ponents can be changed and new client components can be added to the architec- ture without concern about other clients (because the client components operate independently). In addition, data can be passed among clients using the black- board mechanism (i.e., the blackboard component serves to coordinate the trans- fer of information between clients). Client components independently execute processes.
Data-flow architectures. This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe and filter pattern (Figure 14.2a) has a set of components, called
“A good architect is the principal keeper
filters, connected by pipes that transmit data from one component to the next. Each of the user’s vision
filter works independently of those components upstream and downstream, is of the end product.”
designed to expect data input of a certain form, and produces data output (to the
Norman Simenson
next filter) of a specified form. However, the filter does not require knowledge of the working of its neighboring filters.
If the data flow degenerates into a single line of transforms, it is termed batch sequential. This pattern (Figure 14.2b) accepts a batch of data and then applies a series of sequential components (filters) to transform it.
Call and return architectures. This architectural style enables a software designer (system architect) to achieve a program structure that is relatively easy to modify and scale. A number of substyles [BAS98] exist within this category:
• Main program/subprogram architectures. This classic program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components, which in turn may invoke still other components. Figure 13.3 illustrates an architecture of this type.
CHAPTER 14
ARCHITECTURAL DESIGN
F I G U R E 14.2
Pipes
Data flow
(a) Pipes and filters
(b) Batch sequential
• Remote procedure call architectures. The components of a main program/ subprogram architecture are distributed across multiple computers on a net- work
Object-oriented architectures. The components of a system encapsulate
XRef
data and the operations that must be applied to manipulate the data. Communi-
A detailed discussion of object-oriented
cation and coordination between components is accomplished via message architectures is
passing. presented in Part Four.
Layered architectures. The basic structure of a layered architecture is illus- trated in Figure 14.3. A number of different layers are defined, each accomplish- ing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions.
These architectural styles are only a small subset of those available to the software designer. 2 Once requirements engineering uncovers the characteristics and con- straints of the system to be built, the architectural pattern (style) or combination of patterns (styles) that best fits those characteristics and constraints can be chosen. In
2 See [SHA96], [SHA97], [BAS98], and [BUS96] for a detailed discussion of architectural styles and patterns.
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
Components Layered architecture
F I G U R E 14.3
User interface layer
Application layer
Utility layer
Core layer
many cases, more than one pattern might be appropriate and alternative architec- tural styles might be designed and evaluated.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more