[]{.cart-text} {.btn .cart .open-checkout} []{.btn-text-span .d-none .d-sm-inline-block .d-lg-none .d-hg-inline-block}{.btn .btn-secondary .checkout .open-checkout}
{.home} / UML{.type} / Modeling for System Integration{.type}
Constructing Diagrams in the Process View {#constructing-diagrams-in-the-process-view .title}
To construct diagrams in the process view, we chose the interface to baggage transportation from our case study.
The following checklist shows the necessary steps from constructing activity diagrams and sequence diagrams in the process view:
Checklist 5.1 Constructing Diagrams in the Process View
- Determine interfaces---Between which IT systems should communication take place?
- Identify involved systems---Which IT systems exchange information?
- Identify activities and control flow---What has to be done and who is responsible for it?
- Define messages---Which messages have to be exchanged?
- Define rules---What influences actions?
- Verify the view---Is everything correct?
Determine Interfaces---Between Which IT Systems Should Communication Take Place?
To carry out the activity no boarding (Figure 5.11) those business processes or business use cases that require an interaction with the IT system of passenger services in order to be processed are chosen from the business system model. In our case study, this applies to the use case request passenger list, which has an interface each to baggage transportation and customs at the destination airport. To illustrate the following steps, we will look at the interface to baggage transportation (see Figure 5.3).
We select the actions from the activity no boarding that are connected to the exchange of messages:
On the basis of Figure 5.11, we identify the following actions:
- Request passenger list
- Accept request for passenger list
- Generate passenger list
- Send passenger list
- Accept passenger list
- Confirm execution of unloading luggage
- Accept confirmation of unloading luggage
From the sequence diagram of the business model in Figure 5.8, we can see that the following two messages are exchanged:
- Send passenger list (passenger list)
- Confirm (passenger list)
Identify Involved Systems---Which IT Systems Exchange Information?
In order for messages to be sent and received, it has to be known which IT systems are involved and what roles they play:
- Which IT systems are needed for the execution of business processes? Certainly, our passenger services IT system (1) is involved. The IT systems outside the business system can be derived from the actors of the use case diagram of the business model. This is how we found the IT system of the actor baggage transportation (2) in our case study, as shown in Figure 5.12:
- Which IT system initiates the process? The process initiator is baggage transportation (2). Independently from the boarding of passenger services, a timer within baggage transportation (set to 10 minutes before EDT), requests a passenger list of passengers who have not yet boarded, so that the unloading of luggage can take place.
- Which IT system is at the end of the process? In our case study, the activity no boarding is completed when passenger services (1) receive a message from baggage transportation that all luggage from passengers who are not yet on board has been unloaded from the plane.
With this information we can start constructing the activity diagram (Figure 5.13):
Identify Activities and Control Flow---What has to be Done and Who is Responsible for It?
The following questions will help identify actions and the control flow:
- What needs to be done so that the IT system can exchange messages?
- In which order are activities processed?
- Are there actions that occur simultaneously?
- Which conditions have to be met for the execution of actions?
- Do all prior actions have to be completed before the next one can be completed?
- Who is responsible for processing the actions? In which partition do the actions belong?
The action … …is processed by actor…
Request passenger list (1) Baggage transportation Accept request for passenger list (2) Passenger services Send passenger list (3) Passenger services Accept passenger list (4) Baggage transportation Confirm execution of unloading luggage (5) Baggage transportation Accept confirmation of unloading luggage (6) Passenger services
This information is documented in the sequence diagram in Figure 5.14 and in the activity diagram in Figure 5.15:
Define Messages---Which Messages have to be Exchanged?
We can see in the business system model that two messages are exchanged:
- Send passenger list (passenger list)
- Confirm (passenger list)
In the first message send passenger list in Figure 5.16, a passenger list (7) is sent to the IT system of baggage transportation (2), which lists all passengers who have checked in, but have not yet boarded the airplane.
Once the affected pieces of luggage have been unloaded, passenger services (1) receive a confirmation (5). With the confirmation, the passenger list (8) is sent back to passenger services (1).
Both messages receive the passenger list (7) (8) as argument. In our case, the passenger list was forwarded from passenger services (1) to baggage transportation (2), modified there, and sent back to passenger services (1).
At the end, the passenger list is not exactly the same as it was at the beginning of the activity. However, the structure of the business object, Passenger List, remains the same:
You can see in Figure 5.17 that the object flow, which runs just like the control flow, hides the control flow:
Define Rules---What Influences Actions?
Generally, contracts exist for inter-organization message exchange, which record agreements about responsibilities, regulations, etc. International treaties and statutes further influence this kind of message exchange. On the technical as well as statutory level, standards committees regulate rules about data exchange. (As an example, we recommend the relevant specification Collaboration-Protocol Profile and Agreement Specification Version 2.0 by ebXML.)
As another example, we want to mention International Air Transport Association (IATA), which among other things defines messages and their uses for the entire aerospace industry. Such agreements are also becoming more frequent within organizations. The question is:
- Which agreements, contracts, and statutes have to be taken into consideration for the definition of data exchange?
Verify the View---Is Everything Correct?
Completed sequence diagrams and activity diagrams can be verified with the following checklist:
Checklist 5.2 Verifying Sequence Diagram in the Process View
- Are all messages that require confirmation listed with a confirmation in the sequence diagram?
- Is every IT system/every business partner that is involved in the exchange of messages listed in at least one sequence diagram?
- Are all exchanged business objects listed in the sequence diagrams as message arguments?
- Are all important comments inserted into the diagram? Are there perhaps too many comments inserted into the diagram, which reduce the clarity of the diagram?
- Does the message flow correspond to the object flow in the activity diagram?
Checklist 5.3 Verifying Activity Diagrams in the Process View
- When you construct activity diagrams in the process view, remember that only the flows that are involved in the message exchange are relevant. Business processes belong in the business model.
- Is the object flow clearly visible? Are all business objects listed in the activity diagram?
- The conditions of different outputs should not overlap. Otherwise, the control flow is ambiguous, meaning that it is not clear where the flow proceeds at a decision node.
- The conditions must include all possibilities. Otherwise, the control flow can get stuck. In case of doubt, insert an output with the condition “else”.
- Forks and joins should be well balanced. The number of flows that leave a fork should match the number of flows that end in the corresponding join.
Read next
The Static View []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Sequence Diagram{.btn .btn-default rel=“prev”}
Computer Science Distilled{.btn .btn-landing-ref .btn-hg .btn-block .btn-secondary style=“font-size: 16px; position: relative”}
Do you remember anything at all from your computer science class? Quicksort, Graph traversal, Big’O and other stuff? Revise your memories with our new book on Computer Science.
Psst! Did I mention that we’re offering sexy discounts right now?
{width=“250”
height=“312”
srcset=“/images/content-public/logos/logo-2x.png?id=fee3b4b0a14ba60dc0fe368695d78be9 2x”}{.menu-brand}
- Premium Stuff
- Design Patterns
- AntiPatterns
- Refactoring
- Code Smells
- Refactoring techniques
- Composing Methods
- Moving Features between Objects
- Organizing Data
- Self Encapsulate Field
- Replace Data Value with Object
- Change Value to Reference
- Change Reference to Value
- Replace Array with Object
- Duplicate Observed Data
- Change Unidirectional Association to Bidirectional
- Change Bidirectional Association to Unidirectional
- Replace Magic Number with Symbolic Constant
- Encapsulate Field
- Encapsulate Collection
- Replace Type Code with Class
- Replace Type Code with Subclasses
- Strategy
- Replace Subclass with Fields
- Simplifying Conditional Expressions
- Simplifying Method
Calls
- Rename Method
- Add Parameter
- Remove Parameter
- Separate Query from Modifier
- Parameterize Method
- Replace Parameter with Explicit Methods
- Preserve Whole Object
- Replace Parameter with Method Call
- Introduce Parameter Object
- Remove Setting Method
- Hide Method
- Replace Constructor with Factory Method
- Replace Error Code with Exception
- Replace Exception with Test
- Dealing with Generalisation
- UML
- Introduction
- Basic Principles and Background
- Modeling Business Systems
- Business Processes and Business Systems
- One Model---Two Views
- External View
- The Elements of a View
- Use Case Diagrams
- Constructing Use Case Diagrams
- Activity Diagrams
- Constructing Activity Diagrams
- Sequence Diagrams
- Constructing Sequence Diagrams
- High-Level Sequence Diagrams
- Sequence Diagrams for Scenarios of Business Use Cases
- Internal View
- Package Diagram
- Constructing Package Diagrams
- Class Diagram
- Constructing Class Diagrams
- Activity Diagram
- Modeling IT Systems
- External View
- The User View or “I don’t care how it works, as long as it works.”
- The Elements of a View
- Use Case Diagram
- Query Events and Mutation Events
- Use Case Sequence Diagram
- Constructing the External View
- Structural View
- Objects and Classes
- Generalization, Specialization, and Inheritance
- Static and Dynamic Business Rules
- Elements of the View
- Class Diagram
- Constructing Class Diagrams
- The Behavioral View
- The Life of an Object
- The Elements of the View
- Statechart Diagram
- Constructing Statechart Diagrams
- Interaction View
- Seeing What Happens Inside the IT System
- Elements of the View
- Communication Diagram
- Sequence Diagram
- Constructing Communication Diagrams
- Constructing Sequence Diagrams
- Modeling for System
Integration
- Terminology of System Integration
- Messages in UML
- One Model---Two Views
- Process View
- The Business System Model as Foundation
- Elements of the View
- Activity Diagrams
- Sequence Diagram
- Constructing Diagrams in the Process View
- The Static View
- Elements of the View
- Class Diagram
- Constructing Class Diagrams
- Transforming Data from the IT System to the Message “passenger list”
- Transformation of UML Messages into Various Standard Formats
Log in Contact us{.userecho-public rel=“nofollow”}
{srcset=“/images/content-public/logos/logo-min-xs-2x.png?id=34fc05750336c33b7815e231a0f227df 2x”}{.navigation-brand}
Shop Now!{.btn .btn-md .btn-primary .btn-featured}
-
[Contact us]{.caption .d-none .d-xl-inline-block}{.userecho-private rel=“nofollow”}
-
Forum{.userecho-public rel=“nofollow”}
-
Contact us{.userecho-private rel=“nofollow”}
© 2007-2023 SourceMaking.com[ / ]{.d-none .d-md-inline}
All rights reserved.
[]{.cart-text} {.btn .cart .open-checkout} []{.btn-text-span .d-none .d-sm-inline-block .d-lg-none .d-hg-inline-block}{.btn .btn-secondary .checkout .open-checkout}
{.home} / UML{.type} / Modeling for System Integration{.type}
Constructing Diagrams in the Process View {#constructing-diagrams-in-the-process-view-1 .title}
To construct diagrams in the process view, we chose the interface to baggage transportation from our case study.
The following checklist shows the necessary steps from constructing activity diagrams and sequence diagrams in the process view:
Checklist 5.1 Constructing Diagrams in the Process View
- Determine interfaces---Between which IT systems should communication take place?
- Identify involved systems---Which IT systems exchange information?
- Identify activities and control flow---What has to be done and who is responsible for it?
- Define messages---Which messages have to be exchanged?
- Define rules---What influences actions?
- Verify the view---Is everything correct?
Determine Interfaces---Between Which IT Systems Should Communication Take Place?
To carry out the activity no boarding (Figure 5.11) those business processes or business use cases that require an interaction with the IT system of passenger services in order to be processed are chosen from the business system model. In our case study, this applies to the use case request passenger list, which has an interface each to baggage transportation and customs at the destination airport. To illustrate the following steps, we will look at the interface to baggage transportation (see Figure 5.3).
We select the actions from the activity no boarding that are connected to the exchange of messages:
On the basis of Figure 5.11, we identify the following actions:
- Request passenger list
- Accept request for passenger list
- Generate passenger list
- Send passenger list
- Accept passenger list
- Confirm execution of unloading luggage
- Accept confirmation of unloading luggage
From the sequence diagram of the business model in Figure 5.8, we can see that the following two messages are exchanged:
- Send passenger list (passenger list)
- Confirm (passenger list)
Identify Involved Systems---Which IT Systems Exchange Information?
In order for messages to be sent and received, it has to be known which IT systems are involved and what roles they play:
- Which IT systems are needed for the execution of business processes? Certainly, our passenger services IT system (1) is involved. The IT systems outside the business system can be derived from the actors of the use case diagram of the business model. This is how we found the IT system of the actor baggage transportation (2) in our case study, as shown in Figure 5.12:
- Which IT system initiates the process? The process initiator is baggage transportation (2). Independently from the boarding of passenger services, a timer within baggage transportation (set to 10 minutes before EDT), requests a passenger list of passengers who have not yet boarded, so that the unloading of luggage can take place.
- Which IT system is at the end of the process? In our case study, the activity no boarding is completed when passenger services (1) receive a message from baggage transportation that all luggage from passengers who are not yet on board has been unloaded from the plane.
With this information we can start constructing the activity diagram (Figure 5.13):
Identify Activities and Control Flow---What has to be Done and Who is Responsible for It?
The following questions will help identify actions and the control flow:
- What needs to be done so that the IT system can exchange messages?
- In which order are activities processed?
- Are there actions that occur simultaneously?
- Which conditions have to be met for the execution of actions?
- Do all prior actions have to be completed before the next one can be completed?
- Who is responsible for processing the actions? In which partition do the actions belong?
The action … …is processed by actor…
Request passenger list (1) Baggage transportation Accept request for passenger list (2) Passenger services Send passenger list (3) Passenger services Accept passenger list (4) Baggage transportation Confirm execution of unloading luggage (5) Baggage transportation Accept confirmation of unloading luggage (6) Passenger services
This information is documented in the sequence diagram in Figure 5.14 and in the activity diagram in Figure 5.15:
Define Messages---Which Messages have to be Exchanged?
We can see in the business system model that two messages are exchanged:
- Send passenger list (passenger list)
- Confirm (passenger list)
In the first message send passenger list in Figure 5.16, a passenger list (7) is sent to the IT system of baggage transportation (2), which lists all passengers who have checked in, but have not yet boarded the airplane.
Once the affected pieces of luggage have been unloaded, passenger services (1) receive a confirmation (5). With the confirmation, the passenger list (8) is sent back to passenger services (1).
Both messages receive the passenger list (7) (8) as argument. In our case, the passenger list was forwarded from passenger services (1) to baggage transportation (2), modified there, and sent back to passenger services (1).
At the end, the passenger list is not exactly the same as it was at the beginning of the activity. However, the structure of the business object, Passenger List, remains the same:
You can see in Figure 5.17 that the object flow, which runs just like the control flow, hides the control flow:
Define Rules---What Influences Actions?
Generally, contracts exist for inter-organization message exchange, which record agreements about responsibilities, regulations, etc. International treaties and statutes further influence this kind of message exchange. On the technical as well as statutory level, standards committees regulate rules about data exchange. (As an example, we recommend the relevant specification Collaboration-Protocol Profile and Agreement Specification Version 2.0 by ebXML.)
As another example, we want to mention International Air Transport Association (IATA), which among other things defines messages and their uses for the entire aerospace industry. Such agreements are also becoming more frequent within organizations. The question is:
- Which agreements, contracts, and statutes have to be taken into consideration for the definition of data exchange?
Verify the View---Is Everything Correct?
Completed sequence diagrams and activity diagrams can be verified with the following checklist:
Checklist 5.2 Verifying Sequence Diagram in the Process View
- Are all messages that require confirmation listed with a confirmation in the sequence diagram?
- Is every IT system/every business partner that is involved in the exchange of messages listed in at least one sequence diagram?
- Are all exchanged business objects listed in the sequence diagrams as message arguments?
- Are all important comments inserted into the diagram? Are there perhaps too many comments inserted into the diagram, which reduce the clarity of the diagram?
- Does the message flow correspond to the object flow in the activity diagram?
Checklist 5.3 Verifying Activity Diagrams in the Process View
- When you construct activity diagrams in the process view, remember that only the flows that are involved in the message exchange are relevant. Business processes belong in the business model.
- Is the object flow clearly visible? Are all business objects listed in the activity diagram?
- The conditions of different outputs should not overlap. Otherwise, the control flow is ambiguous, meaning that it is not clear where the flow proceeds at a decision node.
- The conditions must include all possibilities. Otherwise, the control flow can get stuck. In case of doubt, insert an output with the condition “else”.
- Forks and joins should be well balanced. The number of flows that leave a fork should match the number of flows that end in the corresponding join.
Read next
The Static View []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Sequence Diagram{.btn .btn-default rel=“prev”}
Computer Science Distilled{.btn .btn-landing-ref .btn-hg .btn-block .btn-secondary style=“font-size: 16px; position: relative”}
Do you remember anything at all from your computer science class? Quicksort, Graph traversal, Big’O and other stuff? Revise your memories with our new book on Computer Science.
Psst! Did I mention that we’re offering sexy discounts right now?
{width=“250”
height=“312”
srcset=“/images/content-public/logos/logo-2x.png?id=fee3b4b0a14ba60dc0fe368695d78be9 2x”}{.menu-brand}
- Premium Stuff
- Design Patterns
- AntiPatterns
- Refactoring
- Code Smells
- Refactoring techniques
- Composing Methods
- Moving Features between Objects
- Organizing Data
- Self Encapsulate Field
- Replace Data Value with Object
- Change Value to Reference
- Change Reference to Value
- Replace Array with Object
- Duplicate Observed Data
- Change Unidirectional Association to Bidirectional
- Change Bidirectional Association to Unidirectional
- Replace Magic Number with Symbolic Constant
- Encapsulate Field
- Encapsulate Collection
- Replace Type Code with Class
- Replace Type Code with Subclasses
- Strategy
- Replace Subclass with Fields
- Simplifying Conditional Expressions
- Simplifying Method
Calls
- Rename Method
- Add Parameter
- Remove Parameter
- Separate Query from Modifier
- Parameterize Method
- Replace Parameter with Explicit Methods
- Preserve Whole Object
- Replace Parameter with Method Call
- Introduce Parameter Object
- Remove Setting Method
- Hide Method
- Replace Constructor with Factory Method
- Replace Error Code with Exception
- Replace Exception with Test
- Dealing with Generalisation
- UML
- Introduction
- Basic Principles and Background
- Modeling Business Systems
- Business Processes and Business Systems
- One Model---Two Views
- External View
- The Elements of a View
- Use Case Diagrams
- Constructing Use Case Diagrams
- Activity Diagrams
- Constructing Activity Diagrams
- Sequence Diagrams
- Constructing Sequence Diagrams
- High-Level Sequence Diagrams
- Sequence Diagrams for Scenarios of Business Use Cases
- Internal View
- Package Diagram
- Constructing Package Diagrams
- Class Diagram
- Constructing Class Diagrams
- Activity Diagram
- Modeling IT Systems
- External View
- The User View or “I don’t care how it works, as long as it works.”
- The Elements of a View
- Use Case Diagram
- Query Events and Mutation Events
- Use Case Sequence Diagram
- Constructing the External View
- Structural View
- Objects and Classes
- Generalization, Specialization, and Inheritance
- Static and Dynamic Business Rules
- Elements of the View
- Class Diagram
- Constructing Class Diagrams
- The Behavioral View
- The Life of an Object
- The Elements of the View
- Statechart Diagram
- Constructing Statechart Diagrams
- Interaction View
- Seeing What Happens Inside the IT System
- Elements of the View
- Communication Diagram
- Sequence Diagram
- Constructing Communication Diagrams
- Constructing Sequence Diagrams
- Modeling for System
Integration
- Terminology of System Integration
- Messages in UML
- One Model---Two Views
- Process View
- The Business System Model as Foundation
- Elements of the View
- Activity Diagrams
- Sequence Diagram
- Constructing Diagrams in the Process View
- The Static View
- Elements of the View
- Class Diagram
- Constructing Class Diagrams
- Transforming Data from the IT System to the Message “passenger list”
- Transformation of UML Messages into Various Standard Formats
Log in Contact us{.userecho-public rel=“nofollow”}
{srcset=“/images/content-public/logos/logo-min-xs-2x.png?id=34fc05750336c33b7815e231a0f227df 2x”}{.navigation-brand}
Shop Now!{.btn .btn-md .btn-primary .btn-featured}
-
[Contact us]{.caption .d-none .d-xl-inline-block}{.userecho-private rel=“nofollow”}
-
Forum{.userecho-public rel=“nofollow”}
-
Contact us{.userecho-private rel=“nofollow”}
© 2007-2023 SourceMaking.com[ / ]{.d-none .d-md-inline}
All rights reserved.