UML - Unified Modeling Language

Prévia do material em texto

D
en
iz
e
 P
im
en
ta
1
Este material está registrado na Biblioteca Nacional.
Registro 397.004 - Livro 739 - Folha 164
D
en
iz
e
 P
im
en
ta
2
Índice
1: Visão Geral
1.1 – Importância da Modelagem 10
1.2 – Introdução à UML 17
1.3 – Introdução ao RUP 21
2: Funções de Dados
2.1 – Definições 35
2.2 – Regras de Contagem 45
2.3 – Práticas de Contagem (Code Data) 52
3: Funções de Transação
3.1 – Definições 66
3.2 – Regras de Contagem 76
3.3 – Práticas de Contagem 87
3.4 – Cálculo dos Pontos não Ajustados 98
4: Fator de Ajuste
4.1 – Definições 105
4.2 – Características Gerais do Sistema 111
5: Cálculo dos Pontos de Função Ajustados
5.1 – Fórmulas 132
5.2 – Exercícios 138
6: Dúvidas e Dicas 142
D
en
iz
e
 P
im
en
ta
3
D
en
iz
e
 P
im
en
ta
4
D
en
iz
e
 P
im
en
ta
5
D
en
iz
e
 P
im
en
ta
6
D
en
iz
e
 P
im
en
ta
7
D
en
iz
e
 P
im
en
ta
8
De uma forma geral iremos ver o que a UML pode oferecer, um histórico da criação da
linguagem até como ela se encontra atualmente.
O entorno da linguagem também será visto, iremos falar de metodologias de
desenvolvimento de software (foco no RUP) e a importância da modelagem de sistemas,
qual o objetivo que nos leva a construir vários diagramas e suas intermináveis
manutenções.
O uso de ferramenta CASE, neste curso, é secundário, porque primeiramente
necessitamos aprender a escrever os diagramas.
D
en
iz
e
 P
im
en
ta
9
Objetivos do Capítulo 1:
1. Importância da Modelagem
2. Introdução à UML
3. Introdução ao RUP
D
en
iz
e
 P
im
en
ta
10
D
en
iz
e
 P
im
en
ta
11
O principal produto, de uma equipe de desenvolvimento, é um bom software capaz de satisfazer às
necessidades de seus usuários e respectivos negócios. Tudo mais é secundário (não é irrelevante).
Para desenvolver software de qualidade duradoura é necessário criar uma arquitetura de fundação
sólida que aceite modificações futuras.
D
en
iz
e
 P
im
en
ta
12
Como na Arquitetura e na Engenharia são utilizadas plantas e esquemas que traduzem
como as coisas são construídas, as relações entre as partes e o todo, o funcionamento e
suas disposições. Não existe nenhuma planta que mostre todos os detalhes de uma
construção, existe a planta hidráulica, a elétrica, a planta baixa e até uma maquete, mas
o entendimento do que é o empreendimento só faz sentido se analisarmos todos esses
‘pontos de vista’.
Nós construímos modelos para dominar a complexidade de um sistema, compreendendo
melhor a sua estrutura e funcionamento. Os modelos permitem que se faça um
planejamento adequado de recursos e pessoas, uma vez que traduzem o tamanho e a
complexidade do sistema.
No processo de desenvolvimento de sistemas também construímos modelos para
documentar a estrutura e o comportamento do sistema.
“Construímos modelos para entender e visualizar um sistema - dominar a sua
complexidade”
D
en
iz
e
 P
im
en
ta
13
Qual o(s) motivo(s) que nos levam a gastar tempo e recursos no desenho de modelos?
O que os modelos fazem para ser tão útil?
D
en
iz
e
 P
im
en
ta
14
Existem metodologias quer pregam o desenvolvimento rápido, como a metodologia XP, onde não há
modelagem no início para levantamento, são feitas reuniões diárias e há a participação efetiva do
conhecedor do negócio “dentro do desenvolvimento” para tirar dúvidas a qualquer momento, existem
pontos negativos e positivos.
No início deste capítulo foram colocados alguns motivos para fazer a modelagem de sistemas antes
do início do desenvolvimento (codificação) do sistema.
O que é melhor? Quando utilizar uma forma e quando não é possível utilizar o desenvolvimento
rápido?
D
en
iz
e
 P
im
en
ta
15
Neste tópico veremos:
•O que é a UML
•Histórico de versões
D
en
iz
e
 P
im
en
ta
16
D
en
iz
e
 P
im
en
ta
17
No início da conceituação de orientação a objeto vários autores trabalhavam isoladamente
construindo diagramas e receitas para um bom desenvolvimento de software, este trabalho foi
motivado com o surgimento das primeiras linguagens orientadas a objetos, como o Smalltalk.
Após um período de trabalho isolado os autores resolveram se unir e trabalhar em conjunto, o
resultado desta união foi a criação da Linguagem de Modelagem Unificada (UML) e do Processo
Unificado, posteriormente conhecido como RUP (Rational Unified Process).
A UML (Unified Modeling Language) é o sucessor de um conjunto de métodos de análise e projeto
orientados a objeto (OOA&D).
A UML é um modelo de linguagem, não um método. Um método pressupõe um modelo de linguagem
e um processo. O modelo de linguagem é a notação que o método usa para descrever o projeto. O
processo são os passos que devem ser seguidos para se construir o projeto.
O modelo de linguagem corresponde ao ponto principal da comunicação. Se uma pessoa quer
conversar sobre o projeto, como outra pessoa, é através do modelo de linguagem que elas se
entendem. Nessa hora, o processo não é utilizado.
A UML define uma notação e um meta-modelo. A notação são todos os elementos de representação
gráfica vistos no modelo (retângulo, setas, o texto, etc.), é a sintaxe do modelo de linguagem. Um
meta-modelo é um diagrama de classe que define de maneira mais rigorosa a notação.
A UML (Unified Modeling Language) é uma linguagem-padrão para a elaboração da estrutura de
projetos de software.
Pode ser empregada para a visualização, especificação, construção e documentação de artefatos
que façam uso de sistemas complexos de software.
“UML é uma linguagem de modelagem, não uma metodologia.”
D
en
iz
e
 P
im
en
ta
18
Na modelagem tradicional há a decomposição funcional, ou seja, o analista divide (decompõe) o
problema em funções e processos, resultando em uma decomposição hierárquica do problema.
Com esta forma o código não é flexível, não se pode, com facilidade, incorporar mudanças futuras.
Um procedimento cirúrgico de uma clínica veterinária, provavelmente pensaríamos na identificação
do animal, diagnóstico, preparação do animal para cirurgia e procedimento cirúrgico. A modelagem
tradicional foca o processo.
O paradigma da orientação a objetos entende o mundo como objetos, o que eles são e o que podem
fazer. Os objetos irão interagir entre si e com os atores através de mensagens. No exemplo da clínica
veterinária teríamos os objetos:
Animal – com suas características relevantes para identificação e apoio à cirurgia, como: nome, raça,
peso, altura, cor, temperatura, etc. O animal pode ser cadastrado, ser medido, ser pesado, ser
consultado pelo nome.
Cirurgia – com a data de agendamento, descrição da necessidade (motivo), descrição da conclusão,
data de realização, qual animal participou, qual cirurgião responsável.
D
en
iz
e
 P
im
en
ta
19
D
en
iz
e
 P
im
en
ta
20
A versão 2 está em aprovação desde Junho de 2003. Algumas ferramentas já começar a implementar
(Eclipse da IBM – código aberto).
A versão 2 da UML trouxe algumas modificações gráficas e inclusão de alguns diagramas.
O XMI (XML Metadata Interchange) entrou como padrão para as ferramentas CASE que trabalham
com a UML para que haja transferência de diagramas de uma ferramenta para outra sem perda de
informação.
Novos Diagramas:
Diagrama de Comunicação – Até a UML 1.5 era chamado de diagrama de colaboração. É usado
para mostrar a colaboração entre objetos, exibindo a troca de mensagens entre eles.
Diagrama de Estrutura de Compósito (Composite Structure) – mostra a cooperação entre
instâncias.
Diagrama de Resumo de Interação (Interaction Overview) – é uma variação do diagrama de
atividades. Os nós do diagrama são frames. Existem 2 tipos de frames: frame de interação
(diagramas de seqüência, comunicação, tempo, resumo de interação) e frame de ocorrência de
interação que indica uma atividade ou operação executada (atividade ou operação).
Diagrama de Tempo (Timing) – é usado para explorar o comportamento de um ou mais objetos
durante um período de tempo.
D
en
iz
e
 P
im
en
ta
21
Como a UML nasceu de trabalhos isolados, podemos entenderporque a constituição da Linguagem
teve diagramas isomorfos, ou seja, que tem a mesma forma, a mesma maneira de expressas um
mesmo assunto.
A UML também não tem regras que ditam que todos os diagramas devem ser usados, ou quais usar.
Os autores entendem que depende do tipo de projeto, cada projeto tem uma característica e
carências diferentes. A idéia aqui é ser flexível suficiente para que em nenhum momento fique
faltando, ou fique descoberto um ponto do projeto. Por isso é interessante conhecer todos os
diagramas, para saber o que usar e como usar na hora que for necessário.
D
en
iz
e
 P
