ICT Standards and Guidelines
Segment 202
Software Applications
Modeling Systems Using the
UML
(Version 2.0)
Table of Contents – Modeling Systems Using the UML
1.0
2.0
3.0
4.0
Introducing Systems Modeling ................................................................. 1
1.1
The Construction Industry as a Role Model ........................................... 1
1.2
Clarifying the Terminology .................................................................. 2
1.2.1 What is a Modeling Language? .................................................. 2
1.2.2 What are Methods?.................................................................. 2
1.2.3 What is Methodology? .............................................................. 3
1.3
Why Should we Model Business Systems or Processes? .......................... 3
1.4
A Brief History of Modeling ................................................................. 3
1.5
What are the Main Uses of a Business Modeling Language? .................... 4
1.5.1 Reverse Engineering ................................................................ 4
1.5.2 Improving the Organization’s Business Processes ........................ 5
1.5.3 Designing Information Systems ................................................ 5
1.6
Examples of Business Modeling “Output” .............................................. 5
1.7
How Does the UML Achieve the Above Aims? ........................................ 5
1.8
Design Characteristics of the UML ....................................................... 6
1.9
The Applications of the UML ................................................................ 8
1.10 The Different Perspectives or Views of the UML ..................................... 9
The Diagrams of the UML ....................................................................... 10
2.1
Why Use Use Cases ......................................................................... 11
2.2
The Use Case Diagram ..................................................................... 11
2.2.1 What Are the Components of a Use Case Model? ....................... 12
2.2.2 Example: Description of an ATM Withdraw Cash Use Case .......... 16
2.2.3 Example: The Log In Use Case for the ATM .............................. 17
2.3
The Class Diagram: Business Objects ................................................ 18
2.3.1 The Notation of the Class Diagram .......................................... 19
2.3.2 Examples of Class Diagrams ................................................... 20
2.4
The Sequence Diagram (Applies to Use Cases) .................................... 23
2.5
The Collaboration Diagram (Applies to Use Cases) ............................... 27
2.6
The State Transition Diagram (Applies to Objects) ............................... 27
2.7
The Activity Diagram (Applies to Use Cases and to Objects) ................. 29
2.8
The Implementation Diagrams .......................................................... 34
2.8.1 The Component Diagram ........................................................ 34
2.8.2 The Deployment Diagram ....................................................... 34
How to Use the UML in a Typical Software Engineering Process ............. 35
3.1
Using the UML in the Segment .......................................................... 35
3.2
The Cycle of Analysis and Design ...................................................... 36
3.3
Initiation Phase: Modeling the AS IS or Current System Model .............. 36
3.4
Initiation Phase: Identifying the Status of the Business Processes ......... 36
3.5
Initiation Phase: Modeling the Analysis of Requirements ...................... 37
3.6
Initiation Phase: System Deployment ................................................ 37
3.7
Planning Phase: Modeling the AS IS or Current System Model............... 38
3.7.1 Developing the Use Case Diagram (System Functions): ............. 38
3.7.2 Developing the Class Diagram (Business Objects): .................... 39
3.7.3 Additional Diagrams .............................................................. 39
3.7.4 Implementation Diagrams ...................................................... 40
3.8
Planning Phase: Modeling the Functional Design .................................. 40
3.9
Planning Phase: Modeling the Technical Design ................................... 41
3.10 Planning Phase: Finalizing the Implementation Diagrams ..................... 43
3.11 Building and Transition Phases .......................................................... 43
Template for Use Case Description ......................................................... 44
5.0
Where to Learn and How to Use the UML? .............................................. 45
Figures – Modeling Systems Using the UML
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1: The Diagrams of the UML .......................................................................
2: Use Case Diagram for an ATM .................................................................
3: Using Extends in a Use Case Diagram ......................................................
4: Using Generalization in Use Case Diagrams...............................................
5:The Class Diagram for Orders ..................................................................
6: The Class Diagram for Consulting Activities ...............................................
7: The Class Diagram for a School ...............................................................
10: The Sequence Diagram for Adding a New Customer .................................
11: The State Diagram for Placing Orders .....................................................
12: Activity Diagram For Orders (Showing Objects) .......................................
13: Activity Diagram to Model a Method .......................................................
14: Activity Diagram Showing Swimlanes by Object .......................................
10
13
14
15
20
21
22
26
28
31
32
33
1.0
Introducing Systems Modeling
The main purpose of Modeling is to use a graphic/textual or diagrammatic language to
express or document the workings of business systems and processes. Such
documentation can be used to:







Produce procedures manuals
Develop training material
Analyze systems and processes when attempting to improve them
Analyze systems or processes that are to be automated
Design workflows
Audit systems and procedures
Investigate troublesome areas in operations
Most of the above uses are of major importance to Software Engineering Processes. This
includes the cases where an organization may acquire the software application off the
shelf as well as when that application is to be developed, internally or externally.
1.1
The Construction Industry as a Role Model
Every business organization has the right to envy the Construction Industry which is
very old. Throughout its 5000 years of experience, it developed a Modeling technique
that resolved all its communications problems.
Architects and Engineers use a highly sophisticated modeling language (Technical
Drawing) that expresses exactly how their new products are going to be built. On
building the new Bridge or Power Station, engineers can document the product, modify it
and update it. The basis of communication is the Technical Drawing, a language that has
become an international industry standard. With this language, the customer, the
developer (Architect), the builder (Contractor), the supplier and all stakeholders have a
detailed and precise understanding of the final product. Furthermore, the Architect using
the language, has a design tool in his hands that allows him to convert the requirements
to a final technical design.
The Business World is very much behind. Up until the early 80’s, no significant language
was found that could model a business process. Primitive flowcharts described workflow
but were very far from useful because:







The flowcharts could not be used to build or rebuild a business process or system
There was no international standard to use
The flowcharts did not cover the whole process or business and where always
short of the full description
The flowcharts were complex and could not be easily visualized
The flowcharts were too technical. Users could not understand them
The modeling techniques did not reflect the way the business “thought”
Modeling techniques, such as Data Flow Diagrams, reflected the way computers
worked and not the way users saw their systems and processes.
This can lead to various disputes and misunderstandings.
Modeling Business Systems Using the UML
Page 1
1.2
Clarifying the Terminology
There are many modeling techniques that use the terms Language, Method and
Methodology. There are major differences between these three terms and these should
be clarified before introducing Business Modeling.
1.2.1 What is a Modeling Language?
A Language describes a Business System. It is used to communicate the Business
System’s processes to the various stakeholders. Many languages can model the same
system. A Language is therefore a means of expression and does not contribute to the
way a business system or process works. It just describes them.
Examples of languages:



The construction sector uses technical drawings to define buildings and other
constructs
The electronics industry has a special language to describe electronic circuitry.
Using a circuit diagram allows the engineers to define the way an amplifier works.
The Unified Modeling Language (UML) to be described in later sections is a
language used to express how a business or technical system works.
1.2.2 What are Methods?
Methods are the techniques used to take a System from one stage to the next. An
architect produces a Drawing. The Drawing Standard is the Language he uses to
communicate his designs. An architect designs a building by placing rooms together in a
usable / pleasing way and making sure that the building follows engineering standards to
be safe. How the architect designs the buildings is the engineering method. That is a
technique. A method achieves a conversion. It takes a concept from one state to
another.
Examples of methods:





An architect uses civil engineering principles to design a building. These principles
are made up of various engineering methods.
An electronic engineer uses the principles of physics and electronics to design a
mobile telephone. When designing such equipment, he uses engineering
methods.
A Software Application designer uses a specific method to convert user
Requirements to a Functional Design. The designer will also use other methods to
convert the Functional Design to a Technical Design. Such methods as database
design, interface design, etc, are all technical methods to be used when
converting the required concepts to a final software product.
A Programmer uses a method to convert the Technical Specifications to
Executable Code. This method is made up of programming principles and
techniques.
A financial analyst uses Activity Based Costing as a method of assessing the costs
of individual activities in an organization.
In software applications, how we go from requirement to code is made up of a set of
methods. We need a language to communicate our interim thoughts and ideas.
Modeling Business Systems Using the UML
Page 2
Each one of these is a “Technology” or an “Engineering”. These technicians need a
language to describe their systems.
1.2.3 What is Methodology?
Having identified a method, we need to describe to others. The description of the
method is called a Methodology. Methodology is therefore a statement telling the
stakeholders “How we plan to work” or “how or methods will be used”.
Example:
Language: we use the Entity Relationship Diagram to describe our database Structure.
The ERD diagram is a language and results in a map showing all tables, their data
elements and their relationships.
Method: we use the principles of Relational Database Management to design such
databases (Codd’s rules on normalization, etc)
Methodology: to explain to a reader what Language and Method we are using.
1.3
Why Should we Model Business Systems or Processes?
We resort to modeling business systems and processes for the following reasons:








1.4
To understand and document existing systems
To design and build new systems and procedures
To communicate more effectively with: customers, users, contractors, owners and
all other stakeholders
To concentrate on separate views of a system
Because we cannot understand complex systems in their entirety
Because modeling is cheaper, faster and more flexible than real life
implementation
To reuse components of the model in other systems
Because the Mind can visual objects more easily than text
A Brief History of Modeling
In the early 80’s, the experiences and objectives of 3 major technologies converged:



Business Organization and Improvements techniques
Software Engineering Process Methodologies and
Object Oriented Programming
Towards the beginning of the 90’s, the major methodologists in these areas found
themselves getting very close to each other.
They were all in search of methods that can make their work efficient, standardized and
easy to learn. Many methods were developed and tried. Competitive standards arose
each espoused by different industries and different cliques.
Modeling Business Systems Using the UML
Page 3
By the mid 80’s, the Object Management Group, a body that is concerned with the
development of standards in the ICT industry, issued a Request for Proposal for a
universal modeling language.
In a major and positive development, various competitors joined hands and started
working together. The result was the Unified Modeling Language or the UML which
was officially accepted by the Object Management Group towards the end of 1997.
The UML is therefore not a new “craze” but the product of years of cooperation,
experience, consensus and maturity.
This language became the basis of Business Modeling. The UML itself is not a method. It
is just a means of expressing the processes in a business system. It is a way of
expressing or modeling systems without any imposition being made on the way these
systems are designed or developed.
It can be seen that the UML was a product of:




Consensus
Cooperation
Experience and
Maturity
Today, the UML is being used in ICT applications, other business systems as well as
technical environments (Design of technical equipment such as mobile phones, ATMs,
etc).
1.5
What are the Main Uses of a Business Modeling Language?
A “Business System” or a “Business Process” is a set of procedures that covers a global
objective within an organization. Examples of processes or business systems:





The Leave Planning and Control System is a process.
Purchasing from the time a material request is placed until the time that the
goods arrive at the stores is another business system or process.
Requesting a loan is a process
The Human Resources Information System is a business system
The billing of power bills is a business system.
An organization can model its Business Systems and Processes for 3 main purposes:
1.5.1 Reverse Engineering
This is the documentation of the current situation of a Business System or its As Is
status. From such a base line, an enterprise can document is processes and business
flow. These models will have the following objectives:





To
To
To
To
To
provide an official document that presents how the business operates
allow analysts to understand the systems and how they operate
train new staff or refresh existing staff on the procedures
familiarize outsiders with the system (Auditors, Software experts, etc)
use the As Is models to modify the systems and improve them
Modeling Business Systems Using the UML
Page 4

To use the As Is models as the basis for automating the processes
Reverse Engineering becomes the first step in the “Communications” process expressing
the Business System or Process in clear models.
Note that Reverse Engineering can be used to document a system for the purpose of
providing Procedure Manuals.
1.5.2 Improving the Organization’s Business Processes
Having modeled the As Is situation, the models provide a natural way of viewing the
enterprise, a way which identifies the key or core processes in the business domains of
interest. The management can then decide on how to improve such processes,
redesigning them or designing new processes from scratch. Such methods as Total
Quality Management, Business Process Reengineering, Activity Based Costing,
the Balanced Scorecard measurement scheme, etc, require the use of clear and valid
models before they can be used effectively.
1.5.3 Designing Information Systems
Again, Business Modeling techniques can be used to capture users’ requirements, going
through analysis, design and development.
When designing a system, models are required to view the As Is processes and to
convert them into the To Be processes. The design method in use for the particular
system will require a language to express all interim documents and diagrams.
1.6
Examples of Business Modeling “Output”
Business Modeling can be used to produce the following:








Procedure Manuals
Requirements Analysis documents
Models of AS IS systems: the way the system is today
Models of the TO BE systems: the way the systems will operate when improved,
modified or updated
Help Files and System Documentation
Training Manuals
Systems Design documents
Systems Testing documents
Many other requirements can be answered using Business Modeling. For the purposes of
Software Applications, most of the above are required.
1.7
How Does the UML Achieve the Above Aims?
In the past, business modelers resorted to such inefficient modeling techniques as
workflow charts and data flow diagrams. Both these techniques suffered from major
deficiencies:
Modeling Business Systems Using the UML
Page 5




