DOCSLIB.ORG

Improving the Software Architecture Design Process by Reusing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Improving the Software Architecture Design Process by Reusing Improving the software architecture design processby reusing technology-specific experience Glib Kutepov InformationSystems Development FraunhoferIESE Fraunhofer-Platz 1 67663Kaiserslautern [email protected] Abstract: Experience with particular technologies such as SOA, Cloud Computing, or Mobile Apps plays acrucial role when designing thearchitectureof asoftwaresystem. Beingaware of thechallenges usuallyencountered when using atechnologyand knowinginadvance how to resolvethese challenges can dramatically increase thequality of thesoftwaresystemarchitectureand decrease thedesigneffort. However, it is not always astraightforwardprocesstocollect the necessaryarchitectural experience,persist it on theorganizational level,and reuse it in theright way, especiallyifthe technologyis new. This paper describes how architecturedesignprocesses can be improved by supplementing them with architectural experience relatedtoaparticular technology.The wayarchitectural experience canbedescribed usingarchitectural scenarios andsolutionpatterns is explained andpersistedinthe architecturedesignprocess. Theefficiencyof the approach is validated with thehelpofacasestudy. 1. Introduction Consider a modern software development organizationthat develops its products with a strong focusonthe architecture. During the software architecture designprocess, the architect identifies keychallengesthat influencethe current system architecture and findsappropriate solutions.Thistaskiscarried out successfully because the architect bases hissystemonfamiliar,wide-spread IT technologies whose caveatsare well known to himorher.Fortunately, theworld of technology does notstandstill: Everyday,some newtechnology appears on the IT scene, which opens up newopportunities: maybe an alternative or an improvement to an existing technology,oracompletelynew technological paradigm,suchas SOA,Cloud Computing, or Mobile Applications.The organizationmay have to incorporate the newtechnology in its architectural practices in ordertostay competitive.Initially, the identificationofchallenges andsolutions will be less effective than before due to a lack of knowledge on the architect’s part regarding the newtechnology.Thismay increase thetime needed forarchitecture design anddecrease quality. However, with time the processwill become more effective andthe qualityof the product will improve. This will be mostly due to the tacit experience of the software 83 architect. Havingone person as the only source of this specific knowledge may jeopardize all the benefits of adoptingthe newtechnology.Thus,awaytosystematically collect andpersist the architect’sexperience in an organization has to be found. Hofmeister et al. [HN99] suggest performing similar activities before designingevery architectural view andrefer to these activities as “Global Analysis”. The core of “Global Analysis” is the identificationoffactor-strategy pairs, which are then applied in the actual view design phase. “Factors” represent the challengesorproblemsthat may influencearchitecture design and“strategies” representsolutions to them.Weseesuch pairsasaneffective tool fordescribingand persisting technology-specific experience. In this paper, we propose an approach forsystematicallycollecting, describing, and reusing such pairsinthe context of the architecture design process. The pairsare collected with the help of project post-mortems, while thefactors are described in the form of architectural scenariosand strategieswithsolutionpatterns.Furthermore,several scenariosare provided forusing such pairsinthe architecture designphase, thus operationalizingthe experience. The paperisstructuredas follows: After an introductory part, the pros andconsofwell- known techniques forpersistingarchitectural experience are described in section2.In section3,the details of the approach are given. Ourexplanationisbased on Fraunhofer ACES -the architecture designprocess [KK11] used forsoftware architecture designat FraunhoferIESE. Section4showshow we instantiated ourideafor the activelyevolving technology of mobile “apps” andparticularly its applicationinthe business domain.The “Initial Validation” chapter features a case studythat was performedinorder to take first stepstowards the validationofthe approach.The section“Conclusion” concludes the paper. 2. Related Work The aim of this paperistoshowthe reader hownew technology canbe efficiently adopted in the architectural practices of software engineeringcompanies.The main challenge in adoptinganew technology is the lackofstructuredorganization-wide architectural experience that canbe reused in an operationalmanner. Thus,our goal is to find a waytocollect andpersist this experience inside the architecture designprocess. Well-knownprocessessuchas ADD [BK01] or BAPO/CAFCR[Sm03] provide solid guidancefor architecture designbut, unfortunately, do not offerany facilities for collectingand persisting architectural experience forfurther reuse.Thismeans that such facilities have to be either invented or created by combiningprior works. We examined relatedworkonexistingsolutions to the following challenges: ways to collect architectural experience andwaystopersist it within thearchitecture design process. One of the prominent techniques forcollectingexperience is “Project Postmortems” [Ti90].How this technique was used forour purpose will be explainedinsection3.2.A popular approach forpersistingarchitectural experience are domain-specific software architectures [Tr95].Researchershave developedabodyofvarious methodologies for 84 approachingsucharchitectures, rangingfromguidelinesand recommendations for creatingdomain-specific architectures [AA07] to proposals of ready-to-use reference architectures [ZL00],[DN08].Unfortunately,the applicabilityofthese approaches is limited to particular well-scopedbusinessdomains,which is not ourcase. Ourtarget is a technology that canhavemultiple applicationareas; therefore it wouldbe tooeffort- consumingand inflexible to model it with a set of software components. Alternative approach fortechnology-specific experience persistenceare pattern languages, such as [BM00],[GH94],orthe factor-strategy pairsof[HN99].Although patternlanguages are a very effective approach,we feel that they lackprecision in describingarchitectural problems: In [HN99],the descriptionofthe factor (problem)is rather unstructured, andinthe “Gang of Four” work [GH94],the problemsare described in terms of object-oriented programming rather than architecture.Inthispaper,these drawbacksare mitigated with the help of architectural scenarios[KB94], [DF99]. It is always a challenge to find the right detail level fordescribingthe solutionpart of a pattern. Forexample, the detail level of [GH94] patterns differs from ours: Unlike the implementationlevel used by [GH94],we describe patterns on the architectural level, whichismore abstract andcan lead to multiple implementations; hence, it is a complex task to describe a patterninsuchawaythat it givesthe architect solid guidance without prescribingany particular implementation. Therefore we propose ourown generic template forsolutiondescriptions. The next sectiondescribes howthese approaches were combined in ordertomitigate the drawbacksofeachone anddevelopthe needed technique. 3. Approach This sectioncontains a step-by-step descriptionofour approach forpersisting technology-specific architectural experience in the architecture designprocess. 3.1Baseline Architecture Method As a basis forthe technology-specific architecture designprocess,we take Fraunhofer ACES [KK11] – the architecture design processactivelyusedbyFraunhofer IESE. The inputtothe processare system requirements obtainedinprevious phases of the software system engineering process, andthe output is,among others,aset of documented architectural viewsofthe system.ACES is a comprehensive processthat guides architects in all theiractivities, startingfromthe identificationofstakeholdersand the understanding of architectural driversvia architecture realizationall the waytothe documentationand validationofthe system architecture produced. The approach consists of twoparts: core competence – the main part, whichincludesdomain- independent sub-processes forarchitecture design, and domaincompetencies – an optional part, whichcontainsdomain-specific static experience artifacts relatedtothe architecture design. The structure of Fraunhofer ACES is showninFigure 1. 85 The “domaincompetencies” (inour case rather “technology competencies”) part of FraunhoferACES foresees threecrucial experience collectionareas - challenges, solutions,and technologies,which represent a similar concept as the factors andstrategy pairsofthe “Global Analysis” of [HN99].Challengescorrespondtofactors and solutions correspondtostrategies. The technologies area is used forpersisting informationabout COTS solutionsthat arerelevant forthe considered domain. Solutions canaddress technologies in their description. This paperfocuses on challengesand solutions in architecture design; therefore the technology part of ACES is not addressed here.ACES provides experience areas, but gives no concrete guidelines on howto collect this experience or howtorepresent it. Figure 1: Fraunhofer ACES In ordertoreuse architectural experience during the architecture designprocess, we examined twosub-processesofthe FraunhoferACES core competencies: ASR[KK11] (ArchitecturallySignificant Requirements) – the processanalyzing stakeholders and elicitingrequirementsspecificallyrelated to the architecture,and DMM [KK11] (Design, Modeling, Migration)
Load more