im
en
ta
22
Os envolvidos com o projeto devem conhecer os diagramas da UML para saber o que
usar quando necessário.
Nunca são usados todos os diagramas em um mesmo projeto – existem diagramas que
falam a mesma coisa (diagramas de interação).
D
en
iz
e
 P
im
en
ta
23
Neste tópico veremos:
•Modelos de Processo (Cascata, Espiral, Iterativo)
•Melhores Práticas da Engenharia de Software
•Introdução ao RUP (Fases e Disciplinas)
D
en
iz
e
 P
im
en
ta
24
No processo de desenvolvimento podemos reconhecer diversas fases que devem ser
cumpridas a fim de que tenhamos o sistema funcionando à disposição do usuário. O
processo de desenvolvimento define a regra do jogo.
Em cada fase do projeto, precisamos executar diversas atividades, tais como:
•Reuniões com os usuários,
•Gerar documentações (cronograma, documento de visão, diversos diagramas, etc),
•Fazer protótipos do sistema,
•Testar funcionalidades,
•Fazer instalações de computadores e sistemas operacionais, etc.
Essas atividades são agrupadas em fases, que dividem o processo de desenvolvimento
de sistemas. Cada processo define fases e atividades.
Todo esse esforço tem como alvo principal a construção de um sistema de qualidade que
seja duradouro, suportando modificações com um mínimo de retrabalho.
D
en
iz
e
 P
im
en
ta
25
O processo de desenvolvimento em cascata pressupõe a finalização de uma etapa
para o início da próxima. As fases são: Anteprojeto, Planejamento, Análise, Projeto,
Desenvolvimento, Homologação e Implantação. As fases variam e são customizadas
conforme a necessidade da empresa.
D
en
iz
e
 P
im
en
ta
26
Desenvolver Iterativamente – Minimiza riscos, acomoda melhor as mudanças, busca de melhor
qualidade, aprendizado e melhoria contínua, aumento da reutilização.
Gerenciar Requisitos – investigar, organizar e documentar os requisitos do sistema, além de firmar
e atualizar acordos entre o cliente e a equipe do projeto sobre os requisitos variáveis do sistema. As
chaves para o gerenciamento eficaz de requisitos incluem manter uma sentença clara dos requisitos,
junto com os atributos aplicáveis e a rastreabilidade para outros requisitos e outros artefatos do
projeto.
Usar Arquitetura de Componentes - tende a reduzir o tamanho efetivo e a complexidade da
solução e, portanto, são mais robustas e flexíveis.
Modelar Visualmente (UML) – ajuda a compreensão de sistemas complexos; explora e compara
alternativas de design a um baixo custo; forma uma base para implementação; captura requisitos com
precisão; e comunica decisões sem ambigüidade.
Verificar Constantemente a Qualidade – os artefatos devem ser avaliados à medida que as
atividades que os produzem são concluídas e na conclusão de cada iteração.
Gerenciar Mudanças – com vários desenvolvedores, organizados em diferentes equipes,
possivelmente em diferentes locais, trabalhando juntos em várias iterações, releases, produtos e
plataformas. Na ausência de controle disciplinado, o processo de desenvolvimento rapidamente se
transforma em caos.
D
en
iz
e
 P
im
en
ta
27
O RUP implementa as melhores práticas, pois é iterativo, tem disciplinas de gerência
de requisitos, de mudanças e de qualidade, é centrado na arquitetura de
componentes, dirigido a casos de uso (indica o uso da UML) e desde cedo dá
condições de mensurar a qualidade através das várias iterações.
D
en
iz
e
 P
im
en
ta
28
O RUP é um processo extenso e completo e é um framework porque pode ser configurado para se
adequar a todos os projetos, ou seja, podemos adaptar o processo à necessidade e assim retirar
atividades desnecessárias, quando preciso, moldando o processo à realidade.
D
en
iz
e
 P
im
en
ta
29
O desenvolvimento iterativo parte o sistema em pedaços e cada parte é submetida às atividades até
que se chaga a implantação e validação para então se juntar com outra parte do sistema e passar
pelo ciclo novamente de forma incremental, até um certo ponto teremos o produto inteiro.
D
en
iz
e
 P
im
en
ta
30
Na maioria das iterações temos um ‘pedaço’ do sistema funcionando para validação com o usuário,
quando a entrega for externa, ou validação com a equipe na entrega interna.
D
en
iz
e
 P
im
en
ta
31
Esta figura representa duas dimensões:
•A horizontal que representa o aspecto dinâmico do processo, como
é ordenado e expresso em termos de fases, ciclos e marcos de
projeto - é o eixo do tempo.
•A segunda dimensão, vertical, são representadas as atividades,
fluxos de trabalho, artefatos e pessoas - é o eixo de conteúdo.
O final de cada iteração é marcado pela entrega de um artefato de software
(uma versão, um módulo, um conjunto de diagramas), esta entrega pode ser
para validação com o usuário (externa) ou para a equipe (interna).
Podemos observar que o compromisso de desenvolver um sistema, envolve diversas
atividades que são executadas continuamente durante todo o projeto.
No RUP as atividades têm uma alocação maior em função da fase em que se
encontra o projeto. As fases ajudam o gerente do projeto a fazer a apropriação de
profissionais e custos, resultando em uma maior eficiência.
Por exemplo, na fase de Concepção (Inception) existe uma alocação maior de
analistas envolvidos na atividade de “Levantamento de Dados” e “Definição do
problema”, representada no diagrama por “Requisitos”. Toda essa informação de
papéis, atividades e artefatos estão no RUP.
Navegue no PUC – Processo Unificado Caixa ( http://sipuc.caixa ou
http://sipuc.extranet.caixa ).
D
en
iz
e
 P
im
en
ta
32
Este artefato é útil para o planejamento do que será desenvolvido e atacado nas iterações e fases do
projeto. Note que um mesmo caso de uso e visto e revisto durante as fases até que o sistema esteja
concluído. O caso de uso é atacado de acordo com os objetivos da fase, desta forma na iniciação
todos os casos de uso são criados e identificados de uma forma macro para que posteriormente, na
fase de elaboração, sejam detalhados (pelo menos 80% dos casos de uso são detalhados nesta
fase). Alguns casos de uso são construídos (por inteiro ou parte dele) ainda na fase de elaboração
com o objetivo de mitigar riscos identificados anteriormente. Na próxima fase, de construção, os
casos de uso têm que ser construídos.
D
en
iz
e
 P
im
en
ta
33
O foco é viabilizar a construção do projeto, estudo do projeto como um todo.
Na fase de concepção é estabelecido o contexto de negócio para o sistema e
delimitado o escopo do projeto. Para tal, identificamos os atores que estarão
interagindo com o sistema, bem como os casos de uso associados às essas
interações.
O contexto de negócio inclui também um critério de sucesso, ponderado em função
de recursos e tempo. Essa ponderação nos dá o grau de “risco” que é possível
assumir.
Além disso, devemos nessa fase elaborar um estudo que tem como produto final um
cronograma básico de execução com as principais fases e datas de entrega.
Essa fase envolve a elaboração de um ante-projeto do sistema (uma proposta)
composto pelo memorial do projeto, escopo pretendido, principais atores envolvidos,
principais casos de uso e o uma estimativa de cronograma (com os principais marcos
do projeto).
D
en
iz
e
 P
im
en
ta
34
O foco é o desenho da solução da construção, aqui que serão feitos os diagramas,
detalhamento do UC.
Consiste de uma análise mais refinada do sistema a ser construído, juntamente com
um plano detalhado de trabalho a ser feito. As metasda fase de elaboração são:
analisar o domínio do problema, estabelecer uma arquitetura funcional, desenvolver
um plano do projeto e minimizar elementos de riscos potenciais ao projeto.
Essa fase envolve a elaboração de um projeto completo, com o detalhamento de
interações e estrutura do sistema. Nessa fase também podemos construir um
protótipo que teste a arquitetura escolhida.
Por exemplo, podemos ter a incumbência de criar uma aplicação para Web usando
Java Server Pages - JSP. Nós vamos detalhar as interações dos atores com cada
caso de uso, vamos modelar as classes do sistema e vamos construir algumas
páginas JSP para testar a sua funcionalidade. Podemos ainda envolver a participação
do cliente nesse processo.
D
en
iz
e
 P
im
en
ta
35
O foco é a codificação da solução encontrada anteriormente.
Durante a fase de construção trabalhamos sobre o protótipo da fase anterior
adicionando novas funcionalidades e refinando as funcionalidades pré-existentes.
Chamamos essa abordagem de iterativa (por ciclos) e incremental (adicionando
valor).
O gerente do projeto define várias versões que devem ser liberadas a cada ciclo,
incluindo alterações, refinamentos e novas funcionalidades.
A cada ciclo é necessário rever os requisitos de cada parte da aplicação, pois essa é
a essência do desenvolvimento incremental.
D
en
iz
e
 P
im
en
ta
36
Nessa fase o software pode ser instalado em ambiente de produção para que os
clientes possam trabalhar com ele. Como esta transição será feita ? Em paralelo com
o sistema atual ou simplesmente o substituído deixará de funcionar para início do
novo sistema ?
Assim que o programa entra em operação, é previsto que alguns pequenos ajustes
sejam necessários para que a versão final esteja disponível.
Um marco dessa fase é a “versão beta” do produto para testes.
Se tiver programado é nesta fase que ocorre o treinamento e outro produto (ou
artefato) é o conjunto de manuais com instruções de uso do sistema.
Ao final dessa fase teremos o produto em sua versão final para uso irrestrito por todo
o público-alvo.
D
en
iz
e
 P
im
en
ta
37
D
en
iz
e
 P
im
en
ta
38
Exercícios do Capítulo 1:
1) O que não se aplica à definição de usuário?
a) É quem utiliza o sistema.
b) É quem especifica requisitos.
c) É quem testa o sistema.
d) É um outro software que interage com a aplicação em questão.
2) A fronteira da aplicação:
a) É determinada após a definição do escopo da contagem.
b) Depende das características gerais do sistema.
c) Pode afetar o propósito da contagem.
d) Nenhuma das respostas anteriores.
3) Fronteiras:
a) Identificam a borda entre a aplicação ou o projeto a ser medido e as
aplicações externas ou o domínio do usuário.
b) Estabelecem o escopo do produto do trabalho a ser medido.
c) Consideram a aplicação do ponto de vista do usuário, o que o usuário pode
entender e descrever.
d) Todas as opções acima.
4) Os procedimentos de contagem de pontos de função incluem os seguintes passos:
a) Determinar quando a contagem será realizada.
b) Determinar o tipo de contagem que será realizada.
c) Medir o esforço associado ao projeto de desenvolvimento.
d) Todos os itens acima estão corretos.
5) A visão do usuário de uma aplicação é descrita por uma ou mais das seguintes
possibilidades:
a) É aprovada pelo usuário.
b) Pode ser usada para contar pontos de função.
c) Pode variar na forma física.
d) Todas as possibilidades acima estão corretas.
6) Os objetivos da análise de pontos de função são:
a) Medir o software independentemente da tecnologia utilizada para
implementação.
b) Medir a funcionalidade que o usuário requisita independentemente de se ele é
ou não disponibilizada.
c) Medir a produtividade associada com o desenvolvimento de um módulo do
software.
d) Medir o software independentemente da tecnologia utilizada para
implementação e medir a produtividade associada ao desenvolvimento do
software.
D
en
iz
e
 P
