Nome: Carlos Eduardo de Santana

Turno: Manhã

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

Capítulo 1:

Em uma equipe de desenvolvimento de software, o principal objetivo é que se construa

um software que atenda as necessidades do usuário. Para isso, é preciso utilizar boas
práticas e ferramentas para o levantamento de requisitos, com a elaboração de modelos
para visualizar e compreender melhor o projeto.
A modelagem é uma técnica de engenharia mais popular e bem sucedida não só entre os
engenheiros de software, mas também na indústria de construção civil, automóveis,
microprocessadores, etc. Um modelo, de uma maneira simples, é uma simplificação da
realidade, eles fornecem uma visão panorâmica do sistema em questão. Exemplos de bons
modelos, são aqueles que mostram os componentes principais e omite os que não tem
tanta importância num certo nível de abstração.
Qualquer projeto pode ser beneficiado pela modelagem, desde pequenos projetos à
projetos de grande complexidade. Ela ajuda a enfrentar os problemas separando-o em
pequenos aspectos para resolver um de cada vez.
A maioria das empresas de software usam pouca modelagem "formal", já que quanto
mais simples for o projeto, menos provável será o uso de modelagem formal. Muitos
desenvolvedores fazem uma modelagem informal no papel para tentar visualizar parte do
sistema, mas costumam ser ineficazes se forem compartilhar, por falta de uma linguagem
padrão.
Utilizar a modelagem irá beneficiar qualquer projeto, desde os mais simples,em que na
medida que o sistema evoluir, possuir uma modelagem será bastante útil futuramente; até
os sistemas mais complexos que, com a utilização de modelagem, irá minimizar a
probabilidade de erros.
De acordo com os princípios da modelagem, a escolha um modelo adequado para tal
sistema, é fundamental para conduzir melhor o projeto e para facilitar a resolução dos
problemas. Com diferentes observadores, poderá ser feito modelos com diferentes níveis de
precisão, com o intuito de visualizar algum aspecto conforme a necessidade do observador.
Os modelos preferíveis são aqueles que estão relacionados com a realidade, porque dessa
forma não irá ocultar pontos importantes do sistema. E para uma melhor investigação do
sistema, é recomendado mais de um modelo de software, com o objetivo de obter várias
visões complementares, a fim de conseguir uma compreensão melhor da arquitetura dos
sistemas.
Na construção de modelos de software, existem muitas maneiras de se definir um modelo.
As duas mais comuns são provenientes da perspectiva de um algoritmo ou da perspectiva
orientada a objetos.
A perspectiva de um algoritmo é a visão tradicional no desenvolvimento de software, em
que o foco é no procedimento, que são questões referentes ao controle e à decomposição
de algoritmos maiores em outros menores. Isso acaba permitindo a tendência de sistemas
instáveis, prejudicando a manutenção futuramente.
Já na visão contemporânea, adota-se a perspectiva orientada a objetos. Nessa visão, o
objeto e a classe é o principal bloco de construção de todos os sistemas de software. Esse
método é uma parte do fluxo principal, em que abrange todos os graus de tamanho e de
complexidade. E, atualmente, muitas linguagens, sistemas operacionais e ferramentas são
orientados a objetos. O desenvolvimento orientado a objetos fornece os fundamentos
conceituais para a montagem de sistemas a partir de componentes com a utilização de
tecnologias com J2EE ou .NET. A visualização, a especificação, a construção e a
documentação de sistemas orientados a objetos é exatamente o objetivo da UML.

Capítulo 2:

A UML é uma linguagem expressiva que serve para visualizar, especificar, construir e
documentar um sistema complexo de software. Para entender UML, é preciso aprender três
elementos principais: os blocos de construção básicos da UML, as regras que determinam
como esses blocos poderão ser combinados e alguns mecanismos comuns aplicados na
UML.
Os blocos de construção são os itens, os relacionamentos e os diagramas. Os itens
dividem-se em quatro tipos:
Itens estruturais que são substantivos usados em modelos da UML, como as classes, as
colaborações, os casos de uso, as classes ativas, os componentes, os artefatos e os nós.
Esses são os itens estruturais básicos que poderão ser incluídos em um modelo da UML.
Itens comportamentais são as ações que representam comportamentos no tempo e no
espaço. Existem dois tipos de itens comportamentais: as interações são um conjunto de
mensagens que mostram as ações correspondentes. Uma máquina de estado é um
comportamento que mostra sequência de estados em resposta a eventos.
Itens de agrupamento são as partes organizacionais dos modelos de UML. Servem para
organizar as partes do projeto e só existem em tempo de desenvolvimento.
Itens anotacionais são os comentários explicativos nos modelos de UML. Servem para
esclarecer ou descrever qualquer elemento do modelo utilizando-se notas.
Os relacionamentos dividem-se em quatro tipos: dependência, associação, generalização
e realização. Uma dependência é um relacionamento no qual um item depende do outro,
em que numa alteração do item independente pode afetar o item dependente. São
representadas por linhas tracejadas, geralmente com setas. Uma associação são conexões
entre elementos do modelo. É representado por linhas sólidas, geralmente com nomes de
papéis e multiplicidades. Uma generalização é um relacionamento entre dois objetos em
que um é substituível pelo outro mais generalizado, como os filhos que compartilham a
estrutura e o comportamento dos pais. São representados por uma linha sólida com uma
seta em branco em direção ao pai. Uma realização é um relacionamento semântico entre
classificadores, em que um especifíca um contrato que outro garante executar. É
representado por uma linha tracejada com uma seta em branco.
Os diagramas na UML são desenhos com os itens e os relacionamentos para permitir
visualizar um sistema parcialmente. Comumente são usados certas combinações de
elementos que são coerentes com as cinco visões mais úteis da arquitetura de sistema
complexo de software. São eles: os diagramas de classes, diagrama de objetos, diagrama
de componentes, diagrama de estruturas complexas, diagrama de caso de uso, diagrama
de sequências, diagrama de comunicações, diagrama de gráficos de estados, diagrama de
atividades, diagrama de implantação, diagrama de pacote, diagrama de temporização e
diagrama de visão geral da interação.
As regras da UML para incentivar a construção de modelos bem-formados são em relação
a nome, escopo, visibilidade, integridade e execução.
 Os mecanismos básicos da UML servem para torna-la mais simples pela adoção de 4
mecanismos: Especificações, Adornos, Divisões comuns e mecanismos de extensão.
Arquitetura de software é o conjunto de métodos, técnicas e processos para a construção
de um sistema. Arquitetura de software não está relacionada somente com a estrutura e
comportamento, mas também à vários outros fatores relacionados com as características do
software. Essas características podem ser descritas mais adequadamente por cinco visões
interligadas, que são a visão de projeto, visão da implementação, visão de caso de uso,
visão do processo e visão da implantação. Cada visão abrange os aspectos do sistema,
utilizando diagramas para visualizar tais aspectos.

Capítulo 3:

De acordo com Brian Kernighan e Denis Ritchie, os autores da linguagem C, "a única
maneira de se aprender uma nova linguagem de programação é utiliza-la para escrever
programas". O mesmos se aplica à UML, utilizando-a para escrever modelos.
O primeiro programa que muitos desenvolvedores fazem quando estão começando em
uma nova linguagem é um programa simples que escreva "Hello, world!" na tela. Vamos
começar a usar a UML dessa forma, modelar "Hello world!" que, aparentemente é um
programa simples, mas por trás existem alguns mecanismos interessantes que a fazem
funcionar.
Em java, para o applet exibir "Hello world!" em um navegador web é bem simples:
1 import 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 }

A primeira linha do código faz com que a classe Graphics fique disponível à próxima
linha e o prefixo java.awt indica em qual pacote está a classe Graphics.
A segunda linha introduz a classe HelloWorld, e as três linhas seguintes declaram uma
operação chamada paint, cuja implementação inicia outra operação, chamada drawString,
responsável pela exibição do "Hello, world!".
Usando UML para modelar essa aplicação, a classe HelloWorld pode ser representada
graficamente como um ícone retangular. A operação paint é mostrado logo abaixo com seus
parâmetros formais omitidos, num quadrado e uma linha pontilhada do paint até uma nota
mostrando o parâmetro g.drawString. Esse diagrama de classes capta o básico da
aplicação "Hello, world!", mas não inclui vários itens. Podemos simplificar e adicionar as
classes Applet e Graphics de uma forma diferente. A classe Applet é empregada como mãe
de HelloWorld e a classe Graphics é usada na assinatura e implementação de uma de suas
operações, paint. Essas classes são representadas como ícones retangulares. A classe
Applet tem uma seta ligando HelloWorld a ela indicando uma generalização. E a classe
Graphics tem uma seta pontilhada ligando o paint a ele, indicando um relacionamento de
dependência.
Esse não é o final, procurando nas bibliotecas de java as classes Applet e Graphics,
descobrimos que elas fazem parte de uma hierarquia maior, possibilitando a construção de
outro diagrama de classes. A representação é assim: as classes estão dentro de cada
retângulo e a classe HelloWorld é filha do Applet, que é filha do Painel, que é filha do
Container, que é filha do Component, e que é filha do objeto. O ImageObserver está
embaixo de um círculo com uma linha sólida ligado ao Component. Esse modelo
corresponde à biblioteca de java - cada classe-filha estende a classe mãe imediata.
ImageObserver é uma interface, por isso é diferente.
Conforme mostram as representações gráficas, HelloWorld colabora diretamente apenas
com duas classes (Applet e Graphics), que estão numa pequena parte da biblioteca maior
de classes predefinidas de Java. Para gerenciar a extensa coleção de pacotes, a linguagem
Java organiza suas interfaces e classes em vários pacotes diferentes.
Esses pacotes podem ser visualizados em um diagrama de classes, são representados
na UML por diretórios com guias. Os pacotes podem ser aninhados, com linhas tracejadas
representando as dependências entre os pacotes.
A parte mais difícil para aprender os mecanismos da linguagem Java, é aprender como
suas partes trabalham em conjunto. Basicamente, um objeto chama outro objeto até chegar
no alvo procurado. Na UML, esses objetos são representados por papéis e essa
modelagem de ordenação de eventos pode ser feita através de um diagrama de sequência.

Capítulo 4:

As classes são os blocos de construção mais importantes de qualquer sistema orientado a

objetos. Uma classe é uma descrição de um conjunto de objetos que tem os mesmos
atributos, operações, relacionamentos e semântica. Uma classe também implementa uma
ou mais interfaces.
A modelagem de um sistema compreende a identificação de itens considerados
importantes de acordo com cada visão. Esses itens formam o vocabulário do sistema a ser
modelado. Em UML esses itens são modelados como classes. A classe representa um
conjunto inteiro de objetos.
A UML permite a representação gráfica de classes, que são graficamente um retângulo.
Essa notação permite dar ênfase às partes mais importantes de uma abstração: seu nome,
atributos e operações.
Cada classe tem um nome que a diferencie das outras classes, pode ser um nome
simples, uma palavra, ou um nome qualificado, em que o prefixo indica o nome do pacote
que ela pertence.
Um atributo é uma propriedade que todos os objetos da classe tem. Graficamente, são
listados num compartimento logo abaixo do nome da classe.
As operações são ações que os objetos podem fazer para modificar o comportamento.
Graficamente, as operações aparecem listadas em um compartimento logo abaixo dos
atributos da classe.
Ao representar uma classe, na maioria dos casos, será uma lista enorme de itens, o que
não é adequado escrever tudo. Portanto, poderão ser omitidos alguns atributos e
operações, e para indicar que tem mais atributos ou operações, termine cada lista com
reticências. Para organizar melhor as extensas listas de atributos e operações, cada grupo
pode receber um prefixo, utilizando estereótipos.
As responsabilidades são obrigações que uma determinada classe executá-ra. Um bom
ponto de partida, ao fazer a modelagem de classes, é especificar as responsabilidades dos
itens existentes em seu vocabulário. Toda classe bem-estruturada tem pelo menos uma
responsabilidade e, na maioria das vezes, um punhado de responsabilidades.
Graficamente, podem ser representadas no final de uma classe.
 Para fazer a modelagem do vocabulário do sistema, precisará pegar as abstrações com
os usuários. Técnicas como os cartões CRC e a análise baseada em casos de uso são
formas excelentes para auxiliar os usuários a descobrir essas abstrações.
A modelagem da distribuição de responsabilidades em um sistema: As abstrações de um
modelo de classe deverá ter um equilíbrio entre as responsabilidades. Cada classe terá que
fazer algo de modo eficiente. Você pode utilizar a UML para ajudar a visualizar e especificar
esse equilíbrio de responsabilidades.
Ocasionalmente, poderemos nos deparar com itens que não são software, como pessoas
e robôs. Para fazer a modelagem desses itens, é preciso abstrai-los como uma classe e
depois criar um novo bloco de construção usando estereótipos para especificar a nova
semântica e fornecer uma indicação visual distintiva, a fim de diferenciar esses itens na
UML. É perfeitamente normal fazer a abstração de humanos e de hardware como classes,
pois cada um representa um conjunto de objetos com estrutura e comportamento comuns.

Capítulo 5:

A maioria das classes não trabalham sozinhas, elas podem ser relacionadas com outras
classes. Para isso, existem 3 tipos principais de relacionamento: dependências,
generalizações e associações. Esses três tipos de relacionamentos abrangem os modos
mais importantes de colaboração entre os itens, eles também mapeiam adequadamente as
formas fornecidas pela maioria das linguagens de programação em relação à conexão de
objetos.
A UML oferece uma representação gráfica para cada um desses tipos de
relacionamentos. Um relacionamento é uma conexão entre itens. É representado
graficamente como um caminho, com tipos diferentes de linha para diferenciar os tipos de
relacionamentos.
Uma generalização é um relacionamento em que um item é a especificação de outro item
mais genérico. As classes genéricas são chamadas de classes-mãe e os tipos específicos,
de classes-filha. As classes-filha herdam, principalmente, os atributos e operações da
classe-mãe. Geralmente as filhas têm atributos e operações além daqueles encontrados
nas respectivas mães. Uma generalização é representada graficamente como linhas sólidas
com uma grande seta triangular apontando a mãe.
Uma associação é um relacionamento estrutural que liga um objeto a outro objeto. A partir
dessa associação, você é capaz de navegar do objeto de uma classe até o objeto da outra
classe e vice-versa. Graficamente, é representada como uma linha sólida conectando as
classes.
Podem ser aplicados quatro tipos de aprimoramentos às associações:
Um nome dizendo o que tal classe faz com outra classe, podendo haver uma seta indicando
a direção.
Um papel, em que descreve o que aquela classe é.
A multiplicidade determina quantos objetos tem ou podem ter em uma extremidade da
associação.
Uma agregação significa que um objeto do todo contém os objetos das partes, é
representada por uma associação simples com um diamante aberto na extremidade do
todo.
Dependências, generalização e associação são itens estáticos, definidos no nível das
classes. Na UML, esses relacionamentos costumam ser visualizados em diagramas de
classes.
 Técnicas básicas de modelagem:
Dependências simples: o tipo mais comum de relacionamento de dependência é a
conexão entre uma classe que somente utiliza outra classe como parâmetro para
determinada operação. Para fazer a modelagem desse relacionamento, é preciso criar uma
dependência apontando, a partir da classe que executa a operação, a classe utilizada como
parâmetro nessa operação.
Herança simples: Ao modelar o vocabulário do sistema, sempre encontraremos classes
parecidas estrutural ou comportamentalmente. Para resolver este problema, devemos
extrair as características estruturais e comportamentais comuns e, a partir disso, juntar
essas características numa classe mais geral ou então crie outra classe ao qual esses
elementos podem ser atribuídos, depois, indicar que as classes mais específicas herdarão
da classe mais geral, utilizando-se um relacionamento de generalização, definido a partir de
cada classe especializada para a classe-mãe mais geral.
Relacionamentos estruturais: Enquanto os relacionamentos de dependência e
generalização são unilaterais, as associações são relacionamentos bilaterais, ou seja, os
objetos interagem entre si, navegando em ambas as direções.
Para fazer a modelagem de relacionamentos estruturais:
Para cada par de classes, se os objetos de uma classe precisarem interagir com objetos de
outras classes como parâmetros de uma operação, especifique uma associação entre as
duas classes.
Para cada uma dessas associações, especifique uma multiplicidade (quando não for *, que
é o padrão) e os nomes de papéis (se ajudar na explicação do modelo).
Se uma das classes de uma associação for um todo quando comparada às classes
encontradas na outra extremidade, e essas parecerem partes, marque esse caso como uma
agregação, não esquecendo de colocar um adorno de diamante na extremidade que se
encontra ao todo.