John wiley sons the art of software architecture; design methods and techniques stephen t albin 2003publishing inc isbn0471228869 html

Using examples in Java, XML, SQL, JSP, C++, and UML, this book: Includes thorough introductions to and applications of methodologies, design representations and models, technologies, ref

.The Art of Software Architecture: Design Methods and Techniques

John Wiley & Sons © 2003 (312 pages)Uncover the necessary steps to building successful software applications

Table of Contents

The Art of Software Architecture?Design Methods and Techniques

Introduction

Chapter 1 - Introduction to Software Architecture

Chapter 2 - The Software Product Life Cycle

Chapter 3 - The Architecture Design Process

Chapter 4 - Introduction to Software Design

Chapter 5 - Complexity and Modularity

Chapter 6 - Models and Knowledge Representation

Chapter 7 - Architecture Representation

Chapter 8 - Quality Models and Quality Attributes

Chapter 9 - Architectural Design Principles

Chapter 10 - Applying Architectural Styles and Patterns

Chapter 11 - Understanding Metamodels

Chapter 12 - Creating Architectural Descriptions

Chapter 13 - Using Architecture Frameworks

Chapter 14 - Software Architecture Quality

Appendix A - Bibliography

Index

List of Figures

List of Sidebars

Back Cover

Software architecture is emerging as a new discipline in response to the growing complexity of software systems and the problems they attempt to solve Software is becoming the dominant component of many systems and it is necessary for thesoftware development community to develop new practices, principles, and standards to manage the growing complexity.This book attempts to synthesize and distill information so that the practicing software architect, and especially the beginning software architect, can fill in the gaps in their understanding of software architecture design

The Art of Software Architecture supplies the information and tools necessary to make sound architectural decisions and

create effective software architectures Using examples in Java, XML, SQL, JSP, C++, and UML, this book:

Includes thorough introductions to and applications of methodologies, design representations and models, technologies, reference models, and architectural frameworks

Applies concepts with analysis, design, and architecture patterns

Demonstrates how to apply design patterns to your software design

Presents software architecting independently of any particular engineering process or organization maturity

About the Author

Stephen T Albin is a software engineer and consultant in northern California and has developed commercial enterprise software applications, platforms, and technologies He is a member of the ACM and IEEE Computer and EngineeringManagement Societies

The Art of Software Architecture—Design Methods and Techniques

Stephen T Albin

Wiley Publishing, Inc

Executive Publisher: Joe Wikert

Executive Editor: Robert M Elliott

Assistant Developmental Editor: Emilie Herman

Editorial Manager: Kathryn A Malm

Assistant Managing Editor: Vincent Kunkemueller

Text Design & Composition: Wiley Composition Services

This book is printed on acid-free paper

Copyright © 2003 by Stephen T Albin

All rights reserved

Published by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section

107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 RosewoodDrive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8700 Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: <permcoordinator@wiley.com>

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose No warranty may be created or extended by sales representatives or written sales materials The advice and strategies contained herein may not be suitable for your situation You should consult with a professional where appropriate Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages

For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002

Trademarks: Wiley, the Wiley Publishing logo and related trade dress are trademarks or registered trademarks of

Wiley Publishing, Inc., in the United States and other countries, and may not be used without written permission All other trademarks are the property of their respective owners Wiley Publishing, Inc., is not associated with any product

or vendor mentioned in this book

Wiley also publishes its books in a variety of electronic formats Some content that appears in print may not be available in electronic books

Library of Congress Cataloging-in-Publication Data:

Albin, Stephen,

The art of software architecture: design methods and

techniques / Stephen T Albin

About the Author

Stephen T Albin is a software engineer and consultant in northern California and has developed commercial enterprise software applications, platforms, and technologies He is a member of the ACM and IEEE Computer and Engineering Management Societies He can be reached at <stevealbin@computer.org>

Software architecture is often confused with low-level design and the technology stack Technology vendors and popular technology-focused journals tend to propagate this misunderstanding As a result, many software engineers produce architecture descriptions that are nothing more than regurgitated diagrams of technology layers The classic enterprise application architecture is often a diagram of so-called architectural layers depicting a presentation layer on top of a business logic layer (or middle-tier) on top of a persistence layer This representation communicates nothing about how the system handles the functional or nonfunctional requirements of the system It merely shows the technology to be used and how that technology will be integrated

There is a temptation to assume that the layers of an application architecture map directly to individual technologies: Presentation is composed of Java Servlets and Java Server Pages (JSP); the business layer is composed of

Enterprise JavaBeans (EJB); and the persistence layer is a relational database management system (RDBMS) For some simple systems, there is a one-to-one correspondence between the architectural layers and individual

technologies Those assumptions quickly become fallacies when the system becomes functionally more complex Presentation logic may be composed not only of the servlets and JSP but also of EJBs and data stored in a relational database (for example, user preferences) Business logic may be composed not only of middle-tier EJB objects but also stored procedures and database triggers as well as other component technologies such as business rules engines and workflow engines

For one system that I had to redesign, the only architectural description that existed was just such a technology stack

It depicted how eXtensible Markup Language (XML) documents would be passed between Java Servlets and

Enterprise JavaBeans as a flexible approach to creating the middle-tier application programming interface (API) It said nothing about how the system was composed of a main business logic subsystem, a security subsystem, and a reporting subsystem Instead, it focused on how XML documents would be mapped to and from the relational

database tables Engineers on the project would often draw whiteboard diagrams of the system to include these three subsystems, as well as several other functional modules The reality was that these were not modules There was no separation or decoupling between any of them The reporting module was composed of some user interface code that queried data from the same database tables that the other functions of the system operated on The security logic wasjust an aspect of the system There was no discernable security module; instead, the security logic was embedded in many objects throughout the system The development organization structured itself around the presentation layer andeverything else, treating the user interface as if it were a true module The resulting system was difficult and costly to develop and maintain

Software architecting involves the design of a system from multiple viewpoints The common viewpoints used in software engineering are the technology stack (or physical) view, the object (or data) model, and the use case (or behavioral) view These viewpoints are useful and necessary because they capture many types of design decisions and represent many system qualities such as functionality, information, and physical construction They do not represent many other important system quality attributes such as modifiability, buildability, security, reliability, and performance, nor do they represent non-operational or business-oriented qualities such as the ability to reduce development and maintenance costs

The problem with representing an architecture with this single technology-focused view is that we only see a vertical slice through a multidimensional system Many architectural decisions cannot be represented in this view If this is the only view we create, then we will probably neglect the other views to the detriment of the system itself

An often ignored architectural viewpoint is the component or subsystem view of a system By definition, a system is an aggregation of cooperating components Without this view the system appears as a single module, despite the fact that engineers may talk about the security subsystem or the reporting system It's easy to draw a few boxes and arrows on a whiteboard, but if these boxes and arrows don't mean anything, then we shouldn't bother

A module has a clear interface that other modules import The internals of the module are free to change A Java Database Connectivity (JDBC) driver is an example Applications rely on the published JDBC Java interfaces Many vendors produce implementations, but they all conform to the same interface and therefore can be replaced If an element of code cannot be replaced by another implementation without causing other elements to change, then that

element of code is not a module What makes a system modular is the relatively small amount of information shared between the modules and the development teams designing and implementing those modules Treating something as

if it were a module will only frustrate the developers and managers

In the above system, one of the first true decompositions of the system was the separation of the reporting system from the operational (or transactional) system The results were tremendous, especially given the simplicity of the decomposition No longer were there performance problems with running queries against the operational tables No longer were operational and reporting use cases intertwined The system was much easier to develop and maintain Inhindsight, the separation of the system into these two modules seems obvious and trivial Yet when no one was looking at the system from this point of view, it was far from obvious, and the problems incurred were great This little

design decision can even be expressed as a software architecture pattern: Separate operational data from analytic

data so that the two are loosely coupled such that they may be designed, developed, and maintained fairly

independently and so that the system may have better performance

Software architecture is emerging as a new discipline in software development in response to the growing complexity

of software systems and the problems they are attempting to solve Software is becoming the dominant component of many systems, and it is necessary for the community to develop new practices, principles, and standards so that we may somehow manage the growing complexity

There are a couple of philosophies concerning how to improve the software crisis One approach is to improve the quality of the software development process In this school of thought, quality can be improved by using iterative development techniques, rapid application development (RAD) tools, frequent integration and testing, and keeping careful records so that an organization can build up historical data that will aid in improving the process in future product cycles It uses iterative/increment development processes like the Rational Unified Process and the Capability Maturity Model (CMM) Another approach for improving software quality is to stay away from the heavyweight

planning-oriented processes and instead adopt agile processes and use of techniques such as RAD and eXtreme Programming (XP)

Most software engineers in the role of software architect have little or no training in the discipline of software

architecture, mostly because there is no well-developed theory or standard university curriculum As for prior

generations of untrained software programmers who developed their craft through trial and error, a lot of rediscovery

of principles, patterns, and techniques occurs Practitioners and researchers began to document reusable patterns of software design and engineering processes There is a body of knowledge accumulating in the industry and being documented as principles and patterns in books, conference proceedings, and technical journals However, the practicing software architect scarcely has time to keep up with the flow of information, let alone enough time to synthesize it into practical knowledge This book is an attempt to synthesize and distill much of this information so that the practicing software architect, and especially the beginning software architect, may be able to fill in the gaps in his

or her understanding of software architecture design

The Art of Software Architecture presents software architecting independently of any particular engineering process or

organization maturity It supplies the software architect with the information and tools necessary to make sound architectural decisions and create effective software architectures The book includes thorough introductions to and applications of methodologies; design representations and models; technologies (such as object-orientation and component-orientation); reference models; architectural frameworks; and analysis, design, and architecture patterns

