Modeling - CL1 Flashcards
UML: Basic Diagram Types
What Is the UML?
The Unified Modeling Language (UML) is a family of graphical notations, backed by single meta-
model, that help in describing and designing software systems, particularly software systems built
using the object-oriented (OO) style. That’s a somewhat simplified definition. In fact, the UML is a
few different things to different people. This comes both from its own history and from the different
views that people have about what makes an effective software engineering process. As a result, my
task in much of this chapter is to set the scene for this book by explaining the different ways in
which people see and use the UML.
Graphical modeling languages have been around in the software industry for a long time. The
fundamental driver behind them all is that programming languages are not at a high enough level of
abstraction to facilitate discussions about design.
Despite the fact that graphical modeling languages have been around for a long time, there is an
enormous amount of dispute in the software industry about their role. These disputes play directly
into how people perceive the role of the UML itself.
The UML is a relatively open standard, controlled by the Object Management Group (OMG), an open
consortium of companies. The OMG was formed to build standards that supported interoperability,
specifically the interoperability of object-oriented systems. The OMG is perhaps best known for the
CORBA (Common Object Request Broker Architecture) standards.
The UML was born out of the unification of the many object-oriented graphical modeling languages
that thrived in the late 1980s and early 1990s. Since its appearance in 1997, it has relegated that
particular tower of Babel to history. That’s a service I, and many other developers, am deeply
thankful for.
Ways of Using the UML
At the heart of the role of the UML in software development are the different ways in which people
want to use it, differences that carry over from other graphical modeling languages. These
differences lead to long and difficult arguments about how the UML should be used.
To untangle this, Steve Mellor and I independently came up with a characterization of the three
modes in which people use the UML: sketch, blueprint, and programming language. By far the most
common of the three, at least to my biased eye, is UML as sketch. In this usage, developers use
the UML to help communicate some aspects of a system. As with blueprints, you can use sketches in
a forward-engineering or reverse-engineering direction. Forward engineering draws a UML
diagram before you write code, while reverse engineering builds a UML diagram from existing
code in order to help understand it.
The essence of sketching is selectivity. With forward sketching, you rough out some issues in code
you are about to write, usually discussing them with a group of people on your team. Your aim is to
use the sketches to help communicate ideas and alternatives about what you’re about to do. You
don’t talk about all the code you are going to work on, only important issues that you want to run
past your colleagues first or sections of the design that you want to visualize before you begin
programming. Sessions like this can be very short: a 10-minute session to discuss a few hours of
programming or a day to discuss a 2-week iteration.
With reverse engineering, you use sketches to explain how some part of a system works. You don’t
show every class, simply those that are interesting and worth talking about before you dig into the
code.
Because sketching is pretty informal and dynamic, you need to do it quickly and collaboratively, so a
common medium is a whiteboard. Sketches are also useful in documents, in which case the focus is
communication rather than completeness. The tools used for sketching are lightweight drawing
tools, and often people aren’t too particular about keeping to every strict rule of the UML. Most UML
diagrams shown in books, such as my other books, are sketches. Their emphasis is on selective
communication rather than complete specification.
In contrast, UML as blueprint is about completeness. In forward engineering, the idea is that
blueprints are developed by a designer whose job is to build a detailed design for a programmer to
code up. That design should be sufficiently complete in that all design decisions are laid out, and the
programmer should be able to follow it as a pretty straightforward activity that requires little
thought. The designer may be the same person as the programmer, but usually the designer is a
more senior developer who designs for a team of programmers. The inspiration for this approach is
other forms of engineering in which professional engineers create engineering drawings that are
handed over to construction companies to build.
Blueprinting may be used for all details, or a designer may draw blueprints to a particular area. A
common approach is for a designer to develop blueprint-level models as far as interfaces of
subsystems but then let developers work out the details of implementing those details.
In reverse engineering, blueprints aim to convey detailed information about the code either in paper
documents or as an interactive graphical browser. The blueprints can show every detail about a
class in a graphical form that’s easier for developers to understand.
Blueprints require much more sophisticated tools than sketches do in order to handle the details
required for the task. Specialized CASE (computer-aided software engineering) tools fall into this
category, although the term CASE has become a dirty word, and vendors try to avoid it now.
Forward-engineering tools support diagram drawing and back it up with a repository to hold the
information. Reverse-engineering tools read source code and interpret from it into the repository
and generate diagrams. Tools that can do both forward and reverse engineering like this are
referred to as round-trip tools.
Some tools use the source code itself as the repository and use diagrams as a graphic viewport on
the code. These tools tie much more closely into programming and often integrate directly with
programming editors. I like to think of these as tripless tools.
The line between blueprints and sketches is somewhat blurry, but the distinction, I think, rests on
the fact that sketches are deliberately incomplete, highlighting important information, while
blueprints intend to be comprehensive, often with the aim of reducing programming to a simple and
fairly mechanical activity. In a sound bite, I’d say that sketches are explorative, while blueprints are
definitive.
As you do more and more in the UML and the programming gets increasingly mechanical, it
becomes obvious that the programming should be automated. Indeed, many CASE tools do some
form of code generation, which automates building a significant part of a system. Eventually,
however, you reach the point at which all the system can be specified in the UML, and you reach
UML as programming language. In this environment, developers draw UML diagrams that are
compiled directly to executable code, and the UML becomes the source code. Obviously, this usage
of UML demands particularly sophisticated tooling. (Also, the notions of forward and reverse
engineering don’t make any sense for this mode, as the UML and source code are the same thing.)
One of the interesting questions around the UML as programming language is how to model
behavioral logic. UML 2 offers three ways of behavioral modeling: interaction diagrams, state
diagrams, and activity diagrams. All have their proponents for programming in. If the UML does gain
popularity as a programming language, it will be interesting to see which of these techniques
become successful.
Another way in which people look at the UML is the range between using it for conceptual and for
software modeling. Most people are familiar with the UML used for software modeling. In this
software perspective, the elements of the UML map pretty directly to elements in a software
system. As we shall see, the mapping is by no means prescriptive, but when we use the UML, we
are talking about software elements.
With the conceptual perspective, the UML represents a description of the concepts of a domain of
study. Here, we aren’t talking about software elements so much as we are building a vocabulary to
talk about a particular domain.
There are no hard-and-fast rules about perspective; as it turns out, there’s really quite a large range
of usage. Some tools automatically turn source code into the UML diagrams, treating the UML as an
alternative view of the source. That’s very much a software perspective. If you use UML diagrams to
try and understand the various meanings of the terms asset pool with a bunch of accountants, you
are in a much more conceptual frame of mind.
In previous editions of this book, I split the software perspective into specification (interface) and
implementation. In practice, I found that it was too hard to draw a precise line between the two, so
I feel that the distinction is no longer worth making a fuss about. However, I’m always inclined to
emphasize interface rather than implementation in my diagrams.
These different ways of using the UML lead to a host of arguments about what UML diagrams mean
and what their relationship is to the rest of the world. In particular, it affects the relationship
between the UML and source code. Some people hold the view that the UML should be used to
create a design that is independent of the programming language that’s used for implementation.
Others believe that language-independent design is an oxymoron, with a strong emphasis on the
moron.
Another difference in viewpoints is what the essence of the UML is. In my view, most users of the
UML, particularly sketchers, see the essence of the UML to be the diagrams. However, the creators
of the UML see the diagrams as secondary; the essence of the UML is the meta-model. Diagrams are
simply a presentation of the meta-model. This view also makes sense to blueprinters and UML
programming language users.
So whenever you read anything involving the UML, it’s important to understand the point of view of
the author. Only then can you make sense of the often fierce arguments that the UML encourages.
Having said all that, I need to make my biases clear. Almost all the time, my use of the UML is as
sketches. I find the UML sketches useful with forward and reverse engineering and in both
conceptual and software perspectives.
I’m not a fan of detailed forward-engineered blueprints; I believe that it’s too difficult to do well and
slows down a development effort. Blueprinting to a level of subsystem interfaces is reasonable, but
even then you should expect to change those interfaces as developers implement the interactions
across the interface. The value of reverse-engineered blueprints is dependent on how the tool
works. If it’s used as a dynamic browser, it can be very helpful; if it generates a large document, all
it does is kill trees.
I see the UML as programming language as a nice idea but doubt that it will ever see significant
usage. I’m not convinced that graphical forms are more productive than textual forms for most
programming tasks and that even if they are, it’s very difficult for a language to be widely accepted.
As a result of my biases, this book focuses much more on using the UML for sketching. Fortunately,
this makes sense for a brief guide. I can’t do justice to the UML in its other modes in a book this
size, but a book this size makes a good introduction to other books that can. So if you’re interested
in the UML in its other modes, I’d suggest that you treat this book as an introduction and move on
to other books as you need them. If you’re interested only in sketches, this book may well be all you
need.
Notations and Meta-Models
The UML, in its current state, defines a notation and a meta-model. The notation is the graphical
stuff you see in models; it is the graphical syntax of the modeling language. For instance, class
diagram notation defines how items and concepts, such as class, association, and multiplicity, are
represented.
Of course, this leads to the question of what exactly is meant by an association or multiplicity or
even a class. Common usage suggests some informal definitions, but many people want more rigor
than that.
The idea of rigorous specification and design languages is most prevalent in the field of formal
methods. In such techniques, designs and specifications are represented using some derivative of
predicate calculus. Such definitions are mathematically rigorous and allow no ambiguity. However,
the value of these definitions is by no means universal. Even if you can prove that a program
satisfies a mathematical specification, there is no way to prove that the mathematical specification
meets the real requirements of the system.
Most graphical modeling languages have very little rigor; their notation appeals to intuition rather
than to formal definition. On the whole, this does not seem to have done much harm. These
methods may be informal, but many people still find them useful—and it is usefulness that counts.
However, methodologists are looking for ways to improve the rigor of methods without sacrificing
their usefulness. One way to do this is to define a meta-model: a diagram, usually a class diagram,
that defines the concepts of the language.
How much does the meta-model affect a user of the modeling notation? The answer depends mostly
on the mode of usage. A sketcher usually doesn’t care too much; a blueprinter should care rather
more. It’s vitally important to those who use the UML as a programming language, as it defines the
abstract syntax of that language.
Many of the people who are involved in the ongoing development of the UML are interested primarily
in the meta-model, particularly as this is important to the usage of the UML and a programming
language. Notational issues often run second place, which is important to bear in mind if you ever
try to get familiar with the standards documents themselves.
As you get deeper into the more detailed usage of the UML, you realize that you need much more
than the graphical notation. This is why UML tools are so complex.
I am not rigorous in this book. I prefer the traditional methods path and appeal mainly to your
intuition. That’s natural for a small book like this written by an author who’s inclined mostly to a
sketch usage. If you want more rigor, you should turn to more detailed tomes.
UML Diagrams
UML 2 describes 13 official diagram types listed in Table 1.1 and classified as indicated on Figure
1.2. Although these diagram types are the way many people approach the UML and how I’ve
organized this book, the UML’s authors do not see diagrams as the central part of the UML. As a
result, the diagram types are not particularly rigid. Often, you can legally use elements from one
diagram type on another diagram. The UML standard indicates that certain elements are typically
drawn on certain diagram types, but this is not a prescription.
Official Diagram Types of the UML 1. Activity Procedural and parallel behavior 2. Class Class, features, and relationships 3. Communication Interaction between objects; emphasis on links 4. Component Structure and connections of components 5. Composite structure Runtime decomposition of a class 6. Deployment Deployment of artifacts to nodes 7 Interaction overview Mix of sequence and activity diagram 8. Object Example configurations of instances 9. Package Compile-time hierarchic structure 10. Sequence Interaction between objects; emphasis on sequence 11. State machine How events change an object over its life 12. Timing Interaction between objects; emphasis on timing 13. Use case How users interact with a system
UML: Use Case Diagram (Essentials)
Use cases are a technique for capturing the functional requirements of a system. Use cases work by
describing the typical interactions between the users of a system and the system itself, providing a
narrative of how a system is used.
Rather than describe use cases head-on, I find it easier to sneak up on them from behind and start
by describing scenarios. A scenario is a sequence of steps describing an interaction between a user
and a system. So if we have a Web-based on-line store, we might have a Buy a Product scenario
that would say this:
The customer browses the catalog and adds desired items to the shopping basket.
When the customer wishes to pay, the customer describes the shipping and credit
card information and confirms the sale. The system checks the authorization on the
credit card and confirms the sale both immediately and with a follow-up e-mail.
This scenario is one thing that can happen. However, the credit card authorization might fail, and
this would be a separate scenario. In another case, you may have a regular customer for whom you
don’t need to capture the shipping and credit card information, and this is a third scenario.
All these scenarios are different yet similar. The essence of their similarity is that in all these three
scenarios, the user has the same goal: to buy a product. The user doesn’t always succeed, but the
goal remains. This user goal is the key to use cases: A use case is a set of scenarios tied together
by a common user goal.
In use case–speak, the users are referred to as actors. An actor is a role that a user plays with
respect to the system. Actors might include customer, customer service rep, sales manager, and product analyst. Actors carry out use cases. A single actor may perform many use cases;
conversely, a use case may have several actors performing it. Usually, you have many customers,
so many people can be the customer actor. Also, one person may act as more than one actor, such
as a sales manager who does customer service rep tasks. An actor doesn’t have to be human. If the
system performs a service for another computer system, that other system is an actor.
Actor isn’t really the right term; role would be much better. Apparently, there was a mistranslation
from Swedish, and actor is the term the use case community uses.
Use cases are well known as an important part of the UML. However, the surprise is that in many
ways, the definition of use cases in the UML is rather sparse. Nothing in the UML describes how you
should capture the content of a use case. What the UML describes is a use case diagram, which
shows how use cases relate to each other. But almost all the value of use cases lies in the content,
and the diagram is of rather limited value.
Content of a Use Case
There is no standard way to write the content of a use case, and different formats work well in
different cases. Figure 9.1 shows a common style to use. You begin by picking one of the scenarios
as the main success scenario. You start the body of the use case by writing the main success
scenario as a sequence of numbered steps. You then take the other scenarios and write them as
extensions, describing them in terms of variations on the main success scenario. Extensions can be
successes—user achieves the goal, as in 3a—or failures, as in 6a.
Each use case has a primary actor, which calls on the system to deliver a service. The primary actor
is the actor with the goal the use case is trying to satisfy and is usually, but not always, the initiator
of the use case. There may be other actors as well with which the system communicates while
carrying out the use case. These are known as secondary actors.
Each step in a use case is an element of the interaction between an actor and the system. Each step
should be a simple statement and should clearly show who is carrying out the step. The step should
show the intent of the actor, not the mechanics of what the actor does. Consequently, you don’t
describe the user interface in the use case. Indeed, writing the use case usually precedes designing
the user interface.
An extension within the use case names a condition that results in different interactions from those
described in the main success scenario (MSS) and states what those differences are. Start the
extension by naming the step at which the condition is detected and provide a short description of
the condition. Follow the condition with numbered steps in the same style as the main success
scenario. Finish these steps by describing where you return to the main success scenario, if you do.
The use case structure is a great way to brainstorm alternatives to the main success scenario. For
each step, ask, How could this go differently? and in particular, What could go wrong? It’s usually
best to brainstorm all the extension conditions first, before you get bogged down working out the
consequences. You’ll probably think of more conditions this way, which translates to fewer goofs
that you have to pick up later.
A complicated step in a use case can be another use case. In UML terms, we say that the first use
case includes the second. There’s no standard way to show an included use case in the text, but I
find that underlining, which suggests a hyperlink, works very nicely and in many tools really will be
a hyperlink. Thus in Figure 9.1, the first step includes the use case “browse catalog and select items
to buy.”
Included use cases can be useful for a complex step that would clutter the main scenario or for steps
that are repeated in several use cases. However, don’t try to break down use cases into sub–use
cases and subsub–use cases using functional decomposition. Such a decomposition is a good way to
waste a lot of time.
As well as the steps in the scenarios, you can add some other common information to a use case.
• A pre-condition describes what the system should ensure is true before the system allows
the use case to begin. This is useful for telling the programmers what conditions they don’t
have to check for in their code.
• A guarantee describes what the system will ensure at the end of the use case. Success
guarantees hold after a successful scenario; minimal guarantees hold after any scenario.
• A trigger specifies the event that gets the use case started.
When you’re considering adding elements, be skeptical. It’s better to do too little than too much.
Also, work hard to keep the use case brief and easy to read. I’ve found that long, detailed use cases
don’t get read, which rather defeats the purpose.
The amount of detail you need in a use case depends on the amount of risk in that use case. Often,
you need details on only a few key use cases early on; others can be fleshed out just before you
implement them. You don’t have to write all the detail down; verbal communication is often very
effective, particularly within an iterative cycle in which needs are quickly met by running code.
Use Case Diagrams
As I said earlier, the UML is silent on the content of a use case but does provide a diagram format
for showing them, as in Figure 9.2. Although the diagram is sometimes useful, it isn’t mandatory. In
your use case work, don’t put too much effort into the diagram. Instead, concentrate on the textual
content of the use cases.
The best way to think of a use case diagram is that it’s a graphical table of contents for the use case
set. It’s also similar to the context diagram used in structured methods, as it shows the system
boundary and the interactions with the outside world. The use case diagram shows the actors, the
use cases, and the relationships between them:
• Which actors carry out which use cases
• Which use cases include other use cases
The UML includes other relationships between use cases beyond the simple includes, such as
«extend». I strongly suggest that you ignore them. I’ve seen too many situations in which teams
can get terribly hung up on when to use different use case relationships, and such energy is wasted.
Instead, concentrate on the textual description of a use case; that’s where the real value of the
technique lies.
Levels of Use Cases
A common problem with use cases is that by focusing on the interaction between a user and the
system, you can neglect situations in which a change to a business process may be the best way to
deal with the problem. Often, you hear people talk about system use cases and business use cases.
The terms are not precise, but in general, a system use case is an interaction with the software,
whereas a business use case discusses how a business responds to a customer or an event.
[Cockburn, use cases] suggests a scheme of levels of use cases. The core use cases are at “sea
level.” Sea-level use cases typically represent a discrete interaction between a primary actor and
the system. Such use cases will deliver something of value to the primary actor and usually take
from a couple of minutes to half an hour for the primary actor to complete. Use cases that are there
only because they are included by sea-level use cases are fish level. Higher, kite-level use cases
show how the sea-level use cases fit into wider business interactions. Kite-level use cases are
usually business use cases, whereas sea and fish levels are system use cases. You should have most
of your use cases at the sea level. I prefer to indicate the level at the top of the use case, as in
Figure 9.1.
Use Cases and Features (or Stories)
Many approaches use features of a system—Extreme Programming calls them user stories—to help
describe requirements. A common question is how features and use cases interrelate.
Features are a good way of chunking up a system for planning an iterative project, whereby each
iteration delivers a number of features. Use cases provide a narrative of how the actors use the
system. Hence, although both techniques describe requirements, their purposes are different.
Although you can go directly to describing features, many people find it helpful to develop use cases
first and then generate a list of features. A feature may be a whole use case, a scenario in a use
case, a step in a use case, or some variant behavior, such as adding yet another depreciation
method for your asset valuations, that doesn’t show up in a use case narrative. Usually, features
end up being more fine grained than use cases.
When to Use Use Cases
Use cases are a valuable tool to help understand the functional requirements of a system. A first
pass at use cases should be made early on. More detailed versions of use cases should be worked
just prior to developing that use case.
It is important to remember that use cases represent an external view of the system. As such, don’t
expect any correlations between use cases and the classes inside the system.
The more I see of use cases, the less valuable the use case diagram seems to be. With use cases,
concentrate your energy on their text rather than on the diagram. Despite the fact that the UML has
nothing to say about the use case text, it is the text that contains all the value in the technique.
A big danger of use cases is that people make them too complicated and get stuck. Usually, you’ll
get less hurt by doing too little than by doing too much. A couple of pages per use case is just fine
for most cases. If you have too little, at least you’ll have a short, readable document that’s a
starting point for questions. If you have too much, hardly anyone will read and understand it.
UML: Class Diagram (Essentials)
If someone were to come up to you in a dark alley and say, “Psst, wanna see a UML diagram?” that
diagram would probably be a class diagram. The majority of UML diagrams I see are class diagrams.
The class diagram is not only widely used but also subject to the greatest range of modeling
concepts. Although the basic elements are needed by everyone, the advanced concepts are used
less often. Therefore, I’ve broken my discussion of class diagrams into two parts: the essentials (this
chapter) and the advanced.
A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them. Class diagrams also show the properties and operations of a
class and the constraints that apply to the way objects are connected. The UML uses the term
feature as a general term that covers properties and operations of a class.
Figure 3.1 shows a simple class model that would not surprise anyone who has worked with order
processing. The boxes in the diagram are classes, which are divided into three compartments: the
name of the class (in bold), its attributes, and its operations. Figure 3.1 also shows two kinds of
relationships between classes: associations and generalizations.
Properties
Properties represent structural features of a class. As a first approximation, you can think of
properties as corresponding to fields in a class. The reality is rather involved, as we shall see, but
that’s a reasonable place to start.
Properties are a single concept, but they appear in two quite distinct notations: attributes and
associations. Although they look quite different on a diagram, they are really the same thing.
Attributes
The attribute notation describes a property as a line of text within the class box itself. The full form
of an attribute is:
visibility name: type multiplicity = default {property-string}
An example of this is:
- name: String [1] = “Untitled” {readOnly}
Only the name is necessary.
• This visibility marker indicates whether the attribute is public (+) or private (-); I’ll
discuss other visibilities on page 83.
• The name of the attribute—how the class refers to the attribute—roughly corresponds to the
name of a field in a programming language.
• The type of the attribute indicates a restriction on what kind of object may be placed in the
attribute. You can think of this as the type of a field in a programming language.
• I’ll explain multiplicity on page 38.
• The default value is the value for a newly created object if the attribute isn’t specified
during creation.
• The {property-string} allows you to indicate additional properties for the attribute. In the
example, I used {readOnly} to indicate that clients may not modify the property. If this is
missing, you can usually assume that the attribute is modifiable. I’ll describe other property
strings as we go.
Associations
The other way to notate a property is as an association. Much of the same information that you can
show on an attribute appears on an association. Figures 3.2 and 3.3 show the same properties
represented in the two different notations.
An association is a solid line between two classes, directed from the source class to the target
class. The name of the property goes at the target end of the association, together with its
multiplicity. The target end of the association links to the class that is the type of the property.
Although most of the same information appears in both notations, some items are different. In
particular, associations can show multiplicities at both ends of the line.
With two notations for the same thing, the obvious question is, Why should you use one or the
other? In general, I tend to use attributes for small things, such as dates or Booleans—in general,
value types (page 73)—and associations for more significant classes, such as customers and orders.
I also tend to prefer to use class boxes for classes that are significant for the diagram, which leads
to using associations, and attributes for things less important for that diagram. The choice is much
more about emphasis than about any underlying meaning.
When to Use Class Diagrams
Class diagrams are the backbone of the UML, so you will find yourself using them all the time. This
chapter covers the basic concepts; Chapter 5 discusses many of the advanced concepts.
The trouble with class diagrams is that they are so rich, they can be overwhelming to use. Here are
a few tips.
• Don’t try to use all the notations available to you. Start with the simple stuff in this chapter:
classes, associations, attributes, generalization, and constraints. Introduce other notations
from Chapter 5 only when you need them.
• I’ve found conceptual class diagrams very useful in exploring the language of a business. For
this to work, you have to work hard on keeping software out of the discussion and keeping
the notation very simple.
• Don’t draw models for everything; instead, concentrate on the key areas. It is better to have
a few diagrams that you use and keep up to date than to have many forgotten, obsolete
models.
The biggest danger with class diagrams is that you can focus exclusively on structure and ignore
behavior. Therefore, when drawing class diagrams to understand software, always do them in
conjunction with some form of behavioral technique. If you’re going well, you’ll find yourself
swapping between the techniques frequently.
Entity Relationship Diagrams
Link:
https://www.smartdraw.com/entity-relationship-diagram/
Data Flow Diagram
Link:
https://www.smartdraw.com/data-flow-diagram/
