Revisões de Software
Parte 4
Ricardo de Almeida Falbo
Tópicos Especiais – Qualidade de Software
2008/2
Departamento de Informática
Universidade Federal do Espírito Santo
Agenda






Técnicas de Leitura de Artefatos do
Desenvolvimento Orientado a Objetos
Modelagem Comportamental: Qualidade de
Diagramas de Estados
Técnicas de Leitura Relativas a Diagramas de
Estados
Modelagem Comportamental: Qualidade de
Diagramas de Seqüência
Técnicas de Leitura de Relativas a Diagramas de
Seqüência
Demais Técnicas de Leitura
Tópicos Especiais - Qualidade de Software 2008/2
2
Técnicas de Leitura de Artefatos do
Desenvolvimento Orientado a Objetos




Técnicas para leitura de artefatos do
desenvolvimento orientado a objetos, tomando
por base uma documentação contendo
diagramas da UML.
Cinco técnicas de Leitura Horizontal.
Seis técnicas de Leitura Vertical.
Orientações para a garantia da qualidade de
Modelos e Diagramas UML.
Tópicos Especiais - Qualidade de Software 2008/2
3
Técnicas de Leitura de Artefatos de
Análise e Projeto Orientados a Objetos
Especificação de
Requisitos
Descrições de Casos
de Uso
H1
Diagrama de
Casos de Uso
V4
Especificação de
Análise
Dicionário de
Projeto
V1
H2
Diagrama de
Classes
V2
H3
V3
Diagrama de
Estados
Diagrama de
Seqüência
H4
Especificação de
Projeto
V6
Dicionário de
Projeto
V5
H5
Diagrama de Classes do
Domínio do Problema
Tópicos Especiais - Qualidade de Software 2008/2
4
Diagramas de Estados



Todo objeto tem um tempo de vida. Na criação,
o objeto nasce; na destruição, o objeto deixa de
existir. Entre esses dois momentos, o objeto
pode atuar, enviando e respondendo mensagens.
Quando o comportamento de um objeto for
variável ao longo do tempo, isto é, seu
comportamento atual depende de seu passado,
é útil especificá-lo por meio de uma máquina de
estados.
Um diagrama de máquina de estados (ou de
forma simplificada diagrama de estados) é uma
especificação de uma máquina de estados (OMG,
2005).
Tópicos Especiais - Qualidade de Software 2008/2
5
Máquina de Estados


Uma máquina de estados especifica as
seqüências de estados pelos quais um objeto
passa durante seu tempo de vida em resposta a
eventos, juntamente com as respostas a esses
eventos (Booch et al., 2006).
É usada para fazer a modelagem do
comportamento de um objeto individual (Booch
et al., 2006).
Tópicos Especiais - Qualidade de Software 2008/2
6
Máquina de Estados


Uma máquina de estados é tipicamente
associada a um classificador (p.ex., casos de uso
e classes), cujas propriedades (p.ex., atributos e
operações de classes) estão disponíveis em
comportamentos da mesma (OMG, 2005).
Normalmente, uma máquina de estados envolve
a especificação do tempo de vida das instâncias
de uma classe, um caso de uso ou um sistema
inteiro (Booch et al., 2006).
Tópicos Especiais - Qualidade de Software 2008/2
7
Máquinas de Estados


Ainda que seja possível aplicar máquinas de
estado para modelar o comportamento de um
caso de uso, na maioria das vezes, interações
são usadas para esse fim (Booch et al., 2006).
Nestas diretrizes para avaliação da qualidade de
artefatos do desenvolvimento orientado a
objetos, considerar-se-á apenas máquinas de
estados comportamentais descrevendo o tempo
de vida de instâncias de uma classe.
Tópicos Especiais - Qualidade de Software 2008/2
8
Máquinas de Estados

Elementos de Modelo Tipicamente Utilizados:






Estado, Pseudo-estado e Vértice
Transição
Evento
Restrição de Guarda
Ação
Atividade
Tópicos Especiais - Qualidade de Software 2008/2
9
Máquinas de Estados



Quando o comportamento de um objeto depende
de seu passado, é importante definir os estados
pelos quais o objeto pode passar.
O objeto deve ser capaz de responder a
eventos.
Quando um evento é detectado e enviado, ele
pode resultar na habilitação de uma ou mais
transições. Mas apenas uma pode ser
deflagrada. Neste caso, restrições de guarda são
avaliadas para definir qual transição deflagrar.
Tópicos Especiais - Qualidade de Software 2008/2
10
Máquinas de Estado - Conceitos



