OOAD ASSIGNMENT 1

reference : THE UML USER GUIDE

I HAVE ADDED THE WHOLE PARAGRAPH RELATING TO THE QUESTIONS SO U CAN CUT SHORT IT ACCORDING TO UR CHOICE & ALSO SORRY AS I WAS NOT ABLE 2 PUT THE DIAGRAM


Q1

Modeling is not just a part of the building industry. It would be inconceivable to deploy a new
aircraft or an automobile without first building models• from computer models to physical wind
tunnel models to full-scale prototypes. New electrical devices, from microprocessors to telephone
switching systems require some degree of modeling in order to better understand the system and
to communicate those ideas to others. In the motion picture industry, storyboarding, which is a
form of modeling, is central to any production. In the fields of sociology, economics, and business
management, we build models so that we can val idate our theories or try out new ones with
minimal risk and cost.
What, then, is a model? Simply put,
A model is a simplification of reality.
A model provides the blueprints of a system. Models may encompass detailed plans, as well as
more general plans that give a 30,000-foot view of the system under consideration. A good model
includes those elements that have broad effect and omits those minor elements that are not
relevant to the given level of abstraction. Every system may be described from different aspects
using different models, and each model is therefore a semantically closed abstraction of the
system. A model may be structural, emphasizing the organization of the system, or it may be
behavioral, emphasizing the dynamics of the system.
Why do we model? There is one fundamental reason.
We build models so that we can better understand the system we are
developing.
Through modeling, we achieve four aims. How the UML addresses these four things is discussed in Chapter 2.
1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.
Modeling is not just for big systems. Even the software equivalent of a dog house can benefit
from some modeling. However, it's definitely true that the larger and more complex the system,
the more important modeling becomes, for one very simple reason:
We build models of complex systems because we cannot comprehend such a
system in its entirety.
There are limits to the human ability to understand complexity. Through modeling, we narrow the
problem we are studying by focusing on only one aspect at a time. This is essentially the
approach of "divide-and-conquer" that Edsger Dijkstra spoke of years ago: Attack a hard problem
by dividing it into a series of smaller problems that you can solve. Furthermore, through model ing,
we amplify the human intellect. A model properly chosen can enable the modeler to work at
higher levels of abstraction.


Q 2
Relationships in the UML
There are 3 kinds of relationships
1. Dependency
2. Association
3. Generalization

These relationships are the basic relational building blocks of the UML. You use them to write
well-formed models. Dependencies are discussed in Chapters 5 and 10.
First, a dependency is a semantic relationship between two things in which a change to one thing
(the independent thing) may affect the semantics of the other thing (the dependent thing).
Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label, as in Figure 2-12.
Figure 2-12 Dependencies

Associations are discussed in Chapters 5 and 10.
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 in Figure 2-13.
Figure 2-13 Associations

Generalizations are discussed in Chapters 5 and 10.
Third, a generalization is a specialization/generalization relationship in which objects of the
specialized element (the child) are substitutable for objects of the generalized element (the
parent). In this way, the child shares the structure and the behavior of the parent. Graphically, a
generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the
parent, as in Figure 2-14.
Figure 2-14 Generalizations

Q3

NOTES :

A note is simply a symbol for rendering constraints and
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, as in Figure
2-11.
Figure 2-11 Notes

This element is the one basic annotational thing you may include in a UML model. You'll typically
use notes to adorn your diagrams with constraints or comments that are best expressed in
informal or formal text. There are also variations on this element, such as requirements (which
specify some desired behavior from the perspective of outside the model)


Streotypes

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, as shown
in Figure 5-4.
Figure 5-4 Association Names

Note
Although an association may have a name, you typically don't need to include one if
you explicitly provide role names for the association, or if you have a model with many
associations and you need to refer to or distinguish among associations. This is
especially true when you have more than one association connecting the same
classes.

