Você está na página 1de 12

Princpios de Anlise e Projeto de Sistemas com UML

3 edio, 2015, Eduardo Bezerra

Alguns Exerccios Resolvidos


Captulo 1
Exerccio 1.1
Sim, porque ele representa graficamente um objeto do mundo real (a cidade).
Caractersticas:

Ele abstrai e s exibe as informaes consideradas relevantes do objeto.


(Encapsulamento) O objeto Mapa fornece servios a outros objetos atravs de
sua interface. Todos os detalhes de como esses servios so implementados
esto encapsulados pelo objeto. Os "clientes" deste objeto s precisam conhecer
a sua interface para utiliz-lo.
(Herana) Um objeto mapa pode ser considerado como um tipo especial de
figura e como tal pode herdar propriedades e operaes de uma figura (carregar,
salvar, aumentar (zoom-in), diminuir (zoom-out), etc.).
(Polimorfismo) Um objeto mapa pode ser formado de outros objetos (por
exemplos, rios, rodovias, lagos, etc.). Quando houver a necessidade de desenhar
o mapa, a mesma mensagem (desenhar) pode ser enviada a seus objetos
componentes. Ao receber tal mensagem, cada objeto componente a implementa
da forma mais adequada para o seu caso.

Exerccio 1.2
a) Mensagens so enviadas para outros objetos atravs da sua interface.
b) Objetos tm uma fronteira (a sua interface). Cada objeto tem um
comportamento interno que no visvel de fora (pelo princpio do
encapsulamento).
c) Objetos de um sistema de software colaboram entre si para realizar as
funcionalidades externamente visveis desse sistema. Esses objetos se
comunicam requisitando servios uns aos outros para resolver problemas ou
para realizar uma funo do sistema ao qual pertencem.

Exerccio 1.3
Sim. Porque de acordo com o primeiro desses princpios, qualquer coisa um objeto.

Exerccio 1.4
H sim. Os modelos utilizados, tanto no contexto do livro, quanto nessas reas, servem
para tornar algo complexo mais inteligvel para a capacidade humana e tambm usam
smbolos e notaes para representar os objetos reais.
Exerccio 1.5
Objeto: um objeto qualquer coisa que possamos ver, sentir, tocar ou idealizar.
Exemplos de objetos so: Eu, esse texto, sua conta de email, etc.
Computacionalmente falando, um objeto uma abstrao de algo do mundo
real. Em vista disso, um objeto nesse bem mais simples que a sua contrapartida
original e representas as caractersticas e comportamentos relevantes desse
original.
Classes: corresponde a um agrupamento de objetos. Ela retm os
comportamento que sero caractersticos aos objetos que dela fazem parte. Por
exemplo: Pessoa uma classe onde estamos contidos todos ns, porm quando
pensamos em algum em especfico, estamos pensando no objeto, quando
idealizamos uma imagem de uma pessoa fizemos usando as caractersticas da
classe. Por exemplo: Camisa uma classe. A camisa que estou usando agora
um objeto dessa classe.
Herana: a capacidade que uma classe tem de herdar caractersticas da classe
que est acima dela hierarquicamente. Por exemplo: Camisa uma subclasse da
classe Roupa, logo ela herda comportamentos e funes. Todas as duas tem a
comportamento de servir como vestimentas para quem a usa.
Mensagem: um pedido ou informao passado de um objeto para outro. Por
exemplo, quando giramos o objeto chave na ignio do carro, ele passa a
mensagem para o carro de queremos que ele funcione, em reposta o carro
executa essa tarefa.
Captulo 4
Exerccio 4.8
A tabela a seguir exibe as alternativas possveis entre relacionamentos entre atores e
casos de uso em um diagrama de casos de uso. As clulas da tabela com um X indicam
possibilidade. As clulas no preenchidas indicam impossibilidade.

Entre atores Entre casos de uso Entre ator e caso de uso


Comunicao X
Incluso X
Extenso X
Generalizao X X

Exerccio 4.14
Considerando-se somente o trecho fornecido no exerccio, podem ser identificados 3
atores em potencial, a saber: Cliente, Vendedor e Depsito. O primeiro o ator
primrio e os dois ltimos so atores secundrios. O nome do caso de uso
correspondente poderia ser Comprar Produtos.

Exerccio 4.16
Na situao descrita neste exerccio, pode-se definir um ator denominado Empregado .
Este seria o ator primrio no caso de uso Registrar Horas Trabalhadas. Podemos
tambm criar um ator denominado Gerncia. que seria o ator primrio no caso de uso
Obter Horas Trabalhadas. O diagrama de casos de uso a seguir ilustra a soluo aqui
descrita.
Exerccio 4.17

Exerccio 4.19
O erro do diagrama est no fato de que atores no se comunicam em um diagrama de
casos de uso.

Na primeira alternativa de escopo (o sistema o browser), o sistema sendo modelado


tem que se comunicar (interagir) com dois atores no caso de uso Obter URL: Usurio
da Internet e Servidor WEB. Na segunda alternativa de escopo (o sistema a
Internet), o prprio servidor WEB faz parte do sistema sendo modelado e por conta
disse no deve ser representado como um ator. Os dois diagramas de casos de uso a
seguir ilustram as duas alternativas diferentes.
Exerccio 4.20
A primeira e a segunda assertiva so verdadeiras. Na verdade essas assertivas so
formas diferentes de declarar a mesma informao: um ator representa um papel em
relao ao sistema.

Considere o exemplo do exerccio 4-16. Pode haver uma pessoa que seja um
funcionrio comum em um certo projeto, alm de ser o gerente em outro projeto. Neste
caso, a mesma pessoa assumir papis diferentes em instantes distintos em relao ao
sistema.