im
en
ta
39
Aprendemos neste capítulo:
• Foi discutida a importância de fazer e criar modelos.
• A UML é uma linguagem, uma notação, não tem uma regra para sua
utilização, permitindo que o desenvolvedor/analista/gerente use os diagramas
como bem entender (seguindo sua notação).
• O RUP é uma proposta de metodologia de desenvolvimento de sistemas
que indica o uso a UML como notação. O RUP tem as regras, os passos a
serem executados para desenvolver software.
D
en
iz
e
 P
im
en
ta
40
Objetivos do Capítulo 2:
•Aprender os novos conceitos da Orientação à Objetos
•Conhecer todos os diagramas da UML descobrindo os objetivos de cada um
D
en
iz
e
 P
im
en
ta
41
D
en
iz
e
 P
im
en
ta
42
D
en
iz
e
 P
im
en
ta
43
D
en
iz
e
 P
im
en
ta
44
D
en
iz
e
 P
im
en
ta
45
A classe casa é como uma forma que irá criar objetos semelhantes. Observe que cada objeto tem
característica própria, a cor o número.
D
en
iz
e
 P
im
en
ta
46
D
en
iz
e
 P
im
en
ta
47
D
en
iz
e
 P
im
en
ta
48
D
en
iz
e
 P
im
en
ta
49
Sobrescrita (override)
O método da subclasse (classe filha) retorna um valor e o método da superclasse (classe pai) retorna
outro.
No exemplo a superclasse contém um método para calcular o salário dos funcionários. A subclasse
herda este método, mas a subclasse pode decidir sobrescrever a implementação da superclasse
redefinindo a forma de calcular o salário dos empregados que trabalham em venda.
D
en
iz
e
 P
im
en
ta
50
Sobrecarga (overload)
Cada método em uma classe é identificado pelo seu nome e sua lista de parâmetros. Podem existir
dois ou mais métodos com o mesmo nome, mas cada um com uma lista de parâmetros diferentes.
Este conceito é chamado sobrecarga de método, esta facilidade permite que seja executada a
mesma ação com diferentes tipos de entradas. Conforme o método do exemplo apresentado abaixo,
utilizado para calcular o valor máximo entre dois números em diferentes combinações de entradas:
public static int maximo ( int x, int y ) {
// calcular o maximo usando dois numeros inteiros
}
public static double maximo ( double x, double y ) {
// calcular o maximo usando dois numeros decimais
}
D
en
iz
e
 P
im
en
ta
51
A mensagem é troca de informações entre objetos. Para uma determinada função funcionar serão
chamados n métodos através dos objetos relacionados, essa comunicação entre objetos, que é a
chamada de operações é chamada de mensagem.
As classes de entidade serão persistidas, provavelmente se tornarão tabelas em um SGBD.
Estereótipos são adornos utilizados para estender o significado de um determinado elemento em um
diagrama, como por exemplo se quisermos representar, ou melhor diferenciar, as classes que serão
persistidas das outras classes, definimos o estereótipo como entity.
D
en
iz
e
 P
im
en
ta
52
D
en
iz
e
 P
im
en
ta
53
Neste tópico veremos todos os Diagramas da UML
D
en
iz
e
 P
im
en
ta
54
D
en
iz
e
 P
im
en
ta
55
D
en
iz
e
 P
im
en
ta
56
Os diagramas estão divididos em dois grandes grupos:
Comportamentais - modelam aspectos dinâmicos do sistema, mostram, na maioria das vezes, como
as entidades interagem para a execução de uma funcionalidade, são eles: de caso de uso,
seqüência, comunicação, de estado, de Tempo (Timming), de Resumo da Interação (Interaction
Overview), Estrutura de Compósito (Composite Structure) e de atividade.
Estruturais - modelam a estrutura do sistema, sua parte estática, mostram como as entidades são
compostas e seus relacionamentos, são eles: diagrama de classe, de objetos, de componente e de
implantação.
D
en
iz
e
 P
im
en
ta
57
A partir deste cenário serão apresentados os diagramas da UML.
D
en
iz
e
 P
im
en
ta
58
Imagine a tela ou o conjunto de telas que fará parte de uma funcionalidade e imagine
a interação do usuário com o sistema, qual a ação do usuário e como o sistema irá
reagir, quais os campos que terão lista de bancos, quais os campos que o usuário
deverá informar valores.
Devemos prever todas as reações do sistema – se o usuáriodigitar letra no lugar de
um número, como o sistema irá reagir ? Neste momento podemos prever inclusive
quais as mensagens de alerta/erro que retornarão ao usuário, afinal de contas o caso
de uso servirá de base para os testes.
D
en
iz
e
 P
im
en
ta
59
Alguns casos de uso que podem ser aplicados ao sistema de controle de horas são
(este é um exemplo os casos de uso não estão levantados na totalidade do sistema):
O funcionário cadastra alocação: para o cadastramento da tarefa será necessária a
interação entre o funcionário e o sistema pois o funcionário deverá informar: a data da
atividade, o horário (hora início e fim) de sua realização, o sistema deverá exibir o
logon do funcionário e uma lista de atividades e projetos, o funcionário deverá
selecionar uma categoria e uma Ordem de Projeto e opcionalmente informar FSA/OS,
Sistema, Aplicação e Observação e então solicitar a confirmar a tarefa, o sistema
deverá gravar a tarefa e exibir a lista de tarefas.
O gerente avalia as horas lançadas: Visto que um gerente pode interagir com mais
de um projeto, ele deverá informar o projeto e o sistema irá listar todos os
funcionários que lançaram horas no projeto informado e que ainda estão aguardando
aprovação, o gerente seleciona o funcionário e seleciona todas as horas do
funcionário e então confirma a aprovação das suas horas – um tratamento de
exceção é a reprovação das horas indevidas, e deve ser previsto neste cenário.
O funcionário consulta mês: o funcionário seleciona navegação pelos meses e o
sistema deverá exibir suas tarefas cadastradas.
D
en
iz
e
 P
im
en
ta
60
O exemplo acima mostra como pode ser feita uma descrição de um caso de uso, neste caso há
divisão entre Cursos Alternativos e Exceções. Nos Cursos Alternativos são descritos passos de uma
outra forma de encerrar o caso de uso corretamente, já as exceções indicam algum problema em
algum momento que poderá ocorrer.
O Caso de Uso também pode servir de base para fazer o Caso de Teste, pois terá todas as exceções
previstas.
O exemplo citado é a descrição de um caso de uso, deverá haver uma descrição para cada caso de
uso apresentado anteriormente.
D
en
iz
e
 P
im
en
ta
61
D
en
iz
e
 P
