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 based on object-oriented architecture

Overview of the UML Ø Modeling elements Ø Relationships Ø Extensibility Mechanisms Ø Diagrams

Modeling elements in all diagrams Ø Structural elements class, interface, collaboration, use case, active class, component, node Ø Behavioral elements interaction, state machine NAME : TYPE [default value] Ø Grouping elements package, subsystem DATA Ø Other elements note METHODS + public INTERFACE private (what is seen from outside) # protected description

Relationships Ø Dependency Ø Association Ø Generalization Ø Realization “simple part of” “lives with the whole”

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 (interaction user – system) Ø Captures system functionality as seen by users Behavior may be extended (similar but more) A user may play more than one actor (ACTOR specifies “WHAT”, and not “HOW”) “uses” Some common functionality

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 0 or more (many) “part of” Relationship between objects of the same class (many departments have common name) “inheritance” Spec. kind of office 1 or more Couples logical and physical part “uses”

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 static aspect, real perspective Ø Captures instances and links at a point in time Instance of abstraction relationship

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 (code components) dependency Components: • Executables • Library • Table • File • Document

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 A piece of 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) Class Message Instance of Anonymous object From a stream From the same message Object lifelines

Sequence Diagram Ø Captures dynamic behavior (time oriented) Ø Purpose Model flow of control Illustrate typical scenarios

Collaboration Diagram “who sends to whom” Ø Captures dynamic behavior (message oriented) – not “when”

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) – states of a particular object event [guard] / action (if TRUE)

Statechart Diagram Ø Captures dynamic behavior (event oriented) Ø Purpose Model object lifecycle Model reactive objects (user interfaces, devices, etc. )

Activity Diagram – work flow, operation Ø Captures dynamic behavior (activity oriented) Building a house Syntax not defined in UML Semantics: activity • Evaluate expression • Send a method • Create or destroy an object Synchronization bars Parallel activities Change of state or attribute

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.

IBM acquire Rational Software IBM and Rational Software Corp. announced the two companies have entered into a definitive agreement for IBM to acquire the equity of Rational at a price of approximately $2. 1 billion in cash or $10. 50 per share. (2003) = IBM