[]{.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 Business Systems{.type}
Activity Diagram {#activity-diagram .title}
Activity diagrams are suitable to show the internal processes of a business system. Contrary to activity diagrams of the external view, in activity diagrams of the internal view the relationships to actors are no longer the focal point.
Activity diagrams of the internal view are also suitable as a basis for instructions.
Reading Activity Diagrams
The reading instructions in previous Activity Diagrams section, can be used for activity diagrams of the internal view.
Constructing Activity Diagrams
Essentially, the construction of activity diagrams of the internal view takes place exactly like the construction of activity diagrams of the external view.
The following checklist and the explanations of the individual steps are adapted to the modified view.
Checklist 3.11 Constructing Activity Diagrams in the Internal View
- Collect information sources---How am I supposed to know that?
- Find activities and actions---Which activities have to be performed so that the goods and services utilized by actors can be provided and delivered?
- Adopt actors from business use cases---Who is responsible for each action?
- Connect actions---In which order are actions processed?
- Refine activities---Do any other activity diagrams have to be added?
- Verify the view---Is everything correct?
Collect Information Sources---How am I Supposed to Know That?
When constructing activity diagrams of the internal view, the same directions as in previous Constructing Use Case Diagrams section, hold true in order to obtain the necessary information.
Find Activities and Actions---Which Activities Have to be Performed so that the Goods and Services Utilized by Actors can be Provided and Delivered?
Here, we can borrow from use cases and actions of activity diagrams of the external view. We have to ask the following question for the individual business processes that are depicted in the external view: How does the internal processing take place and what do the internal business processes look like? Answering the following questions will help you find activities and actions:
- Which work steps have to be performed by employees of the business system to provide and deliver a service?
- What does each employee do?
- Which outside events initiate which activities and actions?
Often, we can find pre-existing documentation of flows, either informal or structured, that we can use to find activities.
Adopt Actors from Business Use Cases---Who is Responsible for Each Action?
Predominantly, workers and organization units from the package diagram are responsible for the actions. Actors from use case diagrams are also used, as long as they are involved in the depicted business processes.
Each worker, each organization unit, and each actor is responsible for certain activities and is inserted into an activity partition (swimlane) as the responsible party. The individual actions are assigned to these responsibilities.
If activity diagrams are refined, it is possible that other areas of responsibility will be added, for example, individual positions or teams.
Connect Actions---In Which Order are Actions Processed?
Connecting the individual actions in a flow generates an initial activity diagram, which describes internal business processes. The following questions help with the construction of the control flow:
- In which order are actions processed?
- Which conditions have to be met in order for an action to be executed?
- Where are branches necessary?
- Which actions occur simultaneously?
- Is the completion of some actions necessary before the flow can proceed to other actions?
Refine Activities---Do any Other Activity Diagrams Have to be Added?
It is possible that individual actions have to be further divided or refined with other activity diagrams. Different scenarios are also described in other activity diagrams.
Verify the View---Is Everything Correct?
Activity diagrams of the internal view also have to be verified in terms of correctness of content. This should be done in collaboration with knowledge carriers.
Checklist 3.12 Verifying Activity Diagrams of the Internal View
- When constructing activity diagrams of the external view, always remember that only internal procedures and business processes are relevant.
- The conditions of different outputs of a decision node should not overlap. Otherwise, the control flow is ambiguous---it is not clear where the flow proceeds after a decision node.
- The conditions have to 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.
In the following Figure 3.40 depicts an activity diagram that represents the internal processing of the activities accepting luggage during check-in by passenger services:
The activity accepting luggage, as shown in Figure 3.40, is carried out by passenger services. It is not important for the passenger or for baggage transportation which actions are performed in what way. The passenger is only interested in whether his or her carry-on is too big and if he or she has to pay for excess weight; baggage transportation needs labels on each piece of luggage. All other details that are shown in the diagram are internal processing details of passenger services and will therefore be labelled as ‘internal view’.
Read next
Modeling IT Systems []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Constructing Class Diagrams{.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 Business Systems{.type}
Activity Diagram {#activity-diagram-1 .title}
Activity diagrams are suitable to show the internal processes of a business system. Contrary to activity diagrams of the external view, in activity diagrams of the internal view the relationships to actors are no longer the focal point.
Activity diagrams of the internal view are also suitable as a basis for instructions.
Reading Activity Diagrams
The reading instructions in previous Activity Diagrams section, can be used for activity diagrams of the internal view.
Constructing Activity Diagrams
Essentially, the construction of activity diagrams of the internal view takes place exactly like the construction of activity diagrams of the external view.
The following checklist and the explanations of the individual steps are adapted to the modified view.
Checklist 3.11 Constructing Activity Diagrams in the Internal View
- Collect information sources---How am I supposed to know that?
- Find activities and actions---Which activities have to be performed so that the goods and services utilized by actors can be provided and delivered?
- Adopt actors from business use cases---Who is responsible for each action?
- Connect actions---In which order are actions processed?
- Refine activities---Do any other activity diagrams have to be added?
- Verify the view---Is everything correct?
Collect Information Sources---How am I Supposed to Know That?
When constructing activity diagrams of the internal view, the same directions as in previous Constructing Use Case Diagrams section, hold true in order to obtain the necessary information.
Find Activities and Actions---Which Activities Have to be Performed so that the Goods and Services Utilized by Actors can be Provided and Delivered?
Here, we can borrow from use cases and actions of activity diagrams of the external view. We have to ask the following question for the individual business processes that are depicted in the external view: How does the internal processing take place and what do the internal business processes look like? Answering the following questions will help you find activities and actions:
- Which work steps have to be performed by employees of the business system to provide and deliver a service?
- What does each employee do?
- Which outside events initiate which activities and actions?
Often, we can find pre-existing documentation of flows, either informal or structured, that we can use to find activities.
Adopt Actors from Business Use Cases---Who is Responsible for Each Action?
Predominantly, workers and organization units from the package diagram are responsible for the actions. Actors from use case diagrams are also used, as long as they are involved in the depicted business processes.
Each worker, each organization unit, and each actor is responsible for certain activities and is inserted into an activity partition (swimlane) as the responsible party. The individual actions are assigned to these responsibilities.
If activity diagrams are refined, it is possible that other areas of responsibility will be added, for example, individual positions or teams.
Connect Actions---In Which Order are Actions Processed?
Connecting the individual actions in a flow generates an initial activity diagram, which describes internal business processes. The following questions help with the construction of the control flow:
- In which order are actions processed?
- Which conditions have to be met in order for an action to be executed?
- Where are branches necessary?
- Which actions occur simultaneously?
- Is the completion of some actions necessary before the flow can proceed to other actions?
Refine Activities---Do any Other Activity Diagrams Have to be Added?
It is possible that individual actions have to be further divided or refined with other activity diagrams. Different scenarios are also described in other activity diagrams.
Verify the View---Is Everything Correct?
Activity diagrams of the internal view also have to be verified in terms of correctness of content. This should be done in collaboration with knowledge carriers.
Checklist 3.12 Verifying Activity Diagrams of the Internal View
- When constructing activity diagrams of the external view, always remember that only internal procedures and business processes are relevant.
- The conditions of different outputs of a decision node should not overlap. Otherwise, the control flow is ambiguous---it is not clear where the flow proceeds after a decision node.
- The conditions have to 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.
In the following Figure 3.40 depicts an activity diagram that represents the internal processing of the activities accepting luggage during check-in by passenger services:
The activity accepting luggage, as shown in Figure 3.40, is carried out by passenger services. It is not important for the passenger or for baggage transportation which actions are performed in what way. The passenger is only interested in whether his or her carry-on is too big and if he or she has to pay for excess weight; baggage transportation needs labels on each piece of luggage. All other details that are shown in the diagram are internal processing details of passenger services and will therefore be labelled as ‘internal view’.
Read next
Modeling IT Systems []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Constructing Class Diagrams{.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.