Presentation on theme: "C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES"— Presentation transcript:
1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 5OBJECT ORIENTATION FOR ARCHITECTING:A CANDIDATE PROCESSLEE W. WAGENHALSALEXANDER H. LEVIS1
2 OUTLINE Introduction - Need for a process An OO Process Example Summary2
3 CONCEPTUAL PROBLEMSWe 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 descriptionsThe goal of most OO texts is to develop software, not architecturesTwo 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 MISSIONOPERATIONALCONCEPTUSE CASE ANALYSISPHYSICALARCHITECTUREVIEWORGANIZATIONMODELLOGICAL ARCHITECTUREVIEWUnless 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
6 A DETAILED VIEW MISSION OPERATIONAL CONCEPT TECHNICAL ARCHITECTURE VIEWORGANIZATIONMODELLOGICALARCHITECTURE VIEWPHYSICALARCHITECTURE VIEWBEHAVIORALDIAGRAMS(inc.Rule Model)CLASS DIAGRAMDATA DICT.EVALUATIONPHASEEXECUTABLEMODELMOPs, MOEs
7 A REQUIREMENTS VIEW MISSION OPERATIONAL CONCEPT TECHNICAL ARCHITECTURE VIEWORGANIZATIONMODELLOGICALARCHITECTUREVIEWPHYSICALARCHITECTURE VIEWBEHAVIORALDIAGRAMS(inc.Rule Model)CLASS DIAGRAMDATA DICT.EVALUATIONPHASEEXECUTABLEMODELMOPs, MOEs
8 A FIVE STAGE PROCESSA five-stage process has been developed that uses the Unified Modeling Language and the associated diagrams to design the Operational and Systems Architecture viewsThe architecture information contained in the diagrams is then mapped into the C4ISR productsNot 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 DICTIONARYALLGATHER DOMAIN INFORMATIONFORMULATE OPERATIONAL CONCEPT1DEVELOP USE CASES AND THEIRDIAGRAMS1DEVELOP BEHAVIORAL DIAGRAMS &RULE MODEL2ENSURECONCORDANCEDEPICTORGANIZATIONAL STRUCTURELOGICALDEVELOP COMPONENT DIAGRAMS3PHYSICALSYNTHESIS EXECUTABLE MODEL4DEVELOP DEPLOYMENT DIAGRAM3DESCRIBE PHYSICALARCHITECTURESTAGE 0STAGE 1STAGE 2STAGE 3STAGE 4
10 A FIVE-STAGE PROCESSSTAGE 0: Problem Definition and Collection of Domain InformationSTAGE 1: Operational Concept and Requirements; Use Cases and DiagramsSTAGE 2: Class Diagrams, Behavioral Diagrams, Rule Model, ConcordanceSTAGE 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 ArchitectureLegacy systems and their characteristicsPlanned systemsFuture systems and alternativesNote: Legacy systems and their interfaces can be thought as physical design constraints on the architecture
12 IDEF0 MODEL OF PROCESSDesignInformationSystemArchitectureA0DomainKnowledgeObject Orientation &UML GuidelinesInformation SystemPurpose: to describe a process for developing an information system architecture using Object OrientationView Point: System Architect
13 OVERALL PROCESS Object Orientation UML Guidelines Operational Concept DomainKnowledgeInformationSystemArchitectureObject OrientationUML GuidelinesDoSTAGE 1A1STAGE 2A2STAGE 3A3MaintainIntegratedDictionaryA4Operational Conceptand Use CasesUML BasedLogical ArchitecturePhysical
14 STAGE 1Once 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 descriptionThe 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.
16 STAGE 2Once 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
18 STAGE 2 (continued)It is the architect’s choice as to which model to begin withThe 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 CONCORDANCEAs with structured analysis, maintaining concordance between the model views is crucialEach 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.
21 CONCORDANCEThe links on the collaboration diagram are labeled with the messages that carry the information between the two objects.UML message formatpredecessor 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 usedMessage labels on collaboration diagrams and on sequence diagrams for the same event should match
22 CONCORDANCEThe 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.
24 STAGE 3In completing the physical architectures, use the principles that applied to structured analysisDefine system nodes and links using the operational concept and organizational features as a guideObjects are grouped into components to create component diagramsComponents are allocated to system nodes in the physical architectureAll logical associations must be instantiated with communications links
25 EXAMPLEA simple example of an Automatic Teller Machine can be used to illustrate the processThe 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 withdrawnCustomers 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: PrimaryDescription: 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 SSNFirstNameLastNameAddressInsertCard()TypePIN()CollectReceipt()CollectCard()Select()EnterAmount()CollectCash()BankBankCodeNameValidateUser()AuthorizeTransaction()FastCash Withdrawal
28 Activity Diagram of Withdrawal Use Case RequestDisplay OptionsAuthorizationInsert CardAuthorizeSelect OptionsTransactionRequest PINReceiveRequestType PINAuthorizationAmount[ Transaction NotAuthorized ][ Transaction Authorized ]Enter AmountRead PINDispense CashRequestCompare Cash LimitCollect Cash[ Amount < CashLimit ]Validate UserPrint Receipt[ Amount > CashLimit ]and Eject CardReceive Validation[ User Validated ][ User NotValidated ]Collected Receipt and CardNewState2
29 INITIAL CLASS DIAGRAM OF ATM transfer informationuse1..*1..*1..*1..*1111own11UserCard(from Use Case View)1has1..*1..*participateperform1..*1..*111..*1..*11manage1..*1..*Account11validate1..*1..*11Session1..*1..*Bankauthorize11maintain1..*1..*1..*1..*1..*1..*1..*1..*ATM1..*Transaction1..*1..*1..*1..*WithdrawFastCashWithdraw
30 ALLOCATE ACTIVITIES TO CLASSES USERBANKATMSESSIONTRANSACTION
31 Activity Diagram of Withdrawal Use Case with Swim Lanes Activities are allocated to ObjectsActivities become operationsThe connectors in the Activity Diagram correspond to Associations in Class Diagram and links in Collaboration and Sequence DiagramsMessages labels can be added
32 ADDING OPERATIONS AND ATTRIBUTES TransactionTransactionIDDateTimeManageLog()RequestAuthorization()ReceiveAuthorization()ApproveWithdraw()WithdrawalAmountCashLimitRequestAmount()CompareCashLimit()FastCashWithdrawalFastCastAmountOperations derived from Activity ModelAttributes defined as needed based on rule model
33 RULE MODEL Based on the Activity Diagram Developed in the same manner as for Structured AnalysisUse Structure English, Decision Tables and TreesRules apply only to the lowest level of decomposition in the Activity DiagramEnsure each Clause of rule matches either:Attribute of ObjectMessage sent to the object (calling the activity/operation)Message or return from the object’s activity/operationAs 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: ATMInsertCard()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 DIAGRAMShows the sequence for messages between objects for the use caseMust match the Activity Diagram in structureEmphasis is on the messages rather than the activitiesMessages 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(): User21: EjectCard()22: PrintReceipt(): Bank1: InsertCard()3: TypePIN()9: Select (Withdraw)18: CollectCash()20: Select (Quit)4: ActivateSession(CardNumber, PIN): ATM: Session7: 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 ATMuse1..*1..*1..*1..*11own11UserCardhas1..*1..*perform1..*1..*1111manage1..*1..*Account1validate1..*1..*1111..*1..*SessionBankauthorize111..*maintain11..*1..*1..*1..*1..*1..*11..*1..*activateATM1..*Transaction1..*1..*Class Diagram is a composite overlay of the collaboration diagrams1..*1..*11WithdrawFastCashWithdrawhas
38 FULL CLASS DIAGRAM Withdraw Card Account ATM 1..* Session 1 1..* 1..* AmountCashLimitRequestAmount()CompareCashLimit()FastCashWithdrawFastCashAmountCardCardNumberPINAccountAccountNumberTypeBalanceWithdraw()Open()Close()ATMATMIDOwnerBankDisplayOptions()ReadCard()DispenseCash()PrintReceipt()EjectCard()RequestPIN()ReadPIN()ActivateSession()Activate()1..*trasnfer informationSessionSessionIDRequestValidation()ReceiveValidation()ConfirmValidation()1hasBankBankCodeNameValidateUser()AuthorizeTransaction()(from Use Case View)managemaintainFULL CLASS DIAGRAMuse1..*1..*11111..*1..*ownUser111..*1..*(from Use Case View)SSNFirstNamehasLastNameAddressInsertCard()TypePIN()CollectReceipt()CollectCard()performSelect()EnterAmount()CollectCash()1..*1..*1111validate1..*1..*authorize1..*1..*111..*1..*1..*1..*1..*1..*TransactionTransactionIDDateTime1..*1..*ManageLog()RequestAuthorization()ReceiveAuthorization()ApproveWithdraw()
39 STATE CHARTSState Charts (or State Transition Diagrams) should be created for each Object ClassNote that this is different from our approach with Structure Analysis where Dynamics Models are produced for the entire systemSame rules apply and concordance must be maintainedStates are consistent with other behavioral diagramsTransitions 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 StateWaiting forCardCard Inserted / RequestPIN()Waiting forPINValidation Received[ User NotValidated ] /PrintReceipt(), EjectCard()PIN Entered / ActivateSession()Waiting forValidationValidation Received[ User Validated ] / DisplayOptions()DisplayingUser collects card and receiptOptionsUser Select Transaction / Activate(Transaction)Waiting forAuthorizationAuthorization Received[ Transaction Authorized ] / DispenseCash()Authorization Received[ Transaction NotAuthorizedOR Amount > Limit ]DispensingCashUser Collects Money / PrintReceipt(), EjectCard()Printing Reciept andReturning Card
41 SUMMARYWe have demonstrated a candidate process by which the Object-Oriented paradigm can be applied to the architecture specification problemUnderstanding and maintaining Concordance and the Integrated Dictionary is absolutely necessaryTools:Rational Rose supports the creation of UML diagrams, but it does not support concordance in the manner needed for architecture developmentPtech’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.