Laborator 5 UML

Lab.
5 Structural modeling
CLASS DIAGRAM
Software Engineering_2010
Conf.dr. Cristina Mndru
Lab. 5 Structural modeling. CLASS DIAGRAM

Bibliography:
Tom Pender, UML Bible
http://www.agilemodeling.com
A. CLASS DIAGRAM
1. Introduction
The Class diagram stands at the center of the object-modeling process. It is the primary
diagram for capturing all the rules that govern the definition and use of objects.
As the repository for all the rules it is also the primary source for forward engineering (turning
a model into code), and the target for reverse engineering (turning code into a model).
Attributes and operations describe the knowledge and behaviour of a class.
Additional embellishments such as stereotypes, tagged values, and constraints describe
how you can customize classes to facilitate development in a particular domain.
The Class diagram is probably the most widely used diagram of the UML.
The Class diagram is also the primary diagram for generating code.
The next figure illustrates that even though each of the other diagrams help modelers
discover valuable information about a subject, everything they uncover must somehow make
its way onto the Class diagram.
The notations of the Class diagram provide a simple and powerful means to specify everything needed to generate
code. With rigor and the proper software support, the Class diagram can even become fully executable. This means
that the model can be tested by executing scenarios and can even generate the complete application in a variety of
implementation environments.
Lab.5 Structural modeling

CLASS DIAGRAM
2. MODELING ELEMENTS
CLASS a definition for a resource; describes a type of object; describes the features of an
entity and how it can be used.
One class definition describes many objects of the same type. An object is an instance of a class.
RELATIONSHIP - The purpose of a relationship is to establish the reason why two classes of
objects need to know about one another, and the rules that govern the relationship. UML
relationships come in three different types: association, generalization, and dependency.
2.1 CLASS MODELING ELEMENTS

Name defines class identity. It must be unique within a package; when referring to classes with the same
name but different owning packages, use the fully qualified name in the format package-name::class-name.
Attribute: define the type of information that can be owned and managed by the type of object
defined by the class that owns the attributes.
Operation (and method): defines how a behavior can be invoked on an object. The operation is
distinct from the method that provides the implementation for the operation. In fact, more than
one method may be defined for the same operation in different classes.
Visibility: defines the level of access allowed to a model element such as a class, an attribute,
or an operation. The allowed visibility values are: private, public, protected, and package.
Multiplicity: Multiplicity defines the number of values that may be assigned to a model element
such as an attribute or a parameter. The number may be expressed as a range, an enumeration,
a fixed number, or an undefined limit (*).
Multiplicity ordering and uniqueness: designates the ordering and the uniqueness of the
values in the set bounded by the multiplicity values.
2.2 RELATIONSHIP TYPES AND MODELING ELEMENTS

Association and link:
Association = semantic relationship between two model elements (classes). Includes the rules
to establish and maintain the integrity of the relationships as the relationships are created and
used by the application.
A link is the simplest form of relationship that supports communication between objects. Two objects are aware of
one another because they own references to one another.
A link is an instance of an association. An association defines a type of link that may exist between types of
objects.
Multiplicity: Each end of an association must define the number of objects that may
participate in the association with one object from te other end.
Constraint: A constraint is a rule that must be enforced for the association to be valid. A
constraint is placed at an end of an association to dictate the conditions that have to be
satisfied before objects (of the type defined by the class at that association end) can
participate in the relationship. Constraints are enclosed in curly braces ({ }).
Role name: A role name explains how an object participates in a link. The role name is
placed at the end of an association next to the class (type of object) that plays the role.

CLASS DIAGRAM
Navigability: Each end of an association is designated as undefined (no notation),

navigable (an arrow on the end of the association), or not navigable (an X on the end of
the association).
Special Types of association