im
en
ta
62
No Diagrama de Classe os objetos envolvidos no sistema de controle de horas são agrupados
em classes. Uma classe é um conjunto de objetos.
Na classe de funcionários, os atributos incluem o logon, nome, unidade, filial e número
funcional. Esta classe também armazena a operação buscarLogon (dentre outras aqui ainda
não definidas).
D
en
iz
e
 P
im
en
ta
63
Um Diagrama de Seqüência oferece uma visão detalhada de um caso de uso. Ele
mostra uma interação organizada em forma de uma seqüência de passos entre os
objetos, dentro de um determinado período de tempo e contribui para que se entenda
a lógica dentro de cada caso de uso.
Os participantes são apresentados dentro do contexto das mensagens que transitam
entre eles.
D
en
iz
e
 P
im
en
ta
64
As restrições de tempo podem ser representadas neste diagrama. A OCL (Object
Constraint Language) é a linguagem que define as restrições, muito utilizada aqui
para determinar as restrições temporais do sistema.
D
en
iz
e
 P
im
en
ta
65
Um Diagrama de Comunicação é outro tipo de diagrama de interação. Assim como
no Diagrama de Seqüência, o Diagrama de Comunicação mostra como um grupo de
objetos num caso de uso interage com os demais. Cada mensagem é numerada para
documentar a ordem na qual ela ocorre.
Os diagramas de comunicação e de seqüência são equivalentes a diferença é que o
diagrama de seqüência tem o tempo como participante fundamental.
D
en
iz
e
 P
im
en
ta
66
O diagrama da figura é equivalente ao diagrama de seqüência anterior. Podemos
dizer que o diagrama de comunicação (antigo diagrama de colaboração) e o
diagrama de seqüência são isomórficos, ou seja, tem a mesma forma, podemos obter
a visão de um a partir do outro.
Enquanto o diagrama de seqüência tem uma visão temporal, o diagrama de
comunicação apresenta uma visão espacial dos objetos.
D
en
iz
e
 P
im
en
ta
67
O estado de um objeto é definido pelos seus atributos em um determinado momento.
Os objetos se movem através de diferentes estados, por serem influenciados por
estímulos externos. O Diagrama de Estado mapeia estes diferentes estados em que
os objetos podem se encontrar e quais os eventos que fazem com que os estados
dos objetos sejam alterados.
D
en
iz
e
 P
im
en
ta
68
A classe alocação guarda as horas cadastradas pelos funcionários, essas horas
devem ser validadas pelos seus respectivos coordenadores que utilizam a
funcionalidade ‘Aprovar Horas’ para aprovar ou reprovar as horas cadastradas em
seu projeto. A figura mostra as alterações de estado da classe alteração.
D
en
iz
e
 P
im
en
ta
69
D
en
iz
e
 P
im
en
ta
70
O Diagrama de Atividade é uma ferramenta útil para desenhar a solução de
implementação e pode estar baseada em um caso de uso ou pode definir um método
mais complexo.
Esta figura mostra as atividades necessárias, do sistema, para a execução do
Cadastro de Alocação, exibindo todos os cenários do caso de uso (uso da decisão).
Observe que há atividades que podem ser executadas em paralelo (threading).
O diagrama de atividade é baseado em um caso de uso inteiro (todos os cenários) ou
em uma classe.
D
en
iz
e
 P
im
en
ta
71
Um Diagrama de Componentes exibe a hierarquia de dependência entre os
componentes do sistema.
Um componente é uma parte do sistema e pode ser entendido como uma tela, uma
biblioteca (dlls), um arquivo de críticas (arquivos js), um executável, etc.
D
en
iz
e
 P
im
en
ta
72
O site tem várias camadas, as páginas ASP chamam algumas regras, neste
diagrama vemos qual a dependência entre elas.
Lembre que os componentes são bibliotecas, executáveis, telas, tabelas, uma parte
qualquer do sistema.
D
en
iz
e
 P
im
en
ta
73
O Diagrama de Implantação mostra o layout físico da rede, onde cada nó representa
uma máquina, podendo mostrar a configuração delas (hardware e software) e
também onde cada componente irá ser instalado.
D
en
iz
e
 P
im
en
ta
74
Neste desenho vemos onde cada componente identificado deverá ser ‘instalado’,
auxiliando a implantação do sistema.
D
en
iz
e
 P
im
en
ta
75
O diagrama de implantação poderá ser usado para caracterizar o hardware e o software necessário a
ser instalado nos nós (máquinas ou periféricos).
Inclusive a conexão entre os nós.
O nó é um elemento físico que representa um recurso computacional com memória e/ou capacidade
de processamento, como máquinas, servidores, hubs, impressoras, etc.
D
en
iz
e
 P
im
en
ta
76
D
en
iz
e
 P
im
en
ta
77
D
en
iz
e
 P
im
en
ta
78
D
en
iz
e
 P
im
en
ta
79
Objetivos do Capítulo 3:
1. Conceitos e Componentes do Diagrama
2. Desenho do Diagrama em três passos:
 Identificação de Casos de Uso
 Descrição dos Casos de Uso
 Desenho do Diagrama de Casos de Uso
D
en
iz
e
 P
im
en
ta
80
A documentação a ser entregue deve ser composta de: o Diagrama de Casos de Uso (desenho) e
para cada caso de uso do diagrama deverá ter um texto descrevendo sua interação.
D
en
iz
e
 P
im
en
ta
81
O Diagrama de Casos de Uso exibe todas as funcionalidades que o sistema têm, com isso ajuda a
definir o escopo do sistema.
Um caso de uso representa uma funcionalidade.
D
en
iz
e
 P
im
en
ta
82
Um requisito representa uma necessidade do usuário que deverá ser refletida de alguma forma no
sistema. Um requisito pode estar espelhado em mais de um caso de uso, e um caso de uso poderá
realizar mais de um requisito.
Os casos de uso somente espelham os requisitos funcionais, para definir os requisitos não funcionais
deve ser utilizado outro documento (Especificação Suplementar).
D
en
iz
e
 P
im
en
ta
83
A modelagem de negócios ou comercial abrange um nível maior dentro da empresa
do que a modelagem do sistema a ser desenvolvido. Ela é utilizada para mapear os
processos da empresa e mostrar como amesma funciona.
O caso de uso de negócios é um guideline, um roteiro utilizado para mapear um
processo, por exemplo precisamos definir para o restaurante como os garçons devem
preparar a mesa a regra de ordenação de talheres e copos ficarão descritos dentro do
caso de uso de negócio ‘Preparar a Mesa’.
Um ator de negócios interage com a empresa ou setor modelado, por exemplo o
fornecedor interage com a empresa, um outro exemplo é o Garçom com o Preparar a
Mesa e Servir o Pedido. Se for indicada a informatização para um melhor controle do
restaurante o Garçom não será necessariamente um ator do sistema.
D
en
iz
e
 P
im
en
ta
84
Iterar - Tornar a dizer; repetir. A iteração é um ciclo. (Dic. Aurélio)
Interação - Ação recíproca de dois ou mais corpos, uns nos outros. 2. Fís. Ação mútua entre duas
partículas ou dois corpos. (Dic. Aurélio)
A interação ou comunicação é o relacionamento entre o ator e o sistema. Pode existir relacionamento
entre casos de uso (extensão, inclusão e generalização).
A figura acima mostra os caminhos de um caso de uso, cada caminho é executado por um cenário.
Todos os fluxos deverão ser previstos na descrição do caso de uso. Um caso de uso tem ‘n’ cenários,
para cada cenário percorreremos um caminho (ou fluxo) do caso de uso.
D
en
iz
e
 P
im
en
ta
85
Os atores (pessoas, outros sistemas, periféricos) interagem com o sistema através de uma fronteira.
No diagrama de caso de uso teremos todas as funcionalidades do sistema. Para cada funcionalidade
iremos descrever as interações entre o ator e as reações do sistema.
D
en
iz
e
 P
im
en
ta
86
D
en
iz
e
 P
im
en
ta
87
O ator é aquele que utiliza o sistema para passar informações. Pode ser outro sistema, um hardware,
um grupo de pessoas. Mas têm que necessariamente interagir com o sistema.
D
en
iz
e
 P
im
en
ta
88
Os diagramas de casos de uso podem ser simplificados por meio da herança entre
atores. Neste caso, mostra-se um caso de uso comum aos atores específicos, que se
comunicam apenas com o ator genérico.
A figura mostra as especializações de “Gerente” para o ator mais genérico
“Funcionário”.
D
en
iz
e
 P
im
en
ta
89
Esta figura informa que o Gerente é uma especialização de Funcionário e a parte
mais especializada herda todas as atividades da classe mais genérica, ou seja, o
Gerente pode tanto Aprovar Horas quanto Cadastrar Ocupação e Consultar Mês, mas
Funcionário pode somente Cadastrar Ocupação e Consultar Mês.
A notação de generalização/especialização pode ser vista entre casos de uso e em
outros diagramas da UML.
Atenção na associação unidirecional entre o caso de uso ‘Aprovar Horas’ e o ator
SisRH, este exemplo indica que o ator somente receberá informações do sistema.
D
en
iz
e
 P