They “thought” the way computers think: control and data
They did not think the way the user things: functions and business objects
They did not have practical limits. This resulted in many cases in wall covered
flowcharts that few people could visualize or use.
There was no limitation on the kind of icons to be included in the charts: data,
files, employees, machines, business rules, decisions, objects, etc.
The main shift in the thinking that the UML introduced is to rely on viewing the business
from two perspectives:
Business Objects: the user thinks of his or her Business Systems or Processes in terms
of the objects within them. So, UML modeling relies heavily on identifying all Business
Objects. Clearly understanding what the business objects are and how they behave is a
major step towards proper communications. Each Business Object will have a particular
behavior: things that can happen to it and that describe its behavior. Each Business
Objects will also have properties or data that describe it.
Use Cases: a Use Case is a new term defining an older concept. Any function that a
Business System can execute for an outsider is a Use Case. They describe in very clear
terms the way this outsider “Uses” the system. Use Cases focus on specific functions and
they express these functions in terms of what happens to the related Business Objects.
Examples: in a private bank’s reception area, the use cases are:









Deposit cash or checks
Withdraw cash
Request bankers checks
Request statements
Open new accounts
Close accounts
Receive transfers
Issue transfers
Request special services such as automatic bill payments
The Business Objects are cash, checks, transfers, customer accounts, managers, clerks,
forms, statements, transactions, accounting summaries, etc.
The above two UML concepts are intertwined. They represent a natural way of viewing a
system. It is the way a user sees it and can easily verify it.
1.8
Design Characteristics of the UML
The UML was designed with the following characteristics in mind:







To provide users with a Modeling Language that was simple to learn
To provide users with a Modeling Language that was ready to use
To ensure that non-technical users can review and analyze the models without
training
To have diagrams and models that are restricted in scope so that analysts are not
tempted to prepare wall paper sized charts. All models fit on A4 sized paper.
To use visually expressive and meaningful icons
To be able to model a variety of Business / Software / Technical systems
To be based on Objects / Use Cases
Modeling Business Systems Using the UML
Page 6









To have an internal architecture so that each diagram can view a different aspect
of the Business System
To be a Language and Not a Method
To be used by Business improvement systems
To be independent of Particular Business Improvement Methods
To be independent of Particular Programming Languages
To be independent of Particular Development Methods
To be able of defining extensions to the Language in the case of very specific
usage
To be able to use the language in a traceable manner, ie, start with Use Cases
and Business Objects and stay with them throughout the modeling process.
In the case of software development, to be able to model Frameworks, Patterns
and Components.
The UML has successfully met the above aims and is fast becoming an international
standard.
Modeling Business Systems Using the UML
Page 7
1.9
The Applications of the UML
The UML is used in several areas of modeling:
1.
Modeling business processes and systems: these can be modeled in several
states:
Step 1: an AS IS model is setup and verified
Step 2: the business process designers use the models to re-engineer the
processes or simply improve them.
Step 3: the models are then used as the basis for implementing the newly
designed processes or systems.
Step 4: the models are used to continuously monitor and control the ongoing
operations of the processes and systems.
2.
Modeling for Software Development: the UML models the initial system and
processes and proceeds to apply the Software Engineering Process onto the
models in the following manner:
Step 1: an AS IS model is setup and verified (Requirements Analysis). This has
the same objective as Step 1 above.
Step 2: Business Analysis is applied on the model to improve the processes and
to arrive at different requirements. This has the same objective as Step 2
above.
Step 3: The designers produce a Technical Design by using the UML diagrams.
These become the functional specification itself.
Step 4: The designers produce a Technical Design by using the UML diagrams.
These become the technical specification itself.
Step 5: Developers use the Technical Design to develop the various units in the
system.
Step 6: Testers use the Use Cases of the UML to complete the testing cycles.
Step 7: Trainers use the Use Cases for training.
Step 8: Documentation Units use the Use Cases to complete the documentation
of the systems and processes.
As can be seen, there is “traceability” in the above process through the use the
UML diagrams.
3.
Modeling Technical Systems: this is beyond the scope of this segment. The
UML is used to model engineering products such as electromechanical or
electronic equipment.
4.
Procedure Manuals: the UML is used to setup a procedure manual by the
detailed modeling of the AS IS system or process.
As can be seen, this segment will use the UML in the second
Modeling Business Systems Using the UML
Page 8
1.10
The Different Perspectives or Views of the UML
The UML is a visual modeling language that expresses a system’s functions through Use
Cases and Business Objects. It is traceable, easy to use and simple to learn. It sees the
system from 4 different perspectives, hence is architectural in its modeling approach:
1.
Use-Case View: This is the functional view, the view that most interests the
stakeholders. It describes the set of scenarios and/or use cases that represent
some significant, central functionality.
2.
The Logical View: Describes the most important Classes (Business Objects),
their organization in packages and subsystems, and the organization of these
subsystems into layers.
3.
The Process View: Describes the tasks (processes and threads) involved in the
system's execution, their interactions and configurations. Also describes the
allocation of objects and classes to tasks.
4.
The Deployment View: Describes the various physical nodes for the most
typical platform configurations. Also describes the allocation of tasks (from the
Process View) to the physical nodes.
A UML model will therefore have different “views” of the same system, to be used as
needed in different contexts.
Modeling Business Systems Using the UML
Page 9
2.0
The Diagrams of the UML
The 8 diagrams of the UML are in use in the following technologies:



Software Engineering Processes
Business Process Reengineering
Design of Technical and Electronic Systems
The following diagram summarizes the 8 diagrams
Figure 1: The Diagrams of the UML
They consist of


Two static diagrams
The Use Case Diagram
The Object Diagram
Four dynamic diagrams
Modeling Business Systems Using the UML
10
Page
The Sequence Diagram
The Collaboration Diagram
The State Transition Diagram
The Activity Diagram
Two implementation diagrams
The Component Diagram
The Deployment Diagram

These diagrams form part of the deliverables of a Software Application Project.
2.1
Why Use Use Cases
The Use Cases provide the following facilities:




2.2
Use Cases are effective communications items. They assist the team in clarifying
the requirements.
Use Cases can be used for both functional as well as non-functional requirements.
For example, a non-functional requirement is the following performance
condition: the Use Case describing the entry of the Payment Order can have an
additional condition stating that during usage in a network of X PCs, the response
time should be within a specific level.
Use Cases assure Traceability, a key objective in project management. At a later
date, Functional and Technical design activities will start with the Use Cases
developed in this activity. Development, testing, implementation, training and
documentation will also use the same Use Cases.
Use Cases discourage the developers from starting to design too early when not
enough information is collected about the rest of the Architecture of the system.
The Use Case Diagram
The most important concept in the UML is the Use Case, a mature concept in use during
the past 6 years.
Definition: a Use Case is a set of activities or procedures that are unified in one
objective and that is to produce “value” to a user or actor outside the system.
Actors are people or other ICT systems that use the system. The functionality of the
system is totally defined by all the Use Cases in a single Use Case diagram.
Examples
Use Cases in a Bank Front Area
 Withdraw cash
 Deposit cash and checks
 Receive inward transfers
 Request statements
 Request check books
 Change foreign notes
Use Cases of a Leave Control System
 Withdraw Cash
 Deposit Cash or Cheques
Modeling Business Systems Using the UML
11
Page








Transfer from one account to the other
Pay Bill (Various)
Get Statement
Change PIN
Replenish cash
Collect deposits
Update balances or limits
Check operation
Note the following:
1.
Use Cases are descriptions of functionalities from the user’s point of view and not
as computer data flow, program flowcharts or database diagrams.
2.
Use Cases are descriptions of functionalities that provide value to the user. If the
Use Case being described does not provide value then it is not to be documented
as a Use Case. For example, getting the signature of a supervisor on a form is not
a Use Case. However, getting a request approved in full is a Use Case.
3.
Use Cases have a unified breakdown of functionalities. It is usual for a Use Case
to deal with one aspect of the system. Use Cases are narrow in this respect and
do not mix functions.
4.
Use Cases can handle a variety of paths within their processing which may be
taken depending on different conditions. For example, while processing a Use
Case for Requesting Compensation, the processing may differ depending on
whether the compensation is for hospitalization, medicines or visits to doctors.
These are different “scenarios” within the same Use Case.
2.2.1 What Are the Components of a Use Case Model?
The Use Case Diagram is a set of documents consisting of the following:
1.
A Document defining the Scope of the Business System description (1 Page)
2.
The Use Case Diagram: a Graphic Diagram showing all the Use Cases, the
Actors and the various Associations between Use Cases. Use Cases are drawn as
ellipses. These are connected to the various users outside the system. There are
relationships between Use Cases which are also indicated. (1 or 2 Pages)
3.
A Textual Description of each Use Case: each Use Case is documented by a
one or two page textual description that defines the process in question. The
description is broad and it not meant to be taken as a final documentation. Other
UML diagrams will handle that. A Template is included in Section 4.0). (Up to 3
pages each)
Use Case diagrams are usually developed in the Requirements Capture subphase and get
refined and modified in the later subphase of the Software Engineering Process.
On the following pages are examples of last two documents for an ATM system.
Modeling Business Systems Using the UML
12
Page
Figure 2: Use Case Diagram for an ATM
Modeling Business Systems Using the UML
13
Page
Figure 3: Using Extends in a Use Case Diagram
In the above Use Case Diagram, there are 5 Use Cases that relate to the main two Use
Cases that are under the “Extend” association. This means that they extend the
functionality of the key or core Use Cases.
For example, Place a Call is a core Use Case. The following Use Cases extend this
functionality:




Place a Conference Call
Use Memory Bank
Use Speed Dialing
Use Last Number Dialed
Extend Use Cases are used when a Use Case has optional functionality that needs to be
highlighted.
Modeling Business Systems Using the UML
14
Page
Figure 4: Using Generalization in Use Case Diagrams
The above Use Case Diagram shows a library with Extend Use Cases. It also shows how
an Actor such as the Librarian “Inherits” the behavior of the Borrower Actor. This
association between the two actors is called a “Generalization” and allows the Modeler to
Modeling Business Systems Using the UML
15
Page
reduce the clutter by saying: “The Librarian has his or her own Use Cases (Maintenance)
but also has the same Use Cases as those used by any Borrower”.
2.2.2 Example: Description of an ATM Withdraw Cash Use Case
Name of use case:
Contacts:
Actors in the use case:
Objectives:
Withdraw Cash
Mr. X
Customer
This Use Case describes the activities of the ATM when a
Customer withdraws Cash from the ATM.
Scenarios and Extensions:
Rejections: Insufficient funds
Options: different ways of selecting amounts
Include (Uses): logging in
Pre-Conditions: the ATM must be switched on and at the Welcome screen
Post-Conditions: the ATM returns to the Welcome screen
Description:
1.
Customer Logs in (Use Use Case: Log In)
In case of
Rejection of PIN, give error message and return to Welcome Screen
Rejection of Card, give error message and return to Welcome Screen
2.
ATM displays main menu that contains the Customer functions:
Withdraw Cash
Deposit Cash
Get Statement
Change PIN
Customer chooses the first one.
3.
ATM displays the Amount Entry screen that defines the different ways the
customer can withdraw cash:
$100
$300
$500
$1000
Set amount in 100’s
There is an option to cancel transaction in which case the ATM returns to the
Welcome Screen.
4.
If the last option is selected, the user has to enter an amount in hundreds. If the
amount entered is not in hundreds, the ATM gives an error message and stays on
this screen.
Modeling Business Systems Using the UML
16
Page
5.
Having entered the amount, the ATM checks the balance. If there is not enough
cash for this account, the ATM displays a warning message and stays with the
Amount Entry screen.
6.
If there is enough cash, the ATM follows these steps:
Give customer message that transaction is being processed
Print the Cash Withdrawal slip
Push cash into drawer
7.
ATM gives a Thank You screen reminding the Customer to remove his or her card
from the entry slot.
8.
ATM returns to the Welcome Screen.
Attachments:
1.
2.
3.
Cash withdrawal slip
Typical ATM card
Layout of ATM keyboard
2.2.3 Example: The Log In Use Case for the ATM
Name of use case:
Contacts:
Actors in the use case:
Log In
Mr. X
None as this is an “Include” Use Case. The following Use
Cases can use this Include Use Case:
Withdraw Cash
Deposit Cash
Get Statement
Change PIN
Objectives: to allow Customer to enter ATM card, check its validity, enter the PIN
number, check its validity and proceed.
Scenarios and Extensions:
Rejections: PIN error, Card error
Pre-Conditions: the ATM must be switched on and at the Welcome screen
Post-Conditions: the ATM returns proceeds from where it was called
Description:
1.
ATM displays Log In screen that instructs user to:
Enter card
Enter the PIN number
Terminate the Use Case or entry by pressing Cancel.
2.
ATM checks the validity of the ATM card. In case it cannot read it, a message is
given and the ATM returns to the Log In Screen
Modeling Business Systems Using the UML
17
Page
3.
ATM checks the PIN against the ATM card. In case there is no match, issue error
message and returns to the Log In Screen.
4.
In case all is OK, the Use Case terminates and returns to the calling Use Case.
Attachments: none.
2.3
The Class Diagram: Business Objects
UML views the organization as a set of business objects. Such objects are not to be
confused with Object Oriented Programming. We are referring here to any “Entity” that
is of interest to the user in implementing his system. Objects may be persons, vouchers,
other ICT systems, real physical objects (Such as an employee ID card) or data tables.
Objects will be defined later.
While analyzing Use Cases, analysts will come across objects of interest to the
organization. These objects have been grouped by UML into 3 major types:
1.
Boundary or Interface Objects: are within the system but are used by the
system to exchange information or control with the users. For example, windows,
menus, login screens, confirmation slips, receipt coupons are all Boundary
Objects.
2.
Control Objects: are standard procedures needed to effect particular activities.
These could be tables of rates, business rules, computational programs, etc. The
UML insists on defining these as objects because past methods have ignored the
existence which led to failures.
3.
Entity Objects: consist of such objects as vouchers, persons, data tables. Of
particular interest is the group called “persistent objects” or objects that are
realizable within the system as tables in a database. They stay within the system
while a voucher may be taken by the employee and destroyed.
To model the above objects or classes, the UML develops the Object / Class Diagram.
It is referred to be either name. This diagram shows the objects in the organization and
draws lines between the rectangles defining the relationships between them. As an
extension of this diagram, an Entity Relationship Diagram will be developed. This defines
the tables in database tables to be implemented by a Relational Database Management
System.
Modeling Business Systems Using the UML
18
Page
2.3.1 The Notation of the Class Diagram
The Class Diagram is made up of rectangles, one for each class. These are related to
each other by such relationships or associations as:



Cardinality: signifies how many of one class relate to another class (One
employee can have 0 or many loans, one product belongs to 1 stock type only,
one branch has 1 manager). Cardinality is shown as a number next to each Class.
Roles: a text that defines how this Class relates to another. (One employee has
a nationality, one project manager is assigned to a project, etc).
Links: these are relationships between classes meant to express business rules
as well as to clarify the workings of the system. There are many types of
relationships such as: associations, aggregation, generalization, etc. These will
not be discussed in this paper as they are elaborate and require many examples.
The Class rectangle contains several segments:




Name of the Class
Properties: these are the attributes or data elements that describe the class
such as the following for an order: order number, date of order, supplier, amount,
etc.
Methods: these are the set of actions or operations that can “happen” to a class
or its behavior. For example, an Order can “Get Created”, “Get Confirmed”, “Get
Received”, “Get Canceled”, “Get its Dates Modified”, etc. In programming terms,
these translate to procedures that have to be developed or coded.
Visibility: defines whether a class is protected from view by other classes, is
private or is public.
The following few pages show examples of some Class Diagrams.
Modeling Business Systems Using the UML
19
Page
2.3.2 Examples of Class Diagrams
The following diagrams show the Class Diagrams for a School, a Consulting Firm and its
projects and a Purchase Orders System.
The notation is not defined as it is elaborate. However, it can be seen that it is a simple
matter to read the diagram. Below each are some examples on how to read the
diagrams.
Figure 5:The Class Diagram for Orders
How to read the diagram?






An order must belong to 1 Customers or a Customer has 0 or more orders.
A Customer can be a Corporate or an Individual Customer
Each corporate customer has 0 or 1 Sales rep
Each Order item has 1 product
Each Order has 1 or more items
Etc
Modeling Business Systems Using the UML
20
Page
Figure 6: The Class Diagram for Consulting Activities
The following can be known about the firm:





Each consultant works on 1 or more projects and each project belongs to only 1
consultant
Each Consultant writes 1 or more proposal and each proposal can be written by 1
consultant
Each Consultant servers 1 or more clients and each client is served by 1
Consultant only
Data appears in one report while a report can have more than 1 item of data
Etc
Modeling Business Systems Using the UML
21
Page
Figure 7: The Class Diagram for a School
The above School is in a University and has the following business relationships:














A school has 1 or more departments
A department can only belong to 1 school
A school has 1 or more students
A student can attend 1 or more courses
A course can have 1 or more students
A course is taught by 1 teacher only
A teacher can teach 1 or more courses
A teacher is assigned to 1 or more departments
A department can have 1 or more teachers
A teach can be the chairman of 0 or 1 department
A department can have 0 or 1 chairman (Teacher)
A course belongs to 1 or more departments
A department can have 1 or more courses
Etc
Modeling Business Systems Using the UML
22
Page
2.4
The Sequence Diagram (Applies to Use Cases)
The Sequence Diagram is a detailed way of describing the activities of a Use Case.
Several Sequence Diagrams may be needed to describe all the scenarios of a single Use
Case.
This diagram consists of several objects and actors on the top of the diagram drawn
horizontally. Below each is a straight downwards time line. Horizontally, the analyst
draws lines showing the sequence of activities within a Use Case.
A set of examples of Sequence Diagrams are shown on the following few pages.
Modeling Business Systems Using the UML
23
Page
Figure 8: The Sequence Diagram for a Telephone Call
Modeling Business Systems Using the UML
24
Page
Figure 9: The Sequence Diagram for a Customer Making a Purchase
Modeling Business Systems Using the UML
25
Page
Figure 10: The Sequence Diagram for Adding a New Customer
Modeling Business Systems Using the UML
26
Page
2.5
The Collaboration Diagram (Applies to Use Cases)
This diagram also has the objective of defining the various scenarios in a single Use
Case. It is equivalent to the Sequence Diagram but is drawn differently. Instead of
showing the objects on top with time lines drawn below them, the Collaboration Diagram
shows the objects as rectangles all over the diagram. It shows the interaction between
them (The collaboration) as lines from one object to the other. The numbering of the
lines defines the sequence of work.
2.6
The State Transition Diagram (Applies to Objects)
This diagram defines the states an object goes through. A compensation request may
show up in different Use Cases. Since it becomes difficult for a user to understand its full
behavior in several Use Cases, UML provides a special diagram to trace how an Object
changes states.
Example:
the states that a request goes through may be:
State: Submitted / Reviewed / Approved / Disbursement given / Rejected
Arrows between states define events taking an object from one state to the other.
The following page shows an example of a State Transition Diagram.
Modeling Business Systems Using the UML
27
Page
Figure 11: The State Diagram for Placing Orders
Modeling Business Systems Using the UML
28
Page
2.7
The Activity Diagram (Applies to Use Cases and to Objects)
This diagram is the equivalent of the State Diagram. It is used when it is clearer to show
the behavior of objects in terms of activities and not states. Activities are shown in
rectangles. When an activity is completed, the object goes to the next activity.
This is one of the most important diagrams in UML, since it can be used to model the
behavior of Objects as well as Use Cases.
The following few pages show examples of State Transition Diagrams.
Modeling Business Systems Using the UML
29
Page
Modeling Business Systems Using the UML
30
Page
Figure 12: Activity Diagram For Orders (Showing Objects)
Modeling Business Systems Using the UML
31
Page
Figure 13: Activity Diagram to Model a Method
Modeling Business Systems Using the UML
32
Page
Figure 14: Activity Diagram Showing Swimlanes by Object
Modeling Business Systems Using the UML
33
Page
2.8
The Implementation Diagrams
These last two diagrams are strictly technical and in many ways do not concern the user.
By relegating them to a separate model, the UML protects the user from the technical
jargon of software developers.
There are two diagrams which we will touch upon briefly:
2.8.1 The Component Diagram
Defines the components in the software application and their relationships: libraries,
executable programs, database engines, databases, office tools, etc.
2.8.2 The Deployment Diagram
Defines where the different components are placed and is essentially a way of describing
the layout of the technical parts of the system: servers, hubs, stations, computers, units
such as scanners, printers, etc.
Modeling Business Systems Using the UML
34
Page
3.0
How to Use the UML in a Typical Software Engineering
Process
The UML relies on diagramming the following two two major diagrams:


The Business Object or the Class Diagram
The Use Case Diagram (Consisting of descriptions of all Use Cases)
The UML proceeds in phases elaborating these diagrams. It follows
Phase 1:
Define the Business Objects and Use Cases and get them verified and
approved. No need for details at this stage.
Phase 2:
Elaborate the Business Objects and Use Cases by introducing more details
in the Models: exception scenarios, associations between use cases, more
detailed description of the behavior and properties of business objects.
Again, these are verified and approved.
Phase 3:
Elaborate the Use Cases by resorting to other UML diagrams such as the
Activity, the Sequence and the Collaboration diagrams. The Business
Objects can also be elaborated using the Activity and the State Diagrams.
Phase 4:
In the case of ICT Systems, an additional two diagrams are introduced to
assist the design in the implementation phase: the deployment and the
components diagrams.
As discussed in the Technical Paper on Software Development Methodologies, it is
recommended to use the Spiral Model for Software Development. Refer to that document
for a more detailed description of the Model. Briefly, the Spiral Model start by initiating
various conceptual or intellectual activities and iterates them outwards. As the number of
iterations increase, the designers and the users start arriving closer and closer to the
realization of the requirements.
3.1
Using the UML in the Segment
This segment shall rely heavily on the UML. However, it does not exclusively propose the
language for modeling the analysis and design of systems:





The UML is a standard modeling language for modeling business systems and
Software Applications in their various stages of Analysis and Design.
The UML is not a product.
A software development unit can decide to use any modeling schemes for its
systems life cycles.
This segment leaves the choice open for an ICT Unit to select its own language
but strongly recommends the use of the UML which is becoming a standard in
such practices.
Analysis of Requirements, Functional Design and Technical Design are each
allocated a special section where the related processes are discussed. It is then
shown how Analysis and Design can use the UML to model their systems.
Note again that the segment does not enforce the use of the UML but strongly endorses
it. An ICT Unit can decide to use any other suitable modeling scheme.
Modeling Business Systems Using the UML
35
Page
3.2
The Cycle of Analysis and Design
The following sections define how the UML can be used while going through a typical
Software Development life cycle using the Spiral Model.
The objective of the process is to produce a set of documents in the following order:




The
The
The
The
AS IS system model
Required system model
Functional Design model
Technical Design model
The Functional Design model can be used as the basis for the acquisition of Commercial
Off the Shelf Software. It can also be used to arrive at the Technical Design model which
can then be used for building the software application.
The following sections define how the UML is used in different phases of the Spiral Life
Cycle going through initiation and planning. A later section briefly describes how the UML
can be used during later phases of building and transition.
3.3
Initiation Phase: Modeling the AS IS or Current System Model
During this phase, it is sufficient to briefly present the following:
1.
Prepare a Use Case Diagram showing all Use Cases, their actors and their
associations.
2.
Prepare the Class Diagram showing the main Business Objects and their
associations.
3.
If there are complex or interesting Use Cases, it may be recommended to
elaborate them textually.
3.4
Initiation Phase: Identifying the Status of the Business Processes
At the initial stage, it would be generally known whether the organization is satisfied
with the system as it is or not. It would also be known whether there is any reason to
change the current system due for example, to changing circumstances, laws or
organization.
In this section, the Project Definition should indicate the following:




Whether improvement or change is required in the business processes or not
The nature of the required change
The reason for the required change
The purpose of the change
Forward Look: there is a corresponding but much more elaborate set of activities for
the Improvement of Business Processes in the Project Planning phase.
Modeling Business Systems Using the UML
36
Page
3.5
Initiation Phase: Modeling the Analysis of Requirements
This section presents a general review of the required system or the system “TO BE”.
The purpose of this section is the following:




To
To
To
To
determine the scope of the new or required system
identify all the known requirements of the stakeholders
generate the first draft model of what the system should do.
determine whether process improvement or reengineering is required
The Appendix introduces the UML and how it can be used in a software engineering
process. Here is how it can be used for Modeling the Current System:
1.
Define the scope of the new or the required business system: where it starts and
ends, what it includes and what is excludes. This may differ from the AS IS
system.
Example:
In the new stock system, we will be controlling the shelf and bin locations.
2.
Revise the main Use Cases of the AS IS system and plot them on a diagram.
3.
Identify the main Actors of the required system.
4.
Should any Use Case not be clear, it can be described in text form, but very
briefly.
5.
Identify the required Business Objects. Describe some of them if they need to be
clarified.
Remember that the above shows WHAT the required system does and not how it does it.
Forward Look: there is a corresponding but much more elaborate set of activities for
the Required System in terms of Functional and Technical Design and Specification. This
will be presented in the Project Planning phase.
3.6
Initiation Phase: System Deployment
Most software applications will probably be setup on a network. The current technology
requires a very careful and intricate deployment of software components on a network.
Furthermore, the project itself needs to define where specific servers and PCs are
located.
Indicate in this section what is known about the deployment of the software and
hardware component.
The Appendix introduces the UML and how it can be used in a software engineering
process. Here is how it can be used for Modeling the Current System:
The UML has two major diagrams called the Implementation Diagrams:
Modeling Business Systems Using the UML
37
Page


