C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES

LECTURE 5 OBJECT ORIENTATION FOR ARCHITECTING:

A CANDIDATE PROCESS
LEE W. WAGENHALS ALEXANDER H. LEVIS

A. H. Levis INCOSE

L. 5 - 1

OUTLINE
Introduction - Need for a process An OO Process Example

Summary

A. H. Levis INCOSE

L. 5 - 2

CONCEPTUAL PROBLEMS
We have seen that the structured analysis approach requires the functional architecture view composed of the activity model, the data model and the rule model plus a consistent physical architecture view.

While object orientation offers an alternative to structured analysis, the Uniform Modeling Language does not offer a process for building complete architecture descriptions
The goal of most OO texts is to develop software, not architectures Two new problems arise:

What is the set of UML diagrams that should be used to represent a complete architecture of an information system or C4ISR?
Can an Object Oriented process be developed and used to design an architecture? As with structured analysis, our requirement is that the combination of information contained in the set of views must be sufficient to yield the specified products and to construct an executable model of the architecture.

A. H. Levis INCOSE

L. 5 - 3

OBJECT ORIENTATION APPROACH: ANALYSIS PHASE

MISSION OPERATIONAL CONCEPT

USE CASE ANALYSIS

LOGICAL ARCHITECTURE VIEW

PHYSICAL ARCHITECTURE VIEW

ORGANIZATION MODEL

Unless the Logical and Physical Architectures are restricted to very high level representations, the Operational Concept is needed to drive both representations and keep them compatible
A. H. Levis INCOSE L. 5 - 4

LOGICAL ARCHITECTURE VIEW

D A T A

D I C T I O N A R Y

CLASS DIAGRAM

BEHAVIORAL DIAGRAMS including Rule Model

IS

LOGICAL ARCHITECTURE VIEW

A. H. Levis INCOSE

L. 5 - 5

A DETAILED VIEW
MISSION OPERATIONAL CONCEPT TECHNICAL ARCHITECTURE VIEW

LOGICAL ARCHITECTURE VIEW

CLASS DIAGRAM BEHAVIORAL DIAGRAMS (inc.Rule Model) DATA DICT.

ORGANIZATION MODEL PHYSICAL ARCHITECTURE VIEW

EVALUATION PHASE EXECUTABLE MODEL MOPs, MOEs

A. H. Levis INCOSE

L. 5 - 6

A REQUIREMENTS VIEW
MISSION OPERATIONAL CONCEPT TECHNICAL ARCHITECTURE VIEW

LOGICAL ARCHITECTURE VIEW

CLASS DIAGRAM BEHAVIORAL DIAGRAMS (inc.Rule Model) DATA DICT.

ORGANIZATION MODEL PHYSICAL ARCHITECTURE VIEW

EVALUATION PHASE

EXECUTABLE MODEL

MOPs, MOEs

A. H. Levis INCOSE

L. 5 - 7

A FIVE STAGE PROCESS

A five-stage process has been developed that uses the Unified Modeling Language and the associated diagrams to design the Operational and Systems Architecture views The architecture information contained in the diagrams is then mapped into the C4ISR products Not all C4ISR products are derivable from the OO architecture design (nor are they derivable from the structured analysis approach) A high level description of the process is shown on the next viewgraph

A. H. Levis INCOSE

L. 5 - 8

A FIVE STAGE PROCESS

GATHER 0 DOMAIN INFORMATION FORMULATE 1 OPERATIONAL CONCEPT DEVELOP USE1 CASES AND THEIR DIAGRAMS DEVELOP 2 CLASS DIAGRAMS

ALL

MAINTAIN INTEGRATED DICTIONARY

DEVELOP 2 BEHAVIORAL DIAGRAMS & RULE MODEL

ENSURE CONCORDANCE 3

LOGICAL

0 DEPICT ORGANIZATIONAL STRUCTURE

PHYSICAL

DEVELOP COMPONENT DIAGRAMS 0 DEVELOP 3 DEPLOYMENT DIAGRAM STAGE 2 STAGE 3

SYNTHESIS EXECUTABLE MODEL 4

DESCRIBE PHYSICAL ARCHITECTURE

STAGE 0
A. H. Levis INCOSE

STAGE 1

STAGE 4
L. 5 - 9

