DII-AF Chief Architects Office. The Architect s Job. 6 June 1997 Rich Hilliard (v 2.0)

Transcription

1 1 The Architect s Job 6 June 1997 Rich Hilliard (v 2.0)

2 2 Acknowledgements This briefing has been evolving since The original version was called Dick & Jane and was created by Jeff Hustad, David Emery for Army SBIS. Tim Rice and Kevin Heideman contributed to DISA Dick & Jane in 1996 which added the results on the SBIS Architecture. Subsequent versions added details on MITRE s work on Architecture Quality Assessment, and the Architecture Description Framework. The latest versions start to define the major activities that the Architect engages in and the activities needed to support that. Jim Moore, Eric Skoog, Jerry Friedman, David Emery all offered comments on this version.

3 3 Outline What is architecture? Why have architects? What does the architect do? What does the architect need to do his job? MITRE s work in architecture

4 4 Why Architecture? Explicitly architected systems seem to turn out faster, better and cheaper Separation of concerns: - Essential system characteristics - Multiple system stakeholders - Separate long-term goals, and evolution from immediate construction concerns - Current systems are contractor-architected! Not incentivized for the long-term! Limited client (buyer) flexibility! Narrows marketplace for mission functionality Architecture as response to failure of the waterfall to address non-user, non-functional requirements of other stakeholders

5 5 What is Architecture? An architecture is the highest-level concept of a system in its environment - IEEE Architecture Working Group An architectural description is a model of the structure and behavior of the whole system - It shows how the system fulfills the needs in the context of its environment - It identifies major system components, their interconnections and dependencies, and the limits within which they must operate

6 6 The Architect s Domain (I): Roles Users Client Testers Architect Program Manager Maintainers Operators Chief Engineer Developers Installers reporting-to and influences relations

7 7 The Architect s Domain (II): Products Policies Vision Available Funding Technology Trends Legacy Systems Goals Needs Architecture... n Design 3 2 Design Design Design 1 Emerging Open Stds System Requirements Detailed Requirements Operational Requirements Life cycle Phases Requirements & Concepts Architecture Design & Implementation

8 8 Characteristics of Architect s Job The ideal architect should be a man of letters, a skillful draftsman, a mathematician, familiar with historical studies, a diligent student of philosophy, aquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. Vitruvius, De Architectura (25 BC) Client-centered - Architect works for the client Systems orientation: bridging problem definition and solution conceptualization - Architect s job is to understand client s needs to produce one or more models (potential solutions)

9 9 Characteristics of Architect s Job (continued) Model-based - Architect then works with engineer - Engineer s job is to design and implement architect s model Certification of construction - Architect oversees construction, ensuring actual implementation meets design Determines acceptance of built system

10 10 Characteristics of Architect s Job (concluded) Multidisciplinary Synthesis: technical, programmatic, managerial - Artistic, Heuristic No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder. John Ruskin, Lectures on Architecture and Painting (1853)

11 Activities and Definitions: Architect a System (context) 11 client and other system stakeholder priorities known requirements Architect a System* architectural standards architectural specifications building permits and certificates A0 * Where system ranges over: individual applications, usual programs, product families, product lines, systems of systems or the whole enterprise.

12 Activities and Definitions: Architect a System 12 formal reqts I1 C1 client and stakeholder priorities Understand Needs and Environment A1 needs, goals and vision community standards: JTA, DII COE, etc. Devise Architectural Concepts A2 architectural rules O1 appropriate technologies Produce Engineering Views architectural specifications O2 A3 design artifacts and built system Oversee Construction A4 O3 approvals to proceed, system acceptance

13 13 Architectural Description An architecture is documented as a model A model is comprised of one or more views - A view represents the whole system to focus on one or more critical concerns - Support multiple audiences each with their own concerns - Reduce perceived complexity through separation of concerns

14 Activities and Definitions: Produce Engineering Views C1 C2 14 predefined views Define Views critical stakeholder concerns, programmatic and technical issues architectural rules architectural standards and constraints 1 I1 architectural concepts Analyze Each View documented engineering views O1 2 inconsistencies Check View Consistency inter-view links 3 open issues Verify Satisfaction of Needs & Constraints 4 needs, goals vision traceability matrix

15 15 Some Typical Views functional, activity views [ICAM, Sowa] data, data flow, information views [Druffel94, Gacek95] static views [Kruchten95, Gacek95] logical views [Kruchten95, Moriconi] behavioral, dynamic, operational views [Luckham95a, Kruchten95, TAFIM] development, maintenance views [Boehm, MITRE96] distributed, network views [Sowa, MITRE95] physical views [Kruchten95, TAFIM]