im
en
ta
90
O Caso de Uso em si é uma seqüência de ações que um sistema desempenha para
produzir um resultado observável por um ator específico. Em outras palavras, um
caso de uso define uma funcionalidade do sistema com um conjunto de ações
tomadas pelo ator e a previsão da reação por parte do sistema.
O Caso de Uso é uma classe, não uma instância. A sua especificação descreve a
funcionalidade como um todo, incluindo erros, possíveis alternativas e exceções que
podem ocorrer durante sua execução. O nome do Caso de Uso deve ser uma frase
indicando a ação que realiza.
Cuidado para não identificar um caso de uso no lugar de um passo! Um caso de uso
tem um conjunto de passos e trata as exceções desses passos. Na descrição do
caso de uso é que teremos que pensar quais as ações que o caso de uso
desempenhará.
Alguns exemplos de casos de uso: Cadastrar Cliente, Registrar Venda, Fechar Caixa,
etc.
D
en
iz
e
 P
im
en
ta
91
Um caso de uso, como dito anteriormente, representa uma funcionalidade do sistema:
tem início, uma entrada, uma solicitação, tem meio, um processamento, uma
gravação e tem um fim, uma confirmação, uma impressão, o resultado de uma
consulta na tela.
D
en
iz
e
 P
im
en
ta
92
O caso de uso é desenhado como uma elipse e seu nome pode vir dentro do desenho
ou abaixo da mesma.
Um caso de uso retrata uma funcionalidade e não uma atividade atômica, pois tem
início meio e fim. Um ator entra no sistema para cadastrar cliente e sai com o cliente
cadastrado.
D
en
iz
e
 P
im
en
ta
93
Notações especiais são utilizadas para facilitar a descrição de funcionalidade mais
complexa. Entre estas notações, destacam-se os casos de usos secundários, que
simplificam o comportamento dos casos de uso primários através dos mecanismos de
extensão e inclusão.
Casos de uso primários são aqueles que são invocados por iniciativa direta de um
ator; casos de uso secundários são invocados em um passo de outro caso de uso. Os
termos “primário” e “secundário”, quando referentes a casos de uso, não fazem parte
da UML.
D
en
iz
e
 P
im
en
ta
94
O caso de uso B estende o caso de uso A quando B representa uma situação
opcional ou de exceção, que normalmente não ocorre durante a execução de A. Essa
notação pode ser usada para representar fluxos complexos opcionais ou anormais.
O caso de uso “estendido” é referenciado nas precondições do caso de uso
“extensor”. As precondições são a primeira parte dos fluxos dos casos de uso.
“Extensão - 1. Ato ou efeito de estender ou estender-se. 2. Qualidade de extenso. 3.
Fís. Propriedade que têm os corpos de ocupar certa porção do espaço. 4.
Desenvolvimento no espaço. 5. Vastidão. 6. Grandeza, força, intensidade. 7. Porção
de espaço. 8. Comprimento. 9. Superfície, área. 10. Ramal telefônico, com o mesmo
número do telefone principal, usado geralmente em residências ou escritórios.” (Dic.
Aurélio)
“Estender - v. 1. Tr. dir. e pron. Alargar(-se), alongar(-se), estirar(-se). 2. Tr. dir.
Desdobrar, desenrolar, desenvolver. 3. Tr. dir. Oferecer, apresentando: Estendeu a
mão ao visitante. 4. Tr. dir. Alastrar, espalhar. 5. Pron. Ocupar certa extensão. 6. Tr.
dir. Esticar. 7. Tr. dir. Tornar mais amplo. 8. Tr. dir. Fazer chegar; levar. 9. Tr. dir.
Expor ao ar, ao sol etc.” (Dic. Aurélio)
D
en
iz
e
 P
im
en
ta
95
O desenho mostra a instância do caso de uso sendo executada e quando chega ao
ponto de extensão um outro caso de uso é chamado e executado para que então se
retorne à execução do caso de uso original (base).
D
en
iz
e
 P
im
en
ta
96
O desenho informa que o cadastro do cliente pode ser chamado diretamente da
solicitação do serviço, mas esta é uma ação que pode ocorrer ou não.
Observe que o caso de uso que estende tem uma relação de dependência com o
caso de uso estendido (seta tracejada), ou seja, a o Cadastro do Cliente só pode ser
executada se Solicitar Serviço for executado antes.
D
en
iz
e
 P
im
en
ta
97
Na figura percebemos que na funcionalidade Comandar Jantar podemos ter um
atalho para Comandar Bebida ou Comandar Sobremesa. Esta técnica é aplicada para
facilitar o uso do sistema. Atenção o uso dos casos de uso estendidos são
facultativos, ou seja, pode haver o pedido de jantar sem bebida e sem sobremesa.
D
en
iz
e
 P
im
en
ta
98
O caso de uso A inclui o caso de uso B quando B representa uma atividade
complexa, comum a vários casos de uso. Essa notação pode ser usada para
representar subfluxos complexos e comuns a vários casos de uso. O caso de uso
“incluído” é referenciado no fluxo do caso de uso “que inclui”.
D
en
iz
e
 P
im
en
ta
99
O desenho mostra a instância de um caso de uso sendo executada e quando chega
em um determinado ponto sempre deverá ser chamado um outro caso de uso (o
incluído), e este é executado para que então se retorne à execução do caso de uso
original (base).
D
en
iz
e
 P
im
en
ta
100
Cadastrar Pagamento são passos comuns a Solicitar Serviço e Cadastrar Venda, por
este motivo este conjunto de passos são isolados em outro caso de uso.
Observe também que o caso de uso que inclui tem uma relação de dependência com
o caso de uso incluído (seta tracejada). Ou seja, Solicitar Serviço e Cadastrar Venda
só podem ser executadas se Cadastrar Pagamento for executada.
D
eniz
e
 P
im
en
ta
101
Neste caso, a solução foi pensada de forma que, quando houver o Comando de
Jantar necessariamente haverá o Pagamento de Conta, da mesma forma quando
houver Comando de Almoço haverá Pagamento de Conta.
O importante é saber ler o que está desenhado, no exemplo o sistema somente será
acionado ao final do processo, quando haverá o registro do consumo (almoço ou
jantar) e logo em seguida o pagamento da conta.
D
en
iz
e
 P
im
en
ta
102
D
en
iz
e
 P
im
en
ta
103
Na generalização de casos de uso o caso de uso pai define todos os passos comuns e os passos
específicos são executados pelo caso de uso filho.
D
en
iz
e
 P
im
en
ta
104
Receber pagamento em cheque, Receber pagamento em dinheiro e Receber pagamento em cartão
são especializações do caso de uso Receber Pagamento.
Os UCs filhos herdam os atributos, operações e seqüências de comportamento do UC pai.
Os UCs filhos podem adicionar e redefinir o comportamento do UC pai, através da inserção de
seqüências adicionais de ações em pontos arbitrários da seqüência do UC pai.
Os UCs filhos podem substituir o UC pai em qualquer lugar que ele aparece.
Relacionamentos de inclusão e extensão do use case filho também modificam o use case do pai.
Normalmente a similaridade entre use cases é identificada após a descrição dos casos.
Outro exemplo: Tanto Checar password quanto Scan de retina servem para validar o usuário, e em
validar usuário tem um conjunto de passos comuns aos subtipos.
D
en
iz
e
 P
im
en
ta
105
O exemplo mostra a descrição de casos de uso em generalização/especialização, a descrição da
esquerda é do UC pai e o da direita representa um dos UC filho.
O passo 5 fica sem definição no ‘Caso de Uso Pai’ e em itálico pois representa na sintaxe da UML
alguma coisa abstrata.
Note que a solução poderia ser apresentada de outras formas, como por exemplo utilizando
<<inclui>> ou <<estende>>, mas esta notação enfatiza o ‘relacionamento de família’, de similaridade
das ações, compartilhando a mesma estrutura, comportamento e intenção.
D
en
iz
e
 P
im
en
ta
106
A UML não dita regras para a construção do diagrama, ela apenas é uma notação. Os passos que se
seguem são uma sugestão para facilitar a construção do diagrama de casos de uso.
D
en
iz
e
 P
im
en
ta
107
Para facilitar a identificação construção do diagrama, dividimos a construção em três partes:
-A primeira é a identificação dos possíveis casos de uso – lembre-se que caso de uso é uma
funcionalidade do sistema e tem início, meio e fim.
-A segunda tarefa é a descrição dos casos de uso, neste momento identificamos os verdadeiros
casos de uso do sistema, casos de uso com um, dois ou três passos podem sair do modelo e seus
passos podem ser identificados como sendo de outro caso de uso. Pode ser identificada também a
necessidade de criar um caso de uso novo quando identificado um conjunto de passos iguais em
mais de um caso de uso.
-A terceira parte é o desenho do diagrama, após a identificação e a descrição dos casos de uso o
desenho do diagrama fica fácil.
D
en
iz
e
 P
im
en
ta
108
D
en
iz
e
 P
im
en
ta
109
D
en
iz
e
 P