Vértice: É uma abstração de um nó em um grafo
de máquina de estados, ou seja, é o super-tipo
de estados e pseudo-estados. Pode ser a origem
ou o destino de um número qualquer de
transições.
Estado: Uma situação invariável (usualmente
implícita) que se mantém durante um certo
tempo no ciclo de vida de um objeto.
Um estado pode ser simples, quando não possui
sub-estados, ou composto. Neste último caso,
pode ter uma máquina de estados aninhada,
quando é denominado estado de sub-máquina.
Tópicos Especiais - Qualidade de Software 2008/2
11
Máquinas de Estado - Conceitos


Pseudo-estado: É uma abstração que inclui
diferentes tipos de vértices transientes (isto é,
transitórios, presentes por um curto espaço de
tempo).
Tipos de Pseudo-estados:



Pseudo-estado inicial: indica o local de início padrão
para uma máquina de estados;
Pseudo-estado terminado (terminate): indica a
destruição do objeto e é equivalente à invocação de
uma ação de destruição do objeto;
Pseudo-estado de escolha (choice), Pseudo-estado de
bifurcação (fork), Pseudo-estado de união (join) etc.
Tópicos Especiais - Qualidade de Software 2008/2
12
Máquinas de Estado - Conceitos




Transição: Relacionamento direcionado entre um
vértice de origem e um vértice destino.
Evento: É a ocorrência de um estímulo capaz de
ativar uma transição de estado.
Ação: É uma execução atômica de
funcionalidade, considerada instantânea, ou
seja, que não pode ser interrompida por
eventos.
Atividade: É uma execução não atômica de
funcionalidade, que leva um certo tempo para
ser realizada e que pode ser interrompida por
eventos.
Tópicos Especiais - Qualidade de Software 2008/2
13
Qualidade de Máquinas de Estado


Vértice: um nó em um grafo de máquina de
estados.
Avaliando a qualidade:


Todo vértice deve ter, pelo menos, uma transição
chegando ou partindo dele.
Vértices (com exceção de estados finais e do pseudoestado inicial) devem ter, pelo menos, uma transição
chegando e uma partindo dele.
Tópicos Especiais - Qualidade de Software 2008/2
14
Qualidade de Máquinas de Estado




Estado: Uma situação invariável (usualmente
implícita) que se mantém durante um certo
tempo no ciclo de vida de um objeto.
Essa situação invariável pode representar uma
situação estática, tal como um objeto esperando
a ocorrência de um evento, ou dinâmica, tal
como uma atividade sendo realizada.
Um estado possui, dentre outros: nome,
comportamento de estado (atividade realizada
enquanto o objeto permanecer nesse estado).
Avaliando a qualidade:

Quando um estado representar uma situação dinâmica,
então o mesmo deve possuir uma atividade.
Tópicos Especiais - Qualidade de Software 2008/2
15
Qualidade de Máquinas de Estado



Estado Final: Um tipo especial de estado que
indica que a máquina de estados (ou submáquina) como um todo foi concluída.
Indica um estado que, quando atingido, não
poderá mais ser alterado.
Avaliando a qualidade:



Um estado final não pode ter uma transição partindo
dele. Por conseguinte, deve ter uma transição chegando
nele.
Não pode ter comportamento associado.
Não pode ter sub-estados.
Tópicos Especiais - Qualidade de Software 2008/2
16
Qualidade de Máquinas de Estado


Pseudo-estado Inicial: indica o local de início
padrão para uma máquina de estados ou subestado.
Avaliando a qualidade:


Um pseudo-estado inicial não pode ser destino de uma
transição. Por conseguinte, deve ter pelo menos uma
transição que se origina nele.
Toda máquina de estados (ou sub-máquina) deve ter
um e somente um pseudo-estado inicial.
Tópicos Especiais - Qualidade de Software 2008/2
17
Qualidade de Máquinas de Estado



Pseudo-estado Terminado: indica a destruição do
objeto.
Uma máquina de estados especifica as
seqüências de estados pelos quais um objeto
passa durante seu tempo de vida.
Avaliando a qualidade:

Um evento que provoca a destruição do objeto não
conduz a um estado do objeto, pois o objeto “morre” e,
portanto, o pseudo-estado terminado deve ser
empregado quando se quiser explicitar essa situação.
Estados em que o objeto efetivamente não existe mais,
tal como “excluído”, não fazem sentido em uma
máquina de estados.
Tópicos Especiais - Qualidade de Software 2008/2
18
Qualidade de Máquinas de Estado

Transição: Relacionamento direcionado entre um
vértice de origem e um vértice destino.
Notação: evento [guarda] / ação

Avaliando a qualidade:



Transições partindo da mesma origem e ativadas pelo
mesmo evento devem ter condições de guarda
diferentes.
Um estado do qual parte uma transição que não
especifica um evento de ativação (transição de parada
ou de conclusão) deve especificar obrigatoriamente um
comportamento de estado (atividade). A transição de
parada é iniciada implicitamente quando seu estado de
origem completa a atividade.
Tópicos Especiais - Qualidade de Software 2008/2
19
Técnicas de Leitura Relativas a Diagramas
de Estado


V2 – Diagrama de Estados x Descrições de Casos
de Uso
H3 – Diagrama de Estados x Diagrama de
Classes de Análise
Tópicos Especiais - Qualidade de Software 2008/2
20
V2 – Diagrama de Estados x Descrições
de Casos de Uso


Um evento em uma máquina de estados
representa a ocorrência de um estímulo capaz
de ativar uma transição de estado.
Em uma máquina de estados de alto nível,
desenvolvida na fase de análise, um estímulo
capaz de ativar uma transição de estados
corresponde tipicamente à ocorrência de um
caso de uso (ou de um fluxo de eventos de um
caso de uso, quando o caso de uso especificar
mais de um fluxo de eventos em seu curso
normal).
Tópicos Especiais - Qualidade de Software 2008/2
21
V2 – Diagrama de Estados x Descrições
de Casos de Uso

Assim, os seguintes aspectos devem ser
verificados quando da aplicação desta técnica:


Os eventos associados a transições entre estados em
um diagrama de estados devem corresponder a fluxos
de eventos e/ou casos de uso em uma descrição de
casos de uso.
Quando pertinente, a descrição de caso de uso
correspondente deve fazer uma menção explícita à
transição para o novo estado.
Tópicos Especiais - Qualidade de Software 2008/2
22
H3 – Diagrama de Estados x Diagrama de
Classes de Análise


Um diagrama de estados deve estar relacionado
a uma classe modelada no diagrama de classes.
A classe correspondente no diagrama de classes
deve conter atributos e/ou operações capazes
de indicar todos os estados pelos quais um
objeto da mesma pode passar.


Se todos os estados de uma máquina de estado são
computáveis, a correspondente classe não necessita de
um atributo “estado”.
Se algum dos estados da máquina de estados não
puder ser computado, a correspondente classe deve
ter um atributo “estado”.
Tópicos Especiais - Qualidade de Software 2008/2
23
Diagramas de Interação



Diagramas de interação são usados para
modelar aspectos dinâmicos de sistemas. Na
maioria das vezes, isso envolve a modelagem de
instâncias concretas ou prototípicas de classes,
juntamente com as mensagens trocadas por
elas, tudo isso no contexto de um cenário que
ilustra um comportamento (Booch et al., 2006).
Diagramas de Seqüência são o tipo mais comum
de diagramas de interação (OMG, 2005).
Diagramas de seqüência enfocam a troca de
mensagens entre objetos, dando ênfase à
ordenação temporal das mesmas (Booch et al.,
2006).
Tópicos Especiais - Qualidade de Software 2008/2
24
Diagramas de Seqüência

Elementos de Modelo Tipicamente Utilizados:


Linha de Vida
Mensagem
Tópicos Especiais - Qualidade de Software 2008/2
25
Técnicas de Leitura Relativas a Diagramas
de Seqüência


V3 – Diagrama de Seqüência x Descrições e
Diagrama de Casos de Uso
H4 – Diagrama de Seqüência x Diagrama de
Classes de Análise
Tópicos Especiais - Qualidade de Software 2008/2
26
H4 – Diagrama de Seqüência x Diagrama
de Classes de Análise



Todos as linhas de vida em um diagrama de
seqüência devem ter a indicação de a qual
classe pertencem. Essas classes devem estar
modeladas no diagrama de classes.
Para cada mensagem enviada a uma linha de
vida em um diagrama de seqüência deve haver
uma operação definida (com mesma assinatura)
na correspondente classe.
Quando uma mensagem enviada a uma linha de
vida corresponder a uma operação construtora
(criação) na classe, a notação correspondente
deverá ser usada no diagrama de seqüência,
dando início à linha de vida.
Tópicos Especiais - Qualidade de Software 2008/2
27
H4 – Diagrama de Seqüência x Diagrama
de Classes de Análise


Quando uma mensagem enviada a uma linha de
vida corresponder a uma operação destrutora
(exclusão) na classe, a notação correspondente
deverá ser usada no diagrama de seqüência,
encerrando a linha de vida.
Quando retornos de mensagens forem
especificados em um diagrama de seqüência, os
mesmos devem corresponder aos respectivos
retornos das operações correspondentes no
diagrama de classes
Tópicos Especiais - Qualidade de Software 2008/2
28
V3 – Diagrama de Seqüência x Descrições
e Diagrama de Casos de Uso


