Unit-1

Basic Structural Modelling

Contents
1. Classes
2. Relationships
3. Common Mechanisms
4. Diagrams
1. Classes:
Terms and Concepts:
• A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.
• Graphically, a class is rendered as a rectangle.
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 qualified 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.
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.
• For example, every wall has a height, width, and thickness; you might
model your customers in such a way that each has a name, address,
phone number, and date of birth.
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 that is shared by all objects of that class.
• A class may have any number of operations or no operations at all.
• For example, in a windowing library such as the one found in Java's awt package,
all objects of the class Rectangle can be moved, resized, or queried for their
properties. Often (but not always), invoking an operation on an object changes
the object's data or state.
• Graphically, operations are listed in a compartment just below the class
attributes. Operations may be drawn showing only their names.
• You can specify an operation by stating its signature, which includes
the name, type, and default value of all parameters and (in the case
of functions) a return type.
Organizing Attributes and Operations
• When drawing a class, you don't have to show every attribute and
every operation at once.
• You can indicate that there are more attributes or properties than
shown by ending each list with an ellipsis ("...").
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 FraudAgent class, as you might find in a credit card application, is responsible
for processing orders and determining if they are legitimate, suspect, or
fraudulent.
Common Modeling Techniques
i)Modeling the Vocabulary of a System
ii)Modeling the Distribution of Responsibilities in a System
iii)Modeling Nonsoftware Things
iv)Modeling Primitive Types
i)Modeling the Vocabulary of a System
ii)Modeling the Distribution of Responsibilities in a System
iii)Modeling Nonsoftware 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.
iv)Modeling Primitive Types
• Model the thing you are abstracting as a class 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.
2. Relationships
Terms and Concepts
• A relationship is a connection among things. In object-oriented
modeling, the three most important relationships are dependencies,
generalizations, and associations. Graphically, a relationship is
rendered as a path, with different kinds of lines used to distinguish
the kinds of relationships.
Dependencies
• A dependency is a relationship that states that one thing (for
example, class Window) uses the information and services of another
thing (for example, class Event), but not necessarily the reverse.
Graphically, a dependency is rendered as a dashed directed line,
directed to the thing being depended on. Choose dependencies when
you want to show one thing using another.
Generalizations
• A generalization is a relationship between a general kind of thing (called the
superclass or parent) and a more specific kind of thing (called the subclass or
child). Generalization is sometimes called an "is-a-kind-of" relationship: one thing
(like the class BayWindow) is-a-kind- of a more general thing (for example, the
class Window). An objects of the child class may be used for a variable or
parameter typed by the parent, but not the reverse.
Associations
• An association is a structural relationship that specifies that objects of one
thing are connected to objects of another. Given an association connecting
two classes, you can relate objects of one class to objects of the other class.
It's quite legal to have both ends of an association circle back to the same
class. This means that, given an object of the class, you can link to other
objects of the same class. An association that connects exactly two classes
is called a binary association. Although it's not as common, you can have
associations that connect more than two classes; these are called n-ary
associations.
• Beyond this basic form, there are four adornments that apply to
associations.
Name
• An association can have a name, and you use that name to describe the
nature of the relationship. So that there is no ambiguity about its meaning,
you can give a direction to the name by providing a direction triangle that
points in the direction you intend to read the name.

Role
• When a class participates in an association, it has a specific role that it plays in
that relationship; a role is just the face the class at the far end of the association
presents to the class at the near end of the association. You can explicitly name
the role a class plays in an association. The role played by an end of an
association is called an end name (in UML1, it was called a role name). the class
Person playing the role of employee is associated with the class Company playing
the role of employer.
Multiplicity
• An association represents a structural relationship among objects. In many
modeling situations, it's important for you to state how many objects may be
connected across an instance of an association. This "how many" is called the
multiplicity of an association's role. It represents a range of integers specifying
the possible size of the set of related objects.
• The number of objects must be in the given range. You can show a multiplicity of
exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can give
an integer range (such as 2..5). You can even state an exact number (for example,
3, which is equivalent to 3..3).
Aggregation
• A plain association between two classes represents a structural
relationship between peers, meaning that both classes are
conceptually at the same level, no one more important than the
other. Sometimes you will want to model a "whole/part" relationship,
in which one class represents a larger thing (the "whole"), which
consists of smaller things (the "parts"). This kind of relationship is
called aggregation, which represents a "has-a" relationship.
 Common Modeling Techniques