Reflexive association: A reflexive association defines a type of relationship that
may exist between objects of the same type (instances of the same class).
Aggregation is a type of association in which one class defines the objects that
participate as parts in an assembly or configuration and the other class represent the
whole, the entire assembly.
Composition is a type of aggregation in which a member object may only be a part
object of at most one aggregate object (and can not exist independently).
Generalization: Generalization provides a means for organizing similarities and differences
among a set of objects that share the same purpose. Generalization is a relationship between
classes in which one class called the superclass, contains features shared by all objects of the
class, and the other class, called the subclass, contains only the features that make a subset of
objects different from all other objects represented by the superclass.
Specialization describes the process of identifying the features that make objects
unique within a superclass. "A specialization" refers to an individual subclass.
Inheritance describes the fact that a subclass has access to the features of a
superclass at the time that it is used to instantiate an object.
Dependencies (refinement, realization, etc.): A dependency represents a high-level abstraction
of the relationship between model entities such as classes or packages. A dependency defines
only the existence of some kind of relationship without specifying the type of relationship. The
general nature of the dependency can be described using a stereotype such as include,
extend, realization, or refinement.
Class name - defines identity and purpose. (who am I)
Attributes - define information known by the class. (what I know)
Relations - define other classes known by the class. (who I know)
Operations - define class capabilities. (what I do)
3.
NOTATION
3.1 CLASSES
3.1.1 GENERAL NOTATION
Name
Attributes
Three predefined class compartments.

Name mandatory
Attributes optional
Operations - optional
Operations
User-defined
...
In addition, UML supports user-defined

compartments so that the modeler can add
project-related information or anything else
that she finds useful.
3.1.2 STEREOTYPE used to further define a class.

CLASS DIAGRAM
UML models a stereotype by enclosing the name in guillemets (French quotation marks) as in entity or control.
Icons from the Object-Oriented Software

Engineering method by Jacobson,
Christerson, Jonsson, and vergaard.
ways to model classes with stereotypes
3.1.3 VISIBILITY
Type
Scope
private
package
public
protected
within a class
within the same package
within a system
within an inheritance tree
A
notation
~
+
#
3.1.4 MULTIPLICITY
Specifies the number of values that may be associated with a model element.
Is modeled as a value expression.
Expresses
range of values
specific value
range without upper limit
set of discrete values
Notation
[vmin..vmax]
[v]
[vmin..*]
[v1, v2, , vn]
Can be annotated with constraints of ordering {ordered}, and uniqueness {unique}.
3.1.5 ATTRIBUTES COMPARTMENT
A list compartment.
May only contain attributes and always appears in the same relative location within
the class icon, just below the name compartment.
Contains all the information that an object can own.
An object can own three types of information:
knowledge about itself, namely its own structure
and its own current condition, called its state.
its immediate relationships.
specific information it may oversee.

CLASS DIAGRAM
Attribute notation
[visibility] [/] name [: type] [multiplicity] [=default] [{property-string}]
In the initial stages of analysis, it is usually easiest to simply default all attributes to private
() visibility. Later, if you find a compelling reason to change it you can always do so.
The attribute contains a derived value.
Derived value
computed, or figured out, using other data and a rule or formula.
used when the calculation is very costly, access is frequent, and timeliness
is critical, while the values don't change very often or not at all.
name - is required and must be unique within the class. Should be as descriptive as possible
to avoid confusion.
If the same name appears in multiple classes and you need to refer to both values in the same context,
the attribute name must be qualified with the class name in the form class_name.attribute_name.
(data) type identifies the kind of information that can be stored in the attribute.
may be:
A reference to a UML primitive Data Type (Integer, UnlimitedInteger, or String)
An enumeration such as Boolean
A reference to a language-specific type such as float, long, short in Java
A reference to another class in the system
multiplicity - specifies the number of values that may be associated with an attribute.
default - values that serve two very valuable purposes:
1. To protect the integrity of the system from being corrupted by missing or invalid values.
2. To provide significant ease-of-use improvements for the client.
Default values are applied to the attribute when an object is created.
property string - defines any information about the attribute that does not fit into one of
the predefined fields for an attribute.