A FIVE-STAGE PROCESS
STAGE 0: Problem Definition and Collection of Domain Information Operational Concept and Requirements; Use Cases and Diagrams Class Diagrams, Behavioral Diagrams, Rule Model, Concordance Physical Nodes and Links; Component Diagrams, allocation to Physical Nodes and Links (Deployment Diagram) Synthesis (executable model)

------------------------------------------------------------------------------------------STAGE 1: STAGE 2: STAGE 3:

STAGE 4:

All STAGES Maintain Integrated Dictionary

A. H. Levis INCOSE

L. 5 - 10

STAGE 0
Define Problem and Identify Domain Gather Domain Information Describe Physical Architecture Legacy systems and their characteristics Planned systems Future systems and alternatives Note: Legacy systems and their interfaces can be thought as physical design constraints on the architecture

A. H. Levis INCOSE

L. 5 - 11

IDEF0 MODEL OF PROCESS

Object Orientation & UML Guidelines

Domain Knowledge

Design Information System Architecture

A0

Information System Architecture

Purpose: to describe a process for developing an information system architecture using Object Orientation View Point: System Architect
A. H. Levis INCOSE L. 5 - 12

OVERALL PROCESS
Object Orientation UML Guidelines Operational Concept and Use Cases Do STAGE 1
A1

Information System Architecture

UML Based Logical Architecture Do STAGE 2

A2

Domain Knowledge Do STAGE 3

A3

UML Based Physical Architecture

Maintain Integrated Dictionary

A4

Integrated Dictionary

A. H. Levis INCOSE

L. 5 - 13

STAGE 1
Once the basic information has been assembled in Stage 0, the process starts by defining the Operational Concept that implies or includes organizations and actions or tasks. This is expressed as the operational concept graphic with a textual description The operational concept is expanded by developing Use Cases.

These describe scenarios between users and the system for which the architecture is being developed. A scenario is a sequence of interactions between a user and a system.
There is no specified format. Textual descriptions listing interactions with actor or system (noun), the next activity (verb), and result (noun) are used. Other formats include a table listing, for each interaction, Actor, System, Pre-condition and Post-condition.
A. H. Levis INCOSE

L. 5 - 14

STAGE 1 ESTABLISH REQUIREMENTS

Object Orientation/UML Guidelines

Operational Concept Domain Knowledge

Formulate Operational Concept

A11

Operational Concept and Use Cases Organizations Use Cases with Diagrams Develop Use Cases
A13

Determine Organizational Features

A12

A. H. Levis INCOSE

L. 5 - 15

STAGE 2
Once the required operation of the system has been defined, the logical architecture for carrying out the use cases is designed. The architect decides what activities and information flows will accomplish the operational concept as defined by each use case, allocates those activities to Classes, determines the attributes that each class needs to carry out its activities (operations), and develops the rules for each operation. Concordance is crucial throughout this process which is iterative rather than sequential

A. H. Levis INCOSE

L. 5 - 16

DEVELOP LOGICAL ARCHITECTURE

Object Orientation/UML Guidelines Object Class Diagram Behavioral Diagrams Operational Concept and Use Cases Domain Knowledge

Develop Class Diagram A21

UML Based Logical Architecture

Object Class Develop Behavioral Diagrams A22

Collaborations, activities, and links Rule Model Develop Rule Model A23

Ensure Concordance A24

Corrections

A. H. Levis INCOSE

L. 5 - 17

STAGE 2 (continued)
It is the architects choice as to which model to begin with
The architect may start with a candidate set of classes and then describe the behavior using the behavioral diagrams (activity diagram or sequence diagram) Alternatively the architect can start with behavioral diagrams, e.g. activity diagram, to determine how the use case will be carried out. Once the activity diagram is created, the activities can be allocated to objects and the activity diagram enhanced with swim lanes to show the interaction between classes.

Regardless of the starting point, the architect will quickly be working with a set of diagrams all showing different aspects of how the architecture will carry out each use case.

A. H. Levis INCOSE

L. 5 - 18

