Use of UML 2.0 Diagrams for Systems Architecture Modeling *

By: Gundars Osvalds

Abstract: The use of object-oriented methodology for architectural design provides the advantage of concurrence with software developers. A sample using the Zachman Framework and UML 2.0 diagrams is presented.

Gundars Osvalds is a Systems of Systems Architect with Boeing, Mission Systems in Columbia, Maryland. He has worked on reviewing, government, and industry architecture frameworks and associated processes. His current focus is the adaptation of object-oriented methodology to enterprise architecture and systems engineering design for use in customer programs.

gundars.osvalds@boeing.com

Use of UML 2.0 Diagrams for Systems Architecture Modeling

Gundars Osvalds

 

The Boeing Company

Space & Intelligence Systems

Mission Systems

7063 Gateway Drive

Columbia, Maryland 21046

gundars.osvalds@boeing.com

 

Introduction

The Unified Modeling Language (UML) was developed to help software designers model software components.  It has evolved over the last few years to include additional diagrams and features in existing diagrams that make UML useful for the systems engineers to model architecture.

The historic methodology for architecture modeling has been the structured (functional) methodology that has it roots in industrial control.  In the last twenty years object-oriented methodology has been developed and has become the standard for designing software.  Its advantage has been in the ability to model activity relationships instead of procedures.  Object- Oriented methodology provides the ability to abstract a problem and to model solutions that are represented by loosely coupled objects that provide capabilities.  Definitions of object activities and data contents are created that represent the users view of the world.  In the design of architecture model that represent the users needs the Systems Architect must provide the software designer specifications of the software components in a methodology that is directly useable by the software designer. 

Currently systems architecture models developed by Systems Engineers to describe the stakeholders problem often use the Structured/Functional Methodology while software designers usually use the Object-Oriented Methodology.  Thus, architectures represented with Functional Representation may not be fully implemented, as designed, by the software developers who use Object-Oriented Representation.  The systems engineer should consider the benefits in utilizing an Object-Oriented Methodology in developing the architecture design.  A benefit in using the same representation (Object-Oriented) is the ability to create a concordant set of engineering products that are traceable from the design to the system implementation.  Another benefit of using Object-Oriented Methodology is that it closely matches the stakeholders view of the world which consists of objects that perform actions and utilize information.  Therefore the use of the Object-Oriented Methodology in the design and documentation of enterprise and system architectures provides reusable design artifacts for software developers. 

Architecture Frameworks

Many architecture frameworks have been developed such as: Federal Architecture Framework, Department of Defense (DoD) Architecture Framework, The Open Group Architecture Framework, and the Zachman Framework for Enterprise Architecture.  Upon comparison of these frameworks, the author found that many were neither complete nor consistent in their definitions of the models needed to fully describe architecture.  The author researched the frameworks and has determined that the Zachman Framework is pure in definition and unencumbered by methodology.  The defined views and abstractions as described in the Zachman Framework were then used to define models.  The model definitions are independent of the diagram definition.  Thus one can take advantage of new feature in UML by taking advantage in new features and new diagrams without having to changing the model and associated processes.

Object-Oriented Methodology

It is important that the system engineering architectural design is represented in a methodology that is easily conveyed to the software developer.  Therefore the use of Unified Modeling Language which specifies object-oriented diagrams should be used to develop both the architectural design as well as ultimately the software specifications.  Since UML is the language of choice by of the software developers its use by the architect is key in convey accurately the software specifications that will be used to implement the software.  Use of the same methodology for architecture and software design also assures traceability between stakeholders needs and implemented software.

Unified Modeling Language

This presentation will demonstrate the modeling of sample architecture with UML 2.  Future enhancements to UML (via SysMLTM) will provide additional systems engineering diagrams and added features to existing diagrams the in UML.  The current version of the OMG UML 2.0 has enhanced capabilities that can provide the systems engineer improved diagrams to allow modeling of system engineering and architecture design.  This presentation will show how one can utilize the latest features of UML 2 to model the sample architecture.

UML State Machine diagrams for behavioral modeling are being used by UML modeling tool vendors to incorporate dynamic modeling as a basis for Model Driven Architecture.  Therefore the State Machine diagrams can be used for developing dynamic models that can be used to verify system operation and some tools can use the diagrams to automatically generate software code.

Definition of Models and Diagrams

Using the Zachman Framework for Enterprise Architecture the author defined models that are used to diagram the views of the architecture.  These models use the object-oriented methodology to create diagrams compliant with the OMG UML 2.0 specifications. 

Sample Problem

A sample problem using the SpeedPass business model is shown using UML 2 diagrams.  The customer is provided a tag that allows him to purchase products without use of credit card, signature or pin number.  The enterprise view models are developed and decomposed down to the level of hardware and software components.  This example will show how the business model can use the same methodology and tools to provide a traceable architectural design.

