Classes

Classes are the most important building block of any object-oriented system. A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces.

You use classes to capture the vocabulary of the system you are developing. These classes may include abstractions that are part of the problem domain, as well as classes that make up an implementation.

Modeling a system involves identifying the things that are important to your particular view. These things form the vocabulary of the system you are modeling. In the UML, all of these things are modeled as classes. A class is an abstraction of the things that are a part of your vocabulary. A class is not an individual object, but rather represents a whole set of objects.

The UML provides a graphical representation of class, as well, as the below figure shows. This notation permits you to visualize an abstraction apart from any specific programming language and in a way that lets you emphasize the most important parts of an abstraction: its name, attributes, and operations.

Names

Every class must have a name that distinguishes it from other classes. A name is a textual string. That name alone is known as a simple name; a path name is the class name prefixed by the name of the package in which that class lives. A class may be drawn showing only its name, as shown below:

A class name may be text consisting of any number of letters, numbers, and certain punctuation marks (except for marks such as the colon, which is used to separate a class name and the name of its enclosing package) and may continue over several lines. In practice, class names are short nouns or noun phrases drawn from the vocabulary of the system you are modeling. Typically, you capitalize the first letter of every word in a class name, as in Customer or TemperatureSensor.

Attributes

An attribute is a named property of a class that describes a range of values that instances of the property may hold. A class may have any number of attributes or no attributes at all. An attribute represents some property of the thing you are modeling that is shared by all objects of that class. At a given moment, an object of a class will have specific values for every one of its class's attributes. Graphically, attributes are listed in a compartment just below the class name. Attributes may be drawn showing only their names, as shown below:

In practice, an attribute name is a short noun or noun phrase that represents some property of its enclosing class. Typically, you capitalize the first letter of every word in an attribute name except the first letter, as in name or loadBearing.

You can further specify an attribute by stating its class and possibly a default initial value, as shown below: 

Operations

An operation is the implementation of a service that can be requested from any object of the class to affect behavior. In other words, an operation is an abstraction of something you can do to an object and that is shared by all objects of that class. A class may have any number of operations or no operations at all. Graphically, operations are listed in a compartment just below the class attributes. Operations may be drawn showing only their names, as shown below:

In practice, an operation name is a short verb or verb phrase that represents some behavior of its enclosing class. Typically, you capitalize the first letter of every word in an operation name except the first letter, as in move or isEmpty.

You can specify an operation by stating its signature, covering the name, type, and default value of all parameters and (in the case of functions) a return type, as shown below:

Organizing Attributes and Operations

When drawing a class, you don't have to show every attribute and every operation at once. An empty compartment doesn't necessarily mean there are no attributes or operations, just that you didn't choose to show them. You can explicitly specify that there are more attributes or properties than shown by ending each list with an ellipsis ("..."). To better organize long lists of attributes and operations, you can also prefix each group with a descriptive category by using stereotypes.

Responsibilities

A responsibility is a contract or an obligation of a class. When you create a class, you are making a statement that all objects of that class have the same kind of state and the same kind of behavior. At a more abstract level, these corresponding attributes and operations are just the features by which the class's responsibilities are carried out. A Wall class is responsible for knowing about height, width, and thickness.

When you model classes, a good starting point is to specify the responsibilities of the things in your vocabulary. Techniques like CRC cards and use case-based analysis are especially helpful here. A class may have any number of responsibilities, although, in practice, every well-structured class has at least one responsibility and at most just a handful.

Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class icon, as shown below:

Responsibilities are just free-form text. In practice, a single responsibility is written as a phrase, a sentence, or (at most) a short paragraph.

Common Modeling Techniques

Modeling the Vocabulary of a System

To model the vocabulary of a system,

• Identify those things that users or implementers use to describe the problem or solution. Use CRC cards and use case-based analysis to help find these abstractions.
• For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes.
• Provide the attributes and operations that are needed to carry out these responsibilities for each class.

Below figure shows a set of classes drawn from a retail system, including Customer, Order, and Product. This figure includes a few other related abstractions drawn from the vocabulary of the problem, such as Shipment (used to track orders), Invoice (used to bill orders), and Warehouse (where products are located prior to shipment). There is also one solution-related abstraction, Transaction, which applies to orders and shipments.