CONCORDANCE
As with structured analysis, maintaining concordance between the model views is crucial Each type of behavioral diagram reflects the design of the same architecture. Each highlights a different aspect of that behavior. Activity Diagrams reflect the processes used to carry out the use cases. They describe the sequencing of activities. Decomposition of activities is supported. The activities will be carried out by the operations of the classes. Thus it is recommended that the names of the activities and the operations be the same. Once activities have been allocated to classes, then the flow of information between them can be determined from the activity diagram and must match the association paths on the collaboration diagram and the flows on the sequence diagram.
A. H. Levis INCOSE

L. 5 - 19

Activity Diagram

CONCORDANCE
Collaboration Diagram
Object 2 1.operationO2() Object 1 2.operationO3()

Object 1

Activity A1 Activity O2 Activity O3 Operation O2

3. activityA4()

Object 2

Activity A4

Class Diagram Sequence Diagram

Object 1 Object 2 Class 1

Operation O3

Class 3

opeationO2() operationO3() activityA4()

Operation O2 Class 2

Operation O3
A. H. Levis INCOSE L. 5 - 20

CONCORDANCE
The links on the collaboration diagram are labeled with the messages that carry the information between the two objects. UML message format predecessor guard-condition sequence expression return value:=message_name (argument list). e.g., 1.1, [x<y]*[I=1..n] s:=drawSegment(n) Not all elements of the message need be used Message labels on collaboration diagrams and on sequence diagrams for the same event should match

A. H. Levis INCOSE

L. 5 - 21

CONCORDANCE
The Class diagram is a composite structure of the collaboration diagrams.
The associations on the Class diagram must represent one or more links on the set of collaboration diagrams. If there is a link on a collaboration diagram and no corresponding association on the class diagram, an error exists. If an association exists and there is no corresponding link on any collaboration diagram, an error may exist. Not that the association names are chosen to enhance overall understanding and they do not have to be the same as the message label of the links.

A. H. Levis INCOSE

L. 5 - 22

STAGE 3
Object Orientation/UML Guidelines

Operational Concept and Use Cases

Develop System Nodes Physical and Links Architecture A31

UML Based Logical Architecture

Develop Component Components Diagrams A32

Domain Knowledge

Develop Deployment Diagram A33

UML Based Physical Architecture

A. H. Levis INCOSE

L. 5 - 23

STAGE 3
In completing the physical architectures, use the principles that applied to structured analysis Define system nodes and links using the operational concept and organizational features as a guide Objects are grouped into components to create component diagrams Components are allocated to system nodes in the physical architecture All logical associations must be instantiated with communications links

A. H. Levis INCOSE

L. 5 - 24

EXAMPLE
A simple example of an Automatic Teller Machine can be used to illustrate the process The operational concept is that we will create an architecture for a system that uses ATMs to allow bank customers to withdraw cash from their bank accounts at any time. Two options will be available: a Fast Cash option that provides a set amount of cash, and a regular withdrawal where the customer can specify the amount of cash to be withdrawn Customers use an ATM card issued by the bank to initiate the process. They must use a PIN.

A. H. Levis INCOSE

L. 5 - 25

USE CASE EXAMPLE

Use Case: Actors: Type: Withdrawal Customer, Bank Primary

Description: A customer arrives at an ATM with ATM Card to withdraw cash. The customer inserts the card into the ATM. The ATM prompts the customer to enter PIN. The customer enters PIN and the system authorizes the withdrawal. The customer enters the amount to be withdrawn. The ATM dispenses the cash and provides a receipt. The ATM sends transaction records to the Bank to update the account balance. On completion, the customer leaves with the cash and receipt

A. H. Levis INCOSE

L. 5 - 26

STAGE 1
Use Case Diagram of ATM
ATM

Withdrawal User
SSN FirstName LastName Address InsertCard() TypePIN() CollectReceipt() CollectCard() Select() EnterAmount() CollectCash()

Bank FastCash Withdrawal

BankCode Name ValidateUser() AuthorizeTransaction()

A. H. Levis INCOSE

L. 5 - 27

Activity Diagram of Withdrawal Use Case

Request Authorization Authorize Transaction

Insert Card

Display Options

Request PIN

Select Options

Type PIN

Request Amount Enter Amount

Receive Authorization
[ Transaction NotAuthorized ] [ Transaction Authorized ]

Read PIN Dispense Cash Request Compare Cash Limit Collect Cash Validate User [ Amount < CashLimit ] Print Receipt and Eject Card

[ Amount > CashLimit ] Receive Validation