Roles are related to the semantics of interfaces, as discussed in Chapter 11.
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 near end of the association presents to the class at the
other end of the association. You can explicitly name the role a class plays in an association. In
Figure 5-5, a Person playing the role of employee is associated with a Company playing the
role of employer.
Figure 5-5 Roles
Note
The same class can play the same or different roles in other associations.

An instance of an association is called a link, as discussed in Chapter 15.
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, and is written as an
expression that evaluates to a range of values or an explicit value as in Figure 5-6. When you
state a multiplicity at one end of an association, you are specifying that, for each object of the
class at the opposite end, there must be that many objects at the near end. You can show a
multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can
even state an exact number (for example, 3).



Q4

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.
Notes may be attached to more than one element by usingdependencies, as discussed in
Chapter 5.
A note may contain any combination of text or graphics. If your implementation allows it, you can
put a live URL inside a note, or even link to or embed another document. In this way, you can use
the UML to organize all the artifacts you might generate or use during development, as Figure 6-
3 illustrates.

Extensibility Mechanisms
The UML provides a standard language for writing software blueprints, but it is not possible for
one closed language to ever be sufficient to express all possible nuances of all models across all
domains across all time. For this reason, the UML is opened-ended, making it possible for you to
extend the language in controlled ways. The UML's extensibility mechanisms include
· Stereotypes
· Tagged values
· Constraints
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building
blocks that are derived from existing ones but that are specific to your problem. For example, if
you are working in a programming language, such as Java or C++, you will often want to model
exceptions. In these languages, exceptions are just classes, although they are treated in very
special ways. Typically, you only want to allow them to be thrown and caught, nothing else. You
can make exceptions first class citizens in your models• meaning that they are treated like basic
building blocks• by marking them with an appropriate stereotype, as for the class Overflow in
Figure 2-19.
Figure 2-19 Extensibility Mechanisms
A tagged value extends the properties of a UML building block, allowing you to create new
information in that element's specification. For example, if you are working on a shrink-wrapped
product that undergoes many releases over time, you often want to track the version and author
of certain critical abstractions. Version and author are not primitive UML concepts. They can be
added to any building block, such as a class, by introducing new tagged values to that building
block. In Figure 2-19, for example, the class EventQueue is extended by marking its version
and author explicitly.
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. As Figure 2-19 shows, you can add a constraint that explicitly
marks these for the operation add.
Collectively, these three extensibility mechanisms allow you to shape and grow the UML to your
project's needs. These mechanisms also let the UML adapt to new software technology, such as
the likely emergence of more powerful distributed programming languages. You can add new
building blocks, modify the specification of existing ones, and even change their semantics.
Naturally, it's important that you do so in controlled ways so that through these extensions, you
remain true to the UML's purpose• the communication of information.






Q 5

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.


To forward engineer a class diagram,
· Identify the rules for mapping to your implementation language or languages of choice.
This is something you'll want to do for your project or your organization as a whole.
· Depending on the semantics of the languages you choose, you may have to constrain
your use of certain UML features. For example, the UML permits you to model multiple
inheritance, but Smalltalk permits only single inheritance. You can either choose to
prohibit developers from modeling with multiple inheritance (which makes your models
language-dependent) or develop idioms that transform these richer features into the
implementation language (which makes the mapping more complex).
· Use tagged values to specify your target language. You can do this at the level of
individual classes if you need precise control. You can also do so at a higher level, such
as with collaborations or packages.
· Use tools to forward engineer your models.



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.
Figure 3-3 was created by reverse engineering part of theJava class library.
To reverse engineer a class diagram,
· Identify the rules for mapping from your implementation language or languages of choice.
This is something you'll want to do for your project or your organization as a whole.
· Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a
new model or modify an existing one that was previously forward engineered. · Using your tool, create a class diagram by querying the model. For example, you might
start with one or more classes, then expand the diagram by following specific
relationships or other neighboring classes. Expose or hide details of the contents of this
class diagram as necessary to communicate your intent.