DOCSLIB.ORG

110707 What Colours Is Your Backlog Boston 2Up.Pptx

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
110707 What Colours Is Your Backlog Boston 2Up.Pptx Agile New England July 2011 Agility and Architecture or: What colours is your backlog? Philippe Kruchten July 7, 2011 Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So*ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of BriLsh Columbia Vancouver, BC Canada [email protected] Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected] Co founder and past-chair Copyright © 2011 Philippe Kruchten 2 Copyright © 2011 Philippe Kruchten 1 Agile New England July 2011 Outline 1. The frog and the octopus 2. Architecture and agility 3. Release planning 4. Technical debt 5. Architecture, agility,… revisited Copyright © 2011 Philippe Kruchten 5 A Conceptual Model of SoYware Development 4 key concepts, 5 key aributes . Intent . Time . Product . Value . Quality . Work . Cost . Risk . People Copyright © 2011 Philippe Kruchten 8 Copyright © 2011 Philippe Kruchten 2 Agile New England July 2011 Intent, Work, People, Product Copyright © 2011 Philippe Kruchten 9 Frog: “All projects are the same” Value Value Cost Cost Copyright © 2011 Philippe Kruchten 10 Copyright © 2011 Philippe Kruchten 3 Agile New England July 2011 Copyright © 2011 Philippe Kruchten 11 Octopus: “All projects are different!” Size Domain, Age of Degree of Industry the CriLcality Innovaon system Rate of Business change Context model Gover Stable architec nance Corporate & Team ture Organizaonal Naonal Culture distribu Maturity on Copyright © 2011 Philippe Kruchten 12 Copyright © 2011 Philippe Kruchten 4 Agile New England July 2011 SW Dev. Project: Tension between Intent and Product Intent Work V Product Copyright © 2011 Philippe Kruchten T 13 Iteraons Copyright © 2011 Philippe Kruchten 14 Copyright © 2011 Philippe Kruchten 5 Agile New England July 2011 Outline 1. The frog and the octopus 2. Architecture and agility 3. Release planning 4. Technical debt 5. Architecture, agility,… revisited Copyright © 2011 Philippe Kruchten 15 Agile & Architecture? Oil & Water? • Paradox • Oxymoron • Conflict • Incompability Copyright © 2011 Philippe Kruchten 16 Copyright © 2011 Philippe Kruchten 6 Agile New England July 2011 What is Agility? • Jim Highsmith (2002): – Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. • Sanjiv Augusne (2004): – Iterave and incremental – Small release – Collocaon – Release plan/ feature backlog – Iteraon plan/task backlog Copyright © 2011 Philippe Kruchten 17 Geng at the Essence of Agility • SoYware development is a knowledge acLvity – Not producLon, manufacturing, administraon… • The “machines” are humans • Dealing with uncertainty, unknowns, fear, distrust • Feedback loops ➜ – reflect on business, requirements, risks, process, people, technology • Communicaon and collaboraon – Building trust ➜ rely on tacit informaon ➜ reduce waste Copyright © 2011 Philippe Kruchten 18 Copyright © 2011 Philippe Kruchten 7 Agile New England July 2011 SoYware Architecture: A DefiniLon " " ""“It#s the hard stuff.”" “It#s the stuff that will be hard to change”" M.Fowler, cited by J. Highsmith 20 Copyright © 2011 Philippe Kruchten ISO/IEC 42010 Architecture: the fundamental concepts or properLes of a system in its environment embodied in its elements, their relaonships, and in the principles of its design and evoluLon Copyright © 2011 Philippe Kruchten 21 Copyright © 2011 Philippe Kruchten 8 Agile New England July 2011 SoYware Architecture SoYware architecture encompasses the set of significant decisions about •! the organizaon of a soYware system, •! the selecLon of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboraon among those elements, •! the composiLon of these elements into progressively larger subsystems, Grady Booch, Philippe Kruchten, Rich Reitman, Kurt BiCner; Raonal, circa 1995 (derived from Mary Shaw) Copyright © 2011 Philippe Kruchten 22 SoYware Architecture (cont.) … •! the architectural style that guides this organizaon, these elements and their interfaces, their collaboraons, and their composiLon. •! SoYware architecture is not only concerned with structure and behavior, but also with usage, funcLonality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aestheLcs. Copyright © 2011 Philippe Kruchten 23 Copyright © 2011 Philippe Kruchten 9 Agile New England July 2011 Perceived Tensions Agility- Architecture •! Architecture = Big Up-Front Design •! Architecture = massive documentaon •! Architects dictate form their ivory tower •! Low perceived or visible value of architecture •! Loss of rigour, focus on details •! Disenfranchisement •! Quality aribute not reducible to stories Hazra, 2008 Rendell, 2009 Blair et al. 2010, etc. Copyright © 2011 Philippe Kruchten 24 Perceived Tensions Agility- Architecture Adaptaon versus AnLcipaon Highsmith 2000 Copyright © 2011 Philippe Kruchten 25 Copyright © 2011 Philippe Kruchten 10 Agile New England July 2011 Issues 1.! SemanLcs 2.! Scope 3.! Lifecycle 4.! Role 5.! Descripon 6.! Methods 7.! Value & cost Copyright © 2011 Philippe Kruchten 26 SemanLcs •! What do we mean by “architecture”? •! What do we mean by “soYware architecture”? Copyright © 2011 Philippe Kruchten 28 Copyright © 2011 Philippe Kruchten 11 Agile New England July 2011 Issues 1.! SemanLcs 2.! Scope 3.! Lifecycle 4.! Role 5.! Descripon 6.! Methods 7.! Value & cost Copyright © 2011 Philippe Kruchten 29 Scope •! How much architecture “stuff” do you really need? •! It depends… •! It depends on your context Copyright © 2011 Philippe Kruchten 30 Copyright © 2011 Philippe Kruchten 12 Agile New England July 2011 Context aributes 1.! Size Size Age of Cricality 2.! CriLcality System 3.! Age of system 4.! Rate of change Rate of Business Context 5.! Business model change model 6.! Domain 7.! Team distribuLon Governance Domain 8.! Governance Team Distribuon Copyright © 2011 Philippe Kruchten 31 All soYware-intensive systems have an architecture •! How much effort should you put into it varies greatly •! 75% of the Lme, the architecture is implicit –! Choice of technology, plaorm –! SLll need to understand the architecture •! Novel systems: –! Much more effort in creang and validang an architecture •! Key drivers are mostly non-funcLonal: –! RunLme: Capacity, performance, availability, security –! Non runLme: evolvability, regulatory, i18n/L10n… Copyright © 2011 Philippe Kruchten 32 Copyright © 2011 Philippe Kruchten 13 Agile New England July 2011 Lifecycle •! When does architectural acLviLes take place? •! The evil of “BUFD” = Big Up-Front Design •! “Defer decisions to the last responsible moment” •! YAGNI = You Ain’t Gonna Need It •! Refactor! Copyright © 2011 Philippe Kruchten 34 Architectural Effort During the Lifecycle Inception Elaboration Construction Transition time Majority of architectural design activities Copyright © 2011 Philippe Kruchten 35 Copyright © 2011 Philippe Kruchten 14 Agile New England July 2011 LiZle dedicated architectural effort Inception Construction Transition time Minimal pure Ideal realm of agile Architectural Activities practices Copyright © 2011 Philippe Kruchten 36 Iteraons and Phases Iterations with focus on Iterations with main architecture focus on features An architectural iteration focuses in putting in place major architectural elements, resulting in a baseline architectural prototype at the end of elaboration. Copyright © 2011 Philippe Kruchten 37 Copyright © 2011 Philippe Kruchten 15 Agile New England July 2011 Team Structure over Time (Very Large) Inception Elaboration Construction and Transition Management team Management team Architecture team Architecture Feature team 1 team Initial team Feature team 2 Prototyping team Infrastructure Feature team 3 team A Infrastructure team B Copyright © 2011 Philippe Kruchten integration team 38 Teams using agile development pracLces Inception Elaboration Construction and Transition Management team Management team Architecture team Architecture Feature team 1 team Initial team Feature team 2 Prototyping team Infrastructure Feature team 3 team A Infrastructure team B Copyright © 2011 Philippe Kruchten integration team 39 Copyright © 2011 Philippe Kruchten 16 Agile New England July 2011 Issues 1.! SemanLcs 2.! Scope 3.! Lifecycle 4.! Role 5.! Descripon 6.! Methods 7.! Value & cost Copyright © 2011 Philippe Kruchten 40 New Role – Agile Architect ? •! A. Johnston defines the agile architect, but it does not seems to be any different from a soYware architect before agile methods came in. •! Combinaon of –! Visionary - Shaper –! Designer – making choices –! Communicator – between mulLple parLes –! Troubleshooter –! Herald – window of the project –! Janitor – cleaning up behind the PM and the developers Copyright © 2011 Philippe Kruchten 42 Copyright © 2011 Philippe Kruchten 17 Agile New England July 2011 FuncLons of the soYware architect Definion of the architecture Delivery of the architecture •! Architecture definiLon •! Ownership of the big picture •! Technology selecLon •! Leadership •! Architectural evaluaon •! Coaching and mentoring •! Design, development and •! Management of non TesLng funcLonal requirements •! Architecture collaboraon •! Quality assurance Brown 2010 Copyright © 2011 Philippe Kruchten 43 Two styles of soYware/system architects •! Maker and Keeper of Big •! Mentor, Troubleshooter, decisions and Prototyper –! Bring in technological –! Implements and try changes architecture –! External collaboraon
Load more