The most common use of properties is to hold the constraints that guarantee the integrity of
the attribute value throughout the object's lifetime.
These rules may be expressed as constraints on the value. The constraints must be
implemented/enforced in any method that attempts to change the attribute value.
3.1.6 OPERATIONS COMPARTMENT

Operations define behaviors, the services that an object can provide.
UML makes a distinction between the interface to a behavior and the implementation of a behavior.
The interface to a behavior is called an operation. An operation declares the information needed to invoke
a behavior. The operation is modeled in the Class diagram.
The implementation of a behavior (not modeled in the Class diagram), is referred to as the method.
Operation notation
[visibility] name ([parameter-list]) ':' [return-result] [{properties}]
In addition, UML supports the use of exceptions, pre-conditions, and post-conditions.

CLASS DIAGRAM
name
should be as meaningful and expressive as possible.

does not have to be unique within a class.
The combination of the name, parameter list, and return result, often called
the signature, must be unique within the class.
(Note : this rule is not the same for all programming-languages. Some languages do not consider
the return result to be part of the signature.)
TIP
Follow the naming standards for the target language because the code will be generated
exactly as it is written in the diagram. For example, constructors are typically identified by the fact that the
operation name is the same as the class name.
Generally, the visibility is set to public until and unless there is a compelling reason to
limit it to package, protected, or private.
parameter-list - ordered list of attributes that together define the input to an operation. The
parameter-list is optional, that is, an operation does not have to have parameters.
Format: pairs name:datatype. separated with commas.

return-result is the output of the operation; has no name, only the return data type.
3.1.7 User-defined compartments

List compartment with a name, properties, stereotypes, etc.
Place to put any information that does not readily fit into any of the pre-defined
compartments.
3.1.8 ADVANCED CLASS FEATURES

a). A template class (parameterized class), supports the creation of a variety of classes
using parameters to describe the specific type of class.
To create a useable class,

the parameters are bound to the template.
The result is a class defined by the combination of the
parameters.
b). An interface supports the definition of a common way to interact with classes that might
not be related.
The means to invoke a behavior is called the operation or operation signature.

An operation signature includes the name, parameters, and return-result.
The unique combination of these elements defines an interface.

CLASS DIAGRAM
Alternative notations for interface
Notation for
REALIZES (IMPLEMENTS)
relationship.
The implementation of an interface is provided by the class that realizes or implements the
interface.
c). An abstract class is a class that cannot be instantiated.
Model an abstract class by italicizing the name of the class, by providing the {abstract}
property in the name compartment, or by adding the {abstract} property to the operation that
does not have a method.
3.2 RELATIONSHIPS
A software application requires a set of resources.
To use them each resource must be described using a class definition. Classes
describe the types of resources, their purpose, and the features that they provide, including attributes
and operations.
To coordinate the interaction of these resources, the way they can communicate
must be explained. To communicate, they need to be aware of one another.
3.2.1 ASSOCIATION
The model of an association contains:
the participating classes.
a connection
2 association ends
The most common type of association is binary association.

There also can be modelled n-ary associations.

CLASS DIAGRAM
rules that govern the relationship:

- name (semantic)
- roles of the participating classes
- multiplicity
- (other) constraints
Name
-
Expresses the intent of the relationship.

Usually - a verb or verb phrase.
Does not generate code.
The association name becomes even more important when two classes have more than one reason for
collaborating, so more association relationships exist between them.
Example: In the venue and event example, for instance,
a venue may sponsor an event while others host the
event. At other times a venue may be both the host and
the sponsor. Next figure uses two associations to
represent the fact that rules for hosting an event are
different from the rules for sponsoring an event. The two
associations need to be defined and maintained
separately.
The goal of an association name is to clearly and concisely define the purpose of the relationship between the two
types of objects. That purpose will guide the definition of the actual communication between the objects and drive
the definition of the roles that each object plays in the communication.
Role
-
explains how an object participates in the relationship
can generate code.
Multiplicity refers to the valid number of objects that may be related to an associated object.
The multiplicity assigned to an association end defines the number of objects that may be
associated with a single object on the other end of the association.
Use keyword {ordered} to specify that objects in the group need to be arranged in a sequence.
Constraint - defines a restriction that needs to be enforced on a modeling element to insure its
integrity throughout the life of the system.
Format - a string of text (in a specific language) that can be attached to almost any element
in the model. The language of the constraint may be OCL, a programming language, or even your own written
language, such as English, German, or French.
Constraints document the IMPLEMENTATION requirements for the end of the association.
They are implemented in the methods that create and alter the object references that represent the relationship.
Navigability describes the need for an object to access another object by "navigating across
the link." The object at the other end of the link can access the object on the navigable end of
the link. Navigability is modeled with an arrow on the end of the association. In an association
with no arrow both ends are navigable.