Zachman Framework Reference

The Zachman Framework has been an industry defacto standard for over 16 years has defined architecture elements by describing the Abstractions (Data, Function, Network, People, Time and Motivation) and Perspectives (Scope, Business Model, Systems Model, Technology Model, and Detailed Representations) shown in Figure 1.  The elements of the framework are a classification scheme that is used to develop architecture models.



Figure 1. Zachman Framework for Enterprise Architecture

Zachman Framework Abstractions

The Zachman framework uses the following Abstractions to describe architectural models:

7       Data (What)

o      Defines the information used to describe the architecture

7       Functions (How)

o      Describes the functionality (activities) needed to create the capabilities need to define the architecture

7       Network (Where)

o      Defines the location of the activities of the enterprise and systems

7       People (Who)

o      Define the people and the organizations that are part of the enterprise; the stakeholders, owners, users of the enterprise.

7       Time (Where)

o      Define the time constraints for the enterprise and systems

7       Motivation (Why)

o      Define the vision and goal components of the enterprise and system that are used to develop the driving force for developing the capabilities that are required for the stakeholders and users.

The Zachman Framework does not define relationships between the Abstractions

Zachman Framework Perspectives

The perspectives defined are Views of the architecture that will be represented in models and diagrams.

7       Scope (Contextual) - Planner

o      Presents the Scope of the Enterprise architecture

7       Business Model (Conceptual) - Owner

o      Documents the system view of the architecture.

7       System Model (Logical) - Designer

o      Documents the logical design of the architecture

7       Technology Model (Physical) - Builder

o      Presents the physical implementation plan for the architecture

7       Detailed Representations (Out-of-context) - Subcontractor

o      The detailed specifications for the

The views are arranged top to bottom with the Scope defining the highest level models and the Detailed Representation defining the architectural specifications to the subcontractor.

Architectural Models

The models for developing this architecture used the concepts presented in the Zachman Framework.  The models defined (refer to Figure 2) provide the basis for the architectural diagrams which currently use the Object Management Group (OMG) Unified Modeling Language (UML) Version 2.0 specifications.  In the next year systems engineering enhancements specifications to UML 2.0 are planned (SysML) with vendor implementation to follow.

Figure 2. Bridging the Zachman Framework with Architectural Views

The architecture contains many views and products in order to completely represent the architecture capabilities and design.  Figure 2 presents the conceptual architectural model that is used for the definition of the architectural views and models.  The following sections describe the architectural views and models that have been defined.  The models were then used to select the UML 2 diagrams that will be used to represent the architecture views.

 

 

Figure 3. Conceptual view of the Enterprise Architecture Framework Architectural

Architecture Model and UML 2 Diagram Defenitions

The OMG UML 2.0 diagrams are used to define the implementation of the architectural models.  Table 1 documents the diagrams that are used to create the static, dynamic, and executable models of the enterprise and systems architectural representation.

TABLE 1  UML 2 Diagram use for Architectural Models

Architecture View

Models for the Views

UML 2 Diagram Description

Notes

Enterprise View

(see Figure 4 for process diagram)

1.1 Capability  Define the internal activities that are performed to satisfy the stakeholders needs.  The use case description includes requirements, pre and post criteria and steps needed to be performed by the use case activity.

UML Use Case (Structural)  Used to define the activities performed to meet the needs of the external human or system clients.

 

Sample problem diagrams are contained in the paper presentation

Enterprise View

 

1.2 Resource - Describes the products and services of the enterprise and their relationships.

UML Component (Structural)  Provides a description of all component and interactions between them.

 

Enterprise View

 

1.3 Organization  Defines the organizations, their relationships, and members of the organizations.

UML Component (Structural)  The components provide the capability to model the Architecture organizations.

 

Enterprise View

 

1.4 Information  Models the data used and relationships between the data elements.

UML Class (Structural)  Uses classes and class attributes to document the data elements.

 

Enterprise View

 

1.5 Conceptual  Depicts the identified enterprise objects (things) and their relationships.

UML Class (Structural)  Uses classes and labeled associations lines to show conceptual relationships.

 

Enterprise View

 

1.6 Interaction  Depicts the identified enterprise objects (things) and their interactions to accomplish the capability desired.

UML Sequence (Behavioral)  Uses defined objects and messages between them to define the interactions needed to implement the capabilities defined.

 

 

 

 

 

Architecture View

Models for the Views

UML 2 Diagram Description

Notes

Business View

(see Figure 5 for process diagram)

2.1 Process Overview  Documents the top level scenarios, each containing an Architectural Scenario.

UML Interaction Overview (Behavioral) - Each occurrence is represented by an activity or another interaction diagram.

Sample problem diagrams are contained in the paper presentation