16 16 Principles of Views Each view presents the whole system from a chosen viewpoint - Complete relative to that viewpoint - Consistent with respect to other views Each view is modeled in terms of components, connections and constraints (governed by a meta model ) Views are linked to increase understanding, consistency and completeness

17 17 Example: Application View Presentation Motif or MS Windows User Interface API, Style Guide Application API, Logical Data Model Data Access SQL, Physical Data Model, RDA Data Storage Presents Information XVT Prepares Information Ada Transforms Information Ada, XDR, IDL Stores/Retrieves Information RDBMS, File System, OLTP Maintains Information Component Connection legend Component Function Connection Technology

18 18 Example: Data View DOD Enterprise Data Model DOD Data Dictionary Unified Data Model IRDS Repository ERA Diagrams (IDEF1X format) <- ERA Diagrams (IDEF1X format) -> Logical Data Models Common Reference Data Model Application Data Models COTS/GOTS Data Models Legacy Data Models SQL ICD Interface Data Stores Integrated Database Legacy

19 19 Example: Distribution View Force XXI Server Database In Garrison Application distribution via Remote Procedure Call Intelligent PCs Remote Data distribution via OLTP accessing split data Server Database... Deployed Split Base

20 20 Example: Security View Operational Security Security Procedures I&A Fortezza Network Security Encryption Least Privilege LAN Switch Routers Apps Hubs Secure RPC Data Stores

21 21 Example: Developer-Maintainer View (partial) source documents system requirements capture and edit system performance modeling system requirements system requirements traces to requirements HW, SW components threads behaviors system threads system component ID and allocation system requirements software performance modeling legacy system considerations legacy systems software threads software components from Distributed View from Data View legacy software and DBMS components considerations software requirements definition software legacy S/W software threads SW requirements components threads software top-level design behaviors to Detailed Design to Testing

22 22 Supporting Activities (Mechanisms) Operational modeling Doctrine and strategic studies Financial planning and analysis, ROI Requirements analysis Simulation Ergonomics, time-motion studies Prototyping Enabling technology studies: e.g., messaging, image processing, information retrieval, multimedia Formal Specification Design and implementation techniques and methods

23 23 Supporting Activities (Mechanisms) Collaboration Self-criticism and architectural assessment Project development and management Planning and scheduling Process Contracting Design reviews, inspections and audits Compliance, conformance testing and analysis Quality assurance

24 24 Organizing Architects Where do architects and designers get their ideas? The answer, of course, is mainly from other architects and designers, so is it mere casuistry to distinguish between tradition and plagiarism? Stephen Bayley, Commerce and Culture (1989) Participative/collaborative: the critique is an essential ingredient in real firms The architecture firm Methods: heuristic, patterns, reuse of solutions, experience base Tools: Creating, Assessment, Delivery, Certification Not a consulting firm

25 25 Community Support What help can we get from outside organizations? - DII-AF - DII COE - Product Lines Architectural Standards - DISA, CISA, JTA, ISO, IEEE - Standards are a support and also a constraint

26 If Architecture were Software... Architectural Maturity Model Level 0: Briefware (Total Chaos) - adjective architecture - cartoons and clip art Level 1: Developer-centric (Initial) - Yesterday s CASE techniques (IDEF, RDD-100, Teamwork) now with architecture in the model names - Ad hoc coordination between programs - Overemphasis on structural aspects:! CSCIs, modules, classes,...! e.g., Garlan and Shaw on software architecture 26

27 If Architecture were Software... Architectural Maturity Model Level 2: Master Builder (Repeatable) - Distinct Architect / Developer roles - Recognition of multiple stakeholders of a system! and techniques for addressing their diverse needs Level 3: Self-Awareness (Defined) - Recognition of architectural discipline! Distinct from systems and software engineering! Means to create and contract for architectural specifications - e.g., Rechtin and Maier 27

28 If Architecture were Software... Architectural Maturity Model Level 4: Architect Firms (Managed) - Architects organized to support their discipline - Tools to support that discipline - Independent analysis of delivered architectural specifications Level 5: Pre-fab construction (Optimizing) - Architectures as real engineering objects - True separation of architectural specification from system implementation - Architectural evolution to support technology insertion 28

29 The Architectural Metaphor: Implications for Systems Engineering Systems are situated in their environments Inherently multi-viewpointed - no essential or correct single view The architect is one actor mediating among - client, users and other stakeholders - developers, vendors, maintainers What s important are the descriptions Descriptions can be unified with appropriate meta model - One set of rendering primitives with open semantics dependent on the view 29