No one book can serve as a software architect's handbook The subject is broad and deep, and it is evolving This book focuses on how software architects create software architectures It outlines the discipline and its methodologies and gives the reader a sense of the scope of the topic Whereas many software architecture books focus on a process

or a technology-based view, this book is organized around the fundamentals, models, and techniques of software architecture design

This book focuses on the design methods and techniques that a software architect must practice You cannot become

a good architect by simply reading about it; you must apply the things you have learned in order to understand how

they should be applied and how best to apply them One barrier to effectively using object-oriented design, for

example, is the skill in actually defining the right objects and their relationships UML and object-oriented programming languages only help you express your designs; they do not help you produce good designs Another barrier is that a solution is only as good as the problem statement If the problem statement is confusing, wrong, or missing, then the design process has no input ("garbage in/garbage out")

The Goals of This Book

The demands of software development organizations strain software designers This is especially true of smaller development organizations that do not have standardized development processes or a lot of experience in architectingsoftware These organizations make up about 70 percent of the software organizations that exist today Most of these organizations cannot implement expansive development methodologies or adopt formal software design specification methods for any number of reasons such as cost of training in time and money, cost of tools to support the

methodology, cost of evangelizing the methodology in terms of time and personal energy, the risk of introducing a new methodology while trying to build software, and simply a lack of understanding of the practical importance of an effective software architecting process Software development organizations need to implement practices that improvethe software architecture without necessarily requiring the organization to change overnight The software architects are often the persons who need to effect this change

This book is especially for the software architect in the smaller, less mature software development organization

(characterized as predominantly practicing ad hoc development) It provides practical guidance on the generation of

effective software architectures It will:

Provide a sound understanding of the fundamental concepts of software architecture

Serve as a road map through the information and schools of thought in software architecture

Teach classic software architecting styles, patterns, heuristics, methodologies, and models

How This Book Is Organized

Most of the literature on software architecture addresses the structure of software but not the design processes and heuristics for generating them Software pattern books provide a lot of help in this area because they not only show abstract software structures but they also provide some techniques for generating architectures based on these patterns What seem to be missing are the fundamentals of software design, especially from the architecture

perspective

This book provides an integrated view of design methods, processes, practices, heuristics, and patterns and gives the reader a better sense of the scope of the topic of software architecture while providing practical guidance for designing software architectures from analysis through implementation

In Chapter 1, "Introduction to Software Architecture," I explore the roots of software architecture The fundamental

problems of software development, which comprise the software crisis, are that software is expensive to develop, it is

typically of low quality, and it is often delivered late Software development has undergone several small revolutions or paradigm shifts to address these problems Each new paradigm incorporates new technologies but still solves the problems the same basic way

Software architecture is an emerging discipline that focuses on the design of software at a level higher than the programming language It is possible to reason about many qualities of a software system before it is built, based on

the architectural design models or architectural description.

In Chapter 2, "The Software Product Life Cycle," I address the role of software architecture in the software product development life cycle There are many methodologies and views of software development, which we call

development life-cycle models Different stakeholders have different perspectives and concerns and need to see different information in order to assess progress and quality Architecture provides another viewpoint of the life cycle that involves developing a system design that balances the competing concerns of all stakeholders

Chapter 3, "The Architecture Design Process," presents a general model of the process of architectural design A design solution to a problem may be a concrete artifact like source code, or it may be an abstract artifact like a high-level model Software design is a progression of refining abstract problem statements to executable code In the middle of this progression is a series of models that help the problem-solving process

Design is the process of finding or discovering solutions to problems Design methods help us search for these solutions Models are one way to manage the complexity of design discovery Models represent essential knowledge for solving a particular problem while suppressing other knowledge that may be irrelevant to the problem and the inclusion of which would only hinder the design process

In Chapter 4, "Introduction to Software Design," I present the fundamental methods and techniques of software design Software design can be viewed as a psychological activity in which a designer is applying design principles to problems in order to produce solutions In a systematic design methodology, we reduce the risk of project failure by

producing more than one possible solution; that is, we search for the solution In Chapter 5, "Complexity and

Modularity," precise definitions of complexity, modularity, and the notion of architectural levels of design are presented Complexity is one of the main forces that we attempt to manage with our software development tools and methods When not managed, complexity can cause a project to be delivered late, over budget, or cancelled Complexity can bemeasured by the interconnectedness of things In order for a system or process to exhibit complexity, it must be an

aggregation of multiple interconnected parts We refer to these connections as dependencies A fundamental tool in

representing a complex system, the design structure matrix (DSM), is presented

The design structure matrix can help the architecture find the right modules for the system and the shared design

decisions among modules, which are called design rules.

Design is about finding solutions to problems In Chapter 6, "Models and Knowledge Representation," we see that problems and solutions are both forms of systems knowledge In order to begin a search for a solution, we must understand the problem There is a hierarchy of systems knowledge starting from the most basic knowledge of the types of attributes of a system, the values of those attributes, generative models that can generate those attribute

values, and finally a physical system that implements the generative model Models are the means by which we capture and represent knowledge about the system that we are designing.

In Chapter 7, "Architecture Representation," we learn about the problems of describing the component structure of a software system The classic views of software have fairly mature modeling notations However, there are no standardarchitecture description languages that are expressive enough to represent many types of architectural styles and yet still be practical This chapter continues the theme of models into the more concrete realm of architecture

representation

In Chapter 8, "Quality Models and Quality Attributes," I present classic system quality attributes and how the

architectural design can address them A system is understood by understanding its quality attributes The classic software quality attribute types include functionality, security, performance, reliability, and modifiability

In Chapter 9, "Architectural Design Principles," we learn about specific methods and techniques that can help us discover the components of the system Design principles are applied within the context of design methods and techniques

Chapter 10, "Applying Architectural Styles and Patterns," presents the concept of architectural style and how it influences the architecting process Architectural styles are generalized knowledge captured about existing system architectures There is a small set of basic architectural styles from which an architecture may be derived

Chapter 11, "Understanding Metamodels," continues the theme of architecture models A metamodel is a model for creating models Well-defined metamodels can help in the discovery and creation of architectural designs by reusing domain knowledge Reference models are metamodels that describe domain-specific problem decompositions A reference model may be an industry standard, such as the common warehouse metamodel or the workflow reference model or an informal model presented in the software design literature In this chapter we see how to use metamodels

in the architecture process

In Chapter 12, "Creating Architectural Descriptions," I present the IEEE Recommended Practice for the Description of Software Intensive Systems, Std 1471 This is a standard framework for software architectural description based on the concept of multiple views

Chapter 13, "Using Architecture Frameworks," continues with the theme of the architectural description In this chapter

I present the 4+1 View Model of Architecture and the ISO Reference Model for Open Distributed Computing

(RM-ODP) as specific frameworks for creating an architectural description The RM-ODP is a powerful model that prescribes five standard views of architecture: the enterprise viewpoint, the information viewpoint, the computational viewpoint, the engineering viewpoint, and the technology viewpoint By following the metamodels of each of these viewpoints, the software architect can create a series of architectural models that represent the system in various states of abstraction

I end the book with Chapter 14, "Software Architecture Quality." In this chapter I return to the subject of quality at the architectural level of design Quality cannot be tested into a system, so a system must be designed with quality The candidate architecture for a system can be assessed to understand the quality attribute characteristics of the system described, before actually constructing the system A software architecture description can be evaluated so that we may understand many potential quality attributes of the system including modifiability, performance, and reliability Each quality attribute can be assessed using different assessment techniques

Who Should Read This Book

Beginning software architects are usually experienced software engineers However, the software engineer must make a mental paradigm shift when it comes to designing software systems at the architectural level All of his or her prior knowledge about object-oriented programming is still applicable, but it must be applied on a different scale, at different levels of abstraction This book is useful for understanding how to architect a software system and even how

to design a single module The design principles can be applied at many levels of software design Experienced software architects will find new material to broaden their knowledge and provide them with a fresh insight into software architecting

Technical managers will gain insight into the processes of software architecting, as well as the styles of architecture and techniques used to generate them This will enable managers to more effectively create project teams, plans, and schedules, as well as implement reuse plans, conduct design reviews, and choose an appropriate process framework Architecture, organization, and process are interwoven The architecture of a system influences the structure of an organization and the process by which a system is realized Technical managers will also learn that the architecture of

a system addresses many business- and development-related requirements

Depending on what you want out of this book, you should have experience in one or more of the following:

Object-oriented programming with a language such as C++ or Java

Managing object-oriented projects

Object-oriented analysis and design

Other systems analysis and design techniques (for example, structured analysis)

Chapter 1: Introduction to Software Architecture

Overview

Software architecture involves the integration of software development methodologies and models, which

distinguishes it from particular analysis and design methodologies The structure of complex software solutions departs from the description of the problem, adding to the complexity of software development Software architecture

is a body of methods and techniques that helps us to manage the complexities of software development

Software architecture is a natural extension of the software engineering discipline In early literature it was simply

referred to as programming in the large Software architecture presents a view of a software system as components

and connectors Components encapsulate some coherent set of functionality Connectors realize the runtime

interaction between components The system design achieves certain qualities based on its composition from components and connectors The architecture of a software system can be specified in a document called the architectural description Software architecture design is not entirely different from existing software design

methodologies Rather it complements them with additional views of a system that have not been traditionally handled

by methodologies like object-oriented design We will learn that software architecture fits within a larger enterprise

architecture that also encompasses business architecture, information technology architecture, and data architecture.

This chapter begins with a brief discussion of the evolution of software development, followed by the fundamental engineering techniques that comprise the discipline of software engineering Finally, we look at the craft of software architecture as a discipline that complements software engineering

Evolution of Software Development

Roughly every decade the software development field experiences a shift in software design paradigms Design methodologies and tools must evolve as the problems and technologies become more complex Software

development was born around 1949 when the first stored-program computer, the Cambridge EDSAC, was created Programs were initially created as binary machine instructions This approach to programming proved to be slow and difficult because of the human inability to easily memorize long, complex binary strings The notion of a

human-readable shorthand for designing programs was conceived Initially, the concept behind the programming

shorthand was to allow a program designer to design a program and for a programmer or coder to manually translate

the shorthand into binary code

In the early 1950s, it became apparent that the majority of a programmer's time was spent correcting mistakes insoftware One response to this situation was the creation of program subroutines that allowed programmers to reuseprogram fragments that had already been written and debugged, thus improving the productivity of programmers Bythe late 1950s, the handcrafting of programs—even with the aid of reusable subroutines—was becoming

uneconomical Hence research in the area of automatic programming systems began Automatic programming would

allow programmers to write programs in a high-level language code, which was easier to read by humans, that would then be converted into binary machine instructions by use of another program Thus, the first paradigm shift in software development was about to occur

Experienced binary programmers were reluctant to change their habits to adopt a new method of working and resisted automatic programming However, automatic programming became the dominant paradigm after International Business Machines (IBM) developed an automatic programming system for scientific programs called FORTRAN (the Formula Translator) Automatic programming not only improved programmer productivity but it also made programs portable across hardware platforms Porting to new hardware prior to automatic programming required rewriting an entire program, which was too costly and a hindrance to selling hardware By the mid-1960s, FORTRAN had

established itself as the dominant language for scientific programming

During the 1960s, there was a dramatic rise in the number of software development contractors and ready-made

programs for specific vertical markets, such as banking and insurance The term software was coined as an implicit

recognition that software was viewed as an entity in its own right Software was also being marketed and sold

separately from hardware, which marked a departure from the earlier practices of giving software away for free as part

of the hardware platform The hiding of the internal details of an operating system using abstract programming interfaces improved programmer productivity and helped make programs more portable across hardware platforms Programs could work with logical files instead of physical locations of bits on a tape or magnetic disk It was also during this period that extensive research began in programming languages, which continued through the 1970s

By the late 1960s, it was clear that software development was unlike the construction of physical structures: You couldn't simply hire more programmers to speed up a lagging development project (Brooks, 1975) Software had become a critical component of many systems, yet was too complex to develop with any certainty of schedule or

quality This imposed financial and public safety concerns The situation became known as the software crisis, and in response the software development community instituted software engineering as a discipline It called for software

manufacturing to be based on the same types of theoretical foundations and practical disciplines that are traditional for the established branches of engineering

In 1968, Edsger Dijkstra published a paper on the design of a multiprogramming system called "THE" (Dijkstra, 1968) This is one of the first papers to document the design of a software system using hierarchical layers, from which the

phrase layers of abstraction was derived Dijkstra organized the design of the system in layers in order to reduce the overall complexity of the software Though the term architecture had not yet been used to describe software design,

this was certainly the first glimpse of software architecture; programming in the large was a common phrase used to describe this aspect of software design

A second paradigm shift occurred in the first half of the 1970s with the development of structured design and software development models These were based on a more organic, evolutionary approach, departing from the

waterfall-based methodologies of hardware engineering Research into quantitative techniques for software design

began but never established itself in mainstream industry, in part due to the inherent qualitative nature of software systems During this time researchers began focusing on software design to address the problems of developing complex software systems The premise of this work was that software design is a separate activity from

implementation in software development and that it requires its own tools, techniques, and modeling languages

In 1972 David Parnas published a paper that discussed how modularity in systems design could improve system flexibility and comprehensibility while shortening development time (Parnas, 1972) He introduced the programming

world to the concept of information hiding, which is one of the most fundamental design principles in software

development today

In the 1980s, software engineering research shifted focus toward integrating designs and design processes into thelarger context of software development process and management Structured design methods could not scale assoftware systems grew in complexity, and in the latter half of the 1980s a new design paradigm began to take

hold—object-orientation With object-oriented programming, software engineers could (in theory) model the problem

domain and solution domain within an implementation language Research that led to object orientation can be traced back to the late 1960s with the development of Simula, a simulation programming language, and it was later refined in Smalltalk Object-oriented programming started to become popular with C++ At this time there was also a shift in application design metaphors from text-based terminals to graphical user interfaces (GUIs) Object-oriented

programming was well suited for the development of GUIs In the late 1980s and early 1990s, the term software

architecture began to appear in literature.

Object-oriented programming was in full swing by the mid-1990s, when the Internet became the new computing platform At around the same time, software design was experiencing another shift This time it was not away from the prior design paradigms, however, but rather toward an integration of methods Object orientation was being

augmented with design techniques such as Class/Responsibilities/Collaborators (CRC) cards and use case analysis Methods and modeling notations that came out of the structured design movement were making their way into the object-oriented modeling methods This included diagramming techniques such as state transition diagrams and processing models

It was becoming obvious that an integrated, multiviewed approach to design was required to manage the complexity ofdesigning and developing large-scale software systems This multiview approach culminated in the development of theUnified Modeling Language (UML), which integrates modeling concepts and notations from many methodologists It was also during the late 1990s that design patterns started becoming a popular way to share design knowledge

I believe that we are experiencing a fifth paradigm shift in software development, which is the recognition that software architecture is an important aspect of software development and of the introduction of software architecture methods and activities into the software development life cycle This shift, like the last one, is not one of divergence of design methods but rather one of the integration of new methods and activities with existing methods and activities

Fundamentals of Software Engineering

The main task of engineers, according to Pahl (Pahl, 1996), "is to apply their scientific and engineering knowledge to the solution of technical problems, and then to optimize those solutions within the requirements and constraints set by material, technological, economical, legal, environmental, and human-related considerations." We can extend this definition to define the main task of software engineers Informally, the main task of software engineers is to apply their logic and programming knowledge to the solution of technical and business problems Then they optimize those solutions within the requirements and constraints set by logic (the material of software engineering); software

technology; and economical, legal, environmental, and safety considerations

The term engineering, as applied to software, is not always entirely appropriate I think it assumes too broad of a

specialty I think of software development as involving many subdisciplines These include specialties like database design and implementation, Structured Query Language (SQL), Java, and C++ programming, and eXtensible

Stylesheet Language Transformations (XSLT) coding The specialties can even be finer grained than this Each of these technologies needs specialists just as there are specialists in established engineering disciplines such as electronic and mechanical engineering In each of these fields there are further specializations Yet we treat software development as if it were a single engineering discipline It is, in fact, several related disciplines Imagine that a competent developer of XSLT is given very clear specifications, to which a given transformation, or stylesheet, must conform, including well-defined inputs and outputs The XSLT designer can produce a stylesheet using available tools and methods and possibly reuse parts from an existing library of XSLT This assumes that we can provide well-definedspecifications

I think that the division of software engineering is probably necessary with some combination of technology

(databases, Java) and problem domains Of course, having specialties with individual techniques, tools, and methods still poses a problem of engineering sophisticated systems that involve integrating these technologies This is where the software architect comes in The software architect could be considered a type of software engineer that may not necessarily be a specialist in all of the particular software engineering domains The software specialist is a specialist

in architecture design, and understands the varieties of technology well enough to integrate them into a cohesive solution to a complex problem

It is not uncommon in practice today to divide labor along technology lines It is common to separate user interface (UI) or presentation development from middle-tier development or back-end development But without architecture, even this separation of engineering specialties will not necessarily help produce high-quality systems Some authors

argue that this separation (called horizontal slicing) is not necessarily effective and advocates a vertical slicing where

each developer owns a set of functional requirements and implements them front to back Both approaches can be used effectively It's more a matter of the skills of the individuals together with the technical leadership and project management techniques

The two primary problems in software development that have yet to be solved satisfactorily are making systems cost effective and of higher quality Improving the productivity of software engineers is an important part of making systems cost effective Improving the quality of systems is important in order to make them safer and more effective in

accomplishing business goals and objectives Improving the quality of the design of a system also aids in achieving cost-effectiveness A major obstacle to solving these two problems is the complexity inherent in developing software This is a result of the complexity of the problems being solved, the wide variety of technologies that may be applied, and the fact that software development is almost purely a design activity (As opposed to other engineering disciplines

of which manufacturing is a major time and cost element of the process, in software even writing code is a design activity and cannot be managed like a manufacturing process.)

Using current methods, technologies, and programming languages, we are able to solve problems to a certain level of complexity However, to break through the barriers established by the complexity of the problem to build larger systems, we need to evolve our methods and tools As systems grow in complexity, certain other quality attributes become more relevant; as the size of a system grows, the number of dimensions of the system also grows In small systems, we can focus on functional correctness and performance In large systems, we need to address attributes such as portability, security, reliability, and modifiability

There are several fundamental software engineering techniques that can help improve the quality and

cost-effectiveness of software:

Reusable assets

General-purpose programming languages

Special-purpose programming languages

Modeling languages and notations

Reusable Assets

Code reuse improves the productivity of the programmer by shortening the amount of time required to implement some functionality Of course, there is a trade-off of time spent discovering, learning, and integrating the reusable code, so reusable code needs to be easy to find, quick to learn, and straightforward to integrate Code reuse manifests itself in the following:

Source code that can be copied and modified to suit or be used as is (for example, C++ algorithms from a shareware repository or copied from a book)

Commercial off-the-shelf (COTS) components that are available in binary (compiled) form and that can be imported or linked to other components or applications This includes:

Binary code "libraries" that can be linked into a program at compile time or loaded and bound at run time (for example, a sockets library)

Operating environments and platforms (for example, operating systems, databases,application servers)

Reusable components, especially ones that address large problem spaces, provide a huge boost in productivity Imagine if you had to write your own middleware, application server, and database in order to develop a distributed business application Of course, all of those reusable technologies contain more features than any single application needs but even to develop the subset required by an application is a formidable and time-consuming task

In order to effectively reuse components, we must be able to express our solution in terms of the abstractions of the component There are times when a particular abstraction, such as relational entities, doesn't suit all of our needs, just

as a natural language may not have words to express certain concepts So we invent new technologies just as we invent new words Object-oriented databases are an example of such an invention When object-oriented

programming started to supplant existing structured languages like C and Pascal, a semantic gap was introduced between the representation of information in the programming language and the representation of information in the database Many papers and books have addressed the object-relational mapping problem Today we have

documented patterns for object-relational mapping that assist us in overcoming this obstacle

General-Purpose Programming Languages

Powerful general-purpose programming languages like C++ and Java provide expressive power for creating solutions

to many complex problems by allowing the programmer to focus on the problem at hand and worry less about specific hardware capabilities General-purpose object-oriented languages don't solve the problem of complexity alone; they must be used in conjunction with guidelines and design patterns How often have you seen a class that was really just

a big collection of structured subroutines, such as the God Class (Riel, 1996)?

Special-Purpose Programming Languages

Some COTS components have specialized programming languages for creating applications or parts of an

application The languages can be easier to use than general-purpose programming languages for specific problems For example, when using a relational database component a programmer uses Data Definition Languages (DDL) and SQL to implement a data storage and access solution SQL is specialized for the domain of relational databases

Specialized languages improve productivity by allowing the developer to think in terms of the abstractions of a specific technology (which is a simpler domain to comprehend) rather than by using the same general-purpose language for allprogramming problems If a programmer had to understand how the data was stored in files and how the files were indexed, the problem would become much more complex Of course, specialized languages introduce complexities of their own The industry addresses this by developing guidelines and design patterns for the effective use of a

particular technology In relational databases, the theory of normal forms was developed to help programmers design databases with certain quality attributes Other examples of specialized languages are Web presentation technologies such as Active Server Pages (ASP), Java Server Pages (JSP), and Hypertext Preprocessor (PHP), and data

representation and transformation languages such as Hypertext Markup Language (HTML), eXtensible Markup Language (XML), and eXtensible Stylesheet Language Transformations (XSLT)

Modeling Languages and Notations

Modeling languages and design notations emerged as methods for improving software design quality It is argued that

an expressive modeling notation can expand our capability to design software much like mathematics allows us to reason about more complex things than our minds would normally be capable of without such a language The entity relationship diagram (ERD), for example, is a powerful modeling language and notation that allows a software engineer to design and communicate expressive data models Without such a language, it would be difficult to think about the information design of a system, and without a notation to represent the diagrams, it would be difficult to communicate those designs to others The formality of the language allows different people to interpret a model in a precise way

The UML is a rich collection of modeling notations for representing many aspects or views of a software system, including the information and information flow, class structure, and object interactions The UML and other modeling languages improve a software engineer's individual capacity to create complex solutions Some UML tools today allowfor partial code generation from UML models It is possible that a language like UML may become a true

programming language (either special-purpose or general-purpose) As we have seen in the brief history above, what begins as a notation for representing software design can become the next-generation programming language

Elements of Software Architecture

In this section, I present an overview of software architecture I explore the definition of software architecture and the relationship between architecture and systems followed by a discussion of architectural descriptions I discuss the relationship between the activities of software architecture and other software design methods In the last section of this chapter, I discuss how software application architecture fits into the context of enterprise architecture

Components, Connectors, and Qualities

Many authors equate architecture with system quality attributes such as reliability and modifiability and how those attributes are affected by the physical decomposition of the software system in terms of components and their

arrangements Different arrangements of components can affect attributes like reliability and modifiability without necessarily affecting the functionality Architectural Description Languages (ADLs) are languages for describing a system at this level of abstraction An ADL is one view of the architecture of a software system To get a more

complete or comprehensive understanding of the architecture requires multiple views

Shaw and Garlan define software architecture abstractly as involving the description of the elements that compose the system, their interactions, the patterns and principles that guide their composition and design, and the constraints on those patterns (Shaw, 1996) A system, therefore, is defined in terms of its physical (implementation) elements or components and their interactions A system itself is also a component, and systems can be composed of other systems Booch considers an object-oriented design to be the application's architecture (Booch, 1994) Others consider the architecture to be the global view or the high-level set of views that are commonly defined in architecture reference models, like the 4 + 1 Model View or the Reference Model for Open Distributed Processing (RM-ODP)

As defined by the Institute of Electrical and Electronics Engineers (IEEE) Recommended Practice for Architecture

Description of Software-Intensive Systems (IEEE standard 1471–2000), an architecture is "the fundamental

organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." This definition is fairly abstract and applies to systems other than just software

The term software architecture in the context of this book means the observable properties of a software system (also known as the form of the system) It is important to note that the structure of a system includes its static and dynamic

forms In the sense of object-oriented design, this includes not only the models of components and classes but also

the models of component and object collaborations and the user-perceivable functions they enable The term software

architecting means the process of creating software architectures Although the classic definition of architecture

includes the processes and the artifacts, I choose to use the word architecting as defined by Rechtin (Rechtin, 1991) to differentiate between the process and the artifacts Finally, the term software architect refers to an individual who performs architecting to produce architectures

All of these definitions include some notion of the function and form of a system in terms of components, their static and dynamic interrelationships and environmental relationships, and the principles and guidelines for the design, evaluation, and evolution of the components and the system as a whole All of these are begging definitions because the definitions are themselves based on abstract, ill-defined concepts These concepts and the overall definition of software architecture shall become clear throughout the course of this book

Software systems have architectures, regardless of how simple they are in terms of components However, an

architecture is not a system In early systems the main attributes of real concern were functionality, portability, memoryusage, and performance—basically, an architecture with relatively few dimensions of quality attributes There was nopressing need for software architectural descriptions Functionality could be comprehended by looking at the sourcecode itself or executing the system with some reasonable set of test data Portability was achieved by simply usinghigher-level general-purpose programming languages Performance could be comprehended by executing the system

or studying the algorithms of the program

When systems started becoming more complex in terms of function and information, the use of structured

programming techniques and data modeling methods helped with the design and comprehension of the software It

was even possible to start modeling the system abstractly as a hierarchy of functions and a graph of information structures, which made it possible to reason about some aspects of the correctness of the program before

implementing the specific functions and data structures Programmers would execute the system or portions of the system to validate the functions and to identify performance bottlenecks They would then correct those functions or make those functions more efficient or refactor the functions if necessary Similarly, the programmers would study the system for memory and other resource usage

As software systems continued to grow in complexity, the structured programming and data modeling techniques could not scale in terms of number of functions or semantic complexity of data, or in terms of other attributes like modifiability and reliability that were becoming more important in software systems In response, object orientation took over as the dominant programming methodology in new application development Object orientation could handlethe increasing complexity of information semantics and functions as well as address quality attributes that were becoming increasingly important: reusability and modifiability As you can see, it is not enough to model the system directly in source code and reason about its properties How do you evaluate source code for reliability, modifiability,

or usability? Even the use of models such as class hierarchies and object collaboration diagrams are not enough to reason about the many quality attributes required in today's software systems We need additional tools and

techniques to design software as the architecture of software grows in complexity

CIVIL ARCHITECTURE: A METAPHOR FOR SOFTWARE DESIGN

The field of civil architecting has become a popular metaphor for the development of software-intensive

systems In civil architecture the architect creates a representation of a building's physical structure that is limited in scale or number of dimensions The architect identifies the constraints on the design such as the location and local building laws and integrates structural, business, and aesthetic concerns The architect is the client's advocate and is trusted to coordinate all aspects of the building project but does not extend to all aspects

of the project The architect addresses usage, value, cost, and building risks within the client's requirements The architect aids the client in making a build or no-build decision

Software systems today really are more analogous to urban developments than to individual buildings Considerhow a software system evolves (albeit in condensed time compared to that of cities) If buildings evolved as drastically as software, we would see buildings where new floors are added or blocks of floors are removed, or where additional buildings are appended to the existing one However, when compared to cities and especially urban development, we do see analogous evolution such as new housing developments sprouting up where there were none, new roads being created, many highways being widened to allow for new traffic requirements, and old neighborhoods being razed and replaced with malls Two separate urban areas eventually merge and become indistinguishable This is more like what is going on in software development today Of course, with all metaphors there are areas where the two things being compared simply don't equate, and this is where we need

to be careful and avoid the fallacy by analogy

The process of creating an architectural description requires intermediate models that help to bridge this chasm This

is the role of design methodologies Commonly, functional and information requirements are mapped to

implementation-independent data models and functional models For example, use case models and application domain object models (both analysis models) serve as intermediate models They formulate the requirements in terms

of concepts closer to the implementation space but still expressed in terms of the problem space.

Depending on the methodology, the functional model and information model are mapped to some logical component model taking into consideration other required quality attributes such as modifiability and performance The resulting models show more clearly the relationship between function and data and other nonfunctional quality attribute

