[ieee future of software engineering - minneapolis, mn, usa (2007.05.23-2007.05.25)] future of...

18
Richard N. Taylor is a Professor of Information and Computer Sciences at the University of California, Irvine. He received the Ph.D. degree in Computer Science in 1980. His research interests are centered on software architectures, especially event-based and peer- to-peer systems and the way they scale across organizational boundaries and decentralized applications. Professor Taylor is the Director of the Institute for Software Research, has served as chairman of SIGSOFT, chairman of the ICSE Steering Committee, and was general chair of FSE 2004. Taylor was a 1985 recipient of a Presidential Young Investigator Award. In 1998 he was recognized as an ACM Fellow and in 2005 was awarded the ACM SIGSOFT Distinguished Service Award. André van der Hoek is an associate professor in the Department of Informatics at the University of California, Irvine. He holds a joint B.S. and M.S. degree in Business-Oriented Computer Science from the Erasmus University Rotterdam, the Netherlands, and a Ph.D. degree in Computer Science from the University of Colorado at Boulder. His research focuses on understanding and advancing the role of design, coordination, and education in software engineering. André is the principal designer of the new B.S. in Informatics at UC Irvine and was honored, in 2005, as UC Irvine Professor of the Year. Software Design and Architecture The once and future focus of software engineering Richard N. Taylor and André van der Hoek Future of Software Engineering(FOSE'07) 0-7695-2829-5/07 $20.00 © 2007

Upload: andre

Post on 13-Feb-2017

216 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

Richard N. Taylor is a Professor of Information and Computer Sciences at the University of California, Irvine. He received the Ph.D. degree in Computer Science in 1980. His research interests are centered on software architectures, especially event-based and peer-to-peer systems and the way they scale across organizational boundaries and decentralized applications. Professor Taylor is the Director of the Institute for Software Research, has served as chairman of SIGSOFT, chairman of the ICSE Steering Committee, and was general chair of FSE 2004. Taylor was a 1985 recipient of a Presidential Young Investigator Award. In 1998 he was recognized as an ACM Fellow and in 2005 was awarded the ACM SIGSOFT Distinguished Service Award. André van der Hoek is an associate professor in the Department of Informatics at the University of California, Irvine. He holds a joint B.S. and M.S. degree in Business-Oriented Computer Science from the Erasmus University Rotterdam, the Netherlands, and a Ph.D. degree in Computer Science from the University of Colorado at Boulder. His research focuses on understanding and advancing the role of design, coordination, and education in software engineering. André is the principal designer of the new B.S. in Informatics at UC Irvine and was honored, in 2005, as UC Irvine Professor of the Year.

Software Design and Architecture

The once and future focus of software engineering Richard N. Taylor and André van der Hoek

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 2: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

Software Design and Architecture

The once and future focus of software engineering

Richard N. Taylor

Institute for Software Research

University of California, Irvine

Irvine, California 92697-3455

[email protected]

André van der Hoek

Institute for Software Research

University of California, Irvine

Irvine, California 92697-3455

[email protected]

Abstract

The design of software has been a focus of soft-ware engineering research since the field’s beginning. This paper explores key aspects of this research focusand shows why design will remain a principal focus.The intrinsic elements of software design, both proc-ess and product, are discussed: concept formation, useof experience, and means for representation, reason-ing, and directing the design activity. Design is pre-sented as being an activity engaged by a wide range ofstakeholders, acting throughout most of a system’slifecycle, making a set of key choices which constitutethe application’s architecture. Directions for designresearch are outlined, including: (a) drawing lessons,inspiration, and techniques from design fields outsideof computer science, (b) emphasizing the design ofapplication “character” (functionality and style) aswell as the application’s structure, and (c) expandingthe notion of software to encompass the design ofadditional kinds of intangible complex artifacts.

1. Introduction

Design is the central focus of software engineering.Design is both a verb and a noun. It is a key thing wedo and that we produce.

Such crisp statements will alternatively strike oneas obvious or, perhaps, as parochial – if not incorrect.Yet if we consider what software engineering is,namely a practice directed at the production of softwaresystems, then design is seen at its heart, as it is in anyother productive enterprise, whether the creation ofskyscrapers, automobiles, toasters, or urban regions.

Not surprisingly, then, many software engineeringresearchers, or those acquainted with software devel-opment, have studied and written about software de-

sign over the past forty years and more. Fred Brooksincluded in his 1975 list of “promising attacks on theconceptual essence” the growing of great designers[21]. Peter Freeman, in 1976 [31], said “Design isrelevant to all software engineering activities and is thecentral integrating activity that ties the others to-gether.”

Design will remain the focus of software engineer-ing. Herb Simon, in his classic, The Sciences of theArtificial [75], includes a discussion of design in thecontext of “artificial” fields, such as software develop-ment, saying:

“The artificial world is centered precisely on thisinterface between the inner [the means] and outer[the task] environments; it is concerned with at-taining goals by adapting the former to the latter.The proper study of those who are concerned withthe artificial is the way in which that adaptation ofmeans to environments is brought about – andcentral to that is the process of design itself.”

Put in software engineering parlance, the outer envi-ronment is the world of requirements, goals, andwants; the inner environment is the set of softwarelanguages, components, and tools we have for buildingsystems. As software engineering researchers, we arealways “raising the floor” – creating new levels of in-frastructure upon which new developments may bebuilt. In Simon’s terms, the “inner environment” orthe “means” is ever changing and expanding. As thefloor rises, however, so do our desires and aspirations.Though achievements in improving design have beenobtained over the previous decades, new challenges fordesign will thus continuously arise.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 3: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

Materials, Tools, and Mechanisms

Goals and Dreams

DESIGN

"The Means"

"The Task"

Figure 1. The continuing place of design.

Nonetheless, at a suitably abstract level the chal-lenges for software design today are the same as theywere forty years ago. They are the intrinsic challengesof design: How to create artifacts to obtain goals, howto represent new conceptions, and how to analyzethem. Brooks made this observation twenty years afterthe original Mythical Man-Month was published. Hesaid the distinctive concerns of software engineeringnow are exactly those he set out earlier, namely “Howto design and build a set of programs into a system;How to design and build a program or a system into arobust, tested, documented, supported product; How tomaintain intellectual control over complexity in largedoses.” [20] (pg. 288). Ten years after that statement itis still true.

Arguably all the major threads of software engineer-ing research are directed at improving our ability tomeet the challenges of designing software. Work inrequirements engineering contributes to Simon’s “outerenvironment”; process research addresses the coordina-tion of all activities focused on creating, implement-ing, and evolving designs; empirical studies improveour ability to assess design artifacts and the processesby which they were created; analysis research improvesour ability to assess candidate designs; work at thepatterns and frameworks level improves our ability torealize designs in source code; and so on.

Though a focus on design has been, and will be,the central issue in software engineering, the type ofdesign on which our energies have been focused hasbeen rather lopsided. Our focus has largely been di-rected at the design of software qua software. That is,we focus on the structure of software and its attributes,such as considering what components and connectorscomprise a system, and what constraints govern theirinteractions. A lesser role in software engineering hasbeen assigned to the design of software as it exhibitscharacteristics to its users. For instance, what “interac-tive feel” does the application give to its users? What“style” does it exhibit? What is its branding, or dis-tinctive behavioral character? Using the analogy ofautomotive design can make the distinction clear: de-

sign research of the first type is directed at the me-chanical organization and structure of the vehicle; de-sign research of the second type is directed at shapingthe car’s appearance, performance, sound, and smell.Doing a good job of one type of design does not im-ply doing a good job with the other, yet they are in-trinsically interrelated. Both are important, and arelegitimately the subject of (software) design research.

Work on design of the first type has certainlyyielded a wide range of important results over the pastseveral decades. Numerous development methods havebeen espoused, many based upon the articulation andapplication of design “principles” such as modularityand planning for change. Means for representing de-signs have been devised; domain-specific approacheshave been created and supporting tools supplied. Inrecent years, particular advances have been made withregard to product families and the careful specificationof system architectures.

Work on design of the second type has often beenignored by software engineering researchers, and in-stead relegated to either other sub-disciplines of com-puter science, especially human-computer interactionresearchers, or simply left to practicing engineers inindustry.

Design of both types is increasingly recognized as acritical corporate and national asset. Designing ofproducts is seen as an activity that cannot be effec-tively off-shored – regardless of the shore on whichone is standing. Design can be a differentiator thatdetermines an organization’s success. The ability todesign effectively is typically the partner of the abilityto innovate.

The remainder of this paper seeks to explore howand where to advance from the state-of-the art. We pro-ceed by first examining some major historical threadsof design research, then highlighting a few notablecurrent trends. These sections are not merely back-ground; by straightforward implication from what wedescribe, some key directions for software researchemerge. Drawing from the perspectives of these twosections, we then examine the character of design inmore detail. The remainder of the paper explicitly laysout a set of further research directions, and concludeswith some challenges and a “long view” of the promis-ing future of software design.

2. Paradigms and Persuasions

The past forty plus years of design research can betaxonomized many ways, such as by describing thehistory of models, methods, and tools over time.These topics are not independent, however. Rather, thebackground or disciplinary orientation of an individualor group tends to bring along a set of beliefs, choices,and approaches. Any such perspective, then, drivesspecific choices in a variety of areas.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 4: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

Prescriptive Design Methods

Perhaps most familiar to the software engineeringresearcher is the perspective of the “software method-ologist”. Typified best, perhaps, by work in the 1970’sand 80’s by such authors as Yourdon [81, 82], Jackson[41, 43], and Parnas [61-65], this strand of work fo-cuses on the first type of design discussed above, thedesign of software as the artifact of interest, and is anapproach that states a principle, then prescribes how todesign based on that principle.

Much of this work has been top-down in style;principles of design are articulated (“separate abstrac-tions”, “use information hiding”, “refine higher-levelabstractions into a set of lower-level abstractions”, etc.)and then either methods for employing those principlesor notations which highlight or support application ofthe principles are developed.

One influential strand of work began with RussAbbott [8], and was then expanded upon and advocatedby authors such as Grady Booch [17]. This designapproach is, roughly, “design by simulation”, in whichthe software application is straightforwardly designedby creating software objects that correspond to entitiesin the real world, and whose methods correspond toactions in the real world. The work contributed to ob-ject-oriented design, and became in a broader contextto be supported by methods such as the Rational Uni-fied Process [51], with designs represented in the Uni-fied Modeling Language (UML) [52].

Notations

Notations have been a part of software design sincethe beginning. Any time design thought is external-ized, such thought must be written down in somestructure or form that supports interpretation at a latertime by others, oneself, or a computerized program. Itis no surprise, then, that notations continue to serve asa primary driver of research in the community.

Notations range from informal conventions that areestablished on-the-fly by a group of designers engagedin a design exercise to precise formalisms that arestandards for the field. Two primary concerns in theformulation of new notations are expressiveness andusability. Expressiveness concerns what aspects of adesign can be captured in the notation; usability con-cerns the fluidity with which designers can work withthe notation. Though both factors are equally impor-tant, the primary driving force behind the developmentof most new notations has been expressiveness – add-ing modeling capabilities, often for a particular analy-sis purpose.

Extensibility is a required property of any modernnotation, as it is now common knowledge that nostandard notation can fulfill all modeling needs. UMLprofiles are perhaps best known in this regard, with a

host of profiles publicly available that address a broadvariety of modeling concerns.

The Wisdom of Experience

Still focusing on the design of software, but com-ing at the problem from essentially a bottom-up per-spective, is a strand of work focused on capturing thelessons of experience in such a way that future designscan be guided. The work on “design patterns” is typi-cal of this strand. While the “Gang of Four” patterns[33] are directed at the programming language level,the concept can be applied at any level of abstraction,including requirements (where the experience may becaptured as “frames” [42]), whole-concept system struc-ture (where the experience is captured as domain-specific software architectures [10, 38, 79]), and gener-ally at the level of system components and connectors(where the experience is captured as styles and architec-tural templates [9, 34]).

Methods for analysis and restructuring of softwaremay reflect insights from this research strand, such asare found in refactoring analysis and reverse engineer-ing.

Knowledge representation and design rationale re-search may contribute to the effective employment ofdesign based upon the wisdom of experience.

HCI Design

Innovation in product design and distinctiveness inproduct design have long been argued as contributingto product (and corporate) success [45] – though suchinnovation is no guarantee of commercial success. Thesoftware engineering literature is relatively silent onthe matter of such design, possibly because researchersview the subject as too domain-dependent, and henceexclusively the focus of developers within that do-main. Even if one assumes that, it is surprising thatsoftware researchers have not focused on the methodsby which innovative domain-specific designs are cre-ated.

The exception is user interface design. Often rele-gated to (at best) the fringes of software engineeringresearch, human-computer interaction research includesa focus on techniques for developing user interfaceswhich effectively engage and satisfy the user. Somelessons of such work are captured, for instance, in pat-terns for web site design, as found in the work of Lan-day and colleagues [80]. This work is partially bottom-up, in the manner described above, but also reflectscognitive understandings of how people interact withweb sites and undertake electronic commerce transac-tions.

The importance of considering this field is indi-cated, in no small measure, by the repeated failure,over many years, of standard software engineering top-

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 5: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

down design techniques to create pleasing and effectiveuser interfaces.

Design Outside of Software

The field of design, and design research, outside ofsoftware engineering and computer science is enor-mous. While both types of design discussed above arewithin this wider world’s view, a greater emphasis isfound on the second type – user experience. Less workis found on representational issues; since physical ob-jects are being designed the representation means (typi-cally sketching) is natural. More work has been di-rected at methodological approaches, with [44] a clas-sic example from the domain of industrial engineering.The software patterns work, however, derives its name,at least, from work in building architecture [11].

The relevance of lessons from design “out there” tosoftware design has been noted by many. Participatorydesign has been advocated by some in the HCI com-munity [35], and, arguably, software engineering’s“agile design” draws from some of its key elements .Less directly, the capabilities of CAD systems likeCATIA have been an inspiration throughout.

A further perspective on design exhibited by thelarger design world, but which software engineeringhas mostly ignored (or scorned) is that of design as art.While Donald Knuth unabashedly titled his monumen-tal series, “The Art of Computer Programming” (e.g.,[46]) and promoted “literate programming” [47], wehave not developed a practice of critiquing the aesthet-ics of any kind of software design, of endeavoring toinstill an appreciation for elegant software design, or ofproviding public forums for the promotion and recog-nition of excellence in design

1.

Cognitive and Social Strategies

A final strand of design research is exemplified bythe work of Donald Schön [72], and found in softwareengineering in the work of, for example, Fischer. Akey perspective emerging from this work is whatSchön terms reflection: the designer reflects upon theprocess and upon the product. Design in this viewemerges as a “conversation” between the materials (theexternal constraints on the design, the initial sketchesattempting to develop a solution) and the designer.

Design, however, is not a solitary activity. Teamsof designers interact, varied stakeholders participate,and broader communities of practice [29] exist withinwhich individual designers perform their work. De-sign, thus, is a social process, one of information ex-change, learning, creative and cognitive stimulation,

1 The ACM Software Systems Award is an excep-

tion, though it is not widely promoted – certainly notin the software engineering community.

and conversation – all aspects that must be taken intoaccount.

3. Contemporary Currents

Contemporary currents in design sometimes addimportant perspectives to the schools of thought de-scribed above, as well as combine, apply, and refinethem.

Agile Methods

While for some “agile methods” are a step back-wards in the history of software design research – be-cause the design exists only in the code –, the agilecommunity has emphasized three important designpractices. First, it is an example of the application ofparticipatory design: by involving the user throughoutthe iterative development process, the product is con-tinuously shaped to meet the user’s needs. Secondly,test-driven development makes the design of function-ality of equal importance to the design of system struc-ture, which represents a rudimentary integration of thetwo types of design we discussed in the Introduction.

Lastly, implicit in the agile approach is that theprocess of design continues throughout development.With little extrapolation, design can be seen to con-tinue throughout the life of the product – a characteris-tic not shared with many products from the realm ofphysical product design.

Aspect-Oriented Software Design

The original aspect-oriented programming paperstates “A design process and a programming languagework well together when the programming languageprovides abstraction and composition mechanisms thatcleanly support the kinds of units the design processbreaks the system into.” It then makes the argumentthat programming languages must conceptually distin-guish components (units of a system’s functional de-composition) from aspects (system properties that can-not be cleanly separated and instead crosscut compo-nents) [54]. This view of AOP strikes an importantchord with design, as separation of concerns is one ofthe leading approaches to tackling a design problem’scomplexity. Unfortunately, this design-oriented per-spective seems to have given way to AOP languageminutiae and a focus on “aspectizing” any and allsoftware artifact. Nonetheless, the critical role of theprogramming language in the design process persists,and AOP has and continues to have an impact as such.

Design Analysis

One of the reasons we design is to reduce risk byenabling prediction of system properties. Not surpris-

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 6: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

ingly, the field has devised numerous ways of perform-ing design-based analyses. Many of these have beendescribed, for example, in the SAVCBS workshopseries (Specification and Verification of Component-Based Systems). Most of these analyses concern exter-nally visible properties, such as reliability, real-timeconstraints, or concurrency, although a fair amount ofwork also concentrates on properties internal to a de-sign, such as structural quality or reusability [71].

Different design representations are suited to differ-ent kinds of analyses; new analyses may require newnotations to be used.

Component-Based Design

A desire to structure large-scale business applica-tions in terms of standard, reusable components con-tinues to drive a non-trivial part of the industrial soft-ware landscape. While each guarantees somewhat dif-ferent properties as emphasized by somewhat differentusage scenarios, component-based design, model-driven architecture, and web services all can be groupedas addressing this desire in a similar manner. In fact,they can be seen as evolving from one another, withcomponent-based design focusing on reuse of the indi-vidual component, model-driven architecture on stan-dardization of components into reusable middleware[30, 40], and web services on reuse of components andmiddleware across distributed and decentralized appli-cations.

Of course, different components do not magicallyfit together. A particular challenge is to design the“glue” that bridges mismatches in functionality, inter-faces, and interaction paradigms.

Software Architecture

The many strands of work in software design de-scribed thus far have most fruitfully blended and ma-tured into the field of software architecture. With anencompassing definition of software architecture as“the set of principal design decisions governing a sys-tem”[78], it engages the full range of design activitiesand includes the full range of participants in the designprocess. Software architecture encompasses work inmodeling and representation, design methods, analy-sis, visualization, supporting the realization of designsinto code, experience capture and reuse, product lines,deployment and mobility, security, adaptation, and soon.

Software architecture research began in earnest inthe early 1990’s (e.g. [66, 73]), though the term isdecades older (it is found, for instance, in many worksfrom the early 70’s). Work in the 90’s was initiallyfocused largely on matters of design representation[56], though the whole movement could be character-ized by a desire to provide substance, structure, and

specificity to the historic field of software design. Ar-guably, software architecture has been focused on thematuration and professionalization of a field previouslybest characterized as craftsman-like.

The successes achieved by software architecture overthe past fifteen years span from commercial use ofproduct-line architectures, such as at Philips [59], tothe architectural underpinnings of the World WideWeb, as characterized by the REST style [27].

Architecture is a backdrop for much of the direc-tions for software design that we characterize in theremainder of the paper; its importance is reflected byits inclusion in this paper’s title.

4. Design, Designing, and Designers

The careful reader will notice that we have, so far,refrained from defining software design, or even designitself. So it is with the contributions discussed in Sec-tions 2 and 3, which by and large typify design accord-ing to a certain perspective (e.g., a phase, in the code,art, engineering) and then work within this perspectiveto make their contributions.

To understand how these perspectives relate and to-gether help or hinder in advancing the field as a whole,it is critical that the field establishes a common basisfrom which its progress can be judged. The followingsummarizes a general model of design that is intendedto form such a basis [13]. The model consists of twointerrelated parts: one part capturing the essence ofdesign-the-product, the other part capturing the essenceof design-the-process.

When used as a noun, design normally indicates theartifact (product) that emerges from the design process,some physical document or other kind of representa-tion that articulates the intent of the designer. Thisproduct results from the choices the designer made,choices that form an abstraction of that what is eventu-ally desired to be realized in the real world [49].

These words are in some ways obvious, but inother ways not sufficiently precise to help guide afield. The general design literature has made variouscharacterizations that can be used as such (e.g., Simon[74], Norman [58], Schön [72]). Figure 2 presents avisual of the amalgamate of these characterizations asthey pertain to the design product. The figure distin-guishes the design space from the outcome space. Dur-ing design, we mentally operate in the design space(where each point represents a unique set of designdecisions), but continuously make decisions that re-flect upon the outcome space (where each point repre-sents a unique artifact). That is, each design decisionalters the set of outcomes that are still possible (SP),cutting away some and re-enabling others. A design,then, is a point in the design space that represents a

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 7: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

set of decisions that together delineate a set of possi-ble outcomes in the outcome space.

2

The customer brings into this their understandingof what are desirable outcomes (D), which, whether ornot explicitly stated, act as constraints on the designprocess. Another set of constraints is exercised by theavailable materials from which an outcome is con-structed by following a design’s blueprint: a designshould describe only outcomes that are feasible (F). Asuccessful design is one that restricts its still possibleoutcomes to those that are desirable and feasible.

Figure 2. Design – The Product.

When used as a verb, design normally indicates theprocess by which a design is achieved. It is understoodto be a human-centered process, involving variedstakeholders. It is also understood to be strongly goal-driven and drawing upon established knowledge of thedesigner and the field at large.

The general design literature has made precise char-acterizations of this process, which are brought to-gether in Figure 3. The design process is one of infor-mation manipulation (broadly construed to encompassinitial creation, transformation, and deletion), withfour types of information involved: goals, ideas, andknowledge, which are all mental, and representations,which are physical expressions of mental information.Each of these types of information is phrased in one ormore languages, and tools may be used to edit and/orinterpret representations. Within this setting, designersengage in one or more activities, through which they –directly and indirectly – explore the design space. Thedesign process, then, is defined as the set of informa-tion manipulation activities through which a success-ful design is obtained.

2 This discussion is not meant to imply the exis-

tence of a separate design phase. The spaces we refer toare ephemeral and largely present as a result of the wayin which human’s think – through abstraction.

Figure 3. Design – The Process.

An important property of this general model of de-sign is that it does not bias itself towards any individ-ual perspective on software design. Rather, it supportsthe field in giving it the ability to precisely relate dif-ferent perspectives and understand their emphases,strengths, and weaknesses.

The Elements of Design Research

A corollary from the preceding discussion is thatthe model points toward exactly where it is possiblefor a discipline as a whole to make progress in bettersupporting its designers. Particularly, it can:

• Improve the materials from which a product thatis envisioned by a (finalized) design is eventuallyincarnated in the real world. For example, theavailability of newer, lighter composites enableddifferent kinds of planes exhibiting differentweight and aerodynamic properties to be designed.

• Improve the languages that are used for capturinggoals, ideas, and knowledge. Alexander’s designpatterns are an example of such an advance, bring-ing together goals and ideas in a single representa-tion that furthermore supports easy adoption.

• Improve the general knowledge the community hasabout its design domain and design processes. Forinstance, the human genome project is of tremen-dous value to the design of new medicines, pro-viding a data bank of knowledge that previouslywas unattainable.

• Improve the portfolio of activities that are used inthe design process. IDEO’s focused form of brain-storming is an example of an activity that led toimproved results, both in terms of time and out-of-the-box solutions [45].

• Improve the tools with which design activities aresupported, particularly in creating and interpretingrepresentations. For example, the automotive in-dustry has made significant leaps in their abilityto design by moving from clay models toCAD/CAM designed 3D visualizations.

All progress, whether in the form of a new methodol-ogy, notation, metric, or analysis algorithm, to name afew, will eventually reduce to these five basic underly-ing categories.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 8: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

The Community of Designers

Just as it is important to understand the fundamen-tal elements of design, so it is important to recognizethe richness of the community of designers – thosewho design, who contribute to the design, and whomust interact with design representations, designers,and design processes. Historically, design has largelybeen seen as a somewhat provincial task performed bya small number of software specialists – perhaps one“chief designer” – during a circumscribed period in aproject’s lifecycle, namely following requirementsanalysis and preceding any implementation. Clearly,such a simplistic notion is either counter to what reallyhappens in a project, or if actually followed yields sub-par results. In truth, the number and types of individu-als with vital interests in a project’s design represents abroad community of interest [29]. Existence of thiscommunity imposes some particular demands on de-sign; recognition of the breadth of the communityhighlights opportunities for improving our practice andexpanding our research agenda.

First, for a project of any significant size, morethan one designer will be involved. Existence of mul-tiple designers thus imposes demands for communica-tion of design concepts [21]. Communication impliesshared representations, an observation that is a naturaloutflow from the general model of design. The effec-tiveness of such communication is determined by thelanguage(s) used [22]. Presence of a design team alsoinduces requirements for coordination of its designactivities. Such coordination could involve formalmanagement if the task is large enough.

Second, however the design is produced, other in-dividuals, playing other roles, are critically engagedwith the design. They must be able to understand anduse it. In traditional development practices wherein theimplementation activity is separate from the design(more about this below), the implementers must beable to comprehend and utilize the design. The practi-cal challenges of this become highlighted should suchimplementation be contracted to another firm, perhapsto one on another continent. In other situations, thecustomer may be desirous of participating in substan-tive review of a design. In yet other situations endusers may be participants in the design process. All ofthese engagements with design highlight the criticalrole of and demands on shared representations of de-sign.

Third, beyond just recognizing the existence of amultiplicity of designers and “design readers”, we alsomust recognize that the multiple stakeholders of a sys-tem (can) all contribute to the design itself. The typicalperspective has been that, since software is being de-signed, software specialists are the only ones whoproperly determine the software’s design. As discussedin detail in [57], however, both application domain

experts and business stakeholders are properly con-tributors to a system’s architecture. Domain expertsnaturally know or determine the key abstractions for asystem, acceptable strategies for meeting regulatoryrequirements, or provide vital insights on what partsand in what ways the design must be flexible to ac-commodate potential future changes. Business-focusedstakeholders may determine key boundaries for a prod-uct-line architecture, and hence determine critical soft-ware interfaces. Design, thus, is not the exclusiveprovince of the software technologist; the multiple andproper contributions from the wide community ofstakeholders must be accommodated. This final com-ment is not easy to achieve, however. Separatestakeholders likely require (or at least request) viewsonto an emerging design which are idiosyncratic totheir perspectives. Supporting multiple viewpointswhile ensuring consistency among them constitutes acurrent challenge towards which the community hasmade progress (e.g., the 4+1 model [50], analyses todiscover inconsistencies [26], and an understandingthat certain forms of inconsistency must be tolerated[15, 28]), but for which much work remains to bedone.

Fourth, arguably the design community increas-ingly includes the end user. Common applicationssuch as spreadsheets and word processors actively in-vite the end user to customize – i.e., design – theirworking environment and the complex artifacts pro-duced with desktop tools. At best the software engi-neering community has barely recognized this commu-nity of designers; after all, they are not software spe-cialists, have little or no formal training in design, andproduce designs researchers may dismiss as trivial, orsimply as poorly done. But the enormous number ofend users, the substantial ability for customization anddesign presented by desktop applications, and the po-tential for improving the quality of end user designsargues strongly for design researchers to turn their at-tention to this special world. As one example, space-craft systems designers use complex, interlocking Ex-cel spreadsheets to design new systems and missions[55]. These complex spreadsheets are designed, how-ever, without any higher level of abstraction or repre-sentation; understanding them and “verifying” them isleft to the engineer, who must interpret the macrospervading the spreadsheets. A better way is surely pos-sible.

5. Research Directions

The introductory section of this paper indicatedhow design will remain an enduring challenge. As ourability to design solutions to current statements ofwants and needs improves and becomes more predict-able, our conception of what might be achieved ex-pands. As “the means” improves and rises, “the task”

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 9: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

becomes more adventuresome and demanding. Ourability to design must be correspondingly enhanced tomake use of the improved materials, tools, and mecha-nisms to create solutions to the new goals and dreams.Seen in this general light, all the elements of designresearch listed in Section 4 above will persist; it is amatter of understanding and improving:

• the materials – the conceptual building blocks –from which designs are eventually realized as arti-facts in the real world.

• the languages that are used for capturing goals,ideas, and knowledge.

• the general knowledge the community has aboutits design domain and design processes.

• the portfolio of activities that are used in the de-sign process.

• the tools with which design activities are sup-ported.

While comprehensive, this list is too generic to beof much use in setting directions; the remainder of thissection is devoted to discussing a variety of more spe-cific directions. Before moving to the more specificdiscussion however, we consider three general issues.

First is the matter of design decisions. Designing isfundamentally a matter of making choices – how toaccomplish something, how to represent something.That suggests that an effective approach to designshould offer a solid understanding of choices: whatthey are, recognizing when they are made, what thealternatives were, and capturing them in such a manneras to allow retrospection. In typical practice we are farfrom having a grasp on this: decisions are often im-plicitly made. It is not until later that we recognizethat certain functionalities or properties were precluded,or inhibited, by an early choice. Decision support sys-tems from the 1980’s, such as gIbis [23], offered ex-plicit support for formally considering choices facing agroup. This type of support is needed, but must beprovided in a lightweight manner that is integral toand supportive of design. Perhaps more important,however, would be practices to aid in recognizingwhen choices are being made.

Second is the matter of the place of design in thesoftware engineering process. As the discussion in theprevious section indicated, the activity of design is notlimited to one individual or one circumscribed place inthe development process. Critical decisions – designdecisions – are made throughout system developmentby a variety of stakeholders. Talk of “requirementsengineering” that is wholly independent of design, forinstance, is frequently either sophistry or simplycounter-productive. As critical decisions about a sys-tem are made – whenever they are made – design isbeing done, the architecture is being established andshould be recognized as such. Similarly, implementa-tion is improperly and unrealistically considered the

rote translation of design to code, sometimes to thepoint where a design intentionally does not make achoice of programming language so to be general innature. Key choices made in and about the implemen-tation process, such as the decision to use a particularimplementation framework or programming language,are important parts of system design, affecting futurestrategies for system modification and adaptation. Theimportance of such design should not be overlooked.The challenge for design researchers is to provide prac-tical guidance to those involved in setting system re-quirements, in coding the system, and indeed in allother aspects of system development for their appropri-ate participation in design. More generally, the ques-tion is how to structure software development proc-esses to support a robust, modern conception of de-sign.

Third is the matter of choice and evaluation [32,74]. As designers confront issues, a set of choicesemerge. Beyond recognizing and recording the choicesmade, designers need support for evaluating alternativechoices so to guide them towards a design’s objec-tives. Analysis techniques may focus on functional ornon-functional system properties, and may span toanalysis based on economic arguments [12, 77]. Whiledevelopment of individual techniques continues to beneeded, the field also should find ways in which suchtechniques can be combined to enable multiple proper-ties to be jointly assessed, in the manner of statisticaldecision theory for example, to enable broadly in-formed choices to be made.

Directions Reflecting Good Recent Pro-gress

In defining a research agenda, it is important to rec-ognize those research directions that “work”, have hadimpact already, and should be explored further becausethey continue to have promise in advancing the field.

The first direction we discuss as such is softwarearchitecture. It is interesting to put architecture in lightof the five directions of design research presented inSection 4. To date, advances have included, amongothers, architectural middleware, description languages,styles, design methods, and environments, which col-lectively cover the five research dimensions alongwhich progress can be made. That is, architecture hasturned out to be a natural fit in pushing design researchforward.

Of particular importance is the focus on early de-sign decisions. Architecture, though it can be mappedonto code effectively, is initially about supporting theexploratory process. Architectural styles are critical inthis regard, documenting accepted solution strategiesas sets of reusable design decisions that can be readilyadopted. Clearly-documented and well-packaged styles

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 10: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

come closest to the original definition of architectureas “structure, form, and rationale” [66].

Architecture has also strongly influenced softwareproduct lines. The vast majority of software productlines are actually realized through product line architec-tures, which are used to distinguish those parts of thesystem that are shared among all products and thoseparts that are variable and depend on the product athand [70]. The use of product lines has become suc-cessful with several success stories emerging that detailhow this kind of domain-driven approach can be bene-ficial and provide a competitive advantage.

That said, there is significant work left to do. De-sign involves multiple stakeholders who may haveradically different concerns. Having focused stronglyon component-connector centric approaches, currentarchitectural description languages lack facilities forspecifying and relating such diverse sets of concerns.Extensible architecture description languages are afoundation, but their modeling capabilities must besupported with flexible environments and design proc-esses.

This strongly relates to the need to manage evolv-ing architectures. When stakeholders make changes, itis often the case that the architecture degenerates. Espe-cially with product line architectures, it is known thateven a pungently cohesive initial definition slowly butsurely may morph into a set of disjoint product archi-tectures. Processes have been employed to amelioratethis problem, but overall our level of understanding isstill limited and our tool support for carrying out suchprocesses trails significantly.

Throughout the design process, whether it is ahigh-level architecture or a low-level UML class dia-gram, it is generally important to ensure that certainproperties are met, such as, for instance, behavioralconsistency, real-time performance constraints, reliabil-ity, levels of security, and concurrency behavior. Theanalysis community has made steady progress in pro-viding analyses that can provide such guarantees andcontinues to work on faster and more efficient analy-ses, analyses for new properties, and general infrastruc-tures[16, 24].

A particular challenge is to make these analyses,and the modeling of the information that is needed todrive them, an integral part of the design process,rather than some activity that is performed as a “check”when the design process has finished. Two problemspersist: the need to create precise representations, andthe need to fully, or almost fully, model a design be-fore it can be analyzed. It is incumbent upon the fieldthat these two problems are overcome, so that analysesbecome usable throughout and especially when it mat-ters most: during rapid generation and evaluation of(not necessarily precise or complete) alternatives, forwhich analyses are vital in understanding the tradeoffsinherent in the design decisions made.

As important as the externally-visible qualities of adesign are its internal qualities: is its structure sound,is it optimal, and will it hold up over time? A recenttrend has seen attempts to assign “value” to designs,particularly by employing economic analyses that stemfrom adapting and applying established economic the-ory to the domain of software design. Most promisingto date is the use of Design Structure Matrices [14];with them, it is possible to visually compare differentmodularizations, assign these modularizations values,and in so doing understand design tradeoffs, such aswhether to refactor or to apply aspects. These results,however, represent only a beginning. Values are as-signed mostly to entire designs, not necessarily indi-vidual design decisions (though these can be valued inthe context of given design changes). Values also are“instant”, for the design as it is now; not how theystand up against future design changes. A critical di-mension of future work, then, is to find mechanismsof valuing individual design decisions over time.

Another important aspect of this work lies in thehistorical lessons it can teach. Applying Design Struc-ture Matrices to numerous designs, both good and bad,can build a portfolio of examples from which it fur-thermore may be possible to deduce general principles.

Finally, we return to the topic of architectural stylesand, more generally, the capture and reuse of architec-tural experience. Experience and "good design practice"can be captured at different levels of abstraction (fromsource code up to the highest level of system structure)and with different degrees of generality (from usefulwithin all application domains to useful only withinhighly specialized application domains). We need theability to capture the lessons from prior developmentsat all points in this space, and to do so in a mannerthat effectively enables other engineers to find, under-stand, assess, and apply the lessons to the develop-ment of new systems. In simplest terms this couldinvolve developing extensive catalogues of architec-tural styles. The richness and variety of experiencedemands better ways of capturing, finding, and usingknowledge, however. Other design disciplines havematured by doing so, it is time we do so as well.

Directions From New Capabilities

Progress in computer science has often been pro-pelled – or compelled – forward as the result of ad-vances in hardware. So it is now with design. Ad-vances in networking, display technology, storage, andprocessor speed offer the potential for significant ad-vances in the practice of design.

As a first instance, consider the potential of search-ing for domain knowledge, prior designs, evaluationsof designs, “similar structures”, and so on, in themanner of Google. That is, the ability to access infor-mation across the Internet, and especially the ability to

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 11: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

search that information in comprehensive fashion, of-fers the potential for exploiting experience from priordesigns in a manner far beyond anything we have yetseen. A simple use of existing Google-like search willnot be sufficient, however. A designer will seldom besearching, for example, for a module with a specifictextual interface. A designer will want to search basedon various architectural abstractions. Enabling searchbased on architectural meta-data, for instance, is a near-term possibility for meeting this goal. Yet any searchscheme that requires some structured meta-data as in-put stands the risk of being overtaken by a technologythat employs a brute-force strategy that is able to pro-vide at least as good results without requiring use ofany standard mark-up or meta-data. This, of course, isthe beauty of today’s Google search as applied todocument searches. One long-term direction, therefore,is to develop search algorithms that perform architec-tural abstraction automatically, and then “page-rank”those abstractions against the user’s query, where thatquery is phrased in terms of architectural properties.

The networking that is a key enabler of Internetsearch is also a key enabler of improved communica-tion between individuals and teams. As the legitimaterole of the many stakeholders in a design process isrecognized, advances in network communications canbe brought to bear to improve their participation. Col-laboration technologies in general offer significant po-tential for the design process [39]. Communicationtechnologies are, relatively-speaking, free; designersshould exploit that.

Display technology offers another basis for im-provement in design practice. Very high resolution,very large screen displays are now readily available.Such displays give designers the potential of seeingmore of a design from more perspectives simultane-ously. And why should design be confined to the flat-land of 2-D displays? Other scientific disciplines havealready exploited high-resolution displays; it remainsfor software designers to design such support for theirown discipline. Designers should have displays ontheir desktops that are at least as large as the televi-sions in their homes. Beyond the desktop, there is noreason why teams do not have specialized designrooms equipped with numerous touch-sensitive dis-plays and batteries of computers that enable instantanalysis.

The continuing decline in the price of storage withan accompanying increase in capacity suggests othernew directions for design. Why not always record de-sign rationale – even as video? Keying video/audiocapture to the designers workstation activities, context,and display offers unprecedented potential for retro-spectively understanding a design and reusing the in-sights present at the time of design. In the case of de-sign forensics following a system failure, for example,such storage offers the potential for identifying the root

cause of a failure, and hence for eliminating relatedlatent errors elsewhere in a system.

Lastly, the continuing rise in processor speeds sug-gests that designers, and those who develop designtools, should never be restrained by a perception ofsomething “taking too long”. Nor should tool devel-opers be distracted into complicated optimizations of,e.g., analysis procedures, when the use of simple bruteforce suffices. If something seems to take too long,just task a few dozen more processors to the problem,or simply wait for the next generation of processors toappear. The time to develop a reliable optimizationmay well exceed the time for a doubling of processorspeed.

In summary, let us as designers exploit advances incomputation to advance the practice of design. Ourtask is as worthy of innovative use of technologies asour clients’ tasks are.

Directions From Design Imperatives

For software design and architecture to mature intoa robust discipline capable of handling the challengesposed by emerging applications, advances in severalareas are imperative. Our list here is eclectic, reflectingour perception of particularly poignant needs.

First is adequate support for moving from architec-ture to implementation, and fluidly moving betweendesign and coding tasks. If design does not ultimatelysupport production of a satisfactory implementation(assuming that the resources and the will to produceare both present), then it is a failed effort. Many cur-rent design approaches fall silent when it comes toimplementation. Since key design decisions may bemade in the implementation context, evolution of thearchitecture must be seamlessly integrated across thecontexts. Seamless integration implies full traceabilitybetween code and higher abstractions, and supportsaccountability of design decisions.

Second is the ability to represent all stakeholdersinterests, as discussed earlier. Multiple interests andmultiple perspectives impose demands for assessing orguaranteeing consistency of design decisions (or for themanagement of inconsistencies between them), as wellas demands for multiple presentations of select designdata.

Third, as software applications become ever-moreinterwoven into organizations and society, we mustdevelop means for the co-design of software and orga-nizational/societal systems. Introduction of a technol-ogy into a group or organization may radically changehow the group behaves – think, for example, of how e-mail has altered both personal and public communica-tion patterns. While a robust literature exists describ-ing how such organizational changes have occurred asthe result of introducing software technologies, weneed a design discipline which integrates the inten-

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 12: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

tional shaping of software technology with the inten-tional shaping of organizations (one easy example isthe integrated performance of business process reengi-neering with design of software systems for that busi-ness). For co-design to take place, a broad range ofexpertise must be woven into the process of design. Tocontinue without such breadth invites organizational“surprises” and application system failures.

Fourth is the design of applications as seen and ex-perienced by users. This was discussed in the Introduc-tion as the “second type” of design. The need and op-portunity is profound; further discussion is reserved forthe Challenges section.

The next two directions are closely related and aremotivated, at least in part, by economics. The first ofthese is supporting design recovery and analysis. Es-tablished systems represent significant economic as-sets. To the extent that such assets can be used to meetnew organizational needs, economic efficiencies arerealized. Recovering the architecture of existing sys-tems enables assessments of potential future uses to bemade so that adaptations can be based on solid archi-tectural understandings. While several research projectsin this field exist and have yielded promising initialresults (see, e.g., [18, 36, 37]), there is still much tobe done. The second and related direction is activelymanaging design evolution – in particular mitigatingarchitectural decay. Here the issue is not recovering adesign to merely enable the first steps of progress to anew or improved system, but the task of assessing anexisting design and evaluating alternatives for modify-ing it to meet new and changing needs. Clearly to theextent the architecture is explicit and faithful to theimplementation, this process is facilitated. But that isonly the beginning; an evaluation framework and proc-ess to assist in comparing alternative modifications isneeded. Such evaluations must not only support exam-ining how immediate demands can be met, but predictlikely consequences for future, as yet unspecified, de-mands.

Lastly, emerging application needs argue for designtechniques that yield self-adaptive systems. An impor-tant topic in its own right, we refer the reader to [48].

Directions From Examining Our Past

We learn from our successes, but we also learn fromour mistakes. This is an age-old lesson that has fueledmuch progress in other design fields. Bridge design asit is today would not be as advanced without the care-ful study of past structural failures [76]. The study of“why things break” has fueled the creation of newer,stronger materials [25]. And a central theme in Pet-roski’s well-known writings is how failure has been amotivator for design innovation [67-69].

How do we perform in software in this regard? Un-fortunately, the answer is “not good”. We do experi-

ence failures, but the field does not profit from them asother disciplines do. A “we will just fix it in the code”attitude is far too prevalent, and we seem to have beenlulled into a modus operandus in which the importanceof design is, consciously and subconsciously, under-valued. Compare the software view of design onceagain with that of bridge design. First off, one mustappreciate the effort that goes into a bridge’s design.Except for a few systems, our discipline rarely per-forms this much design. Second, when something failson a bridge, it is the design that is examined, and les-sons are drawn from it. Such is not the practice insoftware; we rarely go back, carefully study a “faileddesign”, deduce lessons as to why the software (use,deployment, or even development itself) failed, andwhat we should do differently, design-wise, next time– let alone share these lessons with the community.

Any approach to learning from the past must startwith examples. Unfortunately, no software design ex-amples seem to be available. Textbooks contain small-ish systems. Search the web for “Good Software De-sign” or “Bad Software Design Examples” and not asingle system comes forward (though lots of advice onhow to create a “good” design comes forward). Com-pare this to building architecture, where one can findbook after book in the bookstore, including books of“great designs”. Clearly, a first challenge for the com-munity is to begin assembling archives of good andbad design examples. By this we do not just meanUML diagrams, but carefully documented, multi-leveland multi-view explanations that provide in-depth in-sight into underlying design decisions and their rami-fications. It is interesting, in this regard, to examinethe HCI literature. In it, one can find numerous papersthat introduce novel interfaces and describe their under-lying design motivations. Such a practice has not tran-sitioned into the software engineering conferences as ofyet.

We must also promote excellence in design. TheSPLC product line hall of fame is an example of suchrecognition, as is the aforementioned ACM SoftwareSystems Award. In either case, though, we note thatregrettably the actual details of the product and designthat received the award are never shared with thebroader community. Perhaps ACM or IEEE shouldconsider establishing an annual prize for the best soft-ware design, requiring that winning designs are placedin the public domain.

3

From examples, we must then deduce patterns,principles, do’s and do not’s, and other general under-standings that help individuals in building up a reper-toire of knowledge that can assist them in designing.Some of that effort is underway; we mention architec-tural styles, software patterns and anti-patterns, design

3 Of course, we can leave our version of the Razzies

(http://www.razzies.com) to an appropriate blog.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 13: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

critics, bad smell detection and refactoring techniques,HCI design guidelines, and a small handful of generaldesign principles. This work has to continue and bebroadened to cover all aspects of the design productand process.

Finally, we observe that we must not just under-stand good and bad design products, but also focussome of our efforts on understanding good and baddesign practices. By this we explicitly do not meanhigh-level approaches (e.g., Agile), but rather the ap-proaches and techniques that expert designers employin designing their software. For instance, it is well-known that product designers may sketch hundreds ofalternatives before honing in on an eventual choice. Dosoftware design experts follow such an approach? Ifnot, what do they do that makes them successful? Canthese skills be explicated and communicated to others?

Overall, the undercurrent of this section is thatsoftware design is still far removed from being an es-tablished discipline. To move forward, it is critical thefield engages in the necessary deep scientific study ofsoftware design and designing.

Directions From Looking Outside of CS

While the design of software is a relatively new ac-tivity, having only been around for sixty years at themost, design has been practiced in other fields for cen-turies. While sometimes still taught as a craft, orlearned through apprenticeship, design is newly takingshape as an academic discipline, even as a science.There is a Design Research Society [1] (which spon-sors a conference on doctorate research in design), anda wide literature. New university programs in designare emerging, such as Stanford’s “d-School” [7]. Allthis suggests that there is much that software research-ers can consider and draw from in order to advancedesign specifically within the software field. A fewexamples have already appeared in the preceding text:we have referred to work in industrial engineering [44],architecture [11, 19], design processes [72], andcivil/mechanical engineering. We provide a few addi-tional examples here, most of which are inspired bybuilding architecture.

While architecture has already been mentioned, andhas been used for many years as, at least, an analogousactivity to building software, the richness of the build-ing architecture discipline suggests that there are stillfurther insights to mine. For instance, Parnas’s dictumabout designing software for ease of change [63] isexplored, by analogy, with substantially greater rich-ness in Stewart Brand’s “How Buildings Learn” [19].The several layers of a building’s architecture deter-mine the ways in which the building can be adapted tomeet new needs. Bottom-up and top-down approachesto such design are considered and extensively illus-trated. It is a book that, while containing no reference

to software development, can be read, appreciated, andapplied by software engineers.

Another practice from architecture is that of a de-sign charette. A charette is related to software’s designreviews and walkthroughs, but is closer in spirit toagile design, for the purpose of a charette is to move adesign forward quickly, by developing and critiquingdesign in a group setting. In educational settings,charettes are part of design studios, where regular de-sign reviews take place. The normal practice of archi-tecture is to develop models suitable for and used inperiodic, active, productive, constructive group designreviews.

Perhaps most inspirational from the world of archi-tectural design is the development of computer-basedbuilding models that enable designers and users (ten-ants, residents) alike to fly through a proposed design,simultaneously seeing, as desired, both the internalstructure of the building and the appearance and serv-ices of the building. In software design these conceptsare almost always reviewed separately: how the code isorganized is considered almost independently of whatthe user’s experience with the application will be. Inbuilding architecture, the intrinsic relationship betweenthese two views is understood; if the residents of ahouse know in advance where load-bearing beams arethey can adjust their expectations for how the buildingmight be modified in the future. Seeing how well, orhow poorly, the user interface is separated from the restof an application’s code can reveal whether managerscould sensibly direct a desktop application to be retar-geted as a web service.

Architecture even suggests how we might rethinkthe composition of our academic teaching faculty. Ar-chitecture schools typically include many practicingarchitects, just as music schools include many practic-ing musicians. The conviction is that students canonly have an adequate understanding of their disciplinethrough engagement with faculty regularly acquaintedwith the full breadth of disciplinary challenges. Onecould examine many computer science departments andfind no faculty qualified to construct any applicationlarger than a compiler – a task trivial in comparisonwith the challenges regularly faced by many profes-sionals in industry. Students must also engage in thepractice, and do so repeatedly.

Many design professions have another practice fromwhich we could benefit: the study of designs. Design-ers of luxury goods, buildings, machinery, and con-sumer goods alike spend significant time assessing –studying – existing designs. The objective is not onlyto understand how something works, but to assess its“non-functional properties” – what brand sense it con-veys, what its aesthetic is, how it affects its user. Incontrast, most software engineering courses spend notime studying existing design, instead plunging ahead

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 14: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

with green-field approaches, yielding a too-predictableoutcome.

Barriers To Progress

Having made a broad set of suggestions, we mustacknowledge that significant barriers persist to makingthese kinds of advances a reality in practice. First, aswe observed earlier, design is seriously undervalued bymany. On the one hand, we admit that there is somebasis for such undervaluing: the tools and techniquesavailable to the average practitioner are not necessarilyvery good, especially when put in light of the fullspectrum of considerations discussed in Section 4.This state of affairs makes it difficult to convert theskeptic or to provide credible evidence that proper de-sign(ing) does make a difference. On the other hand,such negative attitude hinders progress: the effort spentobjecting might be better spent making advances or atleast encouraging others to do so.

Second, designers are not necessarily equipped withthe right skills and, worse, they may or may not knowwhether their skills match up to a project at hand. Whois qualified and how do they acquire their skills? Cer-tainly, some designers are simply great, whether byexperience or intuition. But a vast majority has to ac-quire their skills somehow, yet a culture of apprentice-ship is virtually non-existent. Granted, not all softwareneeds a great designer, but even the “average designer”must learn somehow.

Compounding this problem is the remarkable toler-ance that software professionals seem to have. If thetools that we use to design are incomplete, inelegant,and difficult in their use, then how can we be expectedto produce designs that are complete, elegant, and leadto easy-to-use systems? And this does not just hold fordesign tools. Poorly designed user interfaces andclunky programs abound. Where are we to find ourinspiration for quality?

A root cause can be found in the education of soft-ware engineers [49, 53]. Most stem from a “standard”Computer Science program, which incorporates at besta few software engineering courses and involves nu-merous other courses which ignore the lessons of soft-ware engineering altogether. Extensive practice withsignificant software design problems is impossible inthis setting. The past decade has seen the emergence ofSoftware Engineering (e.g, [5, 6]) and Informatics(e.g., [2-4]) majors. The focus of most such programsis on design, a trend we welcome. Still, the materialsavailable from which to teach design are limited andmuch innovation is necessary in this regard.

To offer hope, there is the advantage of time. Earlyreports from the SIGSOFT Impact project indicate thatresearch advances may take up to ten or sometimeseven twenty years from initial idea to widespread prac-tical use, as the original idea must find traction and

morph to reflect practical needs and considerations[60]. So, in a field that is as young as software engi-neering, perhaps we are not doing so badly?

Improvements and overcoming the barriers we men-tioned, though, will require the community to undergoa drastic change in mindset. Rather than following thenext hype into believing software development “can bemade easy”, a true discipline must emerge in which itis recognized that design is a critical activity that in-volves serious and difficult work. And herein may laythe most difficult barrier of them all.

6. Challenges and Vision

Design and architecture as described comprises abroad field and arguably sits at the very core of soft-ware engineering. All of its aspects are vital: ways ofdesigning, architectural representations, means for per-forming analysis, techniques for transitioning a designinto an implementation, ways of capturing design ex-perience, and so on. Absence of progress in any one ofthe areas discussed impedes progress in the others.Thus, broadly based advancement on the whole set ofsub-topics constitutes a grand challenge for softwareengineering – an appropriate, critical focus for softwareengineering research. We conclude, therefore, not witha specific design problem as a grand challenge for thefield, but rather repeat and highlight a few technicalitems, providing a bit of a vision for the future, offersome directions for community activities, and finishwith a speculation on the long future of “software”design.

Technical Challenges

Designing a software application involves design-ing its structure as well as its user-observable proper-ties, functional and non-functional alike. By removingthe counterproductive boundary between requirementsand design, a holistic view of product conceptionemerges. By analogy to building architecture, a build-ing can be seen as being composed of beams, bricks,pipes, glass, and wires, but also being composed ofliving spaces, galleries, sun rooms, and cooking facili-ties. Building architects can show clients cut-awayviews of buildings, simultaneously revealing bothstructure and facility, the interrelationships betweennatural light and ceiling truss. Imagine now interactivecut-aways of buildings, whereby the designer couldmove skylights and see the consequences for the roof’sstructure, or change specifications on a window andnote how the quality of interior light improves.

Realizing an analogous vision for software designrequires our supporting the design and visualization ofuser functionality at least as well as our supporting thedesign and visualization of software structures. Notonly must we see and manipulate components and

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 15: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

connectors in an architecture, but see, as we do so,how the user’s data display is changed, or how theelectronic commerce purchasing experience is shaped,or how facilities for controlling the chemical plant areset.

The community must develop the languages, tech-niques, and tools for enabling the multitude ofstakeholders in an application design to sketch, evalu-ate, revise, and refine design concepts for applications.Success will be achieved when clients are able, throughworking with the design team, to see their tasks innew ways and are able to innovate new ways of meet-ing those tasks.

Community Challenges

Achieving the technical vision will require long-term financial support, new venues for publication andcommunity analysis of designs and design technology,a new sense of who the design community comprises,and, perhaps, some “incentives”.

The critical enabler for progress is, of course, ade-quate funding. The centrality of design and architectureto software development demands that significant,stable funding be directed to these activities. The Na-tional Science Foundation’s Science of Design pro-gram is a good start in this direction, but support fordesign research should not be limited to the NSF;other agencies should make this field a priority aswell. Such support should also be continuing. Designwill not be “solved” after three years of work; indeed,as we have argued, design will always be a challenge –our aspirations will not abate.

Software design and architecture research also needsadequate forums for the presentation and review ofresearch advances. Drawing from the study of design inother fields, forums are also needed for the public pres-entation and review of designs themselves. Such re-view can inspire other designers, reveal properties ofnew design techniques and tools, and add to the reper-toire of design experience. Design research often doesnot have the same character as research in other fields,such as software testing and analysis. Hence traditionalforums and criteria are unlikely to be adequate or ap-propriate for review of design advances.

New forums for the discussion of software designwould also be supportive of expanding the communityof contributors. As software design is recognized asengaging teams of designers with expertise spanningspecific application domains, business planners, andsoftware specialists, a forum in which all would feel“at home” would be productive.

Lastly, there is nothing like an incentive to sparkquick advances in a field. Building architects are annu-ally awarded the Pritzker Prize, an award that carriesnot only international fame but a $100,000 reward. Infact, design awards are common in many fields: auto-

motive design, industrial design, fashion design, andso on. Why not spark innovation in software design bycreation of a corresponding prize? A similar kind ofinducement for advancement is a challenge prize, suchas the Ansari X-Prize was for space flight. Establishingappropriate criteria and processes for evaluating soft-ware designs would be a challenge, but the effect onthe community could be significant. For instance, theevaluation could cover the process by which the designwas produced, as well as design itself.

A Vision For The Long Future

One of the themes of this article has been that soft-ware design and architecture has been, and will remain,an intellectual challenge: as our abilities to effectivelydesign for one set of challenges become more effective,a new set of design challenges emerge to demand yetfurther advances. The limit on this cycle is simply thedefinition of “software”. By expanding our sense ofwhat software is, in a very liberal sense, numerousexciting opportunities for contributions from softwaredesign researchers emerge, opportunities for which we,as software designers, have some distinct advantagesover designers from many other fields.

Consider, for example, the interaction design prob-lem faced by automotive designers. One could arguethat what car manufacturers are selling is not sheetmetal and rubber, but a “driving experience”. Such anexperience constitutes a structured amalgam of sights,sounds, feelings, and smells. Driving a car involvesinteraction with not only the control devices in the car,but interaction with passengers, audio and visual in-puts, interaction with other vehicles, laws, and trafficcontrol systems outside the vehicle. If the design prob-lem is to design that interaction experience, what rep-resentation does that design have? The interaction isfundamentally intangible. Traditional design disci-plines, such as automotive design, are stronglygrounded in the physical materials of their traditionalproducts and designers are unaccustomed to a finalreality that is intangible. Software designers, by con-trast, have always dealt with an intangible product:software; we are accustomed to designing, modeling,and assessing a broader set of realities.

If we therefore extrapolate the concept of “software”beyond the traditional confines of the computer to en-compass radically different intangible products, such asthis example automotive interaction, an exciting fron-tier opens up. Software designers may be able to leadthe way into conceptualizing, modeling, and buildingnew kinds of intangible products. Working coopera-tively with designers from other specialties, the pros-pect is for creating new kinds of highly complex sys-tems that are now barely imaginable.

Software design and architecture have a long futureahead of it.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 16: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

7. Acknowledgments

This work was supported in part by the NationalScience Foundation, under grants 0438996 and0536203.

We would like to thank Alex Baker, Eric Dashofy,Peter Freeman, Michael Gorlick, Neno Medvidovic,Peyman Oreizy, David Redmiles, Lee Osterweil, andAlexander Wolf for ongoing collaborations and fruitfuldiscussions that have fueled the opinions expressed inthis paper.

8. References

[1] Design Research Society.<http://www.designresearchsociety.org/>.

[2] University of California, Irvine, Donald Bren Schoolof Information and Computer Sciences, B.S. in In-formatics. <http://www.ics.uci.edu/informatics>.

[3] Indiana University School of Informatics, B.S. o fInformatics. <http://www.informatics.indiana.edu/>.

[4] University of Washington Information School, B.S.of Science in Informatics.<http://www.ischool.washington.edu>.

[5] Milwaukee School of Engineering, B.S. in SoftwareEngineering. <http://www.msoe.edu/eecs/se/>.

[6] Rochester Institute of Technology Department o fSoftware Engineering, B.S in Software Engineering.<http://www.se.rit.edu/degrees.html>.

[7] d.school – The Hasso Plattner Institute of Design a tStanford.<http://www.stanford.edu/group/dschool/>.

[8] Abbott, R.J. Program Design by Informal EnglishDescriptions. Communications of the ACM. 26(11), p.882-894, 1983.

[9] Abowd, G., Allen, R., and Garlan, D. Using Style toUnderstand Descriptions of Software Architecture.ACM SIGSOFT '93 Symposium on the Foundations o fSoftware Engineering. p. 9-20, ACM Press. RedondoBeach, CA, December, 1993.

[10] Agrawala, A., Krause, J., and Vestal, S. Domain-specific software architectures for intelligent guid-ance, navigation and control. 1992 IEEE Symposiumon Computer-Aided Control System Design. p. 110-116, March, 1992.

[11] Alexander, C. The Timeless Way of Building. OxfordUniversity Press: New York, 1979.

[12] Bajcharya, S., Ngo, T., and Lopes, C.V. On Using NetOptions Value as a Value Based Design Framework.Seventh International Workshop on Economics-Driven Software Engineering Research at ICSE'05.May, 2005.

[13] Baker, A. and van der Hoek, A. Examining SoftwareDesign from a General Design Perspective. Institutefor Software Research, University of California, Ir-vine, Technical Report UCI-ISR-06-15, October,2006.

[14] Baldwin, C.Y. and Clark, K.B. Design Rules: ThePower of Modularity. 1, MIT Press: Cambridge,Mass., 2000.

[15] Balzer, R. Tolerating Inconsistency. Thirteenth In-ternational Conference on Software Engineering. p.158-165, IEEE Computer Society Press. Austin,Texas, 1991.

[16] Binkley, D. Source Code Analysis: A Road Map. Fu-ture of Software Engineering 2007 Briand, L. andWolf, A. eds. IEEE-CS Pres, 2007.

[17] Booch, G. Object-Oriented Development. IEEE TSE.12(2), p. 211-221, 1986.

[18] Bowman, I.T., Holt, R.C., and Brewster, N.V. Linux as aCase Study: Its Extracted Software Architecture.Twenty-first International Conference on SoftwareEngineering. Los Angeles, May 16-22, 1999.

[19] Brand, S. How Buildings Learn: What Happens AfterThey're Built. Penguin Books, 1994.

[20] Brooks, F.P. The Mythical Man-Month: Essays onSoftware Engineering. 2 ed., Addison-Wesley, 1995.

[21] Brooks Jr., F.P. The Mythical Man-Month: Essays onSoftware Engineering. Addison-Wesley, 1975.

[22] Clark, H. and Brennan, S. Grounding in Communica-tion. Perspectives on Socially Shared Cognition.American Psychological Association, 1991.

[23] Conklin, J. and Begeman, M.L. gIBIS: A HypertextTool for Exploratory Policy Discussion. ACM Trans-actions on Information Systems: 6(4), p. 303-331 1988.

[24] Dwyer, M., Hatcliff, J., Pasareanu, C., Robby, and Vis-ser, W. Formal Software Analysis: Emerging Trendsin Software Model Checking. Future of Software En-gineering 2007 Briand, L. and Wolf, A. eds. IEEE-CSPress, 2007.

[25] Eberhart, M. Why Things Break: Understanding theWorld by the Way It Comes Apart. Harmony Books:New York, 2003.

[26] Egyed, A. Consistent Adaptation and Evolution ofClass Diagrams during Refinement. Seventh Interna-tional Conference on Fundamental Approaches toSoftware Engineering. p. 37-53, Barcelona, Spain,2005.

[27] Fielding, R.T. and Taylor, R.N. Principled Design ofthe Modern Web Architecture. ACM Transactions onInternet Technology. 2(2), p. 115-150, May, 2002.

[28] Finkelstein, A., Gabbay, D., Hunter, A., Kramer, J., andNuseibeh, B. Inconsistency Handling in Multi-perspective Specifications. IEEE TSE. 20(8), p. 569-578, 1993.

[29] Fischer, G. Communities of Interest: Learningthrough the Interaction of Multiple Knowledge Sys-tems. User Modeling. 2001.

[30] France, R. and Rumpe, B. Model-driven Developmentof Complex Systems: A Research Roadmap. Future o fSoftware Engineering 2007 Briand, L. and Wolf, A.eds. IEEE-CS Press, 2007.

[31] Freeman, P. The Central Role of Design in SoftwareEngineering. Software Engineering Education Free-man, P. and Wasserman, A. eds. Springer-Verlag: NewYork, 1976.

[32] Freeman, P. The Central Role of Design in SoftwareEngineering: Implications for Research. In SoftwareEngineering: Research Directions. p. 121-132, Aca-demic Press, 1980.

[33] Gamma, E., Helm, R., Johnson, R., and Vlissides, J.Design Patterns: Elements of Reusable Object-

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 17: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

Oriented Software. Addison-Wesley ProfessionalComputing Series. Addison-Wesley: Reading, MA,1995.

[34] Garlan, D., Allen, R., and Ockerbloom, J. ExploitingStyle in Architectural Design Environments. ACMSIGSOFT '94 Second Symposium on the Foundationsof Software Engineering. p. 175-188, ACM Press.New Orleans, LA, December, 1994..

[35] Greenbaum, J. and Madsen, K.H. Small Changes:Starting a Participatory Design Process by GivingParticipants a Voice. Participatory Design: Princi-ples and Practices Schuler, D. and Namioka, A. eds.Lawrence Erlbaum Associates: Hillsdale, New Jersey,1993.

[36] Gröne, B., Knöpfel, A., and Kugel, R. Architecturerecovery of Apache 1.3 -- A case study. 2002 Interna-tional Conference on Software Engineering Re-search and Practice. Las Vegas, 2002.

[37] Hassan, A.E. and Holt, R.C. Architecture recovery ofweb applications. Twenty-fourth International Con-ference on Software Engineering. May, 2002.

[38] Hayes-Roth, B., Pfleger, K., Lalanda, P., Morignot, P.,and Balabanovic, M. A domain-specific software ar-chitecture for adaptive intelligent systems. IEEE TSE.21(4), p. 288-301, April, 1995.

[39] Herbsleb, J. Global Software Engineering: The Futureof Socio-technical Coordination. Future of SoftwareEngineering 2007 Briand, L. and Wolf, A. eds. IEEE-CS Press, 2007.

[40] Issarny, V., Caporuscio, M., and Georgantas, N. APerspective on the Future of Middleware-Based Soft-ware Engineering Future of Software Engineering2007 Briand, L. and Wolf, A. eds. IEEE-CS Press,2007.

[41] Jackson, M. System Development. Prentice Hall:Englewood Cliffs, N.J., 1983.

[42] Jackson, M. Problem Frames. Addison-Wesley Pro-fessional: Reading, MA, 2001.

[43] Jackson, M.A. Principles of Program Design. Aca-demic Press, 1975.

[44] Jones, J.C. Design Methods: Seeds of Human Futures.John Wiley & Sons, Ltd.: New York, 1970.

[45] Kelley, T., Littman, J., and Peters, T. The Art of Inno-vation: Lessons in Creativity from IDEO, America'sLeading Design Firm. Currency/Doubleday: NewYork, 2001.

[46] Knuth, D.E. The Art of Computer Programming, Vol-ume 3: Sorting and Searching. Addison-Wesley,1973.

[47] Knuth, D.E. Literate Programming. CSLI LectureNotes, no. 27., Stanford, California: Center for theStudy of Language and Information, 1992.

[48] Kramer, J. and Magee, J. Self-Managed Systems: AnArchitectural Challenge Future of Software Engi-neering 2007 Briand, L. and Wolf, A. eds. IEEE-CSPress, 2007.

[49] Kramer, J. Is Abstraction the Key to Computing?Communications of the ACM. 2007. To appear.

[50] Kruchten, P. The 4+1 View Model of Architecture.IEEE Software. 12(6), p. 42-50, November, 1995.

[51] Kruchten, P. The Rational Unified Process: An Intro-duction. Addison-Wesley: Reading, MA, 2000.

[52] Larman, C. Applying UML and Patterns. An introduc-tion to object-oriented analysis and design and theUnified Process. 2nd ed. Prentice-Hall PTR, 2002.

[53] Lethbridge, T., Diaz-Herrera, J., LeBlanc, R., andThompson, J. Improving Software Practice throughEducation: Challenges and Future Trends Future o fSoftware Engineering 2007 Briand, L. and Wolf, A.eds. IEEE-CS Press, 2007.

[54] Lopes, C.V., Kiczales, G., Mendhekar, A., Maeda, C.,Loingtier, J.-M., and Irwin, J. Aspect-Oriented Pro-gramming. European Conference on Object-OrientedProgramming. Finland, 1997.

[55] Mark, G., Abrams, S., and Nassif, N. Group-to-GroupDistance Collaboration: Examining the “Space Be-tween”. Eighth European Conference of Computer-Supported Cooperative Work. p. 99-118, Helsinki,Finland, September 14-18, 2003.

[56] Medvidovic, N. and Taylor, R.N. A Classification andComparison Framework for Software Architecture De-scription Languages. IEEE TSE. 26(1), p. 70-93, Janu-ary, 2000.

[57] Medvidovic, N., Dashofy, E., and Taylor, R.N. MovingArchitectural Description from Under the TechnologyLamppost. Information and Software Technology.49(1), p. 12-31, 2007.

[58] Norman, D.A. The Design of Everyday Things. 1stBasic paperback ed., Basic Books: New York, 2002.

[59] Ommering, R.v., Linden, F.v.d., Kramer, J., and Magee,J. The Koala Component Model for Consumer Elec-tronics Software. IEEE Computer. 33(3), p. 78-85,March, 2000.

[60] Osterweil, L., Ghezzi, C., Kramer, J., and Wolf, A. Edi-torial ACM TOSEM. 14(4), p. 381-382, 2005.

[61] Parnas, D.L. On the Criteria to be Used in Decompos-ing Systems into Modules. Communications of theACM. 15(12), p. 1053-1058, 1972.

[62] Parnas, D.L. On the Design and Development of Pro-gram Families. IEEE TSE. 2(1), p. 1-9, 1976.

[63] Parnas, D.L. Designing Software for Ease of Extensionand Contraction. IEEE TSE. 5(2), p. 128-137, 1979.

[64] Parnas, D.L., Clements, P.C., and Weiss, D.M. TheModular Structure of Complex Systems. IEEE TSE.11(3), p. 259-266, March, 1985.

[65] Parnas, D.L. and Clements, P.C. A Rational DesignProcess: How and Why to Fake It. IEEE TSE. 12(2), p.251-257, February, 1986.

[66] Perry, D.E. and Wolf, A.L. Foundations for the Studyof Software Architecture. ACM SIGSOFT SoftwareEngineering Notes. 17(4), p. 40-52, October, 1992.

[67] Petroski, H. To Engineer is Human. St. Martin's Press1985.

[68] Petroski, H. The Evolution of Useful Things. AlfredA. Knopf, Inc., 1992.

[69] Petroski, H. Invention by Design: How engineers getfrom thought to thing. Harvard University Press,1996.

[70] Pohl, K., Böckle, G., and van der Linden, F.J. SoftwareProduct Line Engineering: Foundations, Principlesand Techniques. 1 ed., Springer, 2005.

[71] Sarkar, S., Rama, G.M., and Kak, A.C. API-Based andInformation-Theoretic Metrics for Measuring theQuality of Software Modularization. IEEE TSE. 33(1),p. 14-32, January, 2007.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007

Page 18: [IEEE Future of Software Engineering - Minneapolis, MN, USA (2007.05.23-2007.05.25)] Future of Software Engineering (FOSE '07) - Software Design and Architecture The once and future

[72] Schön, D. The Reflective Practitioner: How Profes-sionals Think in Action., Basic Books, Inc. Publish-ers: New York, 1983.

[73] Shaw, M., DeLine, R., Klein, D.V., Ross, T.L., Young,D.M., and Zelesnik, G. Abstractions for Software Ar-chitecture and Tools to Support Them. IEEE TSE.21(4), p. 314-335, April, 1995.

[74] Simon, H.A. The Sciences of the Artificial. 1st ed.The MIT Press, 1969.

[75] Simon, H.A. The Sciences of the Artificial. 2nd ed.The MIT Press, 1981.

[76] Spector, A. and Gifford, D. A Computer Science Per-spective of Bridge Design. Communications of theACM. 29(4), p. 267-283, April, 1986.

[77] Sullivan, K.J., Chalasani, P., Jha, S., and Sazawal, V.Software Design as an Investment Activity: A RealOptions Perspective. Real Options and Business

Strategy: Applications to Decision Making Trigeor-gis, L. ed. Risk Books, 1999.

[78] Taylor, R.N., Medvidovic, N., and Dashofy, E.M.Software Architecture: Foundations, Theory, andPractice. John Wiley & Sons, 2008. In press.

[79] Tracz, W. DSSA (Domain-Specific Software Architec-ture): Pedagogical Example. ACM SIGSOFT SoftwareEngineering Notes. 20(3), July, 1995.

[80] Van Duyne, D.K., Landay, J.A., and Hong, J.I. The De-sign of Sites : Patterns, Principles, and Processesfor Crafting a Customer-centered Web Experience.Addison-Wesley: Boston, 2003.

[81] Yourdon, E. Techniques of Program Structure andDesign. Prentice-Hall: Englewood Cliffs, N.J., 1975.

[82] Yourdon, E. and Constantine, L.L. Structured Design:Fundamentals of a Discipline of Computer Programand Systems Design. Prentice-Hall, Inc., 1979.

Future of Software Engineering(FOSE'07)0-7695-2829-5/07 $20.00 © 2007