Recommended publications
  • (Perry & Wolf 92) Software Architecture (Garlan & Shaw
    ICS 221, Winter 2001 Software Architecture Software Architecture (Perry & Wolf 92) “Architecture is concerned with the selection of architectural elements, their interactions, and the Software Architecture constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” David S. Rosenblum ICS 221 “Design is concerned with the modularization and detailed interfaces of the design elements, their Winter 2001 algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.” Software Architecture Software Architecture (Garlan & Shaw 93) (Shaw & Garlan 96) “Software architecture is a level of design that goes “The architecture of a software system defines beyond the algorithms and data structures of the that system in terms of computational computation; designing and specifying the overall components and interactions among those system structure emerges as a new kind of problem. Structural issues include gross organization and components. … In addition to specifying the global control structure; protocols for communication, structure and topology of the system, the synchronization, and data access; assignment of architecture shows the correspondence functionality to design elements; physical between the requirements and elements of distribution; composition of design elements; scaling the constructed system, thereby providing and performance; and selection among design some rationale for the design decisions.” alternatives.” Analogies with Differences Between Civil and Civil Architecture Software Architecture Civil Engineering and Civil Architecture “Software systems are like cathedrals—first we are concerned with the engineering and design of build them and then we pray.” civic structures (roads, buildings, bridges, etc.) — Sam Redwine ! Multiple views ! Civil: Artist renderings, elevations, floor plans, blueprints ! Physical vs.
    [Show full text]
  • Meaningful Urban Design: Teleological/Catalytic/Relevant
    Journal ofUrban Design,Vol. 7, No. 1, 35– 58, 2002 Meaningful Urban Design: Teleological/Catalytic/Relevant ASEEM INAM ABSTRACT Thepaper begins with a critique ofcontemporary urban design:the eldof urban designis vague because it isan ambiguousamalgam of several disciplines, includingarchitecture, landscapearchitecture, urban planningand civil engineering; it issuper cial because itisobsessedwith impressions and aesthetics ofphysical form; and it ispractised as an extensionof architecture, whichoften impliesan exaggerated emphasison theend product. The paper then proposesa meaningful(i.e. truly consequential to improvedquality of life) approach to urban design,which consists of: beingteleological (i.e. driven by purposes rather than de ned by conventional disci- plines);being catalytic (i.e. generating or contributing to long-term socio-economic developmentprocesses); andbeing relevant (i.e. grounded in rst causes andpertinent humanvalues). The argument isillustratedwith a number ofcase studiesof exemplary urban designers,such asMichael Pyatok and Henri Ciriani,and urban designprojects, such asHorton Plazaand Aranya Nagar, from around the world. The paper concludes withan outlineof future directionsin urban design,including criteria for successful urban designprojects (e.g. striking aesthetics, convenient function andlong-term impact) anda proposedpedagogical approach (e.g. interdisciplinary, in-depth and problem-driven). Provocations In the earlypart of 1998,two provocative urban design eventsoccurred at the Universityof Michigan in Ann Arbor.The rstwas an exhibition organizedas partof aninternationalsymposium on ‘ City,Space 1 Globalization’. The second wasa lecture by the renowned Dutch architectand urbanist, Rem Koolhaas. By themselves,the events generated much interestand discussion, yet were innocu- ous,compared to, say, Prince Charles’s controversialcomments on contempor- arycities in the UKorthe gathering momentumof the New Urbanism movementin the USA.
    [Show full text]
  • On the Value(S) of an Architect
    2 A Discipline Adrift? Teaching Architectural Ethics in Today’s World On the Value(s) of an Architect ANASTASIA H. CORTES Virginia Tech This paper situates architectural ethics in the context of observer: they either like it or they don’t. Architects earn practice by using stakeholder theory and the concept of pro- professional degrees and are licensed, like doctors, lawyers, fessional judgment to describe the activities of architectural and engineers. However, architecture is the lowest paid of practice. Architects are taught the skills necessary to make these four professions. Although buildings are tangible arti- ethical professional judgments in the contexts of design and facts of an architect’s work, the design of a building is less professional service, but they are not necessarily taught easily understood by the lay person than, say, recovery from how to effectively communicate the value of those skills to an illness. Often the public may value the architect’s work those outside the profession. Stakeholder theory provides a based on the subjective evaluation of the observer: they framework to describe the practice of architecture in a way either like it or they don’t. The profession cannot survive on that enables non-practitioners to appreciate value of the the basis of the public’s “like” of their work, as discussed in complex decisions and activities performed by architects. a 2015 article in Forbes magazine, which declared contem- porary architecture to be ugly, irrelevant, and out of touch “There’s a snobbery at work in architecture…The sub- with society.3 In support of this claim, the author offered up ject is too often treated as a fine art, delicately wrapped a description of the American Institute of Architects’ effort in mumbo-jumbo.
    [Show full text]
  • Designing Software Architecture to Support Continuous Delivery and Devops: a Systematic Literature Review
    Designing Software Architecture to Support Continuous Delivery and DevOps: A Systematic Literature Review Robin Bolscher and Maya Daneva University of Twente, Drienerlolaan 5, Enschede, The Netherlands [email protected], [email protected] Keywords: Software Architecture, Continuous Delivery, Continuous Integration, DevOps, Deployability, Systematic Literature Review, Micro-services. Abstract: This paper presents a systematic literature review of software architecture approaches that support the implementation of Continuous Delivery (CD) and DevOps. Its goal is to provide an understanding of the state- of-the-art on the topic, which is informative for both researchers and practitioners. We found 17 characteristics of a software architecture that are beneficial for CD and DevOps adoption and identified ten potential software architecture obstacles in adopting CD and DevOps in the case of an existing software system. Moreover, our review indicated that micro-services are a dominant architectural style in this context. Our literature review has some implications: for researchers, it provides a map of the recent research efforts on software architecture in the CD and DevOps domain. For practitioners, it describes a set of software architecture principles that possibly can guide the process of creating or adapting software systems to fit in the CD and DevOps context. 1 INTRODUCTION designing new software architectures tailored for CD and DevOps practices. The practice of releasing software early and often has For clarity, before elaborating on the subject of been increasingly more adopted by software this SLR, we present the definitions of the concepts organizations (Fox et al., 2014) in order to stay that we will address: Software architecture of a competitive in the software market.
    [Show full text]
  • An Overview of the Building Delivery Process
    An Overview of the Building Delivery CHAPTER Process 1 (How Buildings Come into Being) CHAPTER OUTLINE 1.1 PROJECT DELIVERY PHASES 1.11 CONSTRUCTION PHASE: CONTRACT ADMINISTRATION 1.2 PREDESIGN PHASE 1.12 POSTCONSTRUCTION PHASE: 1.3 DESIGN PHASE PROJECT CLOSEOUT 1.4 THREE SEQUENTIAL STAGES IN DESIGN PHASE 1.13 PROJECT DELIVERY METHOD: DESIGN- BID-BUILD METHOD 1.5 CSI MASTERFORMAT AND SPECIFICATIONS 1.14 PROJECT DELIVERY METHOD: 1.6 THE CONSTRUCTION TEAM DESIGN-­NEGOTIATE-BUILD METHOD 1.7 PRECONSTRUCTION PHASE: THE BIDDING 1.15 PROJECT DELIVERY METHOD: CONSTRUCTION DOCUMENTS MANAGEMENT-RELATED METHODS 1.8 PRECONSTRUCTION PHASE: THE SURETY BONDS 1.16 PROJECT DELIVERY METHOD: DESIGN-BUILD METHOD 1.9 PRECONSTRUCTION PHASE: SELECTING THE GENERAL CONTRACTOR AND PROJECT 1.17 INTEGRATED PROJECT DELIVERY METHOD DELIVERY 1.18 FAST-TRACK PROJECT SCHEDULING 1.10 CONSTRUCTION PHASE: SUBMITTALS AND CONSTRUCTION PROGRESS DOCUMENTATION Building construction is a complex, significant, and rewarding process. It begins with an idea and culminates in a structure that may serve its occupants for several decades, even centuries. Like the manufacturing of products, building construction requires an ordered and planned assembly of materials. It is, however, far more complicated than product manufacturing. Buildings are assembled outdoors by a large number of diverse constructors and artisans on all types of sites and are subject to all kinds of weather conditions. Additionally, even a modest-sized building must satisfy many performance criteria and legal constraints, requires an immense variety of materials, and involves a large network of design and production firms. Building construction is further complicated by the fact that no two buildings are identical; each one must be custom built to serve a unique function and respond to its specific context and the preferences of its owner, user, and occupant.
    [Show full text]
  • Software Engineering (SE) 1
    Software Engineering (SE) 1 SE 352 | OBJECT-ORIENTED ENTERPRISE APPLICATION DEVELOPMENT SOFTWARE ENGINEERING | 4 quarter hours (Undergraduate) (SE) This course focuses on applying object-oriented techniques in the design and development of software systems for enterprise applications. Topics SE 325 | INTRODUCTION TO SOFTWARE ENGINEERING | 4 quarter hours include component architecture, such as Java Beans and Enterprise (Undergraduate) Java Beans, GUI components, such as Swing, database connectivity and This course introduces students to the activities performed at each object repositories, server application integration using technologies stage of the development process so that they can understand the full such as servlets, Java Server Pages, JDBC and RMI, security and lifecycle context of specific tasks such as coding and testing. Topics will internationalization. PREREQUISITE(S): CSC 301. include software development processes, domain modeling, requirements CSC 301 is a prerequisite for this class. elicitation and specification, architectural design and analysis, product SE 356 | SOFTWARE DEVELOPMENT FOR MOBILE AND WIRELESS and process level metrics, configuration management, quality assurance SYSTEMS | 4 quarter hours activities including user acceptance testing and unit testing, project (Undergraduate) management skills such as risk analysis, effort estimation, project This course will focus on the unique aspects of developing software release planning, and software engineering ethics. applications for mobile and wireless systems, such as personal digital CSC 301 or CSC 393 is a prerequisite for this class. assistant (PDA) devices and mobile phones. Topics will include user SE 330 | OBJECT ORIENTED MODELING | 4 quarter hours interface design for small screens with restricted input modalities, data (Undergraduate) synchronization for mobile databases as well as wireless programming Object-oriented modeling techniques for analysis and design.
    [Show full text]
  • Architecture
    Architecture Architects are licensed professionals who design buildings and other structures. The design of a building involves far more than its appearance alone. Buildings also must be functional, safe, economical, and suit the needs of the people who use them. There are three main steps to become an architect: the attainment of a professional degree in architecture, work experience through an internship, and licensure through the passing of the Architect Registration Exam. Explore Become an Architect at NCARB.org. Degree Students choose from three paths to obtain a professional degree in architecture: • 5-year Bachelor of Architecture (B. Arch) degree: most transfer students do not choose this option due to course sequencing or • 2-year master’s degree after obtaining a 4-year bachelor’s degree in architecture or related area (M. Arch) or • 3 to 4-year master’s degree after obtaining a 4-year bachelor’s degree in a major other than architecture (M. Arch) Criteria of Importance for Acceptance to Architecture School May Include • Grade point average • Portfolio if required (freehand drawing, painting, graphic design, sculpture, etc.) • Personal interview • Past practical work experience related to the field (construction, building, planning, etc.) • Strong art, math, and science skills (especially physics) Important Notes • Due to the sequential nature of the coursework, transfer applicants for bachelor degree programs in architecture are often considered for admission as first year students. Four or five additional years to complete the program may be required. • Each architecture school has its own set of requirements. Research each school for specific information. • Make sure to check application deadline dates.
    [Show full text]
  • Composition of Software Architectures Christos Kloukinas
    Composition of Software Architectures Christos Kloukinas To cite this version: Christos Kloukinas. Composition of Software Architectures. Computer Science [cs]. Université Rennes 1, 2002. English. tel-00469412 HAL Id: tel-00469412 https://tel.archives-ouvertes.fr/tel-00469412 Submitted on 1 Apr 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Composition of Software Architectures - Ph.D. Thesis - - Presented in front of the University of Rennes I, France - - English Version - Christos Kloukinas Jury Members : Jean-Pierre Banâtre Jacky Estublier Cliff Jones Valérie Issarny Nicole Lévy Joseph Sifakis February 12, 2002 Résumé Les systèmes informatiques deviennent de plus en plus complexes et doivent offrir un nombre croissant de propriétés non fonctionnelles, comme la fiabi- lité, la disponibilité, la sécurité, etc.. De telles propriétés sont habituellement fournies au moyen d’un intergiciel qui se situe entre le matériel (et le sys- tème d’exploitation) et le niveau applicatif, masquant ainsi les spécificités du système sous-jacent et permettant à des applications d’être utilisées avec dif- férentes infrastructures. Cependant, à mesure que les exigences de propriétés non fonctionnelles augmentent, les architectes système se trouvent confron- tés au cas où aucun intergiciel disponible ne fournit toutes les propriétés non fonctionnelles visées.
    [Show full text]
  • Download Distributed Systems Free Ebook
    DISTRIBUTED SYSTEMS DOWNLOAD FREE BOOK Maarten van Steen, Andrew S Tanenbaum | 596 pages | 01 Feb 2017 | Createspace Independent Publishing Platform | 9781543057386 | English | United States Distributed Systems - The Complete Guide The hope is that together, the system can maximize resources and information while preventing failures, as if one system fails, it won't affect the availability of the service. Banker's algorithm Dijkstra's algorithm DJP algorithm Prim's algorithm Dijkstra-Scholten algorithm Dekker's algorithm generalization Smoothsort Shunting-yard algorithm Distributed Systems marking algorithm Concurrent algorithms Distributed Systems algorithms Deadlock prevention algorithms Mutual exclusion algorithms Self-stabilizing Distributed Systems. Learn to code for free. For the first time computers would be able to send messages to other systems with a local IP address. The messages passed between machines contain forms of data that the systems want to share like databases, objects, and Distributed Systems. Also known as distributed computing and distributed databases, a distributed system is a collection of independent components located on different machines that share messages with each other in order to achieve common goals. To prevent infinite loops, running the code requires some amount of Ether. As mentioned in many places, one of which this great articleyou cannot have consistency and availability without partition tolerance. Because it works in batches jobs a problem arises where if your job fails — Distributed Systems need to restart the whole thing. While in a voting system an attacker need only add nodes to the network which is Distributed Systems, as free access to the network is a design targetin a CPU power based scheme an attacker faces a physical limitation: getting access to more and more powerful hardware.
    [Show full text]
  • Introduction to Software Architecture
    Introduction to Software Architecture Imed Hammouda Chalmers | University of Gothenburg Who am I? • Associate Professor of Software Engineering, previously in Tampere, Finland • Research interests – Software Architecture, Open Source, Software Ecosystems, Software Development Methods and Tools, Variability Management • Developing and supporting open software architectures • Studying socio-technical dependencies in software development • Software ecosystems • Coordinates: [email protected], [email protected] • Room 416, floor 4, Jupiter building, Campus Lindholmen • Phone +46 31 772 60 40 Introduction to Software Architecture 2 • What is software architecture? • Architectural drivers • Addressing architectural drivers • Architectural views • Example system Introduction to Software Architecture 3 What is Software Architecture? • Software Architecture is the global organization of a software system, including – the division of software into subsystems/components, – policies according to which these subsystems interact, – the definition of their interfaces. T. C. Lethbridge & R. Laganière Introduction to Software Architecture 4 What is Software Architecture? • "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them." Len Bass Introduction to Software Architecture 5 What is Software Architecture? • “fundamental concepts or properties of a system in its environment
    [Show full text]
  • The Software Architect -And the Software Architecture Team
    The Software Architect -and the Software Architecture Team Philippe Kruchten Rational Software, 650 West 41st Avenue #638, Vancouver, B.C., V5Z 2M9 Canada pbk@ rational. com Key words: Architecture, architect, team, process Abstract: Much has been written recently about software architecture, how to represent it, and where design fits in the software development process. In this article I will focus on the people who drive this effort: the architect or a team of architects-the software architecture team. Who are they, what special skills do they have, how do they organise themselves, and where do they fit in the project or the organisation? 1. AN ARCHITECT OR AN ARCHITECTURE TEAM In his wonderful book The Mythical Man-Month, Fred Brooks wrote that a challenging project must have one architect and only one. But more recently, he agreed that "Conceptual integrity is the vital property of a software product. It can be achieved by a single builder, or a pair. But that is too slow for big products, which are built by teams."' Others concur: "The greatest architectures are the product of a single mind or, at least, of a very small, carefully structured team."2 More precisely: "Every project should have exactly one identifiable architect, although for larger projects, the principal architect should be backed up by an architecture team of modest size."3 1 Keynote address, ICSE-17, Seattle, April1995 2 Rechtin 1991 , p. 22 3 Booch 1996, p. 196 The original version of this chapter was revised: The copyright line was incorrect. This has been corrected. The Erratum to this chapter is available at DOI: 10.1007/978-0-387-35563-4 35 P.
    [Show full text]
  • Contemporary Design Philosophy in American Architecture
    ^O 1 CONTEMPORARY DESIGN PHILOSOPHY IN AMERICAN ARCHITECTURE by KENNETH EDWARD LAY, JR. B. Arch., The Pennsylvania State University, 1956 e\\i A MASTER'S REPORT submitted in partial fulfillment of the requirements for the degree MASTER OF ARCHITECTURE College of Architecture and Design KANSAS STATE UNIVERSITY Manhattan, Kansas 1966 Approved by: Ma^or Professor , Lb 2j>^i ii a.o- ACKNOWLEDGEMENTS I gratefully acknowledge the guidance and encouragement given me during the planning and writing of this report by Professor Emil C. Fischer, Dean of the College of Architecture and Design at Kansas State University. My most sincere appreciation goes to my wife, Margaret F. Lay, A.S.L.A. whose professional advice and understanding helped immeasurably in its preparation. Appreciation is further extended to my committee members, Professor Jack C. Durgan, Professor J. Cranston Heintzelman, Professor Cecil H. Miller, and Dr. William C. Tremmel, and to my typist, Mrs. Michael R. Hawkins. , TABLE OF CONTENTS CHAPTER PAGE I. INTRODUCTION: THE MODERN MOVEMENT 1 Prior to the Chicago School 2 The Chicago School of Architecture 4 L'Art Nouveau and Cubism 6 The Organic Architecture of Frank Lloyd Wright . 8 The International Style 10 Mies van der Rohe 12 LeCorbusier 14 The Present Situation .............. 16 Design Trends in Architectural Education 17 The Rediscovery of History 19 Structural Experimentation 20 II. THE CLASSIC ARTICLE 22 III. STRUCTURAL EXPRESSIONISM 27 IV. THE AESTHETIC REVIVAL 36 V. THE DIRECTION OF AMERICAN ARCHITECTURE 42 VI. CRITICISM OF CONTEMPORARY DESIGN PHILOSOPHY .... 45 VII. THE NEW FREEDOM WITHIN THE MODERN MOVEMENT 57 VIII. THE NEW FREEDOM'S AVANT-GARDE 71 Dr.
    [Show full text]