requirements This model is closer to the solution space of computational elements and is further from the semantic space of the problem However, it is still expressed in implementation-independent terms In object-oriented terms, this would be another object model (class diagrams, object collaboration diagrams, and sequence diagrams in UML) that still contains the essence of the problem domain objects but transformed to an idealized computing object

The computational view starts to show the shape of the architecture since the computational elements embody not only functional and information requirements but also the nonfunctional requirements It is within this type of model that architectural styles are applied Architectural styles are generalized computational models that are devoid of specific application domain functionality Examples of architectural styles are n-tier client/server, pipes and filters, and

distributed objects The information and functional models do not take into account the architectural style (or should attempt to limit the number of constraints that might affect the selection of architectural styles) It is quite possible that the objects in the computational model no longer resemble their analytical counterparts This is where the complexity

of software architecting lies, and it is at this point where the form of the solution appears to depart from the

description of the problem This is why a clear formulation of the problem is so important Without it, it is easy for software engineers who are focusing on the internals of the software system to lose sight of the overall problem being addressed

The computational model may be influenced by available technologies and possibly by technology requirements For example, the enterprise platform may be chosen in advance It is common for an organization to adopt a platform such

as Microsoft XML Web Services platform (.NET) or Java 2 Enterprise Edition (J2EE) before a full abstraction of the computational model of the system is complete For better or for worse, the software architect must design within these constraints A model of the technology (sometimes referred to as a physical architecture) maps the computational model to physical components such as ASP, JSP, Enterprise JavaBeans (EJBs), Component Object Model (COM) objects, database entities, and XML documents

The mapping of elements between models must also be pspecified as well as the rationale for each model The rationale captures why a decision was made given many competing choices The larger the software system, the moreformal or systematic the models, traces, and rationales should probably be The smaller the system, the less

important The software architecture team must ultimately determine how much is actually modeled and specified and how formal or informal to be It is these activities that form the core set of activities that the architect should perform

Software Architecture versus Software Design Methodologies

How does software architecting differ from software design methodologies such as object orientation? Software architecting is a relatively new metaphor in software design and really encompasses design methodologies such as object orientation as well as analysis methodologies The software architect today is a combination of roles such as systems analyst, systems designer, and software engineer But architecting is more than just a reallocation of

functions: The different aspects of architecting may still be performed by specialists but are now commonly falling

under the orchestration of the chief architect The concept of architecting in software is meant to subsume the activities

of analysis and design into a larger, more coherent design framework In addition, the demands of applications today are different than they were even 10 years ago when object orientation was becoming the established design

paradigm Applications tend to be larger, more integrated, and implemented by using a wide variety of technologies Organizations are realizing that the high cost of software development needs to be brought under some control and that many of the promises or claims of methodologies have still not helped with this cost

If architecting subsumes analysis and design, what makes it different than analysis and design? For example, why is architecting different than object-oriented analysis and design? In many ways it is the same but the scope of the analysis and design efforts is bigger We are recognizing that object models such as class diagrams are still not expressive enough to capture all aspects of a system and that we need to integrate other methodologies and models into a coherent whole This integration of methodologies and models is one thing that distinguishes software

architecting from particular analysis and design techniques

Just as the software development community claimed the name software engineering in an attempt to raise the bar of

current development practices, so has the software engineering community adopted the term software architecture to

say that we recognize that many aspects of software development really resemble systems architecting and urban planning This is most evident in the adoption of pattern languages for software design Originally a concept developed

by Christopher Alexander, pattern languages are reusable elements of architecture wisdom for designing and

constructing cities, buildings, houses, and so on, down to the smallest details, such as the placement of chairs in a room to satisfy certain desired qualities of living (Alexander, 1979)

So to identify a new profession called software architecting is to make a statement that we recognize that software development is really not scientific but rather more closely resembles the craft guilds of the Middle Ages This is not to say that we do not strive for a scientific underpinning to what we do as software developers, but that we are realistic about the state of the art in software design To claim the title is also to make the statement that we recognize that software development is really not a homogeneous activity relegated to a single specialty (programming) but involves many specialties and different technologies Even though these technologies are all software, they really require different expertise and design methods Therefore, we recognize that software architecting involves interdisciplinary software engineering methodologies from object-oriented analysis to functional decomposition; from object-oriented programming to relational database design and XML schema design, and even user interface and usability design

Types of Architecture

In the IT industry, the term architecture is used to refer to several things From an enterprise point of view, there are

four types of architecture:

Business architecture

Information technology (IT) architecture

Information architecture

Application (software) architecture

Collectively, these architectures are referred to as enterprise architecture A business or business process architecture

defines the business strategy, governance, organization, and key business processes within an enterprise The field of business process reengineering (BPR) focuses on the analysis and design of business processes, not necessarily represented in an IT system The IT architecture defines the hardware and software building blocks that make up the overall information system of the organization The business architecture is mapped to the IT architecture The IT architecture should enable achievement of the business goals using a software infrastructure that supports the procurement, development, and deployment of core mission-critical business applications The purpose of the IT architecture is to enable a company to manage its IT investment in a way that meets its business needs by providing a foundation upon which data and application architectures can be built This includes hardware and a software

infrastructure including database and middleware technologies New IT technologies enable business processes and capabilities that would otherwise not be possible The Web is an example

The data architecture of an organization includes logical and physical data assets and data management resources Information is becoming one of the most important assets a company has in achieving its objectives, and the IT architecture must support it Application architecture serves as the blueprint for individual applications systems, their interactions, and their relationships to the business processes of the organization The application architecture is commonly built on top of and utilizes the services of the IT architecture The distinction between what is an element of the application architecture, data architecture, and IT architecture can be blurred As application-specific features become necessary for other applications, they can be migrated into the IT architecture Applications are typically integrated using the IT infrastructure It is common in enterprise development, both in one-off systems and in

commercial systems, that elements of the data architecture and IT architecture are incorporated into the application architecture Sometimes this is for reasons of development efficiency, but it can have an impact on how easily a customer can deploy, integrate, and manage the system

A software application is a computer program or set of programs that uses existing technologies to solve some end-user problem such as the automation of an existing business process Enterprise business applications are largelyinformation processing applications (as opposed to a video game, which performs a lot of real-time simulation but is not a heavy information processor) Some applications are created for a perceived need that has not been proven

This is called greenfield development, and the purpose is typically to tap into new markets and often requires some

technical innovation as well as creation of new approaches to solving business problems What makes this challenging

is that the new approach may not have been feasible without technology For example, applications that perform analytics on customer profile data would not have been economically feasible as a manual business process

Application architecting is more than the specification of the internal physical structure of the software It involves creating models of the problem in order to simplify and understand the problem and creating

implementation-independent models of the solution that address those problems, for example, creating business process workflows and reviewing these with the end users It also involves user interface and interaction design The way the system works should map to how users perceive the system's architecture Users do not need to know the internal structure; they just need to understand how certain elements work together so that they can reasonably predict the application's behavior

In this chapter I presented a brief history of software development, in particular the evolution of software engineering and how a craft of software architecture has emerged as an important aspect of software development There are several observations we can make about software architecture:

Systems have architectures, but architectures are not systems

Architectural descriptions are not architectures; they describe the architecture of a system

Architectural descriptions are composed of multiple views

Software architecture design subsumes and integrates many software design methodologies

In Chapter 2, I present the software product life cycle in more detail and show how various views of the life cycle, including the software architecture view, fit together

Chapter 2: The Software Product Life Cycle

Overview

In this chapter, we categorize the various ways in which stakeholders perceive the software development process and product life cycle using the Rational Unified Process (RUP) as a foundation We use views, which are ways of categorizing or labeling these different perspectives The views may appear to be processes from the point of view of individual stakeholders However, these views are really just different perspectives on the life cycle of a software product and on the software development process The views presented are:

architectural specifications and models (artifacts) I am producing by explaining how they fit into the development life cycle and why they are important The problem stems, in part, from the fact that most software development life cycles do not bring architecture to the forefront as they do requirements, design, implementation, and testing

The management view is presented first in this chapter This is based on the RUP life-cycle phases The software engineering view follows This view captures how software engineers view the development life cycle The engineeringdesign view represents a detailed design process view, which can be thought of as zooming into the design aspect of the software engineering view The architectural view represents the software development life cycle from the perspective of architecting concerns, activities, and artifacts This chapter ends with a discussion of how the views are related

Each view of the development process is comprised of phases, activities, tasks, and steps Intuitively the term phase

implies some interval of time and is externally distinguishable from another phase Phases may be serial, each executing one at a time in a strict order Phases may overlap, in which case a phase begins before a previous phase

ends An example of a phase is the product planning phase The term activity is more abstract than phase In the

context of this discussion, it means a particular type of work performed by an individual or a group For example object-oriented analysis is an activity It may be performed within a single phase or across multiple phases

A task refers to a specific schedulable item A task can appear in a project plan and be assigned resources An

example of a task is to design and implement a specific business object A sequence of steps comprises a task or an activity A step cannot be scheduled or tracked in a project plan very easily but refers to a fundamental action

performed by a designer or programmer An example step of the analysis activity is to identify all candidate domain objects that appear directly or indirectly in the customer requirements

Management View

Managers want to see the progress toward achieving some goal (such as a milestone or deliverable) They typically look for high-level, simplified indicators, such as percentage of work completed In waterfall-based methods, each milestone and the completion of a development phase is marked by the completion of some set of deliverables such

as requirements documents and design specifications

In modern software methodologies, deliverables are rarely completed before work begins on the next deliverable For example, requirements are never fully articulated and understood prior to beginning implementation Sometimes it requires diving into the details of the system's design and implementation to uncover tacit requirements and

