Revisões de Software Parte 4 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal

Revisões de SoftwareParte 4

Ricardo de Almeida Falbo

Tópicos Especiais – Qualidade de Software 2008/2

Departamento de InformáticaUniversidade Federal do Espírito Santo

Tópicos Especiais - Qualidade de Software 2008/2 2

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é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écnicas de Leitura de Artefatos de Análise e Projeto Orientados a Objetos

Diagrama de Casos de Uso

Descrições de Casos de Uso

Especificação de Requisitos

Especificação de Análise

Diagrama de Classes

Dicionário de Projeto

Diagrama de Seqüência

Diagrama de Estados

Especificação de Projeto

Diagrama de Classes do Domínio do Problema

Dicionário de Projeto

H1

H2 H3

H4

H5

V1 V2 V3

V4

V5V6


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).


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).


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).


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.


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


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.


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.


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.


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.


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 pseudo-

estado inicial) devem ter, pelo menos, uma transição chegando e uma partindo dele.



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.



Estado Final: Um tipo especial de estado que indica que a máquina de estados (ou sub-má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.



Pseudo-estado Inicial: indica o local de início padrão para uma máquina de estados ou sub-estado.

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.



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.



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é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



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).



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.


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”.


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).


Diagramas de Seqüência Elementos de Modelo Tipicamente Utilizados:

Linha de Vida Mensagem


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



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.



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



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.



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.


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


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.


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


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.


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.


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.


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.

Documents

Revisões de Software Parte 4 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal