Carlos Eduardo de Santana

Shift: Morning

Resumo dos 5 capítulos do livro UML- GUIA DO USUÁRIO

Chapter 1:

In a software development team, the main goal is to build

software that meets the user's needs. To do this, it is necessary to use good
practices and tools for requirements gathering, with the development of models
to visualize and better understand the project.
Modeling is a technique that is more popular and successful not only among the
software engineers, but also in the civil construction industry, automobiles,
microprocessors, etc. A model, in a simple way, is a simplification of
In reality, they provide a panoramic view of the system in question. Examples of good
Models are those that show the main components and omit those that do not have.
such importance at a certain level of abstraction.
Any project can benefit from modeling, from small projects to
large complex projects. It helps to tackle problems by separating them into
small aspects to solve one at a time.
Most software companies use little 'formal' modeling, as much
the simpler the project, the less likely formal modeling will be used. Many
developers create an informal modeling on paper to try to visualize part of the
system, but they tend to be ineffective when shared, due to a lack of a language
standard.
Using modeling will benefit any project, from the simplest ones, in which the
As the system evolves, having a modeling will be quite useful in the future; until
the most complex systems that, with the use of modeling, will minimize the
probability of errors.
According to the principles of modeling, choosing an appropriate model for such
system, is essential for better managing the project and for facilitating the resolution of the
problems. With different observers, models can be created with different levels of
precision, with the aim of visualizing some aspect according to the observer's needs.
The preferred models are those that are related to reality, because of that
form will not conceal important points of the system. And for a better investigation of
system, it is recommended to have more than one software model, with the aim of obtaining various
complementary visions, in order to achieve a better understanding of the architecture of
systems.
In software model construction, there are many ways to define a model.
The two most common are from the perspective of an algorithm or from the perspective
object-oriented.
The perspective of an algorithm is the traditional view in software development, in
that the focus is on the procedure, which concerns issues related to control and decomposition
of larger algorithms into smaller ones. This ultimately allows the trend of systems
unstable, jeopardizing future maintenance.
In the contemporary view, an object-oriented perspective is adopted. In this view, the
Object and class are the main building blocks of all software systems. This
method is a part of the main flow, encompassing all degrees of size and
complexity. And currently, many programming languages, operating systems, and tools are
object-oriented. Object-oriented development provides the fundamentals
conceptual for the assembly of systems from components using
technologies with J2EE or .NET. The visualization, the specification, the construction and the
The documentation of object-oriented systems is exactly the purpose of UML.

Chapter 2:

UML is an expressive language used to visualize, specify, construct, and

documenting a complex software system. To understand UML, you need to learn three
main elements: the basic building blocks of UML, the rules that determine
how these blocks can be combined and some common mechanisms applied in the
UML.
The building blocks are items, relationships, and diagrams. The items
they are divided into four types:
Structural items that are nouns used in UML models, such as classes, the
collaborations, the use cases, the active classes, the components, the artifacts, and the nodes.
These are the basic structural items that can be included in a UML model.
Behavioral items are the actions that represent behaviors over time and in
space. There are two types of behavioral items: interactions are a set of
messages that show the corresponding actions. A state machine is a
behavior that shows a sequence of states in response to events.
Grouping items are the organizational parts of UML models. They serve to
organize the parts of the project and they only exist during the development time.
Annotation items are the explanatory comments in UML models. They serve to
clarify or describe any element of the model using notes.
Relationships are divided into four types: dependency, association, generalization.
and achievement. A dependency is a relationship in which one item depends on the other,
in that a change in the independent item can affect the dependent item. They are
represented by dotted lines, usually with arrows. An association is connections
between elements of the model. It is represented by solid lines, usually with names of
papers and multiplicities. A generalization is a relationship between two objects in
that one is replaceable by the more generalized other, like children who share the
structure and the behavior of parents. They are represented by a solid line with a
white arrow towards the father. An achievement is a semantic relationship between
classifiers, in which one specifies a contract that another guarantees to execute. It is
represented by a dashed line with a white arrow.
The diagrams in UML are drawings with items and relationships to allow
to visualize a system partially. Certain combinations are commonly used.
elements that are consistent with the five most useful views of system architecture
software complex. They are: class diagrams, object diagram, diagram
of components, diagram of complex structures, use case diagram, diagram
of sequences, communication diagram, state chart diagram, diagram of
activities, deployment diagram, package diagram, timing diagram and
overview diagram of interaction.
The UML rules to encourage the construction of well-formed models are regarding
name, scope, visibility, integrity, and execution.
 The basic mechanisms of UML serve to make it simpler by adopting 4
