1. C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES
LECTURE 5
OBJECT ORIENTATION FOR ARCHITECTING:
A CANDIDATE PROCESS
LEE W. WAGENHALS
ALEXANDER H. LEVIS 1

2. OUTLINE Introduction - Need for a process An OO Process Example
Summary 2

3. 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. 4

4. OBJECT ORIENTATION APPROACH: ANALYSIS PHASE
MISSION
OPERATIONAL
CONCEPT
USE CASE ANALYSIS
PHYSICAL
ARCHITECTURE
VIEW
ORGANIZATION
MODEL
LOGICAL ARCHITECTURE
VIEW
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

5. LOGICAL ARCHITECTURE VIEWIS
BEHAVIORAL DIAGRAMS
including
Rule Model
CLASS DIAGRAM D I C T O N A R Y

6. A DETAILED VIEW MISSION OPERATIONAL CONCEPT TECHNICAL
ARCHITECTURE VIEW
ORGANIZATION
MODEL
LOGICAL
ARCHITECTURE VIEW
PHYSICAL
ARCHITECTURE VIEW
BEHAVIORAL
DIAGRAMS
(inc.Rule Model)
CLASS DIAGRAM
DATA DICT.
EVALUATION
PHASE
EXECUTABLE
MODEL
MOPs, MOEs

7. A REQUIREMENTS VIEW MISSION OPERATIONAL CONCEPT TECHNICAL
ARCHITECTURE VIEW
ORGANIZATION
MODEL
LOGICAL
ARCHITECTURE
VIEW
PHYSICAL
ARCHITECTURE VIEW
BEHAVIORAL
DIAGRAMS
(inc.Rule Model)
CLASS DIAGRAM
DATA DICT.
EVALUATION
PHASE
EXECUTABLE
MODEL
MOPs, MOEs

8. 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

9. A FIVE STAGE PROCESS DEVELOP CLASS DIAGRAMS 2
MAINTAIN INTEGRATED DICTIONARY
ALL
GATHER DOMAIN INFORMATION
FORMULATE OPERATIONAL CONCEPT 1
DEVELOP USE CASES AND THEIR
DIAGRAMS 1
DEVELOP BEHAVIORAL DIAGRAMS &
RULE MODEL 2
ENSURE
CONCORDANCE
DEPICT
ORGANIZATIONAL STRUCTURE
LOGICAL
DEVELOP COMPONENT DIAGRAMS 3
PHYSICAL
SYNTHESIS EXECUTABLE MODEL 4
DEVELOP DEPLOYMENT DIAGRAM 3
DESCRIBE PHYSICAL
ARCHITECTURE
STAGE 0
STAGE 1
STAGE 2
STAGE 3
STAGE 4

10. A FIVE-STAGE PROCESS
STAGE 0: Problem Definition and Collection of Domain Information
STAGE 1: Operational Concept and Requirements; Use Cases and Diagrams
STAGE 2: Class Diagrams, Behavioral Diagrams, Rule Model, Concordance
STAGE 3: Physical Nodes and Links; Component Diagrams, allocation to Physical Nodes and Links (Deployment Diagram)
STAGE 4: Synthesis (executable model)
All STAGES Maintain Integrated Dictionary

11. 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

12. IDEF0 MODEL OF PROCESS
Design
Information
System
Architecture A0
Domain
Knowledge
Object Orientation &
UML Guidelines
Information System
Purpose: to describe a process for developing an information system architecture using Object Orientation
View Point: System Architect

13. OVERALL PROCESS Object Orientation UML Guidelines Operational Concept
Domain
Knowledge
Information
System
Architecture
Object Orientation
UML Guidelines Do
STAGE 1 A1
STAGE 2 A2
STAGE 3 A3
Maintain
Integrated
Dictionary A4
Operational Concept
and Use Cases
UML Based
Logical Architecture
Physical

14. 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.

15. STAGE 1 ESTABLISH REQUIREMENTS
Object Orientation/UML Guidelines
Operational
Concept
Formulate
Domain
Knowledge
Operational
Operational Concept
Concept
and Use Cases
A11
Organizations
Determine
Organizational
Use Cases
with Diagrams
Features
A12
Develop
Use Cases
A13