Modeling the Distribution of Responsibilities in a System

To model the distribution of responsibilities in a system,

• Identify a set of classes that work together closely to carry out some behavior.
• Identify a set of responsibilities for each of these classes.
• Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own.
• Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little.

For example, below figure shows a set of classes drawn from Smalltalk, showing the distribution of responsibilities among Model, View, and Controller classes. Notice how all these classes work together such that no one class does too much or too little.

Modeling Nonsoftware Things

To model non-software things,

• Model the thing you are abstracting as a class.
•  If you want to distinguish these things from the UML's defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give a distinctive visual cue.
• If the thing you are modeling is some kind of hardware that itself contains software, consider modeling it as a kind of node, as well, so that you can further expand on its structure.

As below figure shows, it's perfectly normal to abstract humans (like AccountsReceivableAgent) and hardware (like Robot) as classes, because each represents a set of objects with a common structure and a common behavior.

Modeling Primitive Types

To model primitive types,

• Model the thing you are abstracting as a type or an enumeration, which is rendered using class notation with the appropriate stereotype.
•  If you need to specify the range of values associated with this type, use constraints.

As below figure shows, these things can be modeled in the UML as types or enumerations, which are rendered just like classes but are explicitly marked via stereotypes. Things like integers (represented by the class Int) are modeled as types, and you can explicitly indicate the range of values these things can take on by using a constraint. Similarly, enumeration types, such as Boolean and Status, can be modeled as enumerations, with their individual values provided as attributes.

Software Development Life Cycle

The UML is largely process-independent, means that it is not tied to any particular software development life cycle. However, to get the most benefit from UML, we should consider a process that is:

•  Use case driven
•  Architecture centric
• Iterative and Incremental

Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating system’s architecture, for testing, and for communicating among the stakeholders of the project.

Architecture centric means that a system’s architecture is used as a primary artifact for conceptualizing, constructing, managing and evolving the system under development.

An iterative process is one that involves managing a stream of executable releases. An  iteration is one that involves the continuous integration of the system’s architecture to produce these releases, with each new release embodying incremental improvements over the other.

This use case driven, architecture centric and iterative/incremental process can be broken down into phases. A phase is the span of time between two major milestones of the process. As the below figure shows, there are four phases in the software development life cycle: inception, elaboration, construction and transition. In the figure below, workflows are plotted against these phases, showing their varying degrees of focus over time.

Inception is the first phase of the process, when the seed idea for the development is brought up to the point of being at least internally sufficiently well-founded to warrant entering into the elaboration phase.

Elaboration is the second phase of the process, when the product vision and its architecture are defined. In this phase, the system’s requirements are prioritized and baselined.

Construction is the third phase of the process, when the software is brought from an executable architectural baseline to being ready to be transitioned to the user community.

Transition is the fourth phase of the process, when the software is turned into the hands of the user community. Rarely does the software development process end here, for even during this phase, the system is continuously improved, bugs are eradicated and features that didn’t make an earlier release are added.

An iteration is a distinct set of activities, with a baselined plan and evaluation criteria that result in a release, either internal or external. This means that the software development life cycle can be characterized as involving a continuous stream of executable releases of the system’s architecture. It is this emphasis on architecture as an important artifact that drives the UML to focus on modeling the different views of a system’s architecture.

Architecture

Visualizing, specifying, constructing and documenting a software-intensive system demands that the system be viewed from a number of perspectives. Different stakeholders like end users, analysts, developers, system integrators, testers, technical writers and project managers each looks at the system in different ways at different times over the project’s life. A system’s architecture is perhaps the most important artifact that can be used to manage these different viewpoints and so control the iterative and incremental development of a system throughout its life cycle.

Architecture is the set of significant decisions about:

• The organization of a software system
• The selection of the structural elements and their interfaces by which the system is composed
•  Their behavior, as specified in the collaborations among those elements
• The composition of these structural and behavioral elements into progressively larger sub systems
• The architectural style that guides this organization: the static and dynamic elements and their interfaces, their collaborations and their composition

As the below figure illustrates, the architecture of a software-intensive system can best be described by five interlocking views. Each view is a projection into the organization and structure of the system, focused on a particular aspect of the system.

 