[ User Validated ]

[ User NotValidated ] Collected Receipt and Card

INITIAL CLASS DIAGRAM OF ATM

transfer information

use own

1..* 1 User

1..* 1 1 participate perform

Card
1..*

(from Use Case 1 View) has

1 1 1 validate 1 Bank authorize maintain 1..* 1..* 1..* ATM

1..*

1..*

manage
1..* Session 1..* 1

1..* Account

1..*

1..*

1..* Transaction 1..*

Withdraw

FastCashWithdraw

ALLOCATE ACTIVITIES TO CLASSES

Insert Card Display Options Request Authorization

Request PIN

Select Options

Authorize Transaction

Type PIN

Request Amount [ Transaction NotAuthorized ]

Receive Authorization

Read PIN

Enter Amount

[ Transaction Authorized ] Dispense Cash

Request Validation

Compare Cash Limit Collect Cash

Validate User

[ Amount < CashLimit ] [ Amount > CashLimit ] Print Receipt and Eject Card

Receive Validation

USER BANK
[ User Validated ]

ATM
Collecting Receipt and

[ User NotValidated ]

SESSION TRANSACTION

New Sw imlane6 : User

New Sw imlane7 : Session

New Sw imlane8 : Withdraw

New Sw imlane9 : ATM

New Sw imlane10 : Bank

Activity Diagram of Withdrawal Use Case with Swim Lanes

Activities are allocated to Objects Activities become operations The connectors in the Activity Diagram correspond to Associations in Class Diagram and links in Collaboration and Sequence Diagrams Messages labels can be added

User Insert Card

Activity Diagram of Withdraw Use Case

Session CardID Withdraw ATM

Bank

SignalType=PINRequest Request PIN PIN Type PIN (CardID, PIN) Read PIN (CardID, PIN) Request Validation (CardID, Validation) Validate User Receive Validation [ User Validated ] SignalType=Options [ User NotValidated ] Select Withdraw Select Options SignalType=RequestAmount Request Amount Display Options

Enter Amount

Amount

Compare Cash Limit [ Amount > Limit ]

[ Am ount < Lim it ]

Request Authorization

(TransactionID, CardID, Amount) (TransactionID, Approval) Authorize Transaction

Receive Authorization [ Transaction Authorized ] SignaType=CollectCash Cash Collected Collect Cash [ Transaction NotAuthorized ] Dispense Cash

Print Receipt and Eject Card

Collecting Receipt and Card

(Card, Receipt)

ADDING OPERATIONS AND ATTRIBUTES

Transaction Operations derived from Activity Model Attributes defined as needed based on rule model TransactionID Date Time ManageLog() RequestAuthorization() ReceiveAuthorization() ApproveWithdraw() CompareCashLimit()

Withdrawal

FastCashWithdrawal FastCastAmount

Amount CashLimit
RequestAmount()

A. H. Levis INCOSE

L. 5 - 32

RULE MODEL
Based on the Activity Diagram Developed in the same manner as for Structured Analysis Use Structure English, Decision Tables and Trees Rules apply only to the lowest level of decomposition in the Activity Diagram Ensure each Clause of rule matches either: Attribute of Object Message sent to the object (calling the activity/operation) Message or return from the objects activity/operation As with data modeling in structured analysis, domains must be defined for each attribute and message
A. H. Levis INCOSE L. 5 - 33

Sequence Diagram of FastCash Withdraw Use Case

: User

: Session

: FastCashWithdraw
InsertCard() RequestPIN() TypePIN() ActivateSession(CardNumber, PIN)

: ATM

: Bank

RequestValidation(CardNumber, PIN) ValidateUser(CardNumber) ConfirmValidation() DisplayOptions() Select (FastCashWithdraw)

Activate(FastCashWithdraw) RequestAuthorization(TransactionID, CardNumber, FastCashAmount)

AuthorizeTransaction(TransactionID)

ApproveWithdraw(FastCashAmount)
DispenseCash(FastCashAmount) CollectCash() DisplayOptions() Select (Quit) EjectCard() PrintReceipt()

SEQUENCE DIAGRAM
Shows the sequence for messages between objects for the use case Must match the Activity Diagram in structure Emphasis is on the messages rather than the activities Messages must match the conditions or actions of the rule model for each activity operation

