Software Architecture and the UML Grady Booch Walker
Software Architecture and the UML Grady Booch
Walker Royce Dimensions of software complexity Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance An average software project: - 5 -10 people - 10 -15 month duration - 3 -5 external interfaces - Some unknowns & risks Lower management complexity - Small scale - Informal - Single stakeholder - “Products” Telecom Switch Commercial Embedded Compiler Automotive Software CASE Tool Small Scientific Simulation IS Application Distributed Objects (Order Entry) Defense Weapon System National Air Traffic Control System Large-Scale Organization/Entity Simulation Enterprise IS (Family of IS Applications) Defense MIS System IS Application GUI/RDB (Order Entry) Business Spreadsheet Lower technical complexity - Mostly 4 GL, or component-based - Application reengineering - Interactive performance Higher management complexity - Large scale - Contractual - Many stake holders - “Projects”
Forces in Software Functionality Cost Capacity Availability Performance Technology churn Compatibility Fail safe Fault tolerance Throughput Resilience The challenge over the next 20 years will not be speed or cost or perfor it will be a question of complexity. Bill Raduchel, Chief Strategy Officer, Sun Microsystems Our enemy is complexity, and it’s our goal to kill it. Jan Baan
Mary Shaw, CMU Architectural style Ø An architecture style defines a family of systems in terms of a pattern of structural organization. Ø An architectural style defines a vocabulary of components and connector types a set of constraints on how they can be combined one or more semantic models that specify how a system’s overall properties can be determined from the properties of its parts
Many stakeholders, many views Ø Architecture is many things to many different interested parties end user customer project manager system engineer developer architect maintainer other developers Ø Multidimensional reality Ø Multiple stakeholders multiple views, multiple blueprints
How many views? Ø Simplified models to fit the context Ø Not all systems require all views: Single processor: drop deployment view Single process: drop process view Very Small program: drop implementation view Ø Adding views: Data view, security view
The Value of the UML Ø Is an open standard Ø Supports the entire software development lifecycle Ø Supports diverse applications areas Ø Is based on experience and needs of the user community Ø Supported by many tools
Creating the UML 1. 3 OMG Acceptance, Nov 1997 UML 1. 1 Final submission to OMG, Sep ‘ 97 public feedback First submission to OMG, Jan ´ 97 UML 1. 0 UML partners UML 0. 9 Web - June ´ 96 OOPSLA ´ 95 Other methods Unified Method 0. 8 Booch method OMT OOSE
UML Partners Ø Ø Ø Ø Rational Software Corporation Hewlett Packard I Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft Objec. Time Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys
Contributions to the UML Harel Meyer Before and after conditions Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions and message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs Brock OOSE Responsibilities Shlaer Mellor Object lifecycles Odell Classification
Overview of the UML Ø The UML is a language for visualizing specifying constructing documenting the artifacts of a software intensive system
Overview of the UML Ø Modeling elements Ø Relationships Ø Extensibility Mechanisms Ø Diagrams
Modeling Elements Ø Structural elements class, interface, collaboration, use case, active class, component, node Ø Behavioral elements interaction, state machine Ø Grouping elements package, subsystem Ø Other elements note
Relationships Ø Dependency Ø Association Ø Generalization Ø Realization
Models, Views, and Diagrams A model is a complete description of a system from a particular perspective Use Case Diagrams Sequence Diagrams Scenario Diagrams Collaboration Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams State Diagrams Class Diagrams Models State Diagrams Object Diagrams State Diagrams Component Diagrams Deployment Diagrams Activity Diagrams
Diagrams Ø A diagram is a view into a model Presented from the aspect of a particular stakeholder Provides a partial representation of the system Is semantically consistent with other views Ø In the UML, there are nine standard diagrams Static views: use case, class, object, component, deployment Dynamic views: sequence, collaboration, statechart, activity
Use Case Diagram Ø Captures system functionality as seen by users
Use Case Diagram Ø Captures system functionality as seen by users Ø Built in early stages of development Ø Purpose Specify the context of a system Capture the requirements of a system Validate a system’s architecture Drive implementation and generate test cases Ø Developed by analysts and domain experts
Class Diagram Ø Captures the vocabulary of a system
Class Diagram Ø Captures the vocabulary of a system Ø Built and refined throughout development Ø Purpose Name and model concepts in the system Specify collaborations Specify logical database schemas Ø Developed by analysts, designers, and implementers
Object Diagram Ø Captures instances and links
Object Diagram Ø Shows instances and links Ø Built during analysis and design Ø Purpose Illustrate data/object structures Specify snapshots Ø Developed by analysts, designers, and implementers
Component Diagram Ø Captures the physical structure of the implementation
Component Diagram Ø Captures the physical structure of the implementation Ø Built as part of architectural specification Ø Purpose Organize source code Construct an executable release Specify a physical database Ø Developed by architects and programmers
Deployment Diagram Ø Captures the topology of a system’s hardware
Deployment Diagram Ø Captures the topology of a system’s hardware Ø Built as part of architectural specification Ø Purpose Specify the distribution of components Identify performance bottlenecks Ø Developed by architects, networking engineers, and system engineers
Sequence Diagram Ø Captures dynamic behavior (time oriented)
Sequence Diagram Ø Captures dynamic behavior (time oriented) Ø Purpose Model flow of control Illustrate typical scenarios
Collaboration Diagram Ø Captures dynamic behavior (message oriented)
Collaboration Diagram Ø Captures dynamic behavior (message oriented) Ø Purpose Model flow of control Illustrate coordination of object structure and control
Statechart Diagram Ø Captures dynamic behavior (event oriented)
Statechart Diagram Ø Captures dynamic behavior (event oriented) Ø Purpose Model object lifecycle Model reactive objects (user interfaces, devices, etc. )
Activity Diagram Ø Captures dynamic behavior (activity oriented)
Activity Diagram Ø Captures dynamic behavior (activity oriented) Ø Purpose Model business workflows Model operations
Software engineering process A set of partially ordered steps intended to reach a goal. In software engineering the goal is to build a software product or to enhance an existing one. Ø Architectural process Sequence of activities that lead to the production of architectural artifacts: A software architecture description An architectural prototype
Key concepts Ø Phase, Iterations Ø Process Workflows Activity, steps Ø Artifacts models When does architecture happen? What does happen? What is produced? reports, documents Ø Worker: Architect Who does it?
Lifecycle Phases Inception Elaboration Construction Transition time Ø Inception Define the scope of the project and develop business case Ø Elaboration Plan project, specify features, and baseline the architecture Ø Construction Ø Transition Build the product Transition the product to its users
Major Milestones Inception Elaboration Construction Transition time Vision Baseline Architecture Initial Capability Product Release
Phases and Iterations Inception Prelim Iteration . . . Elaboration Arch Iteration Release . . . Construction Dev Iteration Transition . . . Trans Iteration Release Release . . . Release An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable release
Architecture-Centric Ø Models are vehicles for visualizing, specifying, constructing, and documenting architecture Ø The Unified Process prescribes the successive refinement of an executable architecture Inception Elaboration Construction time Architecture Transition
Unified Process structure Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n+1 #n+2 Iterations Iter. #m+1
Architecture is making decisions The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.
- Slides: 42