i) Modeling Simple Dependencies
ii) Modeling Single Inheritance
iii) Modeling Structural Relationships
i) Modeling Simple Dependencies
• Create a dependency pointing from the class with the operation to
the class used as a parameter in the operation.
i) Modeling Single Inheritance
iii)Modeling Structural Relationships
3. Common Mechanisms:
Terms and Concepts
• A note is a graphical symbol for rendering constraints or comments
attached to an element or a collection of elements. Graphically, a
note is rendered as a rectangle with a dog-eared corner, together
with a textual or graphical comment.
• A stereotype is an extension of the vocabulary of the UML, allowing
you to create new kinds of building blocks similar to existing ones but
specific to your problem. Graphically, a stereotype is rendered as a
name enclosed by guillemets (French quotation marks of the form «
»), placed above the name of another element.
• A tagged value is a property of a stereotype, allowing you to create
new information in an element bearing that stereotype. Graphically, a
tagged value is rendered as a string of the form name = value within a
note attached to the object.
• A constraint is a textual specification of the semantics of a UML
element, allowing you to add new rules or to modify existing ones.
Graphically, a constraint is rendered as a string enclosed by brackets{}
and placed near the associated element or connected to that element
or elements by dependency relationships. As an alternative, you can
render a constraint in a note.
• Stereotypes (Represents new elements)
• Tagged values (Represents new attributes)
• Constraints (Represents the boundaries)
Notes
• A note that renders a comment has no semantic impact, meaning
that its contents do not alter the meaning of the model to which it is
attached. This is why notes are used to specify things like
requirements, observations, reviews, and explanations, in addition to
rendering constraints.
• A note may contain any combination of text or graphics
Other Adornments
• Adornments are textual or graphical items that are added to an
element's basic notation and are used to visualize details from the
element's specification.
Stereotypes
• The UML provides a language for structural things, behavioral things,
grouping things, and notational things. These four basic kinds of
things address the overwhelming majority of the systems you'll need
to model.
• In its simplest form, a stereotype is rendered as a name enclosed by
guillemets (for example,«name») and placed above the name of
another element.
Tagged Values
• Every thing in the UML has its own set of properties: classes have
names, attributes, and operations; associations have names and two
or more ends, each with its own properties; and so on. With
stereotypes, you can add new things to the UML; with tagged values,
you can add new properties to a stereotype.
Constraints
• Everything in the UML has its own semantics. Generalization (usually,
if you know what's good for you) implies the Liskov substitution
principle, and multiple associations connected to one class denote
distinct relationships. With constraints, you can add new semantics or
extend existing rules. A constraint specifies conditions that a run-time
configuration must satisfy to conform to the model.
 Common Modeling Techniques
i) Modeling Comments
ii) Modeling New Properties
iii) Modeling New Semantics
i) Modeling Comments
• Put your comment as text in a note and place it adjacent to the element to
which it refers. You can show a more explicit relationship by connecting a
note to its elements using a dependency relationship.
• Remember that you can hide or make visible the elements of your model
as you see fit. This means that you don't have to make your comments
visible everywhere the elements to which it is attached are visible. Rather,
expose your comments in your diagrams only insofar as you need to
communicate that information in that context.
• If your comment is lengthy or involves something richer than plain text,
consider putting your comment in an external document and linking or
embedding that document in a note attached to your model.
ii) Modeling New Properties
• First, make sure there's not already a way to express what you want
by using basic UML.
• If you re convinced there's no other way to express these semantics,
define a stereotype and add the new properties to the stereotype.
The rules of generalization applytagged values defined for one kind of
stereotype apply to its children.
iii) Modeling New Semantics
• First, make sure there's not already a way to express what you want
by using basic UML.
• If you re convinced there's no other way to express these semantics,
write your new semantics in a constraint placed near the element to
which it refers. You can show a more explicit relationship by
connecting a constraint to its elements using a dependency
relationship.
4. Diagrams
4. Diagrams
Terms and Concepts
• A system is a collection of subsystems organized to accomplish a purpose
and described by a set of models, possibly from different viewpoints.
• A subsystem is a grouping of elements, some of which constitute a
specification of the behavior offered by the other contained elements.
• A model is a semantically closed abstraction of a system, meaning that it
represents a complete and self-consistent simplification of reality, created
in order to better understand the system. In the context of architecture,
• A view is a projection into the organization and structure of a system's
model, focused on one aspect of that system.
• A diagram is the graphical presentation of a set of elements, most often
rendered as a connected graph of vertices (things) and arcs (relationships).
Terms and Concepts
• In modeling real systems, no matter what the problem domain, you'll
find yourself creating the same kinds of diagrams, because they
represent common views into common models. Typically, you'll view
the static parts of a system using one of the following diagrams.
1. Class diagram
2. Component diagram
3. Composite structure diagram
4. Object diagram
5. Deployment diagram
6. Artifact diagram
Terms and Concepts
• You'll often use five additional diagrams to view the dynamic parts of
a system.
1. Use case diagram
2. Sequence diagram
3. Communication diagram
4. State diagram
5. Activity diagram
Terms and Concepts
Structural Diagrams
• The UML's structural diagrams exist to visualize, specify, construct,
and document the static aspects of a system.
• The UML's structural diagrams are roughly organized around the
major groups of things you'll find when modeling a system.
1.Class diagram Classes, interfaces, and collaborations