A. H. Levis INCOSE

L. 5 - 35

Collaboration Diagram of Withdrawal Use Case

Must match the Sequence Diagram (and the Activity Diagram)
2: RequestPIN() 8: DisplayOptions() 17: DispenseCash(Amount) 19: DisplayOptions() 21: EjectCard() 22: PrintReceipt()

6: ValidateUser(CardNumber)

5: RequestValidation(CardNumber, PIN)

: User

: Bank

1: InsertCard() 3: TypePIN() 9: Select (Withdraw) 18: CollectCash() 20: Select (Quit) : ATM 7: ConfirmValidation()

4: ActivateSession(CardNumber, PIN) : Session

11: RequestAmount() 12: EnterAmount()

16: ApproveWithdraw(Amount)

10: Activate (Withdraw)

13: CompareCashLimit()

15: AuthorizeTransaction(TransactionID)
14: RequestAuthorization(TransactionID,CardNumber,Amount)

: Withdraw

Class Diagram of ATM

use own Card 1..* 1..* 1 User has 1..* 1

perform 1 1 1 1 Bank 1 authorize maintain 1..* 1..* ATM 1 Withdraw has FastCashWithdraw 1 activate 1..* 1..* 1..* 1..*Transaction validate manage 1..* Session 1..* 1 1..* 1..* 1..* Account

Class Diagram is a composite overlay of the collaboration diagrams

1..*

trasnfer information

FULL CLASS DIAGRAM

1..* 1 1 User 1 1..*
(from Use Case View) SSN FirstName LastName Address InsertCard() TypePIN() CollectReceipt() CollectCard() Select() EnterAmount() CollectCash() has

use

1..*

Card
CardNumber PIN

own

perform

1..* 1..* Account

AccountNumber Type Balance Withdraw() Open() Close()

1 1 1 1
Bank (from Use Case View) BankCode Name ValidateUser() AuthorizeTransaction() authorize manage validate

1..*

1..* Session
SessionID RequestValidation() ReceiveValidation() ConfirmValidation()

1..*

1..*

maintain

1..* ATM 1..*

ATMID OwnerBank DisplayOptions() ReadCard() DispenseCash() PrintReceipt() EjectCard() RequestPIN() ReadPIN() ActivateSession() Activate()

1..*

1..*

1..*

Transaction
TransactionID Date Time ManageLog() RequestAuthorization() ReceiveAuthorization() ApproveWithdraw()

1..*

Withdraw
Amount CashLimit RequestAmount() CompareCashLimit() has FastCashWithdraw FastCashAmount

STATE CHARTS
State Charts (or State Transition Diagrams) should be created for each Object Class Note that this is different from our approach with Structure Analysis where Dynamics Models are produced for the entire system Same rules apply and concordance must be maintained States are consistent with other behavioral diagrams Transitions are annotated with events (message arrivals), guard functions (from rule model) and actions (that can be operations and match rule model) Path from initial state to final state must match the threads on the activity diagram and match the life-lines on the sequence diagram

A. H. Levis INCOSE

L. 5 - 39

STATE CHART FOR ATM OBJECT CLASS

Initial State
Waiting for Card Card Inserted / RequestPIN() Waiting for PIN Validation Received[ User NotValidated ] / PIN Entered / ActivateSession() PrintReceipt(), EjectCard() Waiting for Validation Validation Received[ User Validated ] / DisplayOptions() Displaying Options User collects card and receipt

User Select Transaction / Activate(Transaction) Waiting for Authorization Authorization Received [ Transaction NotAuthorized Dispensing Cash OR Amount > Limit ] Authorization Received[ Transaction Authorized ] / DispenseCash()

User Collects Money / PrintReceipt(), EjectCard()

Printing Reciept and Returning Card

SUMMARY
We have demonstrated a candidate process by which the Object-Oriented paradigm can be applied to the architecture specification problem Understanding and maintaining Concordance and the Integrated Dictionary is absolutely necessary Tools: Rational Rose supports the creation of UML diagrams, but it does not support concordance in the manner needed for architecture development Ptechs Framework supports object orientation and the creation of the UML diagrams; current DOD funded effort for the automatic generation of the Colored Petri net based executable model in progress.
A. H. Levis INCOSE L. 5 - 41