CLASS DIAGRAM
3.2.2. SPECIAL ASSOCIATIONS

a). Reflexive association
A reflexive association models relationships between objects in the same class.
A reflexive association is a very

common place to use role names.
b). Aggregation
Defines an assembly or a configuration of elements to make a larger more complex unit.
One object represents the interface to the assembly and assumes responsibility for
coordinating the behaviour of the aggregation.
For example, aggregation can model a project team. The classes represent people who are "connected" by
agreements and assignments.
The team can have a point of control, a project leader or manager for instance, who directs the activities of the team.
If the team is assigned to a new location or to work on a new assignment, every member of the team participates in
the relocation or the work on the assignment. They function together as a unit as directed by the project leader.
The aggregate represents the entire configuration and provides a single point of control to
the elements.
The assembly appears to function like a single object - when an instruction is given that
might affect the entire collection of objects and the aggregate object dictates how the
members will respond.
The aggregate object's interface is invoked from outside and the rest is handled within the assembly.
Example:
Reading the model:

An agent may be a part of no more than one agency, but an agent does not have to be part of an agency (0..1), that is
an agent may be independent.
The agency is always comprised of at least one agent but there may be any number of agents (1..*).
An agent is considered an employee (role name) of an agency.
Every agent is constrained by the fact that (s)he must have a current contract in order to be an employee of the agency.

CLASS DIAGRAM
10
c). Composition
Composition (strong aggregation) = aggregation where the life span of the member object
depends on the life span of the aggregate.
The aggregate has control over the behaviour of the member and over the creation and
destruction of the member (the member object cannot exist apart from the aggregate).
3.2.3. GENERALIZATION
The relation in which the objects of a specialized class (subclass) are substitutea for the objects
of a more general class (superclass).
Inheritance is the mechanism by which specific elements incorporate the structure and behaviour
of more general elements.
Inheritance is represented by the generalization relationship.

CLASS DIAGRAM
11
Notation for the generalization relationship
Generalization relates classes to one another where each class contains a subset of features needed to define one type
of object. Instantiating all the feature subsets from each of the classes in a single inheritance/ vertical path of the
generalization results in one object.
Example: To create a Musical object, you would need to combine

the Musical Class, the Play class and the Event class to get all the
features the attributes, the operations, and the associations
that define a Musical object. From the combined set of features,
you could create (instantiate) one object of type Musical.
May be abstract or concrete
Leaf classes - Must be concrete

CLASS DIAGRAM
12
3.2.4. DEPENDENCY
Dependency represents a client-supplier relationship in which a change to the supplier
requires a change to the client.
Dependency may also represent precedence.
Dependency notation
A dependency is modelled using a dashed arrow between model elements (one or more
clients and one or more suppliers).
UML predefines four general types of dependency: abstraction, binding, permission, and
usage.
3.3 SPECIAL KINDS of CLASSES

Utility class
-
has no instances.
represents a named collection of static (classscoped) attributes and operations.
A common use for utility classes is to hold common

functionality used throughout the system. For example, the
Math class provides basic mathematical functions that could be used
virtually anywhere in a system.
Enumeration
-
user-defined datatype that defines a set of values that

don't change (constants).
The values defined in an enumeration class are usually used