Business View

 

2.2 Process  Defines the sequence of activities, the responsible entity and information used in performing the activities of the enterprise.

UML Activity (Behavioral)  Uses swim lanes, activities, data elements and messages interfaces to document the enterprise functions.

 

Business View

 

2.3 Component  documents the components used to define the systems capabilities.

UML Class  (Structural) Documents the component functions using classes and defining the functions as (Methods) and data (Attributes).

 

Business View

 

2.4 Dynamic Interaction  Document the interactions between the system components and the internal and external interfaces.

UML Communications (Behavioral)  Documents the interactions between components and the messages exchanged.

 

Business View

 

2.5 Process State  Defines the business states that are then used to drive the model driven architecture.

UML State Machine (Behavioral)  documents the system dynamic states.

 

Business View

 

2.6 Timeline  Define the time critical business activities and their timing relationships.

UML Timing (Behavioral)  shows relationships between activities in the business architecture.

 

 

 

 

 

Architecture View

Models for the Views

UML 2 Diagram Description

Notes

Logical View

(see Figure 6 for process diagram)

3.1 Logical Activity  describes the activities that are implemented by the logical components.

UML Activity (Behavioral)  shows the logical activities in the system between the elements.

Sample problem diagrams are contained in the paper presentation

Logical View

 

3.2 Static Element  defines the static elements.

UML Class (Structural)  show the object (thing) classes and their functionality, data and relationships to other classes.

 

Logical View

 

3.3 Logical Package  documents the logical grouping of elements.

UML Package (Structural)  Document how the logical elements are grouped into associated packages.

 

Logical View

 

3.4 Message Interaction  document the message interactions between the logical elements.

UML Sequence (Behavioral)  Show the logical message activities between the logical components.

 

 

 

 

 

Architecture View

Models for the Views

UML 2 Diagram Description

Notes

Physical View

(see Figure for process diagram)

4.1 Component  Defines the elements used in the implementation of the system design.

UML Component (Structural)  shows the components that are used to implement the architectural system.

Sample problem diagrams are contained in the paper presentation

Physical View

 

4.2 Interaction  depicts the interface actions between the physical interfaces.

UML Sequence (Behavioral)  Shows interfaces actions between the physical components.

 

Physical View

 

4.3 Component Relationship  Defines the interactions between the components and their relationship to each other and external interfaces.

UML Composite Structure (Structural) - Depicts the internal structure of a component (describe in the component diagram).

 

Physical View

 

4.4 Deployment  Presents the allocation of the components to the subsystem.

UML Deployment (Structural) shows the hardware and software components used to implement the architecture.

 

Physical View

 

4.5 Technology  Document the standards that are used to implement the system components.

UML Class - Documents the industry and Government standards

 

 



 







Sample Problem Description

SpeedPass is a system that provides services to a customer a fast and easy way to pay for gasoline and food products.  The one big advantage is that the user does not need to verify the account with either a signature or a pin code.  The speed of the transaction and minimum interface to the point of sales equipment is the key advantages to the customer.  The vendor can also use the system to gather specific purchase information and use it to provide the customer with sales notices and coupons.

This sample problem will use the models and diagrams defined to create an architecture that represents the SpeedPass system.  The diagrams can then be used as specifications in the implementation of the system.  The purpose of this model is to show how Object-Oriented methodology and diagrams can be used to represent the architecture of a enterprise and systems used to implement its capabilities.  Refer to the diagrams in the accompanying presentation for examples of the architectural models using UML 2 diagrams in the designing of the SpeedPass architecture.

Object-Oriented Architecture Representation

Currently systems engineers have not endorsed the use of object-oriented methodology for architecture.  There is a need for the architecture design to be represented in a common methodology to improve traceability and assure that the architecture designed is accurately conveyed to the software developers.  Today software developers have embraced the object-oriented methodology for design and development of software.  The system engineer developing architectural models and software specifications should provide software designers and developers specifications in the methodology that used for software development.  There is an advantage in using the object-oriented methodology for enterprise and systems architectures modeling is that it can meet the needs of the Stakeholders (owner, users, and external systems), and software designers and developers in a single common representation that satisfies both architects customers (stakeholder and software designer).

Summary

The process documented in this paper uses the Zachman Framework views and industry business and design methodologies in the definition of the Enterprise Architecture views and models.  These defined models are then represented with the use of the Object Management Group (OMG) Unified Modeling Language (UML) 2.0 diagrams.  The diagrams represent the enterprise, systems, and component architecture.  The resultant architecture defined the software and hardware specifications for the system components.  These object models are directly usable by the software developers since the models use the same methodology as used by them. 

 


  Latest Comments  View All Add New RSS ATOM

Move mouse over comment to see the full text

Server Response from: ETNASC01