Exerccio 4.21
A seguir, so apresentados os nomes de casos de uso de acordo com a nomenclatura
adotada no livro. Possveis nomes para atores primrios em cada situao so tambm
fornecidos. Deve-se enfatizar no entanto que isso somente uma conveno de
nomenclatura. Outras convenes podem ser usadas.
a. Transferir Fundos Cliente
b. Comprar Livros Usurio
c. Obter Relatrio de Vendas Gerncia
d. Abrir Estadia Hspede

Captulo 5
Exerccio 5-2
Na modelagem de cartes CRC, utiliza-se cartes de tamanho fixo (normalmente com
as dimenses aproximadas de 10cm x 15cm). O fato de as dimenses utilizadas serem
as mesmas para todo carto contribui para uma distribuio mais uniforme das
responsabilidades. Isso porque quando o carto CRC correspondente a uma certa classe
j foi todo preenchido com responsabilidades, e uma nova responsabilidade deve ser
atribuda, hora de o modelador considerar a criao de uma nova classe para cumprir
com essa responsabilidade, ou ento atribuir essa responsabilidade a uma outra classe..

Exerccio 5-4

Exerccio 5-5

Exerccio 5-7
Exerccio 5-8

Exerccio 5-11
Em um modelo de classes, as responsabilidades atribudas aos objetos devem ser o mais
uniformemente distribudas. Em muitos casos, um modelo no qual h uma classe que
seja responsvel pela maioria das atribuies do sistema muito provavelmente est mal
balanceado quanto distribuio de responsabilidades. Sempre que o modelador
precisar de mais do que as dimenses usuais de um carto CRC para enumerar as
responsabilidades de uma classe, ele deve ser questionar se esta classe no est
sobrecarregada com muitas responsabilidades.
Captulo 7
Exerccio 7-3
O diagrama de sequncia apresenta uma estrutura de repetio aninhada. A ordem na
qual as mensagens so passadas a seguinte: m1, m2, m2, m2, m1, m2, m2, m2.

Exerccio 7-6
Este exerccio diz respeito a duas estruturas de controle encontradas em diagramas de
interao: a centralizada e a descentralizada.

Estrutura centralizada

H um pequeno grupo de objetos que controla a realizao de uma tarefa do sistema e


coordena outros objetos perifricos atravs do envio de mensagens. A inteligncia do
sistema est concentrada nesse pequeno grupo de objetos controladores. De fato, os
objetos desse pequeno grupo podem se encaixar na categoria de "objetos controladores"
(veja detalhes no Captulo 5).

Na situao extrema desta estrutura de controle, um nico objeto contm quase toda a
lgica da aplicao e somente obtm pequenos servios de outros objetos enviando
mensagens para eles. Em relao atribuio de responsabilidades, significa que uma
grande quantidade de responsabilidades foi atribuda quele objeto, tornando-o
excessivamente complexo. Muito provavelmente seria mais adequado que algumas de
suas responsabilidades fossem atribudas a outro(s) objeto(s). Nessa situao, a estrutura
de controle assume a forma de um garfo (fork) no diagrama de sequncia.

Estrutura descentralizada

Dada uma tarefa que o sistema deve realizar, partes dessa tarefa so delegadas a vrios
objetos. A tarefa realizada de forma descentralizada. No h um nico grande objeto
controlador. Em vez disso, cada objeto faz uma parte da tarefa e envia uma mensagem
para outro(s) objeto(s) realizarem uma outra parte. Cada objeto conhece apenas poucos
outros objetos. Note que a "inteligncia" do sistema fica distribuda pelos objetos que
participam da realizao da tarefa.

Na situao extrema da estrutura de controle descentralizada, uma tarefa do sistema


realizada por uma sequncia de envios de mensagens entre objetos O1, O2, ..., On, onde
o objeto Oi envia uma mensagem para o objeto Oi+1. Nesse sentido, cada objeto controla
o seu sucessor na sequncia de mensagens enviadas. Nessa situao, a estrutura de
controle assume a forma de uma escada (stair) no diagrama de sequncia.

Vantagens e desvantagens

H vantagens de desvantagens em ambas as estruturas de controle. A utilizao de uma


ou de outra estrutura depende muito do problema de modelagem a ser resolvido. No
entanto, na prtica, um modelo mais flexvel e robusto obtido quando se combinam
essas duas estratgias, considerando suas caractersticas particulares. muito pouco
provvel que uma boa modelagem de um determinado diagrama de interao seja feita
atravs da utilizao exclusiva de uma ou de outra estratgia.

Uma estrutura de controle descentralizada apropriada quando:

Os objetos tm uma conexo forte (por agregao, por composio, ou por


generalizao).
As mensagens sero sempre enviadas em uma mesma ordem.

Uma estrutura de controle centralizada apropriada quando:

As mensagens podem ser enviadas em ordens diferentes.


Novas operaes poderiam ser inseridas.

A distribuio de responsabilidades segunda categorias (fronteira, controle e entidade)


tambm pode ajudar na identificao de que estrutura de controle mais adequada.
Normalmente, costumo utilizar uma estrutura centralizada em relao ao objeto
controlador de um caso de uso. No entanto, para outros objetos que participem da
realizao desse caso de uso e que se relacionem por agregao, por composio, ou por
generalizao, acho mais adequado usar uma estrutura descentralizada. Portanto, em um
mesmo caso de uso, comum a utilizao das duas estruturas de controle.
Captulo 08
Exerccio 08-06
Exerccio 08-07

Exerccio 08-08

Exerccio 08-09