mechanisms: Specifications, Ornaments, common divisions, and extension mechanisms.
Software architecture is the set of methods, techniques, and processes for construction
of a system. Software architecture is not only related to the structure and
behavior, but also to several other factors related to the characteristics of the
software. These characteristics can be more adequately described by five views
interconnected, which are the project vision, implementation vision, use case vision,
process view and implementation view. Each view encompasses the aspects of the system,
using diagrams to visualize such aspects.

Chapter 3:

According to Brian Kernighan and Denis Ritchie, the authors of the C language, "the only
one way to learn a new programming language is to use it to write
programs." The same applies to UML, using it to write models.
The first program that many developers write when they are starting out in
a new language is a simple program that writes "Hello, world!" on the screen. Let's
start using UML this way, model "Hello world!" which, apparently is a
simple program, but behind it there are some interesting mechanisms that make it
function
In Java, to make the applet display 'Hello world!' in a web browser is quite simple:
1import java.awt.graphics;
2 class HelloWorld extends java.applet.Applet {
3 public void paint (graphics g) {
4 g.drawString("Hello, world!", 10, 10);
5 }
6 }

The first line of the code makes the Graphics class available to the next
The line and the prefix java.awt indicate which package the Graphics class is in.
The second line introduces the HelloWorld class, and the next three lines declare a
operation called paint, whose implementation starts another operation, called drawString,
responsible for displaying "Hello, world!".
Using UML to model this application, the HelloWorld class can be represented
graphically as a rectangular icon. The paint operation is shown just below with its
formal parameters omitted, in a square and a dotted line from paint to a note
showing the parameter g.drawString. This class diagram captures the basics of
Hello, world! application, but does not include several items. We can simplify and add them.
Applet and Graphics classes in a different way. The Applet class is used as a parent.
HelloWorld and the Graphics class is used in the signature and implementation of one of its
operations, paint. These classes are represented as rectangular icons. The class
Applet has an arrow connecting HelloWorld to it indicating a generalization. And the class
Graphics has a dotted arrow connecting the paint to it, indicating a relationship of
dependence.
This is not the end, looking in the Java libraries for the Applet and Graphics classes,
we discovered that they are part of a larger hierarchy, enabling the construction of
another class diagram. The representation is as follows: the classes are inside each
rectangle and the HelloWorld class is a child of the Applet, which is a child of the Panel, which is a child of
Container, which is a child of Component, and which is a child of the object. The ImageObserver is
under a circle with a solid line connected to the Component. This model
corresponds to the Java library - each subclass extends the immediate parent class.
ImageObserver is an interface, so it is different.
As shown by the graphical representations, HelloWorld only collaborates directly
with two classes (Applet and Graphics), which are in a small part of the larger library
of predefined classes in Java. To manage the extensive collection of packages, the language
Java organizes its interfaces and classes into several different packages.
These packages can be viewed in a class diagram, they are represented
in UML by directories with guides. Packages can be nested, with dashed lines.
representing the dependencies between the packages.
The hardest part of learning the mechanisms of the Java language is learning how
its parts work together. Basically, one object calls another object until it reaches
not the target searched for. In UML, these objects are represented by roles and this
event ordering modeling can be done through a sequence diagram.

Chapter 4:

Classes are the most important building blocks of any object-oriented system.
objects. A class is a description of a set of objects that have the same
attributes, operations, relationships, and semantics. A class also implements a
or more interfaces.
The modeling of a system involves the identification of items considered
important according to each perspective. These items form the vocabulary of the system to be
modeling. In UML these items are modeled as classes. The class represents a
whole set of objects.
UML allows for the graphical representation of classes, which are graphically a rectangle.
This notation allows emphasis on the most important parts of an abstraction: its name,
attributes and operations.
Each class has a name that distinguishes it from other classes; it can be a name.
simple, a word, or a qualified name, in which the prefix indicates the name of the package
that she belongs to.
An attribute is a property that all objects of the class have. Graphically, they are
listed in a compartment just below the class name.
Operations are actions that objects can perform to modify behavior.
Graphically, the operations appear listed in a compartment just below the
attributes of the class.
When representing a class, in most cases, it will be a huge list of items, which
it is not appropriate to write everything. Therefore, some attributes may be omitted and
operations, and to indicate that there are more attributes or operations, end each list with
ellipsis. To better organize the extensive lists of attributes and operations, each group
can receive a prefix, using stereotypes.
Responsibilities are obligations that a certain class will execute. A good
starting point, when modeling classes, is to specify the responsibilities of
items existing in your vocabulary. Every well-structured class has at least one
responsibility and, most of the time, a handful of responsibilities.
Graphically, they can be represented at the end of a class.
 To model the vocabulary of the system, you will need to take the abstractions with
the users. Techniques such as CRC cards and use case based analysis are
excellent ways to help users discover these abstractions.
The modeling of the distribution of responsibilities in a system: The abstractions of a
the class model should have a balance between responsibilities. Each class will have to
do something efficiently. You can use UML to help visualize and specify
this balance of responsibilities.
Occasionally, we may come across items that are not software, such as people.
the robots. To model these items, it is necessary to abstract them as a class and
after creating a new building block using stereotypes to specify the new
semantics and provide a distinctive visual indication in order to differentiate these items in
UML. It is perfectly normal to abstract humans and hardware as classes,
because each one represents a set of objects with common structure and behavior.

Chapter 5:

Most classes do not work alone, they can be related to others.

classes. For this, there are 3 main types of relationship: dependencies,
generalizations and associations. These three types of relationships encompass the ways
most important collaborations between the items, they also properly map the
forms provided by most programming languages regarding the connection of
objects.
UML provides a graphical representation for each of these types of
relationships. A relationship is a connection between items. It is represented
graphically like a path, with different types of lines to differentiate the types of
relationships.
A generalization is a relationship in which one item is the specification of another item.
more generic. Generic classes are called parent classes and specific types,
of child classes. Child classes inherit, mainly, the attributes and operations of
mother class. Usually the daughters have attributes and operations in addition to those found
of the respective mothers. A generalization is graphically represented as solid lines.
with a large triangular arrow pointing to the mother.
An association is a structural relationship that links one object to another object. From
from this association, you are able to navigate from the object of one class to the object of the other
class and vice versa. Graphically, it is represented as a solid line connecting the
classes.
Four types of enhancements can be applied to associations:
A name indicating what such a class does with another class, possibly with an arrow indicating
the direction.
A paper that describes what that class is.
The multiplicity determines how many objects there are or can be at one end of the
association.
An aggregation means that an object of the whole contains the objects of the parts, it is
represented by a simple association with an open diamond at the end of
everything.
Dependencies, generalization, and association are static items defined at the level of
classes. In UML, these relationships are usually visualized in diagrams of
classes.
 Basic modeling techniques:
Simple dependencies: the most common type of dependency relationship is the
connection between a class that only uses another class as a parameter for
certain operation. To model this relationship, it is necessary to create a
dependency pointing, from the class that performs the operation, the class used as
parameter in this operation.
Simple inheritance: When modeling the vocabulary of the system, we will always find classes
structurally or behaviorally similar. To solve this problem, we must
extract the common structural and behavioral characteristics and, from this, combine
these characteristics in a broader class or create another class to which they
elements can be assigned, then indicate that the more specific classes will inherit
from the most general class, using a generalization relationship, defined from
each specialized class for the more general parent class.
Structural relationships: While dependency relationships and
generalizations are unilateral, associations are bilateral relationships, that is, the
objects interact with each other, navigating in both directions.
To model structural relationships:
For each pair of classes, if the objects of one class need to interact with objects of
other classes as parameters of an operation, specify an association between them
two classes.
For each of these associations, specify a multiplicity (when it is not *, that
it is the standard) and the role names (if it helps in explaining the model).
If one of the classes of an association is a whole when compared to the classes
found at the other end, and if they seem to be parts, mark this case as a
aggregation, not forgetting to place a diamond ornament at the end that
finds total.