for validation.
The example shows the UML VisibilityKind enumeration used to define visibility
throughout the UML specification. It defines the valid set of values for setting
the scope of access on attributes, operations, and other model elements. Each
entry is a literal, a static string of text (like "public") that represents a valid
option for some value.

CLASS DIAGRAM
13
B. TIPS
CLASSES
Class name:
an accurate and concise descriptor for the type of object represented by the
class
noun or noun phrase
ASSOCIATIONS
Regardless of the complexity, each association has to define its own rules to establish and
maintain the integrity of the relationship. These rules include:
A way to uniquely and meaningfully identify the association.
The number of objects that may participate in the association.
The restrictions on the objects that are allowed to participate in the association.
The role that each type of object plays when it participates in the association.
A means to identify which objects may gain access across the association.
Information about the association, such as when it started, the terms of the
association, when it ended, and its current status.
Together, these rules define how the objects in an application can come into contact and
collaborate with one another.
C. UML to Java mapping

Next are illustrated the main UML constructions in class diagram and their
mapping to Java code.
The Java code presented near the classes is not the final code, but that excerpt that
implements the UML construction illustrated.
Class

CLASS DIAGRAM
14
Visibility for attributes and operations
Class scope attributes and operations
Attribute multiplicity
When an attribute contains multiple values it is usually implemented with some type of array
or with a reference to a container class.
Association
In order for an object to do work, it typically needs to interact with other objects. To do so, a
class must define the valid set of relationships and the rules for establishing and breaking
those relationships.
Likewise, classes need to define a means for each object to contact other objects so that
they can collaborate. The class defines an attribute that can contain a reference to another
object. References to different object types require different attributes.
A reference may be to a collection of objects, all for the same reason. In this case, a single
attribute holds multiple references. In UML, this is modelled using multiplicity. In a
programming language, this is accomplished with an array or some type of container class
like a Java Collection, such as a Set.
For each association relationship on the class diagram, the modeller
(or the modelling tool) must generate a reference attribute.

CLASS DIAGRAM
15
Bi-directional association
Uni-directional association
By default, navigability is defined for both ends of an association. If one end does not need to be
navigable, it is possible to save extra coding and maintenance by using uni-directional
association.
Association roles
Each object needs to hold a reference to the associated object or objects. The reference is held
in an attribute value within the object. When there is only one association then there is only one
attribute holding a reference.
In the generated code, the attribute will be named using the role name of the referenced object.

CLASS DIAGRAM
Association multiplicity
Reflexive association
Aggregation
16

CLASS DIAGRAM
Composition
Interface and Realizes Relationship
Generalization
17

CLASS DIAGRAM
18
Abstract class
D. INDIVIDUAL WORK
1. Study at
http://www.visual-paradigm.com/product/vpuml/provides/structuralmodeling.jsp
the following DEMO:
Class diagram
Exercise 1:
Represent using VP for UML and explain all syntactic elements in the next class diagram.
Exercise 2:
(a) Draw a class diagram representing a book defined by the following statement:
A book is composed of a number of parts, which in turn are composed of a number of chapters.
Chapters are composed of sections.
Focus only on classes and relationships.

CLASS DIAGRAM
19
(b) Add multiplicity.