The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts and testers. With UML, the static aspects of this view are captured in use case diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

The design view of a system encompasses the classes, interfaces and collaborations that form the vocabulary of the problem and its solution. With UML, the static aspects of this view are captured in class diagrams and object diagrams while the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

The process view of a system encompasses the threads and processes that form the system’s concurrency and synchronization mechanisms. With UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes.

The implementation view of a system encompasses the components and files that are used to assemble and release the physical system. With UML, the static aspects of this view are captured in component diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

The deployment view of a system encompasses the nodes that form the system’s hardware topology on which the system executes. With UML, the static aspects of this view are captured in deployment diagrams and the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams and activity diagrams.

Each of these five views can stand alone so that different stakeholders can focus on the issues of the system’s architecture that most concern them. The UML permits us to express every one of these five views and their interactions.

Conceptual Model of the UML

To understand the UML, we need to form a conceptual model of the language, and this requires learning three major elements: 1) UML's basic building blocks, 2) The rules that tell us how these building blocks may be put together and 3) Some common mechanisms that apply throughout the UML.

Building Blocks of UML

The vocabulary of the UML consists of three kinds of building blocks:

1. Things
2. Relationships
3. Diagrams

Things are the abstractions that are first-class citizens in a model; relationships tie these things together and diagrams group interesting collections of things.

Things in UML

There are four kinds of things in UML:

1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

These things are the basic object-oriented building blocks of the UML. We use them to write well-formed models.

Structural Things

Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. In all, there are seven kinds of structural things:

First, a class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically a class is rendered as a rectangle, usually including its name, attributes and operations as shown below:

Second, an interface is a collection of operations that specify a service of a class or component. An interface therefore describes the externally visible behavior of that element. Graphically, an interface is rendered as a circle together with its name. An interface is typically attached to the class or component that realizes that interface.

Third, a collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Therefore, collaborations have structural as well as behavioral dimensions. Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name as shown below:

Fourth, a use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor. A use case is used to structure the behavioral things in a model. A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name as shown below:

Fifth, an active class is a class whose object own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered just like a class, but with thick lines, usually including its name, attributes and operations as shown below:

Sixth,a component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Generally, a component is rendered as a rectangle with tabs, usually including its name as shown below:

Seventh, a node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube, usually including only its name as shown below:

Behavioral Things

Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. In all, there are two primary kinds of behavioral things.

First, an interaction is a behavior contains a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. An interaction involves messages, action sequences and links. Graphically, a message is rendered as a directed line, almost always including the name of its operation as shown below:

Second, a state machine is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. A state machine involves other elements like states, transitions, events and activities. Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates as shown below:

Grouping Things

Grouping things are the organized parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely, packages.

A package is general purpose mechanism for organizing elements into groups. Structural things, behavioral things and even other things may be placed in a package. Graphically, a package is rendered as a tabbed folder, usually including only its name and sometimes, its contents as shown below:

Annotational Things

Annotational things are the explanatory parts of UML models. These are the comments we may apply to describe, illuminate and remark about any element in a model. There is one primary kind of annotational thing, called a note. Graphically a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment as shown below:

Relationships in UML

There are four kinds of relationships in UML:

1.       Dependency

2.       Association

3.       Generalization

4.       Realization

These relationships are the basic relational building blocks of the UML. We use them to write well-formed models.

First, a dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed line, possibly directed and occasionally including a label as shown below:

Second, an association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments such as multiplicity and role names as shown below:

Third, a generalization is a specialization/generalization relationship in which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent as shown below:

Fourth, a realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship as shown below:

Diagrams in UML

A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of things and relationships. We draw diagrams to visualize a system from different perspectives. So, a diagram is a projection into a system. In theory, a diagram may contain any combination of things and relationships. In practice, however a small number of common combinations arise, which are consistent with the five most useful views that make up the architecture of a software-intensive system. For this reason, UML includes nine such diagrams:

1.       Class diagram

2.       Object diagram

3.       Use case diagram

4.       Sequence diagram

5.       Collaboration diagram

6.       Statechart diagram

7.       Activity diagram

8.       Component diagram

9.       Deployment diagram

