Static Modeling

The Class Diagram is the most essential part of UML

modeling as it represents the static structure of the
solution, modeled at the most detailed level.

When the developers develop the solution, their main
source of information is the Class Diagram.

The Class Diagram provides developers with detailed
information about what operation code to develop, along
with information about data types, parameters, and
namespaces.

The different elements of Class diagrams are:
Class
Representation
Attributes
Operation
Class Visibility

A Class is a description of a group of objects with common
properties (Attributes), behavior (Operations),
relationships, and semantic.


A Class is represented using a compartmentalized
rectangle. A class representation comprises of three
sections .

The first section contains the class name.
The second section shows the structure
(attributes).
The third section shows the behavior
(operations).

Attributes represent essential characteristics of the class.

Attributes provide information storage for the class
instance, and are often used to represent the state of the
class instance.


For each attribute, the following should be defined:
Its name, which should follow naming conventions of
both the implementation language and the project

Its type, which will be an elementary data type supported
by the implementation language.

Its default or initial value, to which it is initialized when
new instances of the class are created.

Public: the attribute is visible both inside and outside the
package containing the class.

Protected: the attribute is visible only to the class
itself, to its subclasses, or to friends of the
class (language dependent).

Private: the attribute is only visible to the class itself and
to friends of the class.

Package Friendly: the attribute is visible only within the
package
"An operation is the implementation of a service that
can be requested from any object of the class to affect
behavior".
Class visibility defines whether attributes and operations
of the classes can be accessed by other classes.
+ - Public
# - Protected
-- Private
~- Package friendly

Relationships provide a pathway for communication
between objects. In UML, relationships are modeled as
lines, with different kinds of lines used to represent the
different kinds of relationships.

Following are the different types of relationships:
Association
Aggregation
Composition
Dependency
Generalizations

An Association is a bi-directional connection
between classes.
Multiplicity defines how many objects participate in a
relationship.

It is the number of instances of one class related to ONE
instance of the other class, which is specified for each end
of the association.

In the above example of multiplicity a student may or
may not have a schedule. A student may have
more than one schedule (for different semesters). A
schedule is associated with only one student.

An Aggregation is a stronger form of relationship where the
relationship is between a whole and its parts.

The aggregate has an aggregation association to the constituent parts.

Aggregation is represented by a hollow diamond attached to the end
of an Association Path close to the Aggregate.
Composition is a form of aggregation with strong ownership and
coincident lifetimes of the part with the aggregate.

The whole "owns" the part and is responsible for the creation
and destruction of the part.

The part is removed when the whole is removed. The part may
be removed (by the whole) before the whole is removed. A solid
filled diamond is attached to the end of an association path (on
the "whole side") to

A dependency is a using relationship that represents a relationship
between a client and a supplier where a change in the specification of
the supplier may affect the client.

A dependency relationship denotes a semantic relationship between
model elements, where a change in the supplier may cause a change in
the client, or a relationship between two model elements, where a
change in one may cause a change in the other.

Generalization is a relationship among classes where one class
shares the structure and/or behavior of one or more classes.

Generalization refines a hierarchy of abstractions in which a
subclass inherits from one or more superclasses.

Generalization is an "is-a-kind of' relationship. One should
always be able to say that generalized class is a kind of the
parent class. The terms "ancestor" and "descendent" may be
used instead of "superclass" and "subclass".

A class that exists only for other classes to inherit from it is an abstract
class.

A class that contains at least one abstract operation must be an
abstract class.

In UML, a class is designated as abstract by putting the tagged value
"{abstract}" within the name compartment of the class, under the class
name.

For abstract operations, "{abstract}" is placed after the operation
signature. The name of the abstract item can also be shown in italics.

A discriminator can be used to indicate the basis on which
the ,generalization/specialization occurred.

A discriminator describes a characteristic that differs in
each of the subclasses.
Name collisions:
Both ancestors have attributes and/or operations with the same
name. If the same name appears in several ancestors, it must be
described what this means to the specific inheriting class, for
instance, by qualifying the name to indicate its source of
declaration.

Repeated inheritance:
The same ancestor is being inherited by a descendant more
than once. When this occurs, the inheritance hierarchy will
have a "diamond shape" as shown above. The descendents
end up with multiple copies of an ancestor. If repeated
inheritance is being used, a clear definition of its semantics is a
must; in most cases, the programming language supporting the
multiple inheritance defines this.

Modeling Other Elements are:
Interfaces
Stereotypes
Constraints
An interface is "a collection of operations that are used to
specify a service of a class or component". Interfaces
formalize polymorphism.

Every implementation of the interface must implement at
least the interface. The implementation can in some cases
implement more than the interface.

For example, the same remote can be used to control any
type of television that supports a specific interface (the
interface the remote was designed to be used with).


Stereotypes allow one to extend the basic UML notation by allowing a
new modeling element to be defined based on an existing modeling
element.

The name of a stereotype is shown in guillemots, for example, stereotype
name.

A unique icon may be defined for the stereotype and the new element
may be modeled using the defined icon or the original icon with the
stereotype name displayed, or both. Stereotypes can be applied to all
modeling elements: classes, relationships, components, and so forth.
Each UML element can have at the most one stereotype. The
representation of a stereotype is depicted
Stereotypes:-

Constraints allow for addition of new semantics, or for
changing existing semantics to a UML model.

Constraints are represented as strings enclosed in braces
and placed near the element the constraint applies to.

A dependency relationship can be used if a constraint must
be attached to more than one element.

A professor can only be the Department Head for a
Department which he is a member.

Constraints

A package is a general purpose mechanism for organizing elements
into groups. A package diagram is composed of packages. It contains
the dependencies between them.

Packaging Elements and its Symbols and Notations

Package diagrams are used to reflect the organization of packages
and their elements.

They can be used to represent class elements and Use-Case
elements.

Elements contained in a package share the same namespace and so
the elements should have unique names.



A package provides the same functionality of a folder in
Windows operating system. They are depicted as file
folders and can be applied on any UML diagram.

Elements of a package can be represented inside the
rectangular portion of the package box. Contents of a
package can also be represented outside the package box
and linked using a (+) symbol.


Visibility
This visibility allows for specifying how other packages
can access the elements that are owned by the package.

The public elements of a package constitute the package's
interface.

The dependencies on a package actually represent the
dependencies on the public elements in the package.

Package visibility provides support for the 00 principle of
encapsulation.

Dependency
A dependency relationship between packages indicates
that the contents of the supplier packages may be
referenced by the client.
There are different types of Package diagrams. They are:
Class Package Diagrams
Classes in the same inheritance hierarchy typically
belong in the same package.

Classes related to one another via composition also
often belong in the same package.