contradictions in requirements The architecture of a system, as represented by an architectural description, is not necessarily completed before implementation begins either As with requirements, it may take some detailed design and implementation effort to further understand the system in order to revise the architectural design Modern methodologies attempt to account for this by building into the process feedback loops from implementation and testing all the way back to requirements analysis

This feedback loop is what makes completing certain documents and specifications difficult Methodologies like RUP

do not associate milestones with the completion of specific documents and specifications but rather with achievingsome quasi-measurable goal such as the identification of approximately 80 percent of the use cases or the

establishment of an architectural baseline of code These milestones are not so easy to quantify but represent a morerealistic and intuitive approach to development Management is concerned with cost and schedules and the overallquality of the product—or the product life-cycle view Managers view a software life cycle as a set of milestones and aseries of phases, one completing before the other starts The RUP defines four fundamental life-cycle phases:

Figure 2.1: Management (product life cycle) view.

The four development phases constitute a development cycle A product may undergo multiple development cycles

during its entire life cycle The subsequent cycles are called evolution cycles An evolution cycle may begin while the

previous development cycle is still in transition and maintenance It is quite common for commercial software vendors

to continue fixing bugs and releasing minor enhancements while the next generation is under development

Other models of the software product life cycle are possible The model presented in this chapter captures the essence of a product's life cycle as seen outside of engineering It is the management or executive view of the product life cycle You may be inclined to equate this model of software construction with the waterfall method, which is a traditional software development process that has proved to be ineffective for most software development However the RUP model is not the same as the waterfall model; rather it represents a high-level view of the life cycle as visualized by many product stakeholders and is characterized by specific milestones

Inception Phase

The inception phase (sometimes called the vision phase) is the first phase of any product development project It

begins when one or more persons identify a real or perceived need (the problem) and envision a system that can satisfy the need.

The exit criteria for the inception phase are a product vision and a business case for the product In the RUP this is

called the Lifecycle Objective Milestone (LCO) The stakeholders who desire the system are called the acquirers They

may not be the eventual users of the system The users may be employees of the acquirers or the acquirers may be the organization that also builds the system to sell to customers (and their end users) The software engineering

organization that implements the system is sometimes referred to as the builder.

Elaboration Phase

The elaboration phase—the evolution of the system concept and development planning—begins once the acquirersapprove the project This involves requirements engineering (also referred to as gathering or capturing requirements).Sometimes this phase is referred to as the planning and specification phase

The exit criteria for the elaboration phase are a specification of requirements and an architectural concept The architectural concept describes a high-level design approach that addresses the requirements The builders must sign off on the architectural approach before the elaboration phase is complete The acquirers at this point can make a build/no-build decision based on the feasibility and initial cost and schedule estimates

In the RUP, the end of this phase is called the Lifecycle Architecture Milestone (LCA) The architecture is by no means frozen at this point, but the majority of architecturally significant quality attribute requirements, such as performance and maintainability, must be specified and the architectural approach must be established, as well as the technology to

be used

Construction Phase

The construction phase begins with a specification of requirements, architectural concept, and project plan It is during construction that the product is implemented, unit tested, and system tested The architecture, requirements, and development plan are adjusted as necessary, but there should be relatively few surprises at this point If there are a lot

of unexpected surprises, then the quality of the artifacts needed as input to this phase becomes suspect

The output of the construction phase is a complete version of the product The Initial Operational Capability Milestone (IOC) marks the end of this phase in the RUP

Transition Phase

The transition phase is where the product is transitioned to its users This includes any manufacturing, delivering, training, and supporting In in-house development, a product is said to be "in production." For commercial software, the product is "shipped." The output is a final version of the product, including software, supporting documentation, and training and support services In the RUP, the end of this phase is called the Product Release Milestone The released

version of a product, called a product generation, may enter into a maintenance and support subphase where bug

fixes are made and small enhancements may be introduced

Software Engineering View

The engineering view of software development is nearly orthogonal (or perpendicular), to the management view In theRUP, the product development life cycle is viewed as a two-dimensional model of time (phases) and activities The engineering view (Figure 2.2) represents a software development project as multiple chains of activities runningconcurrently and overlapping This classic waterfall method—borrowed from the hardware design discipline—iscomposed of discrete engineering phases with the creation of a requirements specification to completion, followed bythe creation of a design specification to completion, and finally a manufacturing phase

Figure 2.2: Engineering view of product development.

One of the problems with applying the waterfall process to software development is that changes usually translate directly into delays of the next step in the waterfall The changes are therefore very costly because they can cause a delay in the project The waterfall method fostered the notion that software development was like a manufacturing process and that the process itself can control the quality of a product This is the school of thought represented in the works of the Software Engineering Institute and the work of Watts Humphrey, such as the Capability Maturity Model (Humphrey, 1989) and the Personal Software Process (Humphrey, 1994)

The main activities of software engineering are:

Requirements analysis and specification

Implementation and testing

Deployment and maintenance

The software engineering view can be visualized as a stream of information flowing through each activity (see Figure 2.2) The inputs into the requirement analysis and specification activity are requirements from customers and other sources A set of requirements is transformed, via requirements analysis, into functional specifications of system behavior and nonfunctional specifications This information flows into the design phase and is transformed into a system design The design information is input to the implementation and testing activity, which transforms the design into a binary system Deployment transforms the binary system into a production system Maintenenance involves further iterations of requirements analysis, design, implementation, and testing It transforms an existing production system into a new variation of the system

Another way to visualize this process is to think of the input of each activity as a "what" and the output as a "how" The

"how" of one activity becomes the "what" of the next activity in the chain A customer requirement is a "what," and a functional specification of that requirement is a "how." A functional specification becomes the "what" of the design activity and the design description becomes the "how."

In the RUP, the engineering view is concerned with the coordination of requirements analysis, design, implementation,and testing activities—unlike the waterfall process The engineering activities do not have to run in serial, one

completing before the next It is possible for them to execute in parallel Each activity is activated in a sense whenthere is new input to process In an iterative development model like RUP, each activity may be activated severaltimes In addition to executing in parallel, each activity may have a feedback loop to prior "upstream" activities, as inthe discovery of an ambiguous requirement during design, or the discovery of a design flaw during implementation Inthe RUP, these activities run in parallel, some starting earlier in the development cycle, and some ending earlier thanothers The emphasis and effort involved in each activity vary over time

Each software engineering activity maps to many phases of the management view During the inception phase there isrequirements gathering and analysis and relatively little or no design, implementation, or testing During elaboration there is an increased focus on requirements gathering, analysis, and architectural design There may also be some prototyping development efforts as part of the design activity and this involves some testing as well During the construction phase the requirements gathering, analysis, and architectural design activities begin to taper off The design, implementation, and testing phases are at their peak effort with design eventually tapering off and

implementation and testing staying steady partway through the transition phase Although testing has been performed during construction, more effort is placed into testing during transition

Toward the end of the construction phase, requirements gathering and modeling cease and design tapers off

Eventually the cycle is down to implementation and testing with the testing activity increasing in proportion to the implementation effort The final implementation is reduced to fixing bugs found during testing

The iterative model of development occurs during the construction phase This is where controlled efforts of analysis, design, implementation, and testing occur in relatively small periods of time The iterative model can be applied in the elaboration phase as well but it is in the construction phase that it is primarily used The iterations are short bursts of design, implementation, and testing A single iteration may be as short as 1 or 2 weeks

Once the system passes verification and validation testing, the construction phase is complete and the transition phase begins In the engineering view, deployment involves some additional testing and perhaps a few more iterations

of bug fixing The documentation, which was begun during the construction phase, is finished up and the system goes into production or is shipped Then the defect reports and enhancement requests start pouring in from customers

Requirements Analysis and Specification

Requirements analysis is the activity of gathering, identifying, and formalizing requirements in order to understand the actual problems for which a solution is sought It begins in the inception phase and may continue through the

construction phase The purpose of requirements analysis is to understand the purpose and scope of the system and

to document this knowledge as a functional specification, nonfunctional specification, and perhaps a high-level user interface design

The functional and nonfunctional specifications model the requirements, using natural language prose, semiformal models like use cases and object-oriented analysis, or formal (verifiable) models using something like the Z notation The purpose of the functional and nonfunctional specifications is to capture enough information and knowledge to create an architectural description of a solution that satisfies the purpose of the application or system The initial list of requirements from customers, marketing departments, and other stakeholders describes what the problem is The functional specification describes the behavior of a system that solves the problem The nonfunctional specification describes the qualities of the system that will also address the problem.

Typically, software requirements are provided by customers or from an internal organization, such as product

marketing or product management Quite often engineers are dissatisfied with the level of detail or rigor of the requirements It is common in many software development shops and in-house development efforts for high-level requirements to be handed directly to engineers However, the software architect or architecture team should be the recipient of requirements since requirements drive requirements analysis and architectural design

Not all requirements specify the problem in purely abstract terms There are times when it is appropriate to specify some constraints on the system or application For example, a Web-based application may be part of the problem, not the solution For example, the problem may be to allow the sales organization to have Web access to an existing data warehouse in order to run some basic reports The organization may already have an Information Technology (IT) architecture based on Microsoft XML Web Services platform (.NET) technology, Java 2 Enterprise Edition (J2EE) technology, or Common Object Request Broker Architecture (CORBA) middleware Utilizing the existing IT

architecture becomes part of the context in which requirements are interpreted

Other requirements may narrow the technical solution without specifying exactly what technology is used For example, a requirement may call for a minimum of installed components on the client machines (for example, "zero code on the client") to reduce the maintenance effort of upgrading and troubleshooting installations In this case the requirement is really to reduce maintenance and upgrade effort The solution may be a browser-based user interface