16. 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

17. DEVELOP LOGICAL ARCHITECTURE
Object Orientation/UML Guidelines
Object Class
Diagram
Operational
Concept
Develop
UML Based
and Use Cases
Class
Logical
Architecture
Domain
Knowledge
Diagram
Behavioral
A21
Diagrams
Object Class
Develop
Behavioral
Collaborations,
Diagrams
activities,
A22
and links
Rule Model
Develop
Rule
Model
A23
Ensure
Corrections
Concor-
dance
A24

18. STAGE 2 (continued)
It is the architect’s 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.

19. 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.

20. CONCORDANCE  Activity Diagram Collaboration Diagram Class Diagram
Object 1
Object 2
Object 1
1.operationO2()
Activity
2.operationO3() A1
Operation O2
Activity O2
Object 2
3. activityA4()
Activity O3 
Operation O3
Activity
Class 1
Class 2
Operation O3
Operation O2
Class 3
Class Diagram A4
Sequence Diagram
Object 1
Object 2
opeationO2()
operationO3()
activityA4()

21. 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., , [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

22. 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.

23. STAGE 3 Physical Architecture Domain Knowledge
Object Orientation/UML Guidelines
Operational Concept
and Use Cases
UML Based
Logical Architecture
Develop
A31
Component
Diagrams
A32
Deployment
Diagram
A33
System Nodes
and Links
Components

24. 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

25. 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.

26. USE CASE EXAMPLE Use Case: Withdrawal Actors: Customer, Bank
Type: 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

27. STAGE 1 Use Case Diagram of ATM ATM Withdrawal User Bank
SSN
FirstName
LastName
Address
InsertCard()
TypePIN()
CollectReceipt()
CollectCard()
Select()
EnterAmount()
CollectCash()
Bank
BankCode
Name
ValidateUser()
AuthorizeTransaction()
FastCash Withdrawal

28. Activity Diagram of Withdrawal Use Case
Request
Display Options
Authorization
Insert Card
Authorize
Select Options
Transaction
Request PIN
Receive
Request
Type PIN
Authorization
Amount
[ Transaction NotAuthorized ]
[ Transaction Authorized ]
Enter Amount
Read PIN
Dispense Cash
Request
Compare Cash Limit
Collect Cash
[ Amount < CashLimit ]
Validate User
Print Receipt
[ Amount > CashLimit ]
and Eject Card
Receive Validation
[ User Validated ]
[ User NotValidated ]
Collected Receipt and Card
NewState2

29. INITIAL CLASS DIAGRAM OF ATM
transfer information
use
1..*
1..*
1..*
1..* 1 1 1 1
own 1 1
User
Card
(from Use Case View) 1
has
1..*
1..*
participate
perform
1..*
1..* 1 1
1..*
1..* 1 1
manage
1..*
1..*
Account 1 1
validate
1..*
1..* 1 1
Session
1..*
1..*
Bank
authorize 1 1
maintain
1..*
1..*
1..*
1..*
1..*
1..*
1..*
1..*
ATM
1..*
Transaction
1..*
1..*
1..*
1..*
Withdraw
FastCashWithdraw

30. ALLOCATE ACTIVITIES TO CLASSES
USER
BANK
ATM
SESSION
TRANSACTION

31. 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

32. ADDING OPERATIONS AND ATTRIBUTES
Transaction
TransactionID
Date
Time
ManageLog()
RequestAuthorization()
ReceiveAuthorization()
ApproveWithdraw()
Withdrawal
Amount
CashLimit
RequestAmount()
CompareCashLimit()
FastCashWithdrawal
FastCastAmount
Operations derived from Activity Model
Attributes defined as needed based on rule model

33. 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 object’s activity/operation
As with data modeling in structured analysis, domains must be defined for each attribute and message

34. Sequence Diagram of FastCash Withdraw Use Case
: User
: Bank
: FastCashWithdraw
: Session
: ATM
InsertCard()
DisplayOptions()
Select (FastCashWithdraw)
DispenseCash(FastCashAmount)
CollectCash()
Select (Quit)
EjectCard()
PrintReceipt()
RequestPIN()
TypePIN()
ActivateSession(CardNumber, PIN)
RequestValidation(CardNumber, PIN)
ConfirmValidation()
Activate(FastCashWithdraw)
RequestAuthorization(TransactionID, CardNumber, FastCashAmount)
AuthorizeTransaction(TransactionID)
ApproveWithdraw(FastCashAmount)
ValidateUser(CardNumber)

35. 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

36. Collaboration Diagram of Withdrawal Use Case
6: ValidateUser(CardNumber)
5: RequestValidation(CardNumber, PIN)
2: RequestPIN()
Must match the Sequence Diagram (and the Activity Diagram)
8: DisplayOptions()
17: DispenseCash(Amount)
19: DisplayOptions()
: User
21: EjectCard()
22: PrintReceipt()
: Bank
1: InsertCard()
3: TypePIN()
9: Select (Withdraw)
18: CollectCash()
20: Select (Quit)
4: ActivateSession(CardNumber, PIN)
: ATM
: Session
7: ConfirmValidation()
11: RequestAmount()
12: EnterAmount()
16: ApproveWithdraw(Amount)
10: Activate (Withdraw)
13: CompareCashLimit()
15: AuthorizeTransaction(TransactionID) :
14: RequestAuthorization(TransactionID,CardNumber,Amount)
Withdraw

37. Class Diagram of ATM
use
1..*
1..*
1..*
1..* 1 1
own 1 1
User
Card
has
1..*
1..*
perform
1..*
1..* 1 1 1 1
manage
1..*
1..*
Account 1
validate
1..*
1..* 1 1 1
1..*
1..*
Session
Bank
authorize 1 1
1..*
maintain 1
1..*
1..*
1..*
1..*
1..*
1..* 1
1..*
1..*
activate
ATM
1..*
Transaction
1..*
1..*
Class Diagram is a composite overlay of the collaboration diagrams
1..*
1..* 1 1
Withdraw
FastCashWithdraw
has

38. FULL CLASS DIAGRAM Withdraw Card Account ATM 1..* Session 1 1..* 1..*
Amount
CashLimit
RequestAmount()
CompareCashLimit()
FastCashWithdraw
FastCashAmount
Card
CardNumber
PIN
Account
AccountNumber
Type
Balance
Withdraw()
Open()
Close()
ATM
ATMID
OwnerBank
DisplayOptions()
ReadCard()
DispenseCash()
PrintReceipt()
EjectCard()
RequestPIN()
ReadPIN()
ActivateSession()
Activate()
1..*
trasnfer information
Session
SessionID
RequestValidation()
ReceiveValidation()
ConfirmValidation() 1
has
Bank
BankCode
Name
ValidateUser()
AuthorizeTransaction()
(from Use Case View)
manage
maintain
FULL CLASS DIAGRAM
use
1..*
1..* 1 1 1 1
1..*
1..*
own
User 1 1
1..*
1..*
(from Use Case View)
SSN
FirstName
has
LastName
Address
InsertCard()
TypePIN()
CollectReceipt()
CollectCard()
perform
Select()
EnterAmount()
CollectCash()
1..*
1..* 1 1 1 1
validate
1..*
1..*
authorize
1..*
1..* 1 1
1..*
1..*
1..*
1..*
1..*
1..*
Transaction
TransactionID
Date
Time
1..*
1..*
ManageLog()
RequestAuthorization()
ReceiveAuthorization()
ApproveWithdraw()

39. 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

40. STATE CHART FOR ATM OBJECT CLASS
Initial State
Waiting for
Card
Card Inserted / RequestPIN()
Waiting for
PIN
Validation Received[ User NotValidated ] /
PrintReceipt(), EjectCard()
PIN Entered / ActivateSession()
Waiting for
Validation
Validation Received[ User Validated ] / DisplayOptions()
Displaying
User collects card and receipt
Options
User Select Transaction / Activate(Transaction)
Waiting for
Authorization
Authorization Received[ Transaction Authorized ] / DispenseCash()
Authorization Received
[ Transaction NotAuthorized
OR Amount > Limit ]
Dispensing
Cash
User Collects Money / PrintReceipt(), EjectCard()
Printing Reciept and
Returning Card

41. 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
Ptech’s 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.