30 30 Our Work Technical foundations of software systems architecture - DARPA Domain-Specific Software Architecture C 2 Reference Model (1990) Practical Architecture Method - WCCS Force-level study (1992) - Sustaining Base Information Services (1994) - Army Reserve Component Automation System (1995) - Missile Warning Laptop (1996) - Theater Battle Management Core Systems (ongoing) Architecture Quality Assessment (AQA) ( ) Architecture Description Framework (1997- ) Standardization: IEEE Architecture Working Group ( )

31 Architecture Quality Assessment: Goals Repeatable method yielding objective results - Evaluation based on documentation, not hearsay Based on open sources - Architects will know the criteria on which architectures will be judged - Availability of the criteria may improve overall quality Independent from life cycle, documentation, methodology - Cannot assume traditional deliverables and milestones - No widely accepted architectural methods - Don t assume a Contractor is the Architect 31

32 Architecture Quality Assessment: Uses of an AQA Evaluate a candidate (proposed) architecture Review technical progress during ongoing architecture development Assess a complete, delivered architecture prior to acceptance/implementation Compare two or more architectures in a consistent fashion 32

33 33 Status: Architecture Quality Assessment (AQA) Several partial uses - FAA STARS acquisition - National Missile Defense - C2IPS Transition to TBMCS Identified by C 2 Chief Architects Council for use in Architect s Toolkit Paper in MITRE s Software Engineering & Economics Conference (April 1997)

34 34 Architecture Description Framework (ADF) Premise: To move architecture from buzzword to engineering practice, we need techniques for architectural description Develop automation base for representing, manipulating, and analyzing architectural models - Allow information sharing between tools - Provide a semantically rich delivery format (e.g., between Contractors and Government) Demonstrate industrial-strength basis for architectural description Status: Phase 1 (6 months) funded as MSR

35 35 The Challenge Despite current interest in architecture - No solid foundations for architectural description and specification Our Contractors use off-the-shelf tools to produce architectural deliverables - IDEF, RDD-100, UML, OMT,... Meanwhile, research community is developing next-generation architecture description languages - Rapide, Wright, Dicam, UniCon, ArTek, ACME, FR, MetaH, Gestalt, Resolve,...

36 36 ADF Concept of Operations ADF Services Core Semantics Working Info Traceability Analysis Presentation/Layout Import/Export Adapters Rapide Excel Browser ManSART AQAtool IMPS RDD-100 IDEF 0,1 Architecture Description Framework Catalyst Object Request Broker Doors HTML, VRML

37 37 ADF Schedule Phase 1: Phase 2: Phase 3: Design ADF Small Experiments TBMCS trial use IDL Implementation Host to Catalyst Integrate with Architecture Quality Assessment Provide to IEEE 6 (months) 12 18

38 38 Community Outreach IEEE Architecture Working Group - Design phase leading to! Recommended Practice for Architectural Description soft-sys-arch@spectre.mitre.org - Internet discussion list for architecture issues

39 39 References R. Hilliard, Representing Software Systems Architectures or, Components, Connections, and (why not?), first-class Constraints and Views. Proceedings of the SIGSOFT 96 2nd International Workshop on the Architecture of Software Systems, October 15-16, 1996, San Francisco. D. Emery, R. Hilliard, T. Rice, Experiences Applying a Practical Architectural Method. In Reliable Software Technologies - Ada Europe 96, Alfred Strohmeier (editor), Springer-Verlag, Lecture Notes in Computer Science, volume R. Hilliard, Architectural View Selection, ESC Second Architecture Technical Interchange Meeting, Gunter AFB, 5 December S. Schwarm, T. Rice, R. Hilliard, The Architectural Metaphor as a Foundation for Systems Engineering. Proceedings INCOSE 96 Symposium. D. Emery and R. Hilliard, Architecture, methods and open issues. Proceedings First International Workshop on Software Architectures, Seattle, WA, April

40 40 References (Concluded) R. Hilliard, On The Notion of Architecture in Model-Based Software Engineering. Proceedings DARPA Workshop on Domain-Specific Software Architectures, Hidden Valley, PA, W. Ellis, R. Hilliard, P. Poon, D. Rayford, T. Saunders, B. Sherlund and R. Wade, Toward a Recommended Practice for Architectural Description. Proceedings of 2nd IEEE International Conference on Engineering of Complex Computer Systems, Montreal, 1996.