Recommended publications
  • Software Architecture and Agility
    Agility and Architecture May 18 2010 Agility and Architecture: An Oxymoron? Philippe Kruchten Saturn May 18, 2010 Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of BriIsh Columbia Vancouver, BC Canada [email protected] Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected] Philippe Kruchten 1 Agility and Architecture May 18 2010 Agile & Architecture? Oil & Water? • Paradox • Oxymoron • Conflict • IncompaIbility Outline • Agility?? • SoSware architecture? • A story • Seven viewpoints on a single problem • The zipper model • A clash of two cultures • Summary Philippe Kruchten 2 Agility and Architecture May 18 2010 Agility • A definiIon – Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Jim Highsmith (2002) • CharacterisIcs – IteraIve and incremental – Small release – Collocaon – Release plan/ feature backlog – IteraIon plan/task backlog Sanjiv AugusIne (2004) Agile Values: the Agile Manifesto We have come to value: • Individuals and interacIons over process and tools, • Working soSware over comprehensive documents, • Customer collaboraIon over contract negoIaIon, • Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the leS more Source: hp://www.agilemanifesto.org/ Philippe Kruchten 3 Agility and Architecture May 18 2010 Geng at the Essence of Agility • SoSware development is a knowledge acIvity – Not producIon, manufacturing, administraIon… • The “machines” are humans • Dealing with uncertainty, unknowns, fear, distrust • Feedback loop -> – reflect on business, requirements, risks, process, people, technology • CommunicaIon and collaboraIon -> – Building trust Named Agile Methods • XP = eXtreme Programming (K.
    [Show full text]
  • Reflections on Software Architecture Linda Northrop SEI Fellow
    Reflections on Software Architecture Linda Northrop SEI Fellow Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 © 2016 Carnegie Mellon University Distribution Statement A: Approved for Public Release; Distribution is Unlimited Notices Copyright 2016 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University.
    [Show full text]
  • Kruchten Frog Octopus JSS V6
    Paper submitted to the Journal of Software and Systems, July 2011, resubmitted November 2011. The frog and the octopus: a conceptual model of software development Philippe Kruchten University of British Columbia 2332 Main Mall Vancouver BC V6N2T9 Canada email: [email protected] phone: +1 (604) 827-5654 fax: +1 (604) 822-5949 Abstract We propose a conceptual model of software development that encompasses all approaches: traditional or agile, light and heavy, for large and small development efforts. The model identifies both the common aspects in all software development, i.e., elements found in some form or another in each and every software development project (Intent, Product, People, Work, Time, Quality, Risk, Cost, Value), as well as the variable part, i.e., the main factors that cause the very wide variations we can find in the software development world (Size, Age, Criticality, Architecture stability, Business model, Governance, Rate of change, Geographic distribution). We show how the model can be used as an explanatory theory of software development, as a tool for analysis of practices, techniques, processes, as the basis for curriculum design or for software process adoption and improvement, and to support empirical research on software development methods. This model is also proposed as a way to depolarize the debate on agile methods versus the rest-of-the-world: a unified model. Keywords: software development, conceptual model, ontology, method, software development process, software engineering, theory Visual abstract for JSS: !"#$%& !"#$%& '()*& '()*& Alternate visual abstract for JSS: Authorʼs bio: Philippe Kruchten is professor of software engineering at the University of British Columbia, Vancouver, Canada.
    [Show full text]
  • Understanding Architectural Assets
    ® IBM Software Group Understanding Architectural Assets Peter Eeles [email protected] © 2008 IBM Corporation IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 2 IBM Software Group | Rational software Inputs into this Presentation Working IEEE/IFIP Conference on Software Architecture (WICSA) 2008 18 – 22 February 2008, Vancouver, BC, Canada Working session: Architectural Knowledge IBM Asset Architecture Board Reusable Asset Specification Rational Asset Manager RUP for Asset-based Development © 2006 Tourism Vancouver 3 IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 4 IBM Software Group | Rational software Sources of Architecture Theft From a previous system or from technical literature Method An approach to deriving the architecture from the requirements Intuition The experience of the architect From “Mommy, Where Do Software Architectures Come From?”, Philippe Kruchten 1st International Workshop on Architectures for Software Systems, Seattle, 1995 5 IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 6 IBM Software Group | Rational software What Types of Architectural Asset are there? Reference Design Architecture
    [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]
  • The Past, Present, and Future for Software Architecture
    focusguest editors’ introduction The Past, Present, and Future of Software Architecture Philippe Kruchten, University of British Columbia Henk Obbink, Philips Research Europe Judith Stafford, Tufts University his special issue celebrates 10 years of software architecture con- ferences and workshops and the 10th anniversary of the first IEEE Software special issue on the topic in November 1995. We T aim to address the latest thinking about creating, capturing, and 22 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/06/$20.00 © 2006 IEEE using software architecture throughout a soft- ■ Representation: How do we produce ware system’s life. The articles we’ve chosen durable artifacts to communicate architec- cover innovative methods and techniques ture to humans or machines? The concept emerging from research to support software ■ Economics: What architectural issues drive architecture practice. They also emphasize the business decisions? of software methods, techniques, tools, and software engi- architecture neering principles that support organizations And certainly software architecture is tied as a distinct taking an architecture-centric approach to closely to other disciplines and communities, software development. such as software design (in general), software discipline reuse, systems engineering and system architec- started to What is software architecture? ture, enterprise architecture, reverse engineer- Software architecture involves ing, requirements engineering, and quality. emerge in 1990. ■ the structure and organization by which A brief history of software modern system components and subsys- architecture tems interact to form systems, and Looking back in time will help us position ■ the properties of systems that can best be software architecture’s current status and future designed and analyzed at the system level.
    [Show full text]
  • An Analysis on Waterfall and RUP Models
    Journal of Engineering, Computing and Architecture ISSN NO: 1934-7197 An Analysis on Waterfall and RUP Models Dr. K. Sunil Manohar Reddy Associate Professor, Department of CSE, Matrusri Engineering College, Hyderabad, Telangana. [email protected] Abstract: Two of the vastly used software engineering processes are Waterfall model and Rational Unified Process (RUP) model. The waterfall model is a classical model of software engineering. It is used in governmental projects as well as many major companies associated with software engineering. RUP is a unified model used for large business applications. The main concern in this research is to represent the mentioned models of software development and compare them to show pros and cons of each model. Keywords: Waterfall Model, Unified Process Model, Agile Models 1. Introduction Computer is considered as a time saving mechanism and its progress helps in executing long, complex, repeated processes at a high speed and short time. Noticeably, the number of companies that produce software programs for the purpose of facilitating works of offices, administrations, banks, etc., has increased recently which results in the difficulty of enumerating such companies. During the last five decades, software has been developed from a tool used for solving a problem to a product in itself. Software consists of instructions and programs that contain a collection that has been established to be a part of software engineering procedures [1]. Moreover, the aim of software engineering is to create a suitable work
    [Show full text]
  • Nato Architecture Framework (Naf)
    NATO ARCHITECTURE FRAMEWORK Version 4 Architecture Capability Team Consultation, Command & Control Board January 2018 Acknowledgments for NAFv4 Publication Throughout the development of version 4 of this publication numerous individual experts of NATO Nations participated, resulting in this significant achievement: The realization of the NATO Architecture Framework. This work would not have been possible without the continuous support of the Ministries of Defence of United Kingdom and France, and the NATO Science and Technology Organization. Also special thanks goes to Partner Nations and Industry Partners for their unwavering support in assigning and providing their best professional resources in the architecture domain. The NATO Architecture Framework is a substantial achievement for the Architecture Capability Team under the Consultation, Command and Control Board. Each member of the Architecture Capability Team worked determinedly over the last four years to provide extensive professional guidance and personal effort in the development of this product. The Architecture Capability Team is grateful to all for their contributions to this effort. 4 NAFv4 NAFv4 5 CONTENTS Chapter 1 - Introduction 1 GENERAL ....................................................................................................................................................................... 11 1.1 Purpose ........................................................................................................................................................................
    [Show full text]
  • The Waterfall Model – What It Is Not and Has Never Been
    The Waterfall Model – What It Is Not and Has Never Been Dr. Peter Hantos The Aerospace Corporation 14th Annual NDIA Systems Engineering Conference, San Diego, California October 24-27, 2011 1 © The Aerospace Corporation 2011 Acknowledgements • This work would not have been possible without the following: – Reviewers • Asya Campbell • Suellen Eslinger • Zane Faught • Leslie Holloway – Funding Source • The Aerospace Corporation’s Sustained Experimentation & Research Program 2 Outline • Motivation • Parsing the Title • The Canonical Waterfall Model • Model Characterization • What Does the Waterfall Life Cycle Really Look Like? • Clarifying the Model’s Intent • “Hidden” Concurrency in the Waterfall • Incremental Integration and Pair-wise Testing • Scaling • Conclusion • Acronyms • References 3 Motivation • Your first reaction might be “Why are we talking about the waterfall? I thought that the Waterfall was dead” – Indeed, since the Waterfall model was published, the literature has been full with critiques and proposals for alternative processes, most recently Agile Development • However, a substantial percentage of waterfall project failures can be attributed to lack of understanding of some fundamental issues, issues that are also present when modern methodologies are used – Ignoring such issues will lead to project failure, regardless of the methodology that is used • Also, the waterfall (or, a “mini” waterfall) is still an essential building block of all the more complex life cycle models, such as incremental, evolutionary, spiral, or
    [Show full text]
  • Applying 4+1 View Architecture with UML 2 White Paper Copyright ©2007 FCGSS, All Rights Reserved
    Applying 4+1 View Architecture with UML 2 White Paper Copyright ©2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was released in 2004, building on an already successful UML 1.x standard. UML 2 comes with 13 basic diagram types to support Model Driven Architecture (MDA) and Model Driven Development (MDD). Philippe Kruchten originally presented the 4+1 View Model to describe the architecture of software-intensive systems. This approach uses multiple views to separate stakeholders’ concerns. The 4+1 View Approach is widely accepted by the software industry to represent application architecture blueprints. However, the industry has not yet completely embraced UML 2. IT architects are continuing with UML 1.x artifacts to represent architecture and are consequently missing out on the powerful benefits of the improvements made in UML 2. This article presents the approach for 4+1 View Architecture using UML 2 diagrams. It enhances the original concept of the approach using the current modeling standards and techniques, and aims to encourage Application Architects to adapt relevant UML 2 artifacts. This article discusses each of the views and allocates the UML 2 diagrams to these views. It does not, however, teach semantics and modeling using UML 2 notations. The audience is expected to have a basic understanding of UML and to be able to refer to UML 2 for further details. UML 2 Diagrams Let us briefly review the diagrams available in UML 2 Specification. UML 2 Superstructure Specification divides the 13 basic diagram types into two key categories: • Part I – Structural Diagrams: These diagrams are used to define static architecture.
    [Show full text]
  • Architectural Blueprints—The “4+1” View Model of Software Architecture
    Paper published in IEEE Software 12 (6) November 1995, pp. 42-50 Architectural Blueprints—The “4+1” View Model of Software Architecture Philippe Kruchten Rational Software Corp. 638-650 West 41st Avenue Vancouver, B.C., V5Z 2M9 Canada [email protected] Abstract This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various ‘stakeholders’ of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenario- driven, iterative development process. Keywords: software architecture, view, object-oriented design, software development process Introduction We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of functionality? Are the arrows representing compilation dependencies? Or control flows? Or data flows? Usually it is a bit of everything. Does an architecture need a single architectural style? Sometimes the architecture of the software suffers scars from a system design that went too far into prematurely partitioning the software, or from an over-emphasis on one aspect of software development: data engineering, or run-time efficiency, or development strategy and team organization.
    [Show full text]
  • Object-Oriented Analysis and Design (OOA/D)
    Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN The shift of focus (to patterns) will have a profound and enduring effect on the way we write programs. —Ward Cunningham and Ralph Johnson Objectives • Compare and contrast analysis and design. • Define object-oriented analysis and design (OOA/D). • Illustrate a brief example. 1.1 Applying UML and Patterns in OOA/D What does it mean to have a good object design? This book is a tool to help devel- opers and students learn core skills in object-oriented analysis and design (OOA/D). These skills are essential for the creation of well-designed, robust, and maintainable software using object technologies and languages such as Java, C++, Smalltalk, and C#. The proverb "owning a hammer doesn't make one an architect" is especially true with respect to object technology. Knowing an object-oriented language (such as Java) is a necessary but insufficient first step to create object systems. Knowing how to "think in objects" is also critical. This is an This is an introduction to OOA/D while applying the Unified Modeling Lan- introduction guage (UML), patterns, and the Unified Process. It is not meant as an advanced text; it emphasizes mastery of the fundamentals, such as how to assign respon- sibilities to objects, frequently used UML notation, and common design pat- 1 - OBJECT-ORIENTED ANALYSIS AND DESIGN terns. At the same time, primarily in later chapters, the material progresses to a few intermediate-level topics, such as framework design. Applying UML The book is not just about the UML. The UML is a standard diagramming nota- tion.
    [Show full text]