im
en
ta
110
A descrição de casos de uso é livre não tem regra alguns profissionais utilizam em forma de tabela
outros na forma de texto corrido, a UML não tem regra para isso.
Fluxo (ou curso) típico, normal, ou principal – é o que ocorre se der tudo certo, imaginar o mundo
perfeito, sem erros.
Fluxos (ou cursos) alternativos e/ou exceções – é a descrição de uma alternativa de execução do
curso principal, pode ter uma forma correta alternativa ou os possíveis erros. Como o sistema deverá
reagir se determinada condição for falsa, este é o tipo de informação que deverá constar e estar
mapeada nas exceções.
Existem autores que dividem Cursos Alternativos e Exceções, a UML não obriga nenhum uso, o
Fluxo (ou curso) Alternativo ou Secundário representa uma outra forma de execução de um passo (ou
um conjunto de passos), como uma alternativa do curso principal, como por exemplo a venda à prazo
ou à vista, ambas as formas são possíveis e não indicam erro, são apenas alternativas diferentes de
registrar um pagamento.
D
en
iz
e
 P
im
en
ta
111
D
en
iz
e
 P
im
en
ta
112
A pré-condição é opcional e descreve o estado que o sistema deve estar antes do
início do caso de uso. Por exemplo: o arquivo de importação (a ser gerado por outro
sistema) deve estar gerado e disponível no caminho XYZ.
A pós-condição é opcional e descreve o estado que o sistema vai se encontrar ao
final da execução do caso de uso. Por exemplo: Ao final do caso de uso efetuar
compra o boleto deverá ser impresso.
D
en
iz
e
 P
im
en
ta
113
D
en
iz
e
 P
im
en
ta
114
Depois da identificação e da descrição dos casos de uso o desenho do diagrama se torna simples,
pois os diagramas reais já estão definidos, as inclusões, extensões, generalizações e atores já foram
identificados.
D
en
iz
e
 P
im
en
ta
115
Lembre-se que é com a prática que você irá aprender a fazer os diagramas.
D
en
iz
e
 P
im
en
ta
116
Devemos evitar passos e regras repetidas em ‘n’ casos de uso, para isso devemos procurar unificar e
separar as regras em um caso de uso a ser usado pelos outros.
Atores que têm a mesma interação com o sistema em um caso de uso devem ser generalizados (ver
generalização/especialização de atores).
D
en
iz
e
 P
im
en
ta
117
D
en
iz
e
 P
im
en
ta
118
D
en
iz
e
 P
im
en
ta
119
Objetivos do Capítulo 4:
• Conhecer Componentes do Diagrama de Classes
• Construir um Diagrama de Classe
• Exercícios e Desafios
D
en
iz
e
 P
im
en
ta
120
D
en
iz
e
 P
im
en
ta
121
As classes podem ser exibidas com ou sem seus atributos e/ou métodos, o que é obrigatório é o
nome da classe.
As classes de interface são exibidas como um pequeno círculo, estas especificam um conjunto de
operações ou serviços de uma classe ou componente. As interfaces ultrapassam as fronteiras lógica
e física. A mesma interface utilizada ou realizada por um componente será encontrada utilizada ou
realizada pelas classes que o componente implementa.
As classes exibidas no rodapé da página tem um estereótipo diferente e cada uma indica um tipo
diferente, a primeira é uma classe de controle, a segunda uma classe de fronteira e a terceira uma
classe de entidade.
Classe de Controle – são elementos que coordenam o comportamento do caso de uso, atuando
como uma interface entre fronteira e entidade.
Classe de Fronteira – modelam a interação entre o sistema e seu ambiente. Geralmente são
representadas por Interfaces Gráficas com o Usuário (GUI – Graphical User Interfaces), interfaces
com outros sistemas e interfaces com dispositivos.
Classe de Entidade – atuam de forma a armazenar e controlar informações no sistema.
D
en
iz
e
 P
im
en
ta
122
D
en
iz
e
 P
im
en
ta
123
Os pacotes lógicos são agrupamentos de elementos de um modelo. No modelo de
análise, eles podem ser utilizados para formar grupos de classes com um tema
comum, pode ser útil para a divisão do trabalho na equipe de desenvolvimento.
Os pacotes da figura são usados para agrupar classes especializadas em relação a
esses aspectos.
Pacotes lógicos podem ter relações de dependência e pertinência entre si.
D
en
iz
e
 P
im
en
ta
124
A associação binária é a mais comum nos diagramas de classe.
D
en
iz
e
 P
im
en
ta
125
O exemplo acima indica que um Estado pode ter várias Cidades, a estrutura das duas
classes é idêntica, e uma outra forma mais simplista de desenhar seria em uma única
classe.
D
en
iz
e
 P
im
en
ta
126
A associação n-ária representa o relacionamento com mais de duas classes. O
exemplo acima está exibindo o relacionamento de avaliação de um funcionário em
um projeto, e esta avaliação é para um quesito. Então, por exemplo, o funcionário
João será avaliado em pontualidade no projeto A e terá uma nota de avaliação,
quando ele for trabalhar no Projeto B ele poderá ter outra nota de avaliação no
mesmo quesito.Os quesitos servem para pontuar os funcionários e são exemplo:
organização, limpeza, pontualidade, etc.
D
en
iz
e
 P
im
en
ta
127
Neste exemplo a cauda a fuselagem e as asas do avião poderão ser utilizadas em outro avião. E se o
planador for excluído talvez as partes continuem existindo para um dia compor outro planador.
D
en
iz
e
 P
im
en
ta
128
As figuras mostram dois exemplos de agregação: um documento pode ter figuras e
essas figuras podem ser utilizadas em outros documentos. Estes serão membros do
documento (todo-parte). Da mesma forma um projeto pode trabalhar com classes e
funcionários, que poderão ser utilizados por outro projeto, significa dizer que quando
chegar ao fim de um projeto, as classes e os funcionários poderão ser
reaproveitados.
D
en
iz
e
 P
im
en
ta
129
A composição indica que a ‘parte’ não tem vida sem o ‘todo’. No exemplo o desenho do círculo será
composto de pontos e estes pontos somente poderão compor este círculo.
D
en
iz
e
 P
im
en
ta
130
D
en
iz
e
 P
im
en
ta
131
A composição impõe a cardinalidade de no mínimo 1. Os exemplos sugerem que as
páginas e a capa do livro compõem um livro e não podem compor outro objeto. Assim
como os quartos do hotel somente pertencerão a ele, não faz sentido retirar o quarto
do cadastro e aproveitar para outro hotel (a parte não existe sem o todo).
D
en
iz
e
 P
im
en
ta
132
D
en
iz
e
 P
im
en
ta
133
O uso das restrições é facultativo e serve para identificar o que está desenhado nas especializações
da super-classe. Pode ser que estejam todos os sub-tipos desenhados no diagrama, se fosse
colocado no exemplo acima poderíamos dizer que todas as contas são do tipo Fundo, Corrente ou
Poupança, neste caso a restrição seria ‘completo’. Caso tenha algum tipo de conta não mostrado no
desenho, como Conta Aplicação teríamos a restrição sendo ‘incompleto’.
Para as restrições de sobreposição temos que uma conta bancária pode se comportar como
poupança e como conta corrente, o dinheiro não fica parado nunca está no mínimo rendendo os juros
da poupança. Se o sistema não funcionar desta forma, ou seja, uma conta bancária é uma conta
poupança ou corrente ou fundo de ações temos a restrição de ‘disjunção’.
D
en
iz
e
 P
im
en
ta
134
D
en
iz
e
 P
im
en
ta
135
Um exemplo raríssimo do uso de herança múltipla, o veículo anfíbio herda características (atributos e
métodos) tanto de ‘Terrestre’ quanto da classe ‘Marítimo’.
Neste exemplo as restrições não estão definidas, o que dificulta um pouco o entendimento do
desenho.
D
en
iz
e
 P
im
en
ta
136
No sistema acima nunca será instanciado um Veículo, ou será instanciado Carro ou
Barco.
D
en
iz
e
 P
im
en
ta
137
D
en
iz
e
 P
im
en
ta
138
Os dados de emprego só existem se houver uma pessoa e uma empresa, se não
houver associação entre esses elementos não existirá emprego.
D
en
iz
e
 P
im
en
ta
139
A dependência entre as classes não indica inclusão dos atributos do relacionamento
(não haverá chave estrangeira na geração do banco), essa associação indica
simplesmente que uma classe envia uma mensagem a outra. No exemplo acima o
objeto Pedido solicita uma informação do Produto, por exemplo seu preço. Nada
impede de haver associação entre as classes.
D
en
iz
e
 P
im
en
ta
140
No exemplo acima uma operação de pedido faz referência à um objeto da classe Produto.
D
en
iz
e
 P
im
en
ta
141
Como no diagrama de classe não tem a representação de chave estrangeira, a navegabilidade indica
que a divulgação terá a chave estrangeira da entidade programa, pois todos os objetos de Divulgação
têm a responsabilidade de saber qual o Programa fazem referência.
D
en
iz
e
 P
