Moving from 4+1 to the 5+2 View Modeling of Architecture: Ulcmsm Views As Extensions of Architectural Views
ACE4 Working Group Session, March 29, 2006
Moving from 4+1 to the 5+2 View Modeling of Architecture: ULCMsm Views as Extensions of Architectural Views
Dr. Peter Hantos The Aerospace Corporation
© 2003-2006. The Aerospace Corporation. All Rights Reserved. Acknowledgements
• This work would not have been possible without the following: Feedback – Dr. Sergio Alvarado, Software Architecture & Engineering Department – Suellen Eslinger, Software Engineering & Acquisition Subdivision – Dr. Leslie J. Holloway, Software Acquisition and Process Department Funding source – The Aerospace Corporation Independent Research & Development (IR&D) Program
GSAW/ACE4 2006 – Peter Hantos Slide 1-2 Agenda
• Problem/Goal/Objectives • The 4+1 View Model of Software Architecture • Evolution of Architecture Artifacts in Iterative Development Snapshots of views associated with architecture evolution Concurrent development of artifacts in Iterative Development • Unified Life Cycle Modeling (ULCMsm) ULCM – The 10,000-foot view The Spiral Model’s ULCM generator view using UML activity diagrams ULCM enactment view of pre-planned increments • Integrating the Views - A Little “View Algebra” • Conclusions • Acronyms • References • Backup Slides
______® UML is registered in the U.S. Patent and Trademark Office by the OMG sm ULCM is Service Mark of The Aerospace Corporation GSAW/ACE4 2006 – Peter Hantos Slide 1-3 Problem Statement
• Process Architecting is not well aligned with System and Software Architecting Separately and together they are high-leverage activities of acquisition and development Alignment would result in – Earlier identification and better management of problems – Ultimately, reduced life cycle cost
GSAW/ACE4 2006 – Peter Hantos Slide 1-4 Presentation Goal and Objectives
• Goal Show a key aspect of synergy between Architecture Views and Unified Life Cycle Modeling (ULCM) Views • Objectives Review how Architecture Views evolve during acquisition and development Present ULCM Views* Integrate ULCM Views with P. Kruchten’s 4+1 View Model of Architecture**
______Sources: * (Hantos 2005), (Hantos 2006) ** (Kruchten 1995) GSAW/ACE4 2006 – Peter Hantos Slide 1-5 The 4+1 View Model of Software Architecture
LOGICAL IMPLEMENTATION VIEW VIEW
USE CASE VIEW
PROCESS DEPLOYMENT VIEW VIEW
VIEW* DETAIL STAKEHOLDERS COMMENTS LOGICAL Subsystems, End User Functionality Classes
IMPLEMENTATION Components, Developer, Used to be called Packaging, Project Manager Development Layering View DEPLOYMENT Topology, System Engineer Used to be called Mapping to Physical Platforms View PROCESS Performance, System Integrator It is a Computer Throughput, Engineering Concurrency term USE CASE Architecture Analyst, Sometimes Discovery, Tester called View Validation Scenarios ______* Diagram and view names based on (Kruchten 1998). The author apparently instituted some name changes for selected views since the first publication (See Kruchten 1995). GSAW/ACE4 2006 – Peter Hantos Slide 1-6 Challenging Booch …
• “The 4+1 view model has proven to be both necessary and sufficient for most interesting systems” --- Grady Booch, IBM Fellow Implicit Temporal Notion*
LOGICAL IMPLEMENTATION VIEW VIEW
USE CASE VIEW
PROCESS DEPLOYMENT VIEW VIEW
ThisThis implicit implicit temporal temporal notion notion does does not not reflect reflect the the complete complete dynamics dynamics ______* Emphasis by Hantos GSAW/ACE4 2006 – Peter Hantos Slide 1-7 Snapshots of Views Associated With Architecture Evolution
Development Milestones (Anchor Points)
LOGICAL IMPLEMENTATION LOGICAL IMPLEMENTATION LOGICAL IMPLEMENTATION VIEW VIEW VIEW VIEW VIEW VIEW
USE CASE USE CASE … USE CASE VIEW VIEW VIEW
PROCESS DEPLOYMENT PROCESS DEPLOYMENT PROCESS DEPLOYMENT VIEW VIEW VIEW VIEW VIEW VIEW
Time
ArchitectureArchitecture evolution evolution is is reflected reflected in in view view evolution evolution
GSAW/ACE4 2006 – Peter Hantos Slide 1-8 Concurrent Development of Artifacts in Iterative Development
Selected Artifacts
Use Cases
Class Diagrams
Deployment Diagrams
Activity & State Diagrams
Package Diagrams
Code 0% 100% Effort % Legend: 1st Cycle 2nd Cycle 3rd Cycle
GSAW/ACE4 2006 – Peter Hantos Slide 1-9 ULCM – The 10,000-Foot View
• ULCM is a highly intuitive, pattern-based approach for specifying, constructing, visualizing and documenting the life cycle processes of software-intensive system development • ULCM aspires to be the “Occam’s Razor” of Life Cycle Modeling The medieval rule of parsimony: “Plurality shouldn’t be assumed without necessity” – William of Ockham, 14th century philosopher The LCM rule of parsimony: All Life Cycle Models are constructs or derivatives of 4 basic LCM patterns • ULCM defines two views of life cycle models Generator View – Algorithmic and sequencing aspects Enactment View – Temporal or trace dimension
GSAW/ACE4 2006 – Peter Hantos Slide 1-10 The Spiral Model’s ULCM Generator View Using UML Activity Diagrams
(Increment) Release Anchor Point Implementation Cycles Cycles (Iteration) Cycles Cumulative cost Progress through steps Determine Evaluate alternatives, objectives, identify, resolve risks alternatives, Risk constraints analysis Risk Determine Determine Determine analysis Objectives Objectives Objectives Risk analysis Operational Risk Prototype prototype analy- Proto- 3 Prototype2 Determine Determine Determine Commitment sis type1 Review Alternatives/Constraints Alternatives/Constraints Alternatives/Constraints partition Requirements plan Simulations, models, benchmarks life-cycle plan Concept of operation Software requirements Detailed design Risk Risk Risk Development Requirements Software plan validation product Analysis Analysis Analysis design Code Unit Integration test Design validation and test and verification Integration plan and test Acceptance Risk Risk Risk test Resolution Resolution Resolution Implementation Develop, verify Plan next phases next-level product
Risk-Based Risk-Based Risk-Based Decisions ¿ Decisions ¿ Decisions ¿ Boehm’s Spiral Diagram* Develop, Verify Develop, Verify Develop, Verify Next Level of Product ¿ Next Level of Product ¿ Next Level of Product ¿
Plan Plan Plan Next Phases ¿ Next Phases ¿ Next Phases ¿
Conduct Conduct Conduct Review Review Review
YES YES YES Commitment? Commitment? Commitment?
NO NO NO
ViewView shows shows activity activity sequencing sequencing and and concurrency concurrency details details of of increments increments ______Sources: * Spiral Diagram: (Boehm 1988) ** Nested Spirals: (Hantos 2006) GSAW/ACE4 2006 – Peter Hantos Slide 1-11 ULCM Enactment View of Pre-planned Increments
LOGICAL IMPLEMENTATION LOGICAL IMPLEMENTATION LOGICAL IMPLEMENTATION LOGICAL IMPLEMENTATION VIEW VIEW VIEW VIEW VIEW VIEW VIEW VIEW
USE CASE USE CASE USE CASE USE CASE VIEW VIEW VIEW VIEW
PROCESS DEPLOYMENT PROCESS DEPLOYMENT PROCESS DEPLOYMENT PROCESS DEPLOYMENT VIEW VIEW VIEW VIEW VIEW VIEW VIEW VIEW
System
Increment1
Increment2
Increment3 Potential Evolutionary Increment4 Increment
Increment5
ViewView shows shows temporal temporal dimension: dimension: timing,timing, duration, duration, and and synchronization synchronization of of increments increments
GSAW/ACE4 2006 – Peter Hantos Slide 1-12 Integrating the Views - A Little “View Algebra”
• Why is Kruchten’s Model called the 4+1 View Model? The first 4 views are independent Use Cases of the 5th view cross-cut across the other views – Initially used for discovery and design the architecture – Later they can be used to validate the integrity of the views • How would ULCM Views fit into this structure? The Generator View would be a 5th, independent view The Enactment View has an overarching function – As such, it should belong to the “+” category, similarly to the Use Case View • And the result is: 5+25+2 ViewView ModelModel
GSAW/ACE4 2006 – Peter Hantos Slide 1-13 Conclusions
• Architectural View Models are not static during the acquisition and development life cycle • Life Cycle Models are key in ensuring the synergy across Architecture Evolution, Elaboration, and Evaluation • In view modeling ensuring integrity across views is critical The solution is to use overarching, cross-cutting views • Using ULCM ensures the consistent level of modeling formality of architecture and life cycle models The use of these views could provide direct help to our SMC/NRO customers in implementing the guidelines of the current Software Development Standard for Space Systems (Adams 2005)
GSAW/ACE4 2006 – Peter Hantos Slide 1-14 Acronyms
DBMS Data Base Management System IEEE Institute of Electrical and Electronics Engineers IR&D Independent Research & Development OMG Object Management Group TCP/IP Transmission Control Protocol/Internet Protocol ULCM Unified Life Cycle Modeling UML Unified Modeling Language
GSAW/ACE4 2006 – Peter Hantos Slide 1-15 References
Adams, R.J., et al, Software Development Standard for Space Systems, TOR-2004(3909)-3537, Revision B Boehm, B. W., A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1998 Hantos, P., Unified Life Cycle Modeling Tutorial, INCOSE 2005, Rochester, New York, July 2005 Hantos, P., Interpreting the Spiral Model of Software-Intensive System Development – A ULCMSM Approach, CSER 2006, Los Angeles, California, April 2006 (To be published) Kruchten, P. B., The 4+1 View Model of Architecture, IEEE Software, November 1995 Kruchten, P.B., The Rational Unified Process An Introduction, Addison-Wesley, 1998
GSAW/ACE4 2006 – Peter Hantos Slide 1-16 Backup Slides Logical and Implementation View Examples
Components of Implementation 1 System Design Model Implementation Model objects compilation <
Components of Implementation 2 Components of Implementation 3
Design Model Implementation Model Design Model Implementation Model objects compilation objects compilation <
GSAW/ACE4 2006 – Peter Hantos Slide 1-18 Packages and Layers Example for Implementation 3
ClientClient Application-specific layer
Application-general layer Screens Computations Reports
Java Java Virtual Middleware layer Applet Machine
System-software layer TCP/IP
GSAW/ACE4 2006 – Peter Hantos Slide 1-19 Deployment Views: Evaluating Deployment Options
Deployment of Implementation 2 Using Multiple PCs Deployment of Implementation 3 Using One PC
Server Single Windows PC Multiple Windows PCs :Computations :Screens Server
:Reporting :Computations :DBMS
:Screens :DBMS :Reporting TCP/IP
TCP/IP TCP/IP TCP/IP
Deployment of Implementation 3 Using Deployment of Implementation 3 on Multiple PCs Distributed Servers
Windows PCs Single Windows PC Distributed Servers
:Screens Server :Screens :DBMS :DBMS :Computations :DBMS :Computations :DBMS
:Reporting :Reporting TCP/IP TCP/IP
TCP/IP TCP/IP
GSAW/ACE4 2006 – Peter Hantos Slide 1-20 Boehm’s Spiral Model
Cumulative cost Progress through steps Determine Evaluate alternatives, objectives, identify, resolve risks alternatives, Risk constraints analysis Risk analysis Risk analysis Operational Risk Prototype3 prototype analy- Proto- Prototype2 Commitment sis type1 Review partition Requirements plan Simulations, models, benchmarks life-cycle plan Concept of operation Software requirements Detailed design Development Requirements Software plan validation product design Code Unit Integration test Design validation and test and verification Integration plan and test Acceptance test Implementation Develop, verify Plan next phases next-level product
GSAW/ACE4 2006 – Peter Hantos Slide 1-21 Increment Planning Example with Risk-based Considerations
<< server >> 3 Increment1
<< client >> << interface >> << server >> << client >> << interface >> << server >> 1 2 4 test 2 test
<< server >> 5
<< server >> Increment2 Increment3 3
<< client >> << interface >> << server >> << client >> << interface >> 1 2 test 1 2
GSAW/ACE4 2006 – Peter Hantos Slide 1-22 Software Development Standard for Space Systems
Relevant references from the Standard: 5.6 Software design “… if the system is developed in multiple builds, its design may not be fully defined until the final build. Software design in each build is interpreted to mean the design necessary to meet the software item requirements to be implemented in that build” G.3 Scheduling deliverables “To the maximum extent possible … leaving the door open for incremental delivery of software products, staggered development of software items…” 5.18.2 Joint management reviews “The developer shall plan and take part in joint management reviews…” Appendix E: Candidate joint management reviews E.3.4b “The architectural design of the system/segment/…” E.3.6b “The architectural design of a software item”
GSAW/ACE4 2006 – Peter Hantos Slide 1-23 All trademarks, service marks, and trade names are the property of their respective owners
GSAW/ACE4 2006 – Peter Hantos Slide 1-24