(c) Extend the class diagram to include the following attributes:
book has a publisher, publication date, and an ISBN
each part has a title and a number
each chapter has a title, a number, and an abstract
each section has a title and a number
(d) Note that the Part, Chapter, and Section classes all include a title and a number attribute. Add an
abstract class and a generalization relationship to factor out these two attributes into the abstract
class.
(e) Write Java code for the classes in the final diagram: attributes (that will have private
visibility) and access methods (get() and set()) to each attribute. Define the operations and
write the methods to add parts to a book, to add chapters to a part and to add sections to a
chapter.
Exercise 3:
(a) Draw a class diagram representing the relationship between parents and children. Take into
account that a person can have both a parent and a child. Annotate associations with roles and
multiplicities.
(b) Write Java code that will contain class attributes and access methods to the attributes. Write a
main class that will instantiate more persons, will establish relationships between them and will
display the parents and the children of one of them.
Tip: Build a class Person and add two reflexive associations to model the relations of the person
with her parents and with her children.
Exercise 4:
A company consists of departments. Departments are located in one or more offices. One office
acts as a headquarter. Each department has a manager who is recruited from the set of
employees.
(a) Model the system for the company with a class diagram which consists of all the classes in
your system their attributes, relationships between the classes, multiplicity specifications, and
other model elements that you find appropriate.
(b) Write Java code that will contain class attributes and access methods to the attributes. Write a
main class that will instantiate the components of the company, will establish the relationships
between the components and will display the structure of the company.
Exercise 5:
A token-ring based local-area-network (LAN) is a network consisting of nodes, in which network
packets are sent around. Every node has a unique name within the network, and refers to its next
node. Different kinds of nodes exist: workstations are originators of messages; servers and
printers are network nodes that can receive messages. Packets contain an originator, a
destination and content, and are sent around on a network. A LAN is a circular configuration of
nodes.
(a) Draw a class diagram which consists of all the classes in your system their attributes,
relationships between the classes, multiplicity specifications, and other model elements that you
find appropriate.
(b) Adapt the class diagram from (a) to model a LAN in which we find two kinds of printers: ASCII
printers can only print ASCII documents. PostScript printers can print either ASCII or Postscript
documents. The documents are sent around as content of packets.
(c) Write Java code that will contain class attributes and access methods to the attributes.

Laborator 5 UML

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Laborator 5 UML

Hochgeladen von

Copyright:

Verfügbare Formate

Lab.

Lab. 5 Structural modeling. CLASS DIAGRAM

Lab.5 Structural modeling

2.1 CLASS MODELING ELEMENTS

2.2 RELATIONSHIP TYPES AND MODELING ELEMENTS

Lab.5 Structural modeling

Navigability: Each end of an association is designated as undefined (no notation),

Special Types of association

Three predefined class compartments.

In addition, UML supports user-defined

3.1.2 STEREOTYPE used to further define a class.

Lab.5 Structural modeling

Icons from the Object-Oriented Software

ways to model classes with stereotypes

Can be annotated with constraints of ordering {ordered}, and uniqueness {unique}.

3.1.5 ATTRIBUTES COMPARTMENT

Lab.5 Structural modeling

A reference to a UML primitive Data Type (Integer, UnlimitedInteger, or String)

An enumeration such as Boolean

A reference to a language-specific type such as float, long, short in Java

A reference to another class in the system

the predefined fields for an attribute.

3.1.6 OPERATIONS COMPARTMENT

Lab.5 Structural modeling

should be as meaningful and expressive as possible.

Format: pairs name:datatype. separated with commas.

3.1.7 User-defined compartments

3.1.8 ADVANCED CLASS FEATURES

To create a useable class,

The means to invoke a behavior is called the operation or operation signature.

Lab.5 Structural modeling

Alternative notations for interface

the participating classes.

The most common type of association is binary association.

Lab.5 Structural modeling

rules that govern the relationship:

Expresses the intent of the relationship.

explains how an object participates in the relationship

can generate code.

Lab.5 Structural modeling

3.2.2. SPECIAL ASSOCIATIONS

A reflexive association is a very

Reading the model:

Lab.5 Structural modeling

Lab.5 Structural modeling

Notation for the generalization relationship

Example: To create a Musical object, you would need to combine

May be abstract or concrete

Leaf classes - Must be concrete

Lab.5 Structural modeling

3.3 SPECIAL KINDS of CLASSES

A common use for utility classes is to hold common

user-defined datatype that defines a set of values that

The values defined in an enumeration class are usually used

Lab.5 Structural modeling

A way to uniquely and meaningfully identify the association.

The number of objects that may participate in the association.

C. UML to Java mapping

Lab.5 Structural modeling

Visibility for attributes and operations

Class scope attributes and operations

Lab.5 Structural modeling

Lab.5 Structural modeling

Lab.5 Structural modeling