im
en
ta
142
D
en
iz
e
 P
im
en
ta
143
A multiplicidade indica a quantidade de objetos da classe B pode estar associada a um
objeto da classe A em uma associação.
No exemplo um cliente pode se relacionar com vários objetos da classe pedido, mas um
objeto da classe pedido só poderá estar associado a um objeto da classe cliente (no
mínimo um e no máximo um cliente).
D
en
iz
e
 P
im
en
ta
144
Uma classe pode definir o tipo de acesso que seus membros (propriedades e métodos) permitirão às
demais partes do sistema.
Em uma escala progressiva de “privacidade” dos membros, os tipos de acesso possíveis são público,
pacote, protegido e privado.
O padrão para criação de atributos é com visibilidade privada e os métodos como públicos, desta
forma utilizamos o conceito de encapsulamento (proteção dos dados pelos métodos da própria
classe).
A classe ‘Visibilidade’ exibida acima mostra o desenho da visibilidade na ferramenta CASE Rose.
D
en
iz
e
 P
im
en
ta
145
Exemplo do diagrama de classes completo.
D
en
iz
e
 P
im
en
ta
146
O código acima foi gerado a partir do desenho da classe utilizando a ferramenta CASE JUDE
Community 1.4.3.
D
en
iz
e
 P
im
en
ta
147
O script gerado foi feito usando a ferramenta CASE Rational Rose 2003.
D
en
iz
e
 P
im
en
ta
148
Mais uma vez a UML não tem regra para a construção do diagrama, mas para facilitar sua construção
vamos seguir esses passos.
D
en
iz
e
 P
im
en
ta
149
D
en
iz
e
 P
im
en
ta
150
D
en
iz
e
 P
im
en
ta
151
D
en
iz
e
 P
im
en
ta
152
( Este exercício é complementar, tente fazer e traga dúvidas )
D
en
iz
e
 P
im
en
ta
153
D
en
iz
e
 P
im
en
ta
154
Objetivos do Capítulo 5:
•Visualizar a dinâmica do sistema através do Diagrama de Seqüência.
D
en
iz
e
 P
im
en
ta
155
D
en
iz
e
 P
im
en
ta
156
Um diagrama de sequência dá ênfase à ordenação temporal das mensagens.
É difícil representar lógicas de seleção e repetição sem prejudicar a legibilidade do
diagrama.
D
en
iz
e
 P
im
en
ta
157
Os diagramas de interação são elaborados baseados na descrição de um fluxo (ou sub-fluxo) do caso
de uso juntamente com o diagrama de classes, visto que os diagramas de interação representam as
mensagens entre os objetos, que são os passos levantados na descrição e os objetos são as classes
identificadas no diagrama de classes.
D
en
iz
e
 P
im
en
ta
158
Componentes do Diagrama de Seqüência: Objetos, Mensagem, Linha de Vida, Caixa de Ativação,
Remoção, Restrição.
Tipicamente o objeto que inicia a interação é colocado à esquerda, portanto o desenho é feito da
esquerda para a direita, conforme a utilização dos objetos no contexto. Somente serão exibidos no
diagrama objetos que participarem do roteiro.
D
en
iz
e
 P
im
en
ta
159
Sistemas de Tempo Real são caracterizados por terem que atender, não apenas a correta execução
lógica das tarefas, como também a limites de tempo de execução. Para que uma tarefa em tempo
real seja considerada bem sucedida, ela deve ser concluída com sucesso e dentro de um tempo pré-
determinado, como representar este requisito na UML? Pode ser utilizado o Diagrama de Seqüência
colocando restrições de tempo nas execução das atividades.
A semântica utilizada na restrição é descrita na OCL (Object Constraint Language).
D
en
iz
e
 P
im
en
ta
160
D
en
iz
e
 P
im
en
ta
161
No exemplo acima podemos observar que a instância de Pedido é criada a partir da
tela de cadastro de pedido (frmCadPedido). Note que a instância de Cliente aparece
um pouco abaixo da instância da janela, indicando que ela foi criada depois.
D
en
iz
e
 P
im
en
ta
162
A figura mostra um ‘X’ na linha de vida da instância de pedido indicando a sua
exclusão. Note que a linha de vida do objeto é interrompida.
D
en
iz
e
 P
im
en
ta
163
Evite interações entre atores, pois por definição o ator é externo ao sistema.
D
en
iz
e
 P
im
en
ta
164
O Diagrama de Seqüência é feito a partir da descrição do caso de uso e da definição
das classes.
O Diagrama de Seqüência é um descobridor de métodos das classes, quando
desenhamos o diagrama de classe não temos idéia da quantidade dos métodos das
classes, é até uma atividade difícil tentar descobrir os métodos sem o uso do
diagrama de seqüência.
D
en
ize
 P
im
en
ta
165
Observe na figura a seqüência de passos do caso de uso, identificada pela
numeração.
D
en
iz
e
 P
im
en
ta
166
D
en
iz
e
 P
im
en
ta
167
D
en
iz
e
 P
im
en
ta
168
A condição no diagrama de seqüência é representada através de uma expressão
entre colchetes (Condição de Guarda), e indica que a mensagem só será executada
se a condição for verdadeira.
A repetição é vista com o uso de um quadro no entorno das mensagens que podem
ser repetidas. A figura indica que existem dois passos que podem ser repetidos
indefinidamente que são: Selecionar Item e adicionarItem, as demais mensagens
seguem o fluxo sem repetição. Nota: o uso deste elemento depende da versão da
ferramenta CASE, pois somente foi implementado na versão 2.0 da UML.
D
en
iz
e
 P
im
en
ta
169
O uso de notas é permitido em qualquer diagrama UML, mas utilize com bom senso para não poluir o
diagrama.
D
en
iz
e
 P
im
en
ta
170
D
en
iz
e
 P
im
en
ta
171
D
en
iz
e
 P
im
en
ta
172
D
en
iz
e
 P
im
en
ta
173
Objetivos do Capítulo 6:
•Visualizar o passo a passo da construção do Diagrama de Atividades.
•Esquematizar o ciclo de vida dos objetos através do Diagrama de Estados.
D
en
iz
e
 P
im
en
ta
174
Neste tópico veremos:
•Os componentes do Diagrama de Atividades
•A confecção do diagrama em partes:
•Identificar os fluxos (atividades)
•Identificar atividades executadas em paralelo
•Identificar a ordem de execução
•Identificar desvios e condições
•Desenhar o diagrama
D
en
iz
e
 P
im
en
ta
175
D
en
iz
e
 P
im
en
ta
176
O desenho acima representa o workflow da disciplina de requisitos retirada do RUP, mapeia as
principais atividades (macro-atividades) executadas nesta disciplina e exibe alguns componentes do
diagrama de atividades:
-Início (ou estado de início)
-Fim (ou estado de parada)
-Separação (ou Bifurcação)
-Junção (ou União)
-Atividade
-Transição
-Decisão (ou Ramificação)
Como informado anteriormente pode-se mapear processos com este diagrama.
D
en
iz
e
 P
im
en
ta
177
Uma ação (ou estado de ação) é a menor porção do código.
D
en
iz
e
 P
im
en
ta
178
D
en
iz
e
 P
im
en
ta
179
Decisão (ou ramificação) especifica caminhos alternativos tomando como base
alguma expressão booleana. Para explicitar qual caminho se segue é utilizada a
condição de guarda.
D
en
iz
e
 P
im
en
ta
180
D
en
iz
e
 P
im
en
ta
181
D
en
iz
e
 P
im
en
ta
182
Atividade e estados juntos podem trazer muita informação ao diagrama, cuidado com
a poluição visual, tenha sempre em mente o objetivo do diagrama que está sendo
desenhado.
D
en
iz
e
 P
im
en
ta
183
No exemplo acima temos o fluxo do processo da liberação de um pedido, as
alterações de estados e as atividades que fazem essas alterações.
Quando há a emissão da cobrança para o cliente o pedido tem seu estado alterado
para “aguardando pagamento”.
D
en
iz
e
 P
im
en
ta
184
Para o exemplo apresentado teremos que desenhar um diagrama de atividades.
D
en
iz
e
 P
im
en
ta
185
Com os fluxos identificados fica mais fácil iniciar o desenho do diagrama, nesta parte
devemos pensar nas atividades que o sistema deverá desenvolver. Ao final desta
etapa devemos descobrir se existe alguma atividade que pode ficar em paralelo com
alguma outra.
D
en
iz
e
 P
im
en
ta
186
Este é o estudo de threading ou de processos que são executados simultaneamente,
identificamos no meio de todos os fluxos levantados se existem atividades que podem
ser desenvolvidas simultaneamente.
Após este passo devemos descobrir qual a ordem de execução das atividades
D
en
iz
e
 P
im
en
ta
187
A ordenação da execução das atividades se torna fácil quando se conhece o negócio
em questão, ainda neste momento podem surgir dúvidas de negócio que devem ser
resolvidas juntamente com o usuário/gestor da informação.
Depois devemos descobrir se no nosso esquema há alguma decisão, se a execução
de uma atividade depende de alguma condição.
D
en
iz
e
 P