Um diagrama de seqüência deve mostrar as
interações entre linhas de vida realizadas no
contexto de um fluxo de eventos de um caso de
uso, modelado em um diagrama de casos de
uso e descrito em uma descrição de casos de
uso. De maneira geral, cursos alternativos não
devem ser mostrados ou, se necessário modelálos, isso não deve ser feito no mesmo diagrama
de seqüência.
A seqüência de interações entre linhas de vida
em um diagrama de seqüência deve estar
consistente com a descrição do caso de uso
correspondente.
Tópicos Especiais - Qualidade de Software 2008/2
29
V3 – Diagrama de Seqüência x Descrições
e Diagrama de Casos de Uso

Quando um ator estiver envolvido no fluxo de
eventos do caso de uso sendo modelado por um
diagrama de seqüência, então esse ator deve
ser consistente com o ator modelado no
diagrama de casos de uso.
Tópicos Especiais - Qualidade de Software 2008/2
30
Demais Técnicas de Leitura





H2 – Dicionário de Projeto x Diagrama de
Classes: Fase de Análise
H5 – Dicionário de Projeto x Diagrama de
Classes: Fase de Design
V4 – Dicionário de Projeto x Descrições de Casos
de Uso
V5 – Diagrama de Classes: Análise x Design
(Domínio do Problema)
V6 – Dicionário de Projeto: Análise x Design
Tópicos Especiais - Qualidade de Software 2008/2
31
V4 – Dicionário de Projeto x Descrições de
Casos de Uso

Quando uma descrição de caso de uso contiver
uma definição de um conceito mapeado em uma
classe ou atributo, a definição da correspondente
classe ou atributo no dicionário de projeto deve
ser consistente com a definição na descrição de
caso de uso.
Tópicos Especiais - Qualidade de Software 2008/2
32
H2 – Dicionário de Projeto x Diagrama de
Classes: Fase de Análise



Para cada classe existente no diagrama de classes deve
haver uma entrada no dicionário de projeto, associada a
uma descrição sucinta da mesma.
Todos os atributos e operações apresentados no diagrama
de classes devem estar enumerados e sucintamente
descritos na entrada do dicionário de projeto referente à
correspondente classe.
Restrições de integridade não passíveis de registro pela
notação da UML devem ser explicitamente declaradas no
dicionário de projeto. As classes, associações e atributos
envolvidos em uma restrição de integridade devem estar
consistentes com o diagrama de classes
Tópicos Especiais - Qualidade de Software 2008/2
33
H5 – Dicionário de Projeto x Diagrama de
Classes: Fase de Design

Idem H2 e mais:


Os tipos de dados indicados para parâmetros e tipos
de retorno de operações e para atributos devem ser
consistentes em ambos os artefatos e consistentes
com a linguagem de programação escolhida como
plataforma de implementação ou com utilitários /
frameworks adotados no projeto.
Quando não for possível identificar um tipo de dado
para um atributo, então uma nova classe deve ser
criada no diagrama de classes de design.
Tópicos Especiais - Qualidade de Software 2008/2
34
V5 – Diagrama de Classes: Análise x Design
(Domínio do Problema)


As classes da fase de análise devem estar mapeadas no
correspondente diagrama de classes de design. De
maneira geral, esse mapeamento deve ser em uma
classe, ainda que possam ocorrer casos em que uma
classe deixa de existir na fase de projeto.
Atributos de uma classe de análise devem estar
mapeados no correspondente diagrama de classes de
projeto. De maneira geral, esse mapeamento deve ser em
um atributo da classe correspondente. Contudo, é
bastante comum que um elemento tratado como atributo
na fase de análise dê origem a uma nova classe na fase
de projeto. Neste caso, a nova classe criada na fase de
projeto deve estar associada à classe da qual o atributo
fazia parte no diagrama de análise. Além disso, as
multiplicidades da nova associação devem ser
consistentes com a multiplicidade do atributo.
Tópicos Especiais - Qualidade de Software 2008/2
35
V6 – Dicionário de Projeto: Análise x
Design


As definições de classes, atributos e operações
que se repetem nas fases de análise e design
devem estar consistentes nos respectivos
dicionários de projeto.
Novas classes, operações e atributos, presentes
apenas na fase de design devem estar descritas
no dicionário de projeto da fase de design.
Tópicos Especiais - Qualidade de Software 2008/2
36
Referências


OMG, Unified Modeling Language
Superstructure, version 2.0, formal/05-07-04
August 2005.
Booch, G., Rumbaugh, J., Jacobson, I., UML Guia
do Usuário, 2a edição, Editora Campus, 2006.
Tópicos Especiais - Qualidade de Software 2008/2
37