laborator 5 uml

Lab.5 Structural modeling 1 Software Engineering_2010 CLASS DIAGRAM Conf.dr. Cristina Mîndruþã

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.

id1788732 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com

http://www.agilemodeling.com


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.


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».

3. NOTATION

3.1 CLASSES 3.1.1 GENERAL NOTATION

3.1.2 STEREOTYPE � used to further define a class.

Three predefined class compartments. Name � mandatory Attributes � optional Operations - optional

In addition, UML supports user-defined compartments so that the modeler can add project-related information or anything else that she finds useful.

Name

Attributes

Operations

User-defined

...

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)


UML models a stereotype by enclosing the name in guillemets (French quotation marks) as in «entity» or «control».

3.1.3 VISIBILITY

Type Scope A notation

private within a class - package within the same package ~

public within a system + protected within an inheritance tree #

3.1.4 MULTIPLICITY

Specifies the number of values that may be associated with a model element. Is modeled as a value expression.

Expresses Notation range of values [vmin..vmax] specific value [v]

range without upper limit [vmin..*] set of discrete values [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.

ways to model classes with stereotypes

Icons from the Object-Oriented Software Engineering method by Jacobson, Christerson, Jonsson, and Övergaard.

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.


Attribute notation

[visibility] [/] name [: type] [multiplicity] [=default] [{property-string}]

name - is required and must be unique within the class. Should be as descriptive as possible to avoid confusion.

(data) type identifies the kind of information that can be stored in the attribute.

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 Operation notation

[visibility] name ([parameter-list]) ':' [return-result] [{properties}]

In addition, UML supports the use of exceptions, pre-conditions, and post-conditions.

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.

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.

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

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.


name should be as meaningful and expressive as possible. does not have to be unique within a class.

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.

b). An interface supports the definition of a common way to interact with classes that might not be related.

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.

To create a useable class, the parameters are bound to the template. The result is a class defined by the combination of the parameters.

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.


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

3.2.1 ASSOCIATION

The model of an association contains:

the participating classes.

a connection

2 association ends

Alternative notations for interface Notation for REALIZES (IMPLEMENTS) relationship.

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.

The most common type of association is binary association. There also can be modelled n-ary associations.


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 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.

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.

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.

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.


3.2.2. SPECIAL ASSOCIATIONS

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

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.

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.

A reflexive association is a very common place to use role names.

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.


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.


Notation for the generalization relationship

May be abstract or concrete

Leaf classes - Must be concrete

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.


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 (class-

scoped) 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.


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


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.


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.


Association multiplicity

Reflexive association

Aggregation


Composition

Interface and Realizes Relationship

Generalization


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.

http://www.visual-paradigm.com/product/vpuml/provides/structuralmodeling.jsp


(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

Documents

class diagram bibliography

class definition

class identity

modeling elements class

class modeling elements

primary diagram

structural modeling

type of object