im
en
ta
188
Os desvios são as opções de caminhos que podem ser trilhadas no decorrer da
execução das atividades.
Ao término desta identificação dá-se o início do desenho do diagrama.
D
en
iz
e
 P
im
en
ta
189
Não há mistério no desenho do diagrama, a princípio devemos identificar as
atividades, depois as atividades que podem ser colocadas em paralelo e a ordem que
devem ser executadas, em seguida descobrir se há desvios e suas condições. Pronto
o desenho está pronto.
Porque usar a junção e bifurcação ?
A bifurcação do exemplo indica que o ‘Contratar Arquiteto’ e o ‘Adquirir Local’ são
atividades que podem ser simultâneas, inclusive podem ser feitas por recursos
diferentes (processadores ou profissionais).
A junção do exemplo, indica que para que o ‘Desenho do Projeto’ seja iniciado ele
deve esperar que o ‘Contratar Arquiteto’ e o ‘Adquirir Local’ estejam finalizados.
D
en
iz
e
 P
im
en
ta
190
Relembrando a descrição do caso de uso, seus cursos normais e alternativos.
D
en
iz
e
 P
im
en
ta
191
No desenho do diagrama fica fácil visualizar todas as exceções do caso de uso.
Neste exemplo somente foram desenhadas as ações do sistema para facilitar a
legibilidade do diagrama, por outro lado seria mais completo se fossem inseridas as
ações dos atores. Essa decisão deverá ser tomada visando legibilidade e completeza
do entendimento dos fluxos do caso de uso.
D
en
iz
e
 P
im
en
ta
192
D
en
iz
e
 P
im
en
ta
193
Neste tópico veremos:
•Componentes do diagrama
•Máquina de estados
D
en
iz
e
 P
im
en
ta
194
O diagrama de estados visa o estudo do comportamento do objeto. Como os
diagramas na UML são complementares, o diagrama de classe deve ter uma
propriedade para a informação do estado do objeto criado e o diagrama de caso de
uso deve prever a alteração do estado deste objeto nas várias etapas do seu ciclo de
vida.
O diagrama de estados observa o comportamento de uma instância.
D
en
iz
e
 P
im
en
ta
195
D
en
iz
e
 P
im
en
ta
196
D
en
iz
e
 P
im
en
ta
197
D
en
iz
e
 P
im
en
ta
198
Esta divisão é opcional adotada somente por alguns autores.
Compartimento de Nome – local onde conterá o nome do estado.
Compartimento de Transições Internas – lista as ações ou atividades executadas
enquanto o objeto estiver no estado em foco.
As palavras reservadas que aparecem antes das ações na área de transições
internas identificam o evento que é disparado, são elas:
Entry - identifica uma ação que é executada na entrada do estado.
Exit - identifica uma ação que é executada na saída do estado.
Do - identifica uma atividade executada continuamente enquanto o objeto estiver no
estado.
Include – é uma chamada de uma submáquina.
D
en
iz
e
 P
im
en
ta
199
Na transição (a seta entre estados) fica com o nome do evento ou o que foi
responsável na mudança de estado do objeto.
Na alteração do estado de um objeto pode ser necessário executar alguns métodos,
isso é representado através da ação, que também poderá aparecer na transição ou
dentro do estado.
A condição de guarda também será exibida na transição.
D
en
iz
e
 P
im
en
ta
200
Observe que o evento é o que faz com que o objeto mude de estado, seu conceito
está intimamente ligado ao da transição.
D
en
iz
e
 P
im
en
ta
201
A máquina de estados (ou Superestado ou Estado Composto) foi criada para agrupar
estados e facilitar a leitura do diagrama.
D
en
iz
e
 P
im
en
ta
202
D
en
iz
e
 P
im
en
ta
203
Nas figuras exibidas percebemos a facilidade da leitura permitida pelo super estado
(máquina de estados).
Perceba que tanto o vôo aberto quanto lotado passam para a situação fechado,
independente da situação anterior o que faz com que o vôo passe para fechado são
os 10 minutos antes da decolagem. Com esta modelagem uma transição foi
suprimida e o modelo ficou mais legível.
Classe 
Vôo
D
en
iz
e
 P
im
en
ta
204
Este exemplo didático e bem simples auxilia a visão de um desenho mais limpo eclaro com o uso da
máquina de estados. Imagine este desenho sem o super-estado ‘Para frente’ com os sub-estados
mantendo transição com o neutro.
O objetivo principal do agrupamento de estados é facilitar a legibilidade.
D
en
iz
e
 P
im
en
ta
205
D
en
iz
e
 P
im
en
ta
206
No exemplo apresentado teremos que desenhar um diagrama de estados para uma
pesquisa.
D
en
iz
e
 P
im
en
ta
207
Lembre-se existem classes que simplesmente não têm necessidade de estudar seus estados.
D
en
iz
e
 P
im
en
ta
208
Volte ao enunciado e descubra os estado do objeto (Pesquisa).
D
en
iz
e
 P
im
en
ta
209
Na identificação dos eventos temos que buscar as ações que são executadas no
sistema, para a classe em questão, ou seja, temos que identificar quais são as ações
no sistema que alteram o estado da ‘Pesquisa’.
D
en
iz
e
 P
im
en
ta
210
Depois de empregar os passos anteriores o desenho do diagrama se torna muito
fácil.
Lembre-se que o diagrama pode ser enriquecido com outras características do
sistema como a ação, condições de guarda, agrupamento de estados e o
compartimento de transições internas.
D
en
iz
e
 P
im
en
ta
211
O uso do Diagrama de Estados é facultativo, ele só será utilizado quando houver
necessidade de representar os estados de uma classe, é o estudo do ciclo de vida
que um objeto poderá trilhar.
D
en
iz
e
 P
im
en
ta
212
D
en
iz
e
 P
im
en
ta
213
D
en
iz
e
 P
im
en
ta
214
Em um contexto geral percebemos que o diagrama de estados depende do diagrama
de classes e do diagrama de casos de uso e podemos ter mais de um diagrama de
estados por sistema.
Lembramos mais uma vez que os diagramas se completam e conforme vamos
identificando eventos, estados devemos rever o diagrama de classes e casos de uso.
Os diagramas devem estar coerentes.
D
en
iz
e
 P
im
en
ta
215
D
en
iz
e
 P
im
en
ta
216
Objetivos do Capítulo 7:
• Exercitar o aprendizado através da construção dos diagramas de Casos de
Uso, Classe, Seqüência, Atividade e Estado.
D
en
iz
e
 P
im
en
ta
217
Este texto exprime uma idéia do negócio apresentado e pode não suprir todas as suas
dúvidas, portanto fica livre a sua decisão na hora de modelar. O que é importante aqui é
saber apresentar as soluções no desenho dos diagramas e não as regras do negócio.
D
en
iz
e
 P
im
en
ta
218
D
en
iz
e
 P
im
en
ta
219
D
en
iz
e
 P
im
en
ta
220
D
en
iz
e
 P
im
en
ta
221
D
en
iz
e
 P
im
en
ta
222
D
en
iz
e
 P
im
en
ta
223
Exercícios Resolvidos
Cap. 1
1-c; 2-d; 3-d; 4-b; 5-d; 6-a
Cap. 2
Exercício Teórico: 1-b; 2-d; 3-d; 4-a; 5-c
Exercício Prático:
Cap. 3
Votação Eletrônica – Entrada Externa – 9 DER (número (entra e sai conte
apenas uma vez), foto, nome, sigla do partido, cargo, nome vice, foto vice,
ação e mensagem) e 3 ALR (Candidato, Partido e Eleitor) – Média – 4 PFB
Exercício Teórico: 1-a; 2-b; 3-c; 4-b; 5-b; 6-b; 7-b
Exercício Prático:
Cap. 4
Exercício Teórico: 1-c; 2-d; 3-d; 4-b; 5-a
Cap. 5
Parte 1
1-c; 2-c; 3-a; 4-c; 5-d
Parte 2
1-b; 2-c; 3-c; 4-c; 5-b
Descrição Tipo
(ALI/AIE)
DER
(qtd)
RLR
(qtd)
Complexidade
(B – M – A)
Pontos
Agenda Telefônica ALI 2 1 B 7
Configuração ALI 2 1 B 7
Descrição Tipo
(EE/SE/CE)
DER
(qtd)
ALR
(qtd)
Complexidade
(B – M – A)
Pontos
Agenda – InclusãoAgenda EE 4 1 B 3
Agenda – BuscaAgenda CE 4 1 B 3
Agenda – AlteraçãoAgenda EE 4 1 B 3
Agenda – Exclusão de um 
nomeAgenda
EE 3 1 B 3
Agenda – Exclusão de todos EE 2 1 B 3
Configuração – alteração tipos 
de toque
EE 3 1 B 3
Configuração – alteração 
volume de toque
EE 3 1 B 3
Bloqueio/Desbloqueio das 
teclas
EE 2 0 B 3
D
en
iz
e
 P
im
en
ta
224
Este material está registrado na Biblioteca Nacional.
Registro 397.004 - Livro 739 - Folha 164