[]{.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}
Class Diagram {#class-diagram .title}
The class diagram can be used to illustrate the structural parts of a business system, meaning the relationships between individual employees, business objects, and outside parties. We significantly simplify class diagrams on the business-model level and use only very few elements. It still holds true: less is often more!
When the manifold options of class diagrams are used, these diagrams are no longer easy to read. On the business-system level we have to act on the assumption that involved parties have little or no IT expertise and know nothing about class terminology and class diagrams. The expected advantage of UML, namely easier communication between the various involved parties, would be significantly impaired. For a deeper explanation of class diagrams, refer to Modeling IT Systems:
In class diagrams we work with only a few elements:
Class «Worker»
We have already described the class worker in Package Diagram. Those are exactly the same classes as the ones we use here in the class diagram; just as in the package diagram, they can be depicted with the worker symbol or the class symbol:
As you can see in Figure 3.34, you can state the entire path name of a class to illustrate membership of a package. In our example, the entire path signifies that the class check -in employee belongs to the package check-in, and that the package check-in belongs to the package passenger services, each divided by a double colon. The class worker is used in the class diagram to illustrate relationships with other employees, actors, and business objects.
Class «Business Object»
We have already described the class business object in Package Diagram. Those are exactly the same classes as the ones we use here in the class diagram:
Just as in the package diagram, they can be depicted with the business object symbol or the class symbol.
Association
An association represents a relationship that has a precisely defined meaning. The association can be labeled with the name of the association. If you want to assign a direction to the association’s name, you can insert a triangle that points to the direction in which the name is supposed to be read:
In addition to the above-mentioned elements, we would like to mention the generalization. However, we do not think that the use of this element is mandatory.
Generalization
A generalization is a specific relationship between a general and a specific element. Generalization and specialization help with hierarchical structuring. If several business objects are supposed to be combined to one comprehensive item, generalization is the right tool (see Figure 3.35):
However, for workers we recommend structuring in package diagrams:
Reading Class Diagrams
Figure 3.36 shows a small excerpt of a class diagram from our case study. It contains the classes check-in employee (1), ticket (2), and boarding pass (3), as well as their associations:
You can see by the label (4) of the worker symbol (1), that the check-in employee belongs to the organization unit check-in, which is a division of passenger services.
The labels that are written in front of the label for the worker, separated by double colons, indicate the organization units that the workers belong to. You can see that passenger services and check-in are organization units from the package diagram.
The labels of the business object symbols (5 and 6) show that we have two business objects: ticket (5) and boarding pass (6).
Associations between classes should be read in the following manner:
- A check-in employee (4) verifies (7) a ticket (5).
The small triangle (8) next to the name of the association (7) indicates the direction in which the name of the association is supposed to be read. All associations within class diagrams can be read in this way.
We do not use any multiplicities in class diagrams of the business-system model, meaning, for the benefit of clarity, we do not make any statements about the number of objects in classes that are involved in associations.
It is not yet important if a check-in employee issues one or several boarding passes. Important quantities can be included as comments. Quantities will be of interest later: in the IT-system model, which will be described in Modeling IT Systems.
Read next
Constructing Class Diagrams []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Constructing Package 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}
Class Diagram {#class-diagram-1 .title}
The class diagram can be used to illustrate the structural parts of a business system, meaning the relationships between individual employees, business objects, and outside parties. We significantly simplify class diagrams on the business-model level and use only very few elements. It still holds true: less is often more!
When the manifold options of class diagrams are used, these diagrams are no longer easy to read. On the business-system level we have to act on the assumption that involved parties have little or no IT expertise and know nothing about class terminology and class diagrams. The expected advantage of UML, namely easier communication between the various involved parties, would be significantly impaired. For a deeper explanation of class diagrams, refer to Modeling IT Systems:
In class diagrams we work with only a few elements:
Class «Worker»
We have already described the class worker in Package Diagram. Those are exactly the same classes as the ones we use here in the class diagram; just as in the package diagram, they can be depicted with the worker symbol or the class symbol:
As you can see in Figure 3.34, you can state the entire path name of a class to illustrate membership of a package. In our example, the entire path signifies that the class check -in employee belongs to the package check-in, and that the package check-in belongs to the package passenger services, each divided by a double colon. The class worker is used in the class diagram to illustrate relationships with other employees, actors, and business objects.
Class «Business Object»
We have already described the class business object in Package Diagram. Those are exactly the same classes as the ones we use here in the class diagram:
Just as in the package diagram, they can be depicted with the business object symbol or the class symbol.
Association
An association represents a relationship that has a precisely defined meaning. The association can be labeled with the name of the association. If you want to assign a direction to the association’s name, you can insert a triangle that points to the direction in which the name is supposed to be read:
In addition to the above-mentioned elements, we would like to mention the generalization. However, we do not think that the use of this element is mandatory.
Generalization
A generalization is a specific relationship between a general and a specific element. Generalization and specialization help with hierarchical structuring. If several business objects are supposed to be combined to one comprehensive item, generalization is the right tool (see Figure 3.35):
However, for workers we recommend structuring in package diagrams:
Reading Class Diagrams
Figure 3.36 shows a small excerpt of a class diagram from our case study. It contains the classes check-in employee (1), ticket (2), and boarding pass (3), as well as their associations:
You can see by the label (4) of the worker symbol (1), that the check-in employee belongs to the organization unit check-in, which is a division of passenger services.
The labels that are written in front of the label for the worker, separated by double colons, indicate the organization units that the workers belong to. You can see that passenger services and check-in are organization units from the package diagram.
The labels of the business object symbols (5 and 6) show that we have two business objects: ticket (5) and boarding pass (6).
Associations between classes should be read in the following manner:
- A check-in employee (4) verifies (7) a ticket (5).
The small triangle (8) next to the name of the association (7) indicates the direction in which the name of the association is supposed to be read. All associations within class diagrams can be read in this way.
We do not use any multiplicities in class diagrams of the business-system model, meaning, for the benefit of clarity, we do not make any statements about the number of objects in classes that are involved in associations.
It is not yet important if a check-in employee issues one or several boarding passes. Important quantities can be included as comments. Quantities will be of interest later: in the IT-system model, which will be described in Modeling IT Systems.
Read next
Constructing Class Diagrams []{.fa .fa-arrow-right}{.btn .btn-primary rel=“next”}
Return
[]{.fa .fa-arrow-left} Constructing Package 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.