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

Tópicos Especiais - Qualidade de Software 2008/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ópicos Especiais - Qualidade de Software 2008/2

Tópicos Especiais - Qualidade de Software 2008/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

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 V1 V2 V3 Dicionário de Projeto H2 Diagrama de Classes H3 Diagrama de Estados Diagrama de Seqüência H4 Especificação de Projeto V6 V5 Dicionário de Projeto Diagrama de Classes do Domínio do Problema H5 Tópicos Especiais - Qualidade de Software 2008/2

Tópicos Especiais - Qualidade de Software 2008/2 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

Tópicos Especiais - Qualidade de Software 2008/2 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

Tópicos Especiais - Qualidade de Software 2008/2 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

Tópicos Especiais - Qualidade de Software 2008/2 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

Tópicos Especiais - Qualidade de Software 2008/2 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

Tópicos Especiais - Qualidade de Software 2008/2 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

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

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

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

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. Tópicos Especiais - Qualidade de Software 2008/2

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

Qualidade de Máquinas de Estado 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. Tópicos Especiais - Qualidade de Software 2008/2

Qualidade de Máquinas de Estado 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. Tópicos Especiais - Qualidade de Software 2008/2

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

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

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

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

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

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

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

Diagramas de Seqüência Elementos de Modelo Tipicamente Utilizados: Linha de Vida Mensagem Tópicos Especiais - Qualidade de Software 2008/2

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

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

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

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

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

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

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

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

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

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

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

Tópicos Especiais - Qualidade de Software 2008/2 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