لطفا منتظر باشید ...
2.4 Paragraphs
A paragraph is a grouping of
sentences about a common subject. For example, the English language
groups sentences into paragraphs, such as the one you are currently
reading. UML paragraphs are diagrams. A diagram
is a collection of UML sentences. The elements that make up a diagram
are known
as diagram elements. For example, all the
elements on the figures shown earlier are diagram elements.The main subject about which we communicate is a system that resides
in a domain. A domain, also known as a
context, is a
broad
area of interest that has a generally accepted collection of concepts
and their relationships. These concepts are classes, and their
relationships are associations; both are
known as domain
elements. For example, the project management system may
be used to manage projects in various industries, including product
manufacturing, strategic services, financial services, information
technology consulting, and so forth, and each industry is a different
domain. Understanding a user's domain is critical as
a launching point for developing a system that the user and
other
stakeholders (those having a stake or interest
in the project) will find useful and valuable.A system is
a
collection
of elements organized together for a specific purpose. These elements
are known as system elements. To understand a
system, we focus on its architecture. The architecture of a system
involves the elements that make up the system and the way they work
together to provide the functionality of the system. The major
elements that make up a system are known as
architectural elements. A
system's elements and their relationships define the
system's structure, and the way the elements
interact and collaborate define the system's
behavior.A system may be recursively
decomposed
into smaller systems, called subsystems and
primitive elements. Subsystems
may be
further decomposed into sub-subsystems and
primitive elements, and so forth. When fully decomposed, a system and
all its subsystems consist of primitive elements. Primitive elements
cannot be further decomposed. For example, the project management
system can be decomposed into the following:
A user interface subsystem responsible for providing an interface
through which users can interact with the system.
A business processing subsystem responsible for implementing business
functionality.
A data subsystem responsible for implementing data storage
functionality.
When the primitive elements of a
system or subsystem are objects, the
system is considered an object-oriented system.
When the primitive elements are simply data elements and functions or
procedures, the system is considered a non-object-oriented
system.The UML provides various modeling techniques for communicating using
diagrams. Each type of diagram emphasizes something about a system,
and any number of diagrams may be used to communicate about a system.
The next sections introduce these diagram types using the project
management system requirements provided at the beginning of this
chapter. Each diagram is further explored in Parts II and III of this
book.In addition to the diagram types shown in the following sections, the
UML allows us to define our own diagrams, as necessary. For example,
we can define a database schema diagram that communicates the tables
in a database and their relationships. In the UML, diagrams belong to
two broad categories or types: structural and behavioral. Also, there
are other, more general elements that apply to both types of
diagrams.
2.4.1 Structural Modeling
Structural modeling assists in understanding and communicating the
elements that make up a system and the functionality the system
provides. The following sections briefly introduce the various
structural modeling diagrams provided by the UML. Part II describes
each diagram type in more detail.
2.4.1.1 Class diagrams
Class diagrams depict the structure of
a system in general. Class diagrams
have the following types of elements:
A class
Shown as a solid-outline rectangle
labeled with a name,
this represents a general concept.
An association
Shown as a solid-line path
labeled with a
name, this represents a relationship between classes.
An attribute
Shown as a text string in a
class's
second compartment, this represents what objects of the class know.
An operation
Shown as a text string in
a
class's third compartment, this represents what
objects of the class can do.
Figure 2-15 is based on the following paragraphs
from the requirements description provided at the beginning of the
chapter, and combines many of the sentences discussed in the figures
shown earlier in this chapter:
A project manager uses the project management system to manage a
project. The project manager leads a team to execute the project
within the project's start and end dates. Once a
project is created in the project management system, a manager may
initiate and later terminate the project due to its completion or for
some other reason.As input, a project uses requirements. As output, a project produces
a system (or part of a system). The requirements and system are work
products: things that are created, used, updated, and elaborated on
throughout a project. Every work product has a description, is of
some percent complete throughout the effort, and may be validated.
However, validation is dependent on the type of work product. For
example, the requirements are validated with users in workshops, and
the system is validated by being tested against the requirements.
Furthermore, requirements may be published using various types of
media, including on an intranet or in paper form; and systems may be
deployed onto specific platforms.
These paragraphs describe some of the classes that make up the
project management system. We can communicate this information on a
single diagram as shown in Figure 2-15, or by using
multiple diagrams, as done throughout the earlier part of this
chapter. Chapter 3 describes class diagrams in
detail.
Figure 2-15. Class diagram
2.4.1.2 Object diagrams
Object diagrams depict the
structure of a system at a particular
point in time. Object diagrams have the following types of elements:
An object
Shown as a solid-outline
rectangle labeled with a name
followed by a colon followed by the name of its class, all fully
underlined, this represents a specific concept. Both names are
optional, and the colon is only present if the class is specified.
A link
Shown as a solid-line path
labeled
with the name of its association fully underlined, this represents a
specific relationship between objects.
An attribute value
Shown as a text string followed by an equal symbol and its value in an
object's second compartment, this represents what
the object knows.
Figure 2-16 is based on the following paragraph from
the requirements description provided at the beginning of the
chapter:
The project management system must be able to handle the following
scenario. Si, who is a manager, manages three projects, named Eagle,
Falcon, and Hawk. All projects involve anonymous or unnamed teams.
The Eagle project is producing a project management system, similar
to the one being described. The Falcon project is using the Java
platform to produce another type of system, which is targeted for the
broad market. The Hawk project is using the Microsoft .NET platform
to produce a system similar to the Falcon project, but one that has
additional organization-specific requirements. Therefore, the Falcon
and Hawk projects share some common requirements, while the Hawk
project has additional organization-specific requirements.
This paragraph describes a specific situation that the project
management system must be able to handle using the various classes
that make up the system. We can communicate this information on a
single diagram, as shown in Figure 2-16, or by using
multiple diagrams, as has been done earlier in this chapter. Chapter 3 describes object diagrams in detail.
Figure 2-16. Object diagram
2.4.1.3 Use-case diagrams
Use-case diagrams depict the
functionality of a system. Use-case
diagrams have the following types of elements:
An actor
Shown as a "stick figure" icon,
this
represents users and
external systems with which the system we are discussing interacts.
A use case
Shown as an ellipse, this represents a
functional
requirement that is described from the perspective of the users of a
system.
A communicate association
Shown as a solid-line path from an
actor to a use case, this
represents that the actor uses the use case.
Figure 2-17 is based on the following part of a
paragraph from the requirements description provided at the beginning
of the chapter:
A project manager uses the project management system to manage a
project.
This identifies specific functionality that the project management
system must provide to its users. Chapter 4
describes use-case diagrams in detail.
Figure 2-17. Use-case diagram
2.4.1.4 Component diagrams
Component diagrams, also known
as implementation
diagrams, depict the implementation of a system. Component
diagrams have the following types of elements:
A component
Shown as a rectangle with two
small rectangles
protruding from its side, this represents a part of the system that
exists while the system is executing.
A dependency relationship
Shown as a dashed arrow from a client component to a suppler
component, this represents that the client component uses or depends
on the supplier component.
Figure 2-18 is based on the following part of a
paragraph from the requirements description provided at the beginning
of the chapter:
For auditing and security purposes, the project management system has
two parts, a user interface and database.
This paragraph describes how the project management system is
implemented when it is executing. Chapter 5
describes component diagrams in detail.
Figure 2-18. Component diagram
While the object-oriented paradigm focuses on using objects, the
component-based paradigm focuses on using
components. Both paradigms are based on the principles of
abstraction, encapsulation, generalization, and polymorphism.
2.4.1.5 Deployment diagrams
Deployment diagrams, also known
as implementation
diagrams, depict the implementation environment of a
system. Note that both component and deployment diagrams are specific
types of implementation diagrams. Deployment diagrams have the
following types of elements:
A node
Shown as a three-dimensional
rectangle, this
represents a resource that is available during execution time. A
component that resides on a node is nested inside the node.
A communication association
Shown as a solid-line path
between nodes, this represents a
communication path between the nodes.
Figure 2-19 is based on the following part of a
paragraph from the requirements description provided at the beginning
of the chapter:
The database of the project management system executes on a central
server. The user interface of the project management system executes
on a desktop client computer, has access to a printer, and uses the
database to store project-related information.
This describes the implementation environment of the project
management system. Chapter 5 describes deployment
diagrams in detail.
Figure 2-19. Deployment diagram
2.4.2 Behavioral Modeling
Behavioral modeling assists in understanding and communicating how
elements interact and collaborate to provide the functionality of a
system. The UML supports a number of diagrams useful for behavioral
modeling, and these are briefly described in the following sections.
Part III describes these types of diagrams in more detail.
2.4.2.1 Sequence diagrams
Sequence diagrams, also known
as interaction
diagrams, depict how elements interact over time. A
horizontal axis shows the elements involved in the interaction, and a
vertical axis represents time proceeding down the page. Sequence
diagrams have the following types of elements:
Classes and objects
Classes are shown much the same way
as on class diagrams. Objects may
also be shown much the same way as on object diagrams. In Chapter 6, you will encounter
roles, which define placeholders for classes and
objects.
A lifeline
Shown as a vertical dashed line from
an element, this
represents the existence of the element over time.
A communication
Shown as a horizontal solid arrow from
the lifeline of the sender to the lifeline of the receiver and
labeled with the name of the operation to be invoked, this represents
that the sender sends a message or stimulus to the receiver.
Figure 2-20 is based on the following part of a
paragraph from the requirements description provided at the beginning
of the chapter:
When creating a project, a project managers use a user interface to
enter their contact information (at minimum, a name and phone
number), the project's name, start and end dates, a
description of the requirements and system, and a description of the
team. Once the required information is provided, the system processes
the request appropriately by storing the information and confirming
completion.
This paragraph describes a specific scenario the classes and objects
that make up the project management system must be able to handle.
Chapter 6 describes sequence diagrams in detail.
Figure 2-20. Sequence diagram
2.4.2.2 Collaboration diagrams
Collaboration diagrams, also known
as interaction
diagrams, depict how elements interact over time and how
they are related. Note that both sequence and collaboration diagrams
are specific types of interaction diagrams. Collaboration diagrams
have the types of elements that are described in the list shown next.
Classes and objects
Classes are shown much the same
way as on class diagrams. Objects may
also be shown much the same way as on object diagrams. Again, in
Chapter 6, you will encounter roles that define
placeholders for classes and objects.
Associations
These are shown much the same
way as on class diagrams. Links may
also be shown much the same way as on object diagrams.
A communication
This is shown as an arrow attached
to a relationship pointing from the sender toward the receiver. It is
labeled with a sequence number showing the order in which the
communication is sent followed by a colon followed by the name of the
operation to be invoked. It represents that the sender sends a
message to the receiver.
Figure 2-21 is based on the same part from the
requirements description provided at the beginning of the chapter as
Figure 2-20 but additionally includes the
relationships. Chapter 6 describes collaboration
diagrams in detail.
Figure 2-21. Sequence diagram
2.4.2.3 State diagrams
State diagrams, also known
as statechart
diagrams, depict the lifecycle of an element. State
diagrams have the following types of elements:
A state
Shown as a rectangle with
rounded corners, this represents a
condition or situation of an element.
An event
This is an occurrence of receiving a message.
A transition
Shown as a solid line from a
source state to a target state
labeled with an event, this represents that if the element is in the
source state and the event occurs, it will enter the target state.
Initial state
When an element is
created, it enters its
initial state, which is shown as a small, solid,
filled circle. The transition originating from the initial state may
be labeled with the event that creates the element.
Final state
When an element
enters its final
state, which is shown as a circle surrounding a small
solid filled circle (a bull's eye), it is destroyed.
The transition to the final state may be labeled with the event that
destroys the element.
Figure 2-22 is based on the following part of a
paragraph from the requirements description provided at the beginning
of the chapter:
Initially, the project is inactive. It becomes active when human
resources are assigned to the project, may become inactive again if
human resources are unassigned from the project, and is removed from
the system once it is completed.
This paragraph describes the lifecycle of a project object that makes
up the project management system. Chapter 7
describes state diagrams in detail.
Figure 2-22. Sequence diagram
2.4.2.4 Activity diagrams
Activity diagrams depict
the activities and responsibilities
of elements. Activity diagrams have the following types of elements:
An action state
Shown as a shape with
straight top and bottom with convex
arcs on the two sides, this represents processing.
A control-flow transition
Shown as a solid line from a source action state to a target
action state, this represents that once the source action state
completes its processing, the target action state starts its
processing.
An initial action state
Shown as a small solid filled circle, the control-flow transition
originating from the initial state specifies the first action state.
A final action state
Shown as a circle surrounding a
small solid filled circle (a bull's eye), the
control-flow transition to the final state specifies the final action
state.
An object-flow
Shown as a dashed arrow between
an action state and an object, this
represents that the action state inputs or outputs the object. An
input object flow, which points to an action state, represents that
the action state inputs the object. An output object flow, which
points to an object, represents that the action state outputs the
object.
A swimlane
Shown as a visual region
separated from neighboring swimlanes by
vertical solid lines on both sides and labeled at the top with the
element responsible for action states within the swimlane, this
represents responsibility.
Figure 2-23 is based on the same part of the
requirements description provided at the beginning of the chapter as
Figures Figure 2-20 and Figure 2-21, but emphasizes the activities and
responsibilities of a project manager and the project
management system. Chapter 8 describes activity
diagrams in detail.
Figure 2-23. Activity diagram
2.4.3 Other Elements
A language often contains elements that are purely notational and
other elements that allow for extending the language. UML is no
different. UML provides notational items such as notes. Stereotypes
and properties allow you to extend the UML.
2.4.3.1 Notes
A note, shown as a rectangle with
a bent upper-right
corner that may be attached to another element using a dashed line,
represents a comment similar to comments in programming languages.Figure 2-24 shows a comment attached to the
Project class.
Figure 2-24. Notes, stereotypes, and properties
2.4.3.2 Stereotypes
A stereotype, shown as a text
string keyword
enclosed in guillemets («», pronounced
gee-a-may) or double-angle brackets, before or above the name of an
element, represents a specific meaning associated with the element.Figure 2-24 shows a stereotype attached to the
Project class in this example, indicating that the
class represents a database table. Chapter 9
describes stereotypes in more detail.
2.4.3.3 Properties
Properties are shown as a
comma-delimited
list of text strings inside a pair of braces ({})
after or below the name of an element, and expressed in any natural
or computer language, represents characteristics of the element. The
text string representing a property can take on two forms:
A text string may
be a tagged value,
shown as a keyword-value pair (a keyword followed by an equal sign
followed by its value) that represents a characteristic of the
element and its value.
A text string may be a constraint, shown as a
text string that may be expressed in the Object Constraint Language
(OCL) that represents a condition the element must satisfy.
Figure 2-24 shows the properties of the
Project class, including the version that is used,
as well as the business rule concerning the start and end dates of a
project. Chapter 9 describes properties in more
detail, and Chapter 10 describes the OCL in more
detail.