2.Component diagram Components

3.Object diagram Objects

4.Deployment diagram Nodes

Terms and Concepts
Behavioral Diagrams
• The UML's behavioral diagrams are used to visualize, specify,
construct, and document the dynamic aspects of a system.
• The UML's behavioral diagrams are roughly organized around the
major ways you can model the dynamics of a system.
1.Use case diagram Organizes the behaviors of the system

2.Sequence diagram Focuses on the time ordering of messages

3.Collaboration Focuses on the structural organization of objects that send and receive
diagram messages

4.State diagram Focuses on the changing state of a system driven by events

5.Activity diagram Focuses on the flow of control from activity to activity

Terms and Concepts
Common uses
Common uses
Common Modeling Techniques
ii) Modeling Simple Collaborations
• Identify the mechanism you'd like to model. A mechanism represents some
function or behavior of the part of the system you are modeling that results from
the interaction of a society of classes, interfaces, and other things.
• For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as
well.
• Use scenarios to walk through these things. Along the way, you'll discover parts of
your model that were missing and parts that were just plain semantically wrong.
• Be sure to populate these elements with their contents. For classes, start with
getting a good balance of responsibilities. Then, over time, turn these into
concrete attributes and operations.
iii) Modeling a Logical Database Schema
• Identify those classes in your model whose state must transcend the lifetime of
their applications.
• Create a class diagram that contains these classes. You can define your own set of
stereotypes and tagged values to address database-specific details.
• Expand the structural details of these classes. In general, this means specifying the
details of their attributes and focusing on the associations and their multiplicities
that relate these classes.
• Watch for common patterns that complicate physical database design, such as
cyclic associations and one-to-one associations. Where necessary, create
intermediate abstractions to simplify your logical structure.
• Consider also the behavior of these classes by expanding operations that are
important for data access and data integrity. In general, to provide a better
separation of concerns, business rules concerned with the manipulation of sets of
these objects should be encapsulated in a layer above these persistent classes.
• Where possible, use tools to help you transform your logical design into a physical
design.
Forward and Reverse Engineering
• Forward engineering is the process of transforming a model into code through a mapping to an
implementation language.
• Forward engineering results in a loss of information, because models written in the UML are
semantically richer than any current object-oriented programming language.
• In fact, this is a major reason why you need models in addition to code. Structural features, such as
collaborations, and behavioral features, such as interactions, can be visualized clearly in the UML,
but not so clearly from raw code.
• Reverse engineering is the process of transforming code into a model through a mapping from a
specific implementation language.
• Reverse engineering results in a flood of information, some of which is at a lower level of detail
than you'll need to build useful models.
• At the same time, reverse engineering is incomplete.
• There is a loss of information when forward engineering models into code, and so you can't
completely recreate a model from code unless your tools encode information in the source
comments that goes beyond the semantics of the implementation language.
Common Modeling Techniques
i) Modeling Different Views of a System
ii)Modeling Different Levels of Abstraction
iii)Modeling Complex Views
Common Modeling Techniques
i)Modeling Different Views of a System
• Decide which views you need to best express the architecture of your
system and to expose the technical risks to your project. The five
views of an architecture described earlier are a good starting point.
• For each of these views, decide which artifacts you need to create to
capture the essential details of that view. For the most part, these
artifacts will consist of various UML diagrams.
• As part of your process planning, decide which of these diagrams
you'll want to put under some sort of formal or semi-formal control.
These are the diagrams for which you'll want to schedule reviews and
to preserve as documentation for the project.
Common Modeling Techniques

ii)Modeling Different Levels of Abstraction

• Consider the needs of your readers, and start with a given model.
• If your reader is using the model to construct an implementation,
she'll need diagrams that are at a lower level of abstraction, which
means that they'll need to reveal a lot of detail. If she is using the
model to present a conceptual model to an end user, she'll need
diagrams that are at a higher level of abstraction, which means that
they'll hide a lot of detail.
Common Modeling Techniques
iii)Modeling Complex Views
• First, convince yourself that there is no meaningful way to present
this information at a higher level of abstraction, perhaps eliding some
parts of the diagram and retaining the detail in other parts.
• If you've hidden as much detail as you can and your diagram is still
complex, consider grouping some of the elements in packages or in
higher-level collaborations, then render only those packages or
collaborations in your diagram.
• If your diagram is still complex, use notes and color as visual cues to
draw the reader's attention to the points you want to make.