L. 5 - 1 © A. H. Levis INCOSE LECTURE 5 OBJECT ORIENTATION FOR ARCHITECTING: A CANDIDATE PROCESS...
-
Upload
cole-brewer -
Category
Documents
-
view
217 -
download
0
Transcript of L. 5 - 1 © A. H. Levis INCOSE LECTURE 5 OBJECT ORIENTATION FOR ARCHITECTING: A CANDIDATE PROCESS...
L. 5 - 1© A. H. LevisINCOSE
LECTURE 5
OBJECT ORIENTATION FOR ARCHITECTING:
A CANDIDATE PROCESS
LEE W. WAGENHALS
ALEXANDER H. LEVIS
C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES
L. 5 - 2© A. H. LevisINCOSE
OUTLINE
• Introduction - Need for a process
• An OO Process
• Example
• Summary
L. 5 - 3© A. H. LevisINCOSE
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.
L. 5 - 4© A. H. LevisINCOSE
OBJECT ORIENTATION APPROACH:ANALYSIS PHASE
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
LOGICAL ARCHITECTURE
VIEW
OPERATIONALCONCEPT
PHYSICALARCHITECTURE
VIEW
MISSION
USE CASE ANALYSIS
ORGANIZATIONMODEL
L. 5 - 5© A. H. LevisINCOSE
LOGICAL ARCHITECTURE VIEW
LOGICAL ARCHITECTURE
VIEWIS
BEHAVIORAL DIAGRAMSincluding
Rule Model
CLASS DIAGRAMDICTIONARY
DATA
L. 5 - 6© A. H. LevisINCOSE
A DETAILED VIEW
ORGANIZATIONMODEL
OPERATIONALCONCEPT
LOGICALARCHITECTURE
VIEW
PHYSICALARCHITECTURE VIEW
EXECUTABLEMODEL MOPs, MOEs
TECHNICALARCHITECTURE VIEW
BEHAVIORAL DIAGRAMS (inc.Rule Model)
CLASS DIAGRAM
DATA DICT.
MISSION
EVALUATIONPHASE
L. 5 - 7© A. H. LevisINCOSE
A REQUIREMENTS VIEW
ORGANIZATIONMODEL
OPERATIONALCONCEPT
LOGICALARCHITECTURE
VIEW
PHYSICALARCHITECTURE VIEW
EXECUTABLEMODEL MOPs, MOEs
TECHNICALARCHITECTURE VIEW
BEHAVIORAL DIAGRAMS (inc.Rule Model)
CLASS DIAGRAM
DATA DICT.
MISSION
EVALUATIONPHASE
L. 5 - 8© A. H. LevisINCOSE
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
L. 5 - 9© A. H. LevisINCOSE
A FIVE STAGE PROCESS
GATHER DOMAIN
INFORMATION
DEVELOP CLASS
DIAGRAMS
DEVELOP BEHAVIORAL DIAGRAMS &RULE MODEL
DEPICTORGANIZATIONAL
STRUCTURE
DESCRIBE PHYSICAL ARCHITECTURE
DEVELOP DEPLOYMENT
DIAGRAM
DEVELOP COMPONENT DIAGRAMS SYNTHESIS
EXECUTABLE MODEL
STAGE 0 STAGE 1 STAGE 2 STAGE 3 STAGE 4
LOGICAL
PHYSICAL
MAINTAIN INTEGRATED DICTIONARY
ALL0 FORMULATE
OPERATIONAL CONCEPT
DEVELOP USE CASES AND
THEIRDIAGRAMS
1
1
0
2
2
3
03 4
ENSURECONCORDANCE
L. 5 - 10© A. H. LevisINCOSE
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
L. 5 - 11© A. H. LevisINCOSE
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
L. 5 - 12© A. H. LevisINCOSE
IDEF0 MODEL OF PROCESS
Purpose: to describe a process for developing an information system architecture using Object Orientation
View Point: System Architect
Design Information
System Architecture
A0
Domain Knowledge
Object Orientation &UML Guidelines
Information System Architecture
L. 5 - 13© A. H. LevisINCOSE
OVERALL PROCESS
DomainKnowledge
Information SystemArchitecture
Object OrientationUML Guidelines
Do STAGE 1
A1
DoSTAGE 2
A2
DoSTAGE 3
A3
Maintain Integrated Dictionary
A4
Operational Concept and Use Cases
UML Based Logical Architecture
Physical Architecture
IntegratedDictionary
UML Based
L. 5 - 14© A. H. LevisINCOSE
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.
L. 5 - 15© A. H. LevisINCOSE
STAGE 1 ESTABLISH REQUIREMENTS
Domain Knowledge
Object Orientation/UML Guidelines
Operational Concept and Use Cases
Formulate Operational
ConceptA11
Develop Use Cases
A13
Determine Organizational
FeaturesA12
Use Cases with Diagrams
Operational Concept
Organizations
L. 5 - 16© A. H. LevisINCOSE
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
L. 5 - 17© A. H. LevisINCOSE
DEVELOP LOGICAL ARCHITECTURE
UML Based Logical ArchitectureDomain
Knowledge
Object Orientation/UML Guidelines
Operational Concept and Use Cases
Develop Class
Diagram
A21
Develop Behavioral Diagrams
A22
DevelopRule Model
A23
Ensure Concor-dance
A24
Object Class
Collaborations, activities, and links
Object Class Diagram
Rule Model
Behavioral Diagrams
Corrections
L. 5 - 18© A. H. LevisINCOSE
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.
L. 5 - 19© A. H. LevisINCOSE
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.
L. 5 - 20© A. H. LevisINCOSE
CONCORDANCE
Activity A1
Activity O2
Activity O3
Activity A4
Object 1 Object 2
Object 1
Object 2
Operation O3
Operation O2
Object 1 Object 2
opeationO2()
operationO3()
activityA4()
2.operationO3()
1.operationO2()
3. activityA4()
Activity Diagram
Collaboration Diagram
Class 1
Class 2
Operation O3
Operation O2
Class 3
Class Diagram
Sequence Diagram
L. 5 - 21© A. H. LevisINCOSE
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
L. 5 - 22© A. H. LevisINCOSE
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.
L. 5 - 23© A. H. LevisINCOSE
STAGE 3
Physical ArchitectureDomain Knowledge
Object Orientation/UML Guidelines
Operational Concept and Use Cases
UML Based Logical Architecture
Develop Physical
ArchitectureA31
Develop Component Diagrams
A32
Develop Deployment
Diagram
A33
System Nodes and Links
Components
UML Based
L. 5 - 24© A. H. LevisINCOSE
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
L. 5 - 25© A. H. LevisINCOSE
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.
L. 5 - 26© A. H. LevisINCOSE
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
L. 5 - 27© A. H. LevisINCOSE
ATM
Withdrawal
FastCash Withdrawal
Use Case Diagram of ATM
User
SSNFirstNameLastNameAddress
InsertCard()TypePIN()
CollectReceipt()CollectCard()
Select()EnterAmount()CollectCash()
Bank
BankCodeName
ValidateUser()AuthorizeTransaction()
STAGE 1
Activity Diagram of Withdrawal Use Case
Insert Card
Type PIN
Request PIN
Request
Receive Validation
Display Options
Select Options
Enter Amount
Request Amount
Compare Cash Limit
Read PIN
Validate User
Request Authorization
Receive Authorization
Collect Cash
Dispense Cash
Print Receipt and Eject Card
Authorize Transaction
Collected Receipt and Card
[ Transaction Authorized ][ Transaction NotAuthorized ]
[ User Validated ]
[ User NotValidated ]
[ Amount < CashLimit ]
[ Amount > CashLimit ]
Withdraw FastCashWithdraw
Card
Account
ATM
1..*
1..*
1..*
1..*
transfer information
SessionBank
1..*1 1..*1
manage
1..*
1
1..*
1
maintain
1..*
1
1..*
1
validate
Transaction
1..*
1
1..*
1
1..*
1
1..*
1
authorize
User
(from Use Case View)1..*
1
1..*
1own
1..*
1
1..*
1
has
1..*
1..*
1..*
1..*use
1..*
1
1..*
1
participate
1..*
1..*
1..*
1..*
perform
INITIAL CLASS DIAGRAM OF ATM
1
1..*
ALLOCATE ACTIVITIES TO CLASSES
USER
BANK
ATM
SESSION
TRANSACTION
Insert Card
Type PIN
Request PIN
Request Validation
Receive Validation
Display Options
Select Options
Enter Amount
Request Amount
Compare Cash Limit
Read PIN
Validate User
Request Authorization
Receive Authorization
Collect Cash
Dispense Cash
Print Receipt and Eject Card
Authorize Transaction
Collecting Receipt and
[ Amount < CashLimit ]
[ Transaction Authorized ]
[ Transaction NotAuthorized ]
[ Amount > CashLimit ]
[ User Validated ]
[ User NotValidated ]
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
Insert Card
Type PIN
Enter Amount
Select Options
Collect Cash
Collecting Receipt and Card
User
Request Validation
Receive Validation
Activity Diagram of Withdraw Use Case
Session
Request Amount
Select Withdraw
Compare Cash Limit
Request Authorization
Receive Authorization
Withdraw
Read PIN
Request PIN
Display Options
Dispense Cash
Print Receipt and Eject Card
ATM
Validate User
Authorize Transaction
Bank
[ Amount < Limit ]
[ Amount > Limit ]
[ User Validated ]
[ User NotValidated ]
CardID
PIN
(CardID, PIN)
(CardID, PIN)
(CardID, Validation)
(TransactionID, CardID, Amount)
(TransactionID, Approval)
(Card, Receipt)
SignalType=PINRequest
[ Transaction Authorized ]
[ Transaction NotAuthorized ]SignaType=CollectCash
Cash Collected
SignalType=Options
SignalType=RequestAmount
Amount
NewSwimlane10 : BankNewSwimlane9 : ATMNewSwimlane8 : WithdrawNewSwimlane7 : SessionNewSwimlane6 : User
L. 5 - 32© A. H. LevisINCOSE
ADDING OPERATIONS AND ATTRIBUTES
• Operations derived from Activity Model
• Attributes defined as needed based on rule model
Transaction
TransactionIDDateTime
ManageLog()RequestAuthorization()ReceiveAuthorization()ApproveWithdraw()
Withdrawal
AmountCashLimit
RequestAmount()
CompareCashLimit()
FastCashWithdrawal
FastCastAmount
L. 5 - 33© A. H. LevisINCOSE
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
Sequence Diagram of FastCash Withdraw Use Case
: User : Bank : FastCashWithdraw : Session : ATM
InsertCard()
DisplayOptions()
Select (FastCashWithdraw)
DispenseCash(FastCashAmount)
CollectCash()
DisplayOptions()
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)
L. 5 - 35© A. H. LevisINCOSE
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
Collaboration Diagram of Withdrawal Use Case
Must match the Sequence Diagram (and the Activity Diagram)
: User
: ATM
: Bank
: Session
: Withdraw
13: CompareCashLimit()
1: InsertCard()3: TypePIN()
9: Select (Withdraw)18: CollectCash()20: Select (Quit)
2: RequestPIN()8: DisplayOptions()
17: DispenseCash(Amount)19: DisplayOptions()
21: EjectCard()22: PrintReceipt()
4: ActivateSession(CardNumber, PIN)
7: ConfirmValidation()
10: Activate (Withdraw)16: ApproveWithdraw(Amount)
5: RequestValidation(CardNumber, PIN)
6: ValidateUser(CardNumber)
11: RequestAmount()
12: EnterAmount()
14: RequestAuthorization(TransactionID,CardNumber,Amount)
15: AuthorizeTransaction(TransactionID)
Class Diagram of ATM
Class Diagram is a composite overlay of the collaboration diagrams
Withdraw FastCashWithdraw
Card
Account
ATM
1..*1..*
Session
1..*
11
has
Bank
1..*1 1..*1
manage
1..*
1
1..*
1
maintain
1..*
1
1..*
1
validate
Transaction
1..*
1
1..*
1
1..*
1
1..*
1
authorize
User
1..*
1
1..*
1own
1..*
1
1..*
1
has
1..*
1..*
1..*
1..*use
1..*1..*
1..*
1..*
1..*
1..*
perform
activate
1
1 1..*
Withdraw
AmountCashLimit
RequestAmount()CompareCashLimit()
FastCashWithdraw
FastCashAmount
Card
CardNumberPIN
Account
AccountNumberTypeBalance
Withdraw()Open()Close()
ATM
ATMIDOwnerBank
DisplayOptions()ReadCard()DispenseCash()PrintReceipt()EjectCard()RequestPIN()ReadPIN()ActivateSession()Activate()
1..*
1..*
1..*
1..*
trasnfer information
Session
SessionID
RequestValidation()ReceiveValidation()ConfirmValidation()
1..*
1
1..*
1
has
Bank
BankCodeName
ValidateUser()AuthorizeTransaction()
(from Use Case View)
1..*
1
1..*
1
manage
1..*
1
1..*
1
maintain
1..*
1
1..*
1
validate
Transaction
TransactionIDDateTime
ManageLog()RequestAuthorization()ReceiveAuthorization()ApproveWithdraw()
1..*
1
1..*
1
1..*
1
1..*
1
authorize
User
SSNFirstNameLastName
Address
InsertCard()TypePIN()
CollectReceipt()CollectCard()
Select()EnterAmount()CollectCash()
(from Use Case View)1..*
1
1..*
1
own
1..*
1
1..*
1
has
1..*
1..*
1..*
1..*use
1..*
1
1..*
1
1..*
1..*
1..*
1..*
perform
FULL CLASS DIAGRAM
L. 5 - 39© A. H. LevisINCOSE
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
STATE CHART FOR ATM OBJECT CLASS
Waiting for Card
Initial State
Waiting for PIN
Card Inserted / RequestPIN()
Displaying Options
Waiting for Authorization
Dispensing Cash
Printing Reciept and Returning Card
User Collects Money / PrintReceipt(), EjectCard()
Waiting for Validation
PIN Entered / ActivateSession()
User Select Transaction / Activate(Transaction)
Validation Received[ User Validated ] / DisplayOptions()
Validation Received[ User NotValidated ] / PrintReceipt(), EjectCard()
Authorization Received[ Transaction Authorized ] / DispenseCash()Authorization Received
[ Transaction NotAuthorized OR Amount > Limit ]
User collects card and receipt
L. 5 - 41© A. H. LevisINCOSE
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.