A class diagram shows a set of classes, interfaces, collaborations and their relationships. These diagrams are the most common diagrams found in modeling the object-oriented systems. Class diagrams address the static design view of a system. Class diagrams that include active classes address the static process view of a system.

An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams.

A use case diagram shows a set of use cases and actors and their relationships. Use case diagrams address the static use case view of a system. Theses diagrams are especially important in organizing and modeling the behaviors of a system.

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams. Interaction diagrams address the dynamic view of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages. A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.

A statechart diagram shows a state machine, consisting of states, transitions, events and activities. Statechart diagrams address the dynamic view of a system.

An activity diagram is a special kind of statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects.

A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system.

A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of architecture. They are related to component diagrams in that a node typically encloses one or more components.

Rules of UML

The UML’s building blocks can’t simply be thrown together in a random fashion. Like any other language, UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with all its related models.

The UML has semantic rules for:

 

Models built during the development of a software-intensive system tend to evolve and may be viewed by many stakeholders in different ways and at different times. For this reason, it is common for the development team to not only build models that are well-formed, but also to build models that are:

 

These less-than-well-formed models are unavoidable as the details of a system unfold during the software development life cycle.

Common Mechanisms in UML

UML is made simpler by the presence of four common mechanisms that apply consistently throughout the language:

1.       Specifications

2.       Adornments

3.       Common divisions

4.       Extensibility mechanisms

Specifications

The UML is more than just a graphical language. Rather, behind every part of its graphical notation there is a specification that provides a textual statement of syntax and semantics of that building block. For example, behind a class icon is a specification that provides the full set of attributes, operations and behaviors that the class embodies. We use the UML’s graphical notation to visualize the system. We use UML’s specification to state the system’s details.

Adornments

Most elements in the UML have a unique and direct graphical notation that provides a visual representation of the most important aspects of the element. For example, the notation for a class is intentionally designed to be easy to draw, because classes are the most common element found in modeling object-oriented systems.

A class’s specification may include other details, such as whether it is abstract or the visibility of its attributes and operations. Many of these details can be rendered as graphical or textual adornments to the class’s basic rectangular notation. The below figure shows a class, adorned to indicate that it is an abstract class with two public, one protected and one private operation:

Common Divisions

In modeling object-oriented systems, the world often gets divided in at least a couple of ways. First, there is division of class and object. A class is an abstraction and an object is one concrete manifestation of that abstraction. In UML, we can model classes as well as objects, as shown below:

 

In the above figure, there is one class, named customer, together with three objects: Jan, :Customer and Elyse.

Second, there is separation of interface and implementation. An interface declares a contract, and an implementation represents one concrete realization of that contract. In UML, you can model both interfaces and their implementations as shown below:

In the above figure, there is one component named spellingwizard.dll that implements two interfaces, IUnknown and ISpelling.

Extensibility Mechanisms

The UML provides a standard language for writing software blueprints, but it is not possible for one closed language to ever be enough to express all possible nuances of all models across all domains across all time. For this reason, UML is opened-ended, making it possible for us to extend the language in controlled ways. UML’s extensibility mechanisms include:

·         Stereotypes

·         Tagged values

·         Constraints

A stereotype extends the vocabulary of the UML, allowing us to create new kinds of building blocks that are derived from existing ones but that are specific to our problem. For example, if we are working in a programming language, such as Java or C++, we will often want to model exceptions. In these languages, exceptions are just classes, although they are treated in very special ways.

A tagged value extends the properties of a UML building block, allowing us to create new information in that element’s specification. For example, if we are working on a shrink-wrapped product that undergoes many releases over time, we often want to track the version and author of certain critical abstractions. Version and author are not primitive concepts in UML. They can be added to any building block, such as a class, by introducing new tagged values to that building block as shown in the figure below:

A constraint extends the semantics of a UML building block, allowing you to add new rules or modify existing ones. For example, you might want to constrain the EventQueue class so that all additions are done in order. Below figure shows that you can add a constraint that explicitly marks these for the operation add.

Collectively, these three extensibility mechanisms allow you to shape and grow UML to our project’s needs.

More Resources:
http://www.cs.uah.edu/~rcoleman/Common/SoftwareEng/UML.html