or it may be a fairly heavyweight client that has built-in functionality for communicating with another server that manages client application releases to ensure that each remote workstation can be upgraded easily and with minimumuser interaction

Design

Design is the activity of transforming requirements specifications into a technically feasible solution It is here that design methods such as first principles and design patterns are used The purpose of design is to map the various requirements to technology and to reason about the correctness of the approach before implementing the solution Requirements may be specified using several views such as behavioral (use cases), informational (object models), and "nonfunctional" (ad hoc and other methods) The design maps these various inputs to software entities such as objects The design activity encompasses classic object-oriented design as well as higher-level architectural design methods

The result of design is a specification of how to build the application or system and the technical constraints on the implementation For example, a single performance requirement may map to several performance constraints on several related components, which when executed together must satisfy the performance requirement

Design solutions may be specified informally or by using notations such as those in the Unified Modeling Language (UML) The level of detail of a design specification varies It is a commonly held belief among software developers that the amount of effort expended on design is never sufficient

Implementation and Testing

Implementation is where design is transformed into the source code that describes an executable system

Implementation also involves building and testing the system in part and in whole Some development cycle models separate unit testing, which is the testing of an individual or discrete subsystem, from integration testing, which is the testing of the operation of the entire application or system involving the available subsystems

As we have postulated, writing source code for a system is a form of design itself The distinction, then, between implementation and design is in the granularity or focus of the design The design activity within the engineering view typically involves some higher-level modeling language that may not be directly transformed into source code Some

modeling tools that support UML may have rudimentary code-generation capabilities but don't support round tripping,

the ability to move between source code and UML views of a system's implementation Many UML tools do support this capability and thus tend to further blur the distinction between implementation and design.

Deployment and Maintenance

The completed executable system must eventually be delivered to the acquirers and deployed so that end users may use it An in-house or custom system is deployed into production use and commercial software is shipped to

customers Most business software developed in-house and commercially follows a spiral life-cycle pattern, where new versions with additional features and enhancements are released incrementally

When an application or system goes into maintenance, it is considered to be complete with respect to the initial vision

of the product The maintenance engineering team is responsible for fixing defects in the system and adding minor function enhancements In the spiral life-cycle approach, a development cycle is followed by another evolutionary development cycle instead of a strict maintenance phase It is common to have a "maintenance branch" of a system

so that the current and prior releases can both be supported during the evolutionary development cycle But the earlier versions are typically not maintained for very long Once the next major or minor version of a product is shipped, some earlier versions are no longer supported and customers must upgrade in order to continue getting support A product may reach a point in its life cycle where it can no longer evolve and enters a true maintenance phase in the classic sense

Engineering Design View

The engineering design view is a little different from the software engineering view in that it is a model for pure engineering design The engineering design view subsumes some aspects of the engineering requirements

specification, design, and implementation activities The engineering design view that I present is adapted for software design from a mechanical engineering design process described by Pahl and Beitz (Pahl, 1996) In this model, the design process is subdivided into four phases: product planning, conceptual design, embodiment design, and detailed design These phases are sequential, but the activities within each can overlap As with the activities in the software engineering view, information flows from phase to phase but the phases are not strictly serial (see Figure 2.3):

Product planning

Conceptual design

Embodiment design

Detail design

Figure 2.3: Engineering design phases.

"Problems become concrete tasks after the clarification and definition of the problems which engineers have to solve

to create new technical products (artifacts)," according to Pahl (1996) In the established engineering fields such as

mechanical engineering, design engineers create the design of a product and the physical realization of the product is the responsibility of manufacturing engineers Software development has a similar division of labor The specification

of an application is the responsibility of systems analysts and the realization of an application is the responsibility of

software programmers.

The analogy of engineering to software development carries with it the notion that the realization or implementation of

a software system is a manufacturing problem and that the input for the implementation of a system is a design specification of the system A more accurate comparison is programmers as design engineers and language compilers

as manufacturing engineers

Each of these phases focuses on a different level of abstraction and a different set of design objectives The design phases do not proceed in a pure serialized fashion; rather, they are driven by various inputs such as quality attributes and by the exchange of information among them and in their distinct objectives (such as what types of risks each phase attempts to mitigate) There is a logical flow of information between the phases with respect to time The

product development cycle begins with product planning activities The output of product planning feeds the

conceptual design activities Conceptual design investigates details; if the details are inaccurate or incomplete, another cycle of product planning may be necessary The output of conceptual design, or working principles, feeds the

embodiment design phase The term working principle refers to a candidate design approach such as a design pattern,

architectural pattern, or algorithm that addresses some subset of requirements

While conceptual design focuses on the search for a working principle or a set of working principles, the embodiment design activities focus on elaboration of a subset of the working principles or just a single working principle if the other candidates can be eliminated It is possible that during embodiment design there are flaws discovered in the working principles that require another iteration of conceptual design An assumption made about a particular working principle during conceptual design such as using XML documents to transfer data between a client application and a server may prove to be too slow or too difficult to maintain during embodiment design In this case, the working principle must

be changed or disqualified if there are better design candidates

The output of embodiment design is sometimes referred to as detail design in some software development

communities, but to be consistent I include writing source code in the definition of detail design The output of

embodiment design feeds detail design Embodiment design may include a detailed class hierarchy design, Interface Definition Language (IDL) files, and possibly some source code such as C++ headers for classes, or Java interfaces touse as guidelines or as a framework for programmers to use when implementing the application or system Issues discovered during detailed design may require another iteration of embodiment design (which may require another iteration of conceptual design or even product planning)

During the product development life cycle, each phase will have a time when it is the dominant activity In the early stages of development, product planning is the dominant activity and may involve a couple of iterations of product planning and conceptual design and no embodiment or detail design During architectural design the emphasis is on conceptual and embodiment design Toward the end of the development life cycle (the construction phase), detail design will be the dominant activity, although there may be some iteration of embodiment design as well Product planning and conceptual design should be fairly complete at this point If it isn't, and coding begins, then planning and conceptual design problems may be uncovered when they are more costly to fix in terms of schedule and effort.The architectural description is developed and revised during all engineering design phases Each phase emphasizes

a subset of the architectural models Models that capture the problems, the application domain, and the intended behavior and other quality attributes of the system are created during the latter half of product planning and during conceptual design Also during conceptual design, high-level representations of the internal form or structure of the system are created such as structural models and models that represent how technologies may be utilized

During embodiment, design representations of lower-level software structures and technology utilization are created Finally, during detail design, the actual source-level artifacts are created, which feed the tools that produce the executable system There is definitely some overlap in the models that are created and revised and the design phases For example, technology models are created as early as the conceptual design phase, yet continue to be refined through the detail design phase

Product Planning: Specification of Information

Product planning begins with a vision of a product or the identification of a need and takes into account the market, the company, and the economy Product planning occurs during the inception phase but they are not the same Product planning includes the activities conducted during product inception Once the product development life cycle goes into the elaboration phase and beyond, the product planning activities should be complete or revisited infrequently

During product planning, the problem is defined (the task is clarified) and a requirements list is created In engineering

design, the product of this phase is called the specification of information In software development, these are the

functional and nonfunctional specifications The requirements do not necessarily identify all of the required quality

attributes or functionality but rather establish the core capabilities of the application or system

Conceptual Design: Specification of Principle

During the conceptual design, the domain problem is analyzed and structured and a set of working principles or solution concepts is created or revised The output of conceptual design is a candidate architecture or concept also

called the specification of principle A typical practice in the conceptual design phase is to produce multiple solution

variants from which further architectural analysis and evaluation can be performed The models developed in this phase are the conceptual models, but that doesn't mean that they are purely logical models devoid of any technology

decisions The term conceptual in this context should not be confused with the notion of a user's conceptual model of how a system works, which we will refer to as virtuality or cognitive model.

A conceptual model for our digital library example system may identify the use of XML for content representation during editing and authoring and the use of Extensible Stylesheet Language Transformations (XSLT) for generating the presentation or published content The exact XML application (vocabulary or Document Type Definition [DTD]) andthe details of the XSLT are not necessarily mentioned because the purpose is to establish a working principle

Embodiment Design: Specification of Layout

In established engineering fields, embodiment design refers to specification of layout Other terms such as main

design, scheme design, and draft design also capture what is meant by embodiment design In software design the

selected architectural design concepts identified during conceptual design are fleshed out It is common to carry forward a subset of solution concepts found during conceptual design and to perform architectural and engineering evaluations on those designs

During this phase the project development plans are firmed up as the architecture solidifies and cost, resource, and time estimates are made It is during this phase that the architectural activities are wrapped up and software

engineering design is emphasized Some coding may begin on prototypes or early prototypes created during the conceptual design phase It is common for an architecture team to build a basic skeleton of the application or system

to serve as both a prototype and/or proof-of-concept and to serve as the basis for further development during the detail design (implementation) phase

Detail Design: Specification of Production

This is the implementation phase in software engineering Recall that the production and manufacturing process in software development is trivial Many authors compare the execution of a compiler as the equivalent of a production or manufacturing process The process also consists of packaging software and distributing it (Many companies are nowusing the Internet as a software delivery vehicle so that the distribution process is relegated to uploading the software

to a server that customers or potential customers can download to their personal computers.)

In established engineering fields, this phase is where the physical arrangement, dimensions, and other material properties are specified and captured in schematics or other drawings The output of this phase is called the

specification of production and is detailed enough to begin the production and manufacture of a product There are no

product design decisions made beyond this point In building architecture the specification of production is the