The Deployment Diagram: Defines the components in the software application
and their relationships: libraries, executable programs, database engines,
databases, office tools, etc.
The Component Diagram: Defines where the different components are placed and
is essentially a way of describing the layout of the technical parts of the system:
servers, hubs, stations, computers, units such as scanners, printers, etc.
The initial Use Cases defined earlier will determine much of the infrastructure. However,
the technology policies of the Ministry or Agency are also of importance (Performance,
modernization, compatibility with legacy systems, etc). Finally, cost and lead time
considerations come into such infrastructural issues as:
Operating systems
RDBMS’s
Architectural categories: client/server, multi-tier, central system
Web servers or other types of specialized servers
WAN’s and LAN’s
The deliverable of this activity should include any justification needed to move from the
current to the new infrastructure.
In this section, whatever is currently known can be modeled in general terms.
3.7
Planning Phase: Modeling the AS IS or Current System Model
Based on the earlier general models developed in the Project Definition, the Business
Analysts can then proceed to elaborate the analysis as follows:
During the Project Initiation Phase, the Software Engineering team will require to have a
brief and general view of the current system, as it is. Their objective is to produce a set
of UML diagrams that define the system and include it in the Project Definition
Document.
This section presents a general review of the current system or the “AS IS” system. The
purpose is not to analyze the system as in most cases, it would be changed. The purpose
is to note down the baseline from which the change is to be made.
Another purpose would be to ensure that the scope of the system or process being
automated is clear.
3.7.1 Developing the Use Case Diagram (System Functions):
This activity results in the development of a document that contains the following
sections:




The scope of the Business System
The list of all Actors
The Use Case Diagram broken down into as many packages as required
A textual description for each Use Case
The following steps can be followed:
Modeling Business Systems Using the UML
38
Page
1.
Define the scope of the business system: where it starts and ends, what it
includes and what is excludes. The scope of the system should be developed in no
more than 1 or 2 pages.
2.
Identify ALL the Use Cases of the system. No Use Cases should be left out.
Meetings should take place between the Business Analysts and the Users.
3.
Group the Use Cases that belong to business subsystems, units or that have
related functions together in what the UML calls: Packages. Each of these
packages becomes a subsystem or a subprocess.
4.
Identify the main Actors using the Use Cases. These are the persons or systems
outside the required system that trigger the Use Cases. Each Actor has an
observable and measurable benefit from one or more of the se Cases.
5.
Prepare a Use Case Diagram for each of the packages showing all the Use Cases,
the Actors.
6.
Show all the associations between the Use Cases: Generalization, includes and
extends.
7.
Show any inheritance relationships between Actors.
8.
Develop the textual form for each Use Case. A template is presented in Section
4.0. The Template shows all the elements to be defined for each Use Cases.
9.
As each Use Case is being developed, the various scenarios within it need to be
identified. Scenarios cover such issues as: alternative actions within one Use
Case, options available to the Actor, error conditions, etc.
3.7.2 Developing the Class Diagram (Business Objects):
The Business Objects in use in the various Use Cases can be modeled using the Class
Diagram of the UML.
1.
Identify ALL Business Objects or Classes.
2.
Describe each class’s properties and behavior (Methods).
3.
Determine the relationships between the classes: ordinary associations,
inheritance and aggregation.
3.7.3 Additional Diagrams
In case the analysts feel that the Use Cases or the Business Classes do not truly model
the Business System, further elaboration can be attempted for some of the more
complex or crucial Use Cases or Classes using any of the following UML models:
The Sequence Diagram
The Activity Diagram
Moreover, if the Business System has specific Objects that have interesting or elaborate
behavior, such behavior may cut across the Use Cases and hence not be clearly
Modeling Business Systems Using the UML
39
Page
captured. Use the State Diagram for such objects to completely model the life cycle
behavior of the objects.
Example:
The behavior of an application form is typically modeled using the State Diagram. The
application crosses many Use Cases, so it is best to model all the Use Cases first, then
use the State Diagram to model its life cycle behavior.
3.7.4 Implementation Diagrams
The UML implementation diagrams are called: the Deployment and the Component
Diagram. In case there are existing ICT systems in use, their topology can be modeled
using these two diagrams.
3.8
Planning Phase: Modeling the Functional Design
Collect the following information:




All material presented in the approved Project Definition
Updated sections of the Project Plan. Typically, these would be the major sections
on objectives, constraints, etc.
The approved Requirements Definition Document as per the previous section.
Any related technical material of use in the design process: drawings, entity
relationship diagrams, UML diagrams, topological layout of components, etc.
The design activities can now proceed. These are essentially engineering processes and
will not be developed in this segment.
Depending on the modeling language in use, this activity covers the full modeling of the
Functional Design.
1.
Update the System Scope document.
2.
Identify all Use Cases and package them in suitable subsystems, processes or
modules. Prepare a Use Case Diagram. Usually, for medium and large systems,
this may be made up of several diagrams each one modeling a specific package
or module.
3.
For each Use Case, the following should be completed:





4.
Document the full Use Case as per the Template in Section 4.0.
Identify all its Actors
Identify all its scenarios
Identify all its pre-conditions and its post-conditions
Identify all the <<extends>> and <<includes>> Use Cases
For the following types of Use Cases, elaborate the modeling by further models
using Activity, Sequence or Collaboration diagrams:



Complex Use Cases
Critical Use Cases that are core to the overall system or process
Use Cases that relate to interfaces with other systems
Modeling Business Systems Using the UML
40
Page



Use Cases that have a high priority in implementation terms and require early
qualification
Use Cases that have business objects of interest and that will be modeled by
State diagrams as shown below.
Use Cases that are of particular interest to specific stakeholders who wish to
see them in detail.
Notice that the design process is in the Functional state and as such, the objects
on the above diagrams are still at the level of business objects and not technical
objects such as interfaces, database objects, etc.
5.
Prepare a State Diagram for any object that is of interest, especially objects that
cross many Use Cases. For example, application forms are usually business
objects that appear in many Use Cases. Analyzing the Use Cases they appear in
may be too complex a way to understand and confirm their behavior. They are
good candidates for state modeling.
6.
Prepare a Class Diagram showing all the Business Objects mentioned in the
identified Use Cases. For each Class, show the following:



Show all attributes (Properties)
Show all operations (Methods)
Show all data declarations
Also, show all associations between classes.
7.
Analyze the Entity Relationship Diagram (ERD) extracted from the Class
Diagram. Review its structure and ensure that it follows the good practices
presented in the Database segment. (Note that some visual modeling tools for
the UML have the capability of generating ERDs from the Class Diagram directly).
8.
Prepare the two Implementation Diagrams showing all software and related
hardware components:


The Component Diagram
The Deployment Diagram
Good Practice: The above UML documentation should be governed by a strict
Configuration Management approach to ensure that the overall design is complete
(Baselined) and that all changes are properly controlled.
Good Practice: This is part of an iteration. As modeling advances, it will identify areas
in the design that need a further look. The Functional Design Process therefore loops
between Steps 2 and 3 until the designers reach the conviction that the system has been
properly designed.
3.9
Planning Phase: Modeling the Technical Design
Collect the following information:


All material presented in the approved Project Definition
The approved Requirements Definition and the Functional Specifications
Documents as per the previous sections.
Modeling Business Systems Using the UML
41
Page

Any related technical material of use in the design process: drawings, entity
relationship diagrams, UML diagrams, topological layout of components, etc.
The design activities can now proceed. These are essentially engineering processes and
will not be developed in this segment.
1.
The functional Use Cases are now completely identified and apart from changes
in the design, there would be no need to revise them nor the Use Case
Diagram.
2.
There may be additional Use Cases that are totally technical, ie, not seen as
“functions” by the general users. These could cover issues related to database
processing, stored procedures, components that are transparent to the user such
as those used for database access, algorithmic work, interface activities, user
interface functions, etc.
These Use Cases must now be identified and detailed in full reaching the following
levels:





3.
Document the full Use Case as per the Template in Section 4.0.
Identify all its Actors
Identify all its scenarios
Identify all its pre-conditions and its post-conditions
Identify all the <<extends>> and <<includes>> Use Cases
Select the model needed to elaborate each Use Case. It could be any one of
these:


The Activity Diagram
The Sequence or Collaboration diagrams
Elaborate each Use Case using the above diagrams. Notice that the design
process is in the Technical state and as such, the objects on the above diagrams
will need to be the business as well as the technical objects such as interfaces,
database objects, etc.
5.
Elaborate the earlier State Diagrams for any object that is of interest, especially
objects that cross many Use Cases.
6.
Elaborate the earlier Class Diagram showing all the Business Objects mentioned
in the identified Use Cases. For each Class, show the following:



Show all attributes (Properties)
Show all operations (Methods)
Show all data declarations
Also, show all associations between classes.
This diagram would need to be updated as the Technical Design would by force
introduce many new classes that are not “functional” in nature and hence
transparent to the user.
7.
Finalize the design of the Entity Relationship Diagram (ERD) extracted from
the Class Diagram. Review its structure and ensure that it follows the good
Modeling Business Systems Using the UML
42
Page
practices presented in the Database segment. (Note that some visual modeling
tools for the UML have the capability of generating ERDs from the Class Diagram
directly).
8.
Finalize the two Implementation Diagrams showing all software and related
hardware components:


The Component Diagram
The Deployment Diagram
Good Practice: The above UML documentation should be governed by a strict
Configuration Management approach to ensure that the overall design is complete
(Baselined) and that all changes are properly controlled.
Good Practice: This is part of an iteration. As modeling advances, it will identify areas
in the design that need a further look. The Technical Design Process therefore loops
between Steps 2 and 3 until the designers reach the conviction that the system has been
properly designed.
3.10
Planning Phase: Finalizing the Implementation Diagrams
By now, the Project Team would have developed the two UML diagrams (Component and
Deployment Diagrams). All components will be clearly identified. All locations, servers
and other implementation elements will be known.
3.11
Building and Transition Phases
The Development team will use the UML in the following manner:
1.
During development, all Technical Designs will be used to produce the code that
will be built into the final product. Project management principles ensure that the
Technical Design is subjected to strict Configuration Management techniques. It
will also ensure that work is assigned by Use Case packages.
2.
Training, documentation and implementation can also be carried out by resorting
to the Use Case packages.
3.
Installation will be completed according to the final Implementation Diagrams
included in the Technical Design.
The above shows that the UML relies heavily the traceability of the Use Cases, starting
with general Use Cases and Class Diagrams at the beginning of the project and using the
same Use Cases throughout.
Modeling Business Systems Using the UML
43
Page
4.0
Template for Use Case Description
Name of use case: As on the Use Case Diagram
Contacts: Names of persons mostly involved with the functions
Actors in the use case:
Goals: Briefly describe the main goal or goals of this Use Case. This is mostly for
readers who wish to scan read the document without going into the details of the Use
Case.
Scenarios and Extensions: Include some of the scenarios and the extensions, if any.
Pre-conditions: Events or activities that must be completed before the Use Case can be
carried out
Description: Step by step narrative of all scenarios. This is the main body of the Use
Case detailed description.
Post-conditions: The endings that the Use Case can result in
Frequency and Volumes: define how often this Use Case takes place. This is useful for
establishing priorities and system capacity.
Attachments: Documents, diagrams, vouchers, diskettes, etc.
Modeling Business Systems Using the UML
44
Page
5.0
Where to Learn and How to Use the UML?
The market is saturated with text books, tutorials and websites that instruct prospective
users on the use of the UML. Moreover, there are many standard texts that define the
language references and standards for the UML. It is strongly suggested that prospective
users of the UML should acquire such sources and resort to them.
There are two levels of tools to use with the UML:
1.
UML Visual Modeling Tools: These are products whose only aim is to model
systems using the UML. They will have most of the following facilities:





A repository of the models
The facility of viewing the system from different perspectives (Use Cases
can show their related sequence diagrams, sequence diagrams can be
converted automatically to collaboration diagrams, etc).
The facility of generating source code of a specific language from Class
Diagrams resulting in a major saving of time (Java, C++, etc).
The facility of generating SQL scripts for key database engines to generate
the ERD as modeled by the Class Diagrams.
The facility of documenting the diagrams on the fly. For example, the text
for Use Cases can be embedded “behind” the Use Case icon.
Various other special facilities are also available.
2.
General diagramming tools: Commercial diagramming tools often have
templates for the various graphic icons in use by the UML. These products are
easy to use but only provide diagramming facilities. It remains up to the user to
carry out the facilities provided by the first type of tools.
The first type is more flexible to use but requires training. The second type is simpler to
use and is much lower in cost. However, it is limited in its functionalities.
The market is saturated with text books, tutorials and websites that instruct prospective
users on the use of the UML. Moreover, there are many standard texts that define the
language references and standards for the UML. It is strongly suggested that prospective
users of the UML should acquire such sources and resort to them.
Modeling Business Systems Using the UML
45
Page