blueprint along with requisite engineering drawings that a construction company uses to guide the actual construction

of the building In software it is the source code and other machine-readable artifacts that result in the construction of

the final executable system Source code is a specification of an abstract machine, and a compiler realizes that machine in platform-specific machine instructions (including byte codes) and data formats

Architectural View

The architectural view provides a different but complementary perspective to the management, software, and

engineering design views The traditional architect's role is to help the acquirer understand his or her needs more fully and accurately and to create an architectural concept of a system that is feasible to build, given available technology, resources, and time The architect also oversees construction The architectural view of a software development cycle

is centered on the design of the application or system and how the design drives the development This is referred to

as architecture-driven software construction (Sewell, 2002) The four phases of architecting are as follows:

Predesign phase

Domain analysis phase

Schematic design phase

Design development phase

These phases are sequentially related (see Figure 2.4) but, like the software engineering and engineering design phases, they do not necessarily occur in a single sequential pass The four phases above when combined with the following build phases form an architecture-driven software construction method:

Project documents phase

Staffing or contracting phase

Construction phase

Postconstruction phase

Figure 2.4: Architecting phases.

These phases are sequential and milestone-driven, similar to the management view

Predesign Phase

Traditionally, the architect is involved fairly early in a project In software development, the software architect may be part of the product planning team as well as the engineering team The architect may have relevant domain expertise and contribute to the vision of the product This is more often the case for commercial software development and in-house development In contracted development, the architect may be part of the contractor's organization, not the acquirer's organization, and therefore not necessarily involved in product planning Regardless, the software architect may need to participate in product planning and the analysis and formulation of requirements as well as the creation of broad budget and schedule objectives by establishing the scope and scale of the project The architect must listen to the acquirer and study the entire enterprise context in which the application will be a part The architect must let the acquirer make value judgments such as what features are and are not important in the application

The architect must study the enterprise in which the application or system is a part Recall from Chapter 1 the four

types of architecture that form an enterprise architecture The architecture of a business application may need to take into account the information architecture of the organization, not just the information model of the application itself, since often the enterprise application addresses a limited aspect of the entire organization's enterprise problem In addition, the application architecture may need to take into account the underlying IT architecture itself If an

application server, Web server, database vendor, operating system, or middleware product is chosen before

application architecture begins, then it must be considered part of the underlying IT architecture

The existing technology platform or technology stack becomes part of the context in which requirements are

formulated, and not part of the solution An enterprise software vendor must also consider these other architecture types because they become part of a customer's requirements Often a customer has an investment in technologies such as application servers and database servers If an enterprise software vendor does not use Original Equipment Manufacturer (OEM)-platform technology, a customer may resist purchasing platform technologies from another vendor when they already have comparable technologies

Domain Analysis Phase

During domain analysis the software architect strives to understand as completely and accurately as possible the needs of the acquirers and users and the application domain and to document this knowledge Sources of domain knowledge include domain experts, domain-related literature, and existing requirements specifications from earlier or similar systems This phase corresponds closely to the requirements analysis and specification software engineering activities With respect to the management view, the bulk of domain analysis would occur during the elaboration phaseand continue through the construction phase

Domain analysis is one of the most important activities of software architecting It is, in my experience, the single most ignored activity in software development, especially in commercial enterprise software product planning I believe that well-crafted domain analysis models contribute significantly to the success of enterprise application development Software engineers tend to focus on the computer science domain It is up to the architect to ensure that the engineers understand the application domain models because it is those models that represent the semantics of the problem domain Solving the wrong problem can cause entire projects to be scrapped, wasting time and money

Schematic Design Phase

During schematic design, the software architect prepares the architectural-level design, which is specified in an architectural description This design is depicted in high-level models that represent the behavior of the system, the information captured in and processed by the system, the user interface and user interaction design, the modular structure of the solution, and the technology needed to implement the application or system along with the rationales for the various design and technology decisions

This phase involves a lot of communication between the architect and various stakeholders and reviews and

evaluations of the design variations represented in the architectural description With respect to the engineering design view, this phase emphasizes conceptual design development

Design Development Phase

The design development phase focuses on refining the architectural description and selecting among alternative designs The architectural description is evolved to the point where accurate schedules can be created The schematicdesign and design development phases are often iterated and the boundary between them tends to blur as the architecture converges to a final design that is detailed enough to assess risks and to make a decision to proceed with development With respect to the engineering design view, this phase emphasizes embodiment design

Building Phases

The building phases described by Marc and Laura Sewell (Sewell, 2002) depart from the analysis and design focus and compare closely with the management view In their book they consider the design development phase to be a building phase I have included it in the above sections to emphasize it with the other architecting (design) phases, because this book focuses on those phases and not on the other building phases

In the project documents phase the architect focuses on development concerns such as how the system should be constructed and in what sequence the components should be developed A description may be prepared of how the system should be constructed This would include a construction plan, a user interface style guide, and a test guide.During the staffing and contracting phase the architect may help the acquirer identify a development contractor or help with the creation of a development team using internal resources In building construction, the building architect would assist with the details of contracts and cost assessments This phase may not even occur in most software

development efforts, especially if the acquirer is also the builder or if the builder is a commercial software vendor

The construction phase mirrors the phase of the same name in the management view From the architecture

perspective, the architect oversees construction ensuring that what is built is valid with respect to the architectural description The architect is involved in design reviews and in the analysis of design problems uncovered as well as the handling of change requests Even though the bulk of architectural design is complete, there is still need for the architect to make changes to the design and to assess the impact of those changes on the architecture itself and on the cost and effort of development

The post-construction phase corresponds to the transition phase in the management view The architect may assist in the deployment of the system and in training users The architect may also remain involved with maintenance efforts

Synthesizing the Views

Each of the views of software development involves some set of phases or activities In the management view, the inception phase is an interval of time followed by the elaboration phase, which is a distinct interval of time In the context of a single project or incremental release, once the inception phase is complete you never go back to it; it is a milestone that cannot be unreached

These phases don't overlap by definition, but within these phases there are overlapping and repeated activities such

as requirements gathering, requirements analysis and specification, design, implementation, and testing Each of these activities also occurs in time but they are not phases in the sense that once one is complete you move on to the next, never to revisit it or only to revisit it in some predetermined scheduled time (as a task) These activities are reentrant and may be performed within the context of some development cycle iteration A phase in the sense of a project life cycle isn't iterative; otherwise, there would be no sense in having the concept of a phase to judge the progress of a product In a spiral and/or evolutionary life-cycle model, there may be several development cycles, but these are not the same as iterations, which occur within a development cycle

An activity may be part of a larger task and may involve many steps The tasks are specific to the problem we are solving In this case, the tasks help us accomplish the goal of engineering software and are defined by the goal The specific activities and artifacts produced are defined by a methodology

Let's use an executing program as an analogy for the software engineering life cycle An executing application has phases It has a load phase where it is initially loaded into memory, assigned resources, and started It has an

execution phase where work is performed Finally, it has an exit phase where the resources are returned to the operating system and the program is unloaded from memory and nontransient data persisted Within the execution phase, the program performs many tasks based on how the user uses the application A single task (such as creating

a document) may involve several activities such as accepting input from a keyboard, formatting runtime object data into a storage format, and writing that data to a file or database

Each activity is intended to accomplish the goal of the task itself and the type of activity may be incidental It may not

be necessary to format the data prior to persisting it, depending on the target of persistence The formatting activity is incidental to the task An activity is made up of individual nondecomposable steps, which are the programming language statements that comprise the activity such as the various operating system calls to create a file and write bytes to the file The implementation of the activity is the objective of the programmer, and each individual programmer may utilize a different style or algorithm to accomplish the activity The software architect chooses the activities that compose a task based on factors such as requirements and prior experience Each architect may compose a task using a different set of activities yet still accomplish the same goal

Similar to our program design analogy, the tasks of software engineering can be accomplished in a variety of ways using the activities that are appropriate given the design of the engineering organization and its processes The task of engineering software may be accomplished using activities such as structured analysis and design or object-oriented analysis and design Different organizations will use different activities based on their collective experience and skills

to accomplish the same goal What all this means is that there is no one right way to design and construct software You should choose the activities that make the most sense given the project at hand, including finding a balance between risk and development speed

We can also view a development cycle as data flows, where each piece of data belongs to some engineering

document such as requirements or design A document can be thought of as a data store; every time it is modified, its changes flow to another document In between each flow is a process that transforms the data A process in between

a requirements document and a design document is a transformation process that transforms a set of requirements into a set of design elements From this view, there are no explicit phases The transformation processes are the activities and the types of documents we are storing, and they constrain the types of activities that can be used These

documents are also referred to as models, and this view can be thought of as a model-driven approach.

As you can see, no one view captures the essence of the development cycle When we look at the development cycle

as a data flow involving model transformations, we are ignoring the management aspect and the engineering iterative aspect, because neither of those concepts can be effectively captured in this particular view Likewise, when we view

the development cycle from the management view, we ignore the model transformations and only see specific milestones, which might be the completion of some particular models.

We can see by analogy that the description of the architecture of a software system has a similar characteristic to the description of a software development life cycle: It must involve multiple views There are also similar dualistic views of software architecture On the agile side of software design is the anti-model and/or focus on source code architecting

On the heavily planned side is the idea that every document must be up-to-date and maintained just as thoroughly as source code and that every aspect and design decision of the system must be represented in documentation

Although it is tempting to see these two views as opposites, they can also be viewed as points on a two-dimensional view with one axis being technical expertise and the other being customer satisfaction More accurately, the various individual practices within each methodology can be placed on such a plane