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

Revisões de SoftwareParte 3

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 Funcional: Qualidade de Modelos de

Casos de Uso Modelagem Estrutural: Qualidade de Diagramas

de Classes de Análise


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.


Artefatos Documento de Especificação de Requisitos:

Diagrama de Pacotes (opcional) Diagramas de Casos de Uso Descrições de Casos de Uso

Documento de Especificação de Análise: Diagrama de Pacotes (opcional) Diagramas de Classes Diagramas de Estados (opcional) Diagramas de Seqüência (opcional) Dicionário de Projeto descrevendo classes, atributos e

operações


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


Qualidade de Modelos de Casos de Uso

Modelo de Casos de Uso: Diagramas de Casos de Uso + Descrições de Casos de Uso

Elementos de Modelo: Ator Caso de Uso Associações entre Atores e Casos de Uso Relacionamentos de Generalização / Especialização

entre Atores Relacionamentos entre Casos de Uso

Generalização / Especialização entre Casos de Uso Inclusão Extensão


Qualidade de Modelos de Casos de Uso: Atores

Ator: especifica um papel desempenhado por um usuário ou outro sistema que interage com o sistema em questão, mas que é externo ao mesmo (OMG, 2005).

Avaliando a qualidade: O próprio sistema ou uma parte dele não pode ser um

ator. Um ator só pode ter dois tipos de relacionamentos:

associações com casos de uso, sendo que essas só podem ser binárias.

generalização / especialização com outros atores. Evitar nomes muito gerais (tal como usuário do

sistema), pois não especifica claramente o papel desempenhado pelo ator.


Qualidade de Modelos de Casos de Uso: Casos de Uso

Casos de Uso: são meios de especificar usos requeridos para um sistema, capturando requisitos funcionais.

Um caso de uso é uma especificação de um conjunto de ações realizadas por um sistema, que produz um resultado de valor observável para um ou mais atores ou patrocinadores do sistema (OMG, 2005).

Avaliando a qualidade: Todo caso de uso base deve prover uma funcionalidade

significativa para os usuários do sistema. Se isso não acontecer, o caso de uso não faz sentido.

As ações descritas em um caso de uso devem ser de responsabilidade do sistema em desenvolvimento ou relacionadas à interação de atores com o mesmo.



Um caso de uso representa uma declaração de um comportamento oferecido pelo sistema, sem se referenciar a sua estrutura interna (OMG, 2005).

Avaliando a qualidade: A descrição de um caso de uso deve ser feita usando

conceitos do domínio do problema, sem se preocupar com aspectos computacionais e de implementação.

Os termos usados para designar os conceitos utilizados na descrição de casos de uso devem ser mantidos na fase de análise para facilitar a rastreabilidade.



Um caso de uso pode incluir variações possíveis de seu comportamento básico, tais como comportamentos de exceção e manipulação de erros (OMG, 2005).

Avaliando a qualidade: A descrição de um caso de uso deve separar o fluxo de

eventos principal (normal) dos fluxos de evento alternativos e de exceção.



Cada caso de uso especifica uma unidade de funcionalidade útil que o sistema provê para os usuários. Essa funcionalidade, que é tipicamente iniciada por um ator, deve ser sempre realizada na íntegra para que o caso de uso termine.

Considera-se que o caso de uso foi concluído se, após sua execução, o sistema encontra-se em um estado no qual nenhuma entrada ou ação adicional é esperada, ou em um estado de erro (OMG, 2005).

Avaliando a qualidade: A descrição de um caso de uso deve especificar fluxos

de eventos completos que atendam a metas do usuário.



O comportamento de um caso de uso pode ser descrito por uma especificação, incluindo texto em linguagem natural, pré e pós-condições, diagramas de atividades, diagramas de interação etc. Qual dessas técnicas utilizar depende da natureza do caso de uso, bem como do futuro leitor. Elas podem ser combinadas (OMG, 2005).

Avaliando a qualidade: A descrição de um caso de uso pode especificar mais

de um fluxo de eventos relacionados a uma mesma macro-funcionalidade.

Quando um outro diagrama UML for usado para descrever um caso de uso, técnicas de leitura vertical devem ser aplicadas.


Qualidade de Modelos de Casos de Uso: Generalização/Especialização de Casos de Uso

Uma generalização é um relacionamento taxonômico entre um classificador mais geral e um classificador mais específico (OMG, 2005).

Casos de uso são tipos de classificadores e, portanto, podem ser generalizados / especializados.

Avaliando a qualidade: Quando um caso de uso é uma especialização de outro,

então ele deve prover os mesmos fluxos de eventos principais, possivelmente alterados. Além disso, ele pode prover novos fluxos de eventos principais.

As descrições não devem se repetir. Apenas as porções alteradas ou incluídas devem ser especificadas na descrição do caso de uso especializado.


Qualidade de Modelos de Casos de Uso: Inclusão de Caso de Uso

Relacionamento de Inclusão: define que um caso de uso base contém o comportamento especificado em outro caso de uso.

O comportamento do caso de uso incluído é inserido no comportamento do caso de uso base.

O caso de uso base depende somente do resultado do caso de uso incluído, resultante da execução do mesmo (OMG, 2005).

Avaliando a qualidade: A descrição do caso de uso base não deve fazer

menção a informações ou passos do caso de uso incluído, mas somente à sua chamada e a seu resultado.



O relacionamento de inclusão deve ser usado quando há partes comuns no comportamento de dois ou mais casos de uso. Essa parte comum é, então, extraída em um caso de uso separado, a ser incluído por todos os casos de uso base que tenham essa parte comum. Por conseguinte, o comportamento do caso de uso incluído não é significativo por si só.

O uso principal do relacionamento de inclusão é o reuso de partes comuns e, portanto, o quê está especificado no caso de uso base normalmente não é completo em si, mas dependente das partes incluídas para ser significativo (OMG, 2005).



O caso de uso incluído não é opcional. Ele é sempre requerido para que o caso de uso base execute corretamente (OMG, 2005).

Avaliando a qualidade: O comportamento do caso de uso incluído deve ser

sempre necessário para a realização correta do caso de uso base.

Uma vez que o comportamento do caso de uso incluído vai ser inserido em diversos casos de uso base que o incluem, sua descrição tem de ser compatível com as descrições de todos eles. Além disso, ela deve estar aderente ao formato de uma chamada que retorna um resultado para o caso de uso base prosseguir a sua execução.

Um caso de uso não pode incluir um caso de uso que o inclua direta ou indiretamente.


Qualidade de Modelos de Casos de Uso: Extensão de Caso de Uso

Relacionamento de Extensão: especifica que o comportamento de um caso de uso pode ser estendido pelo comportamento de outro caso de uso, tipicamente suplementar.

É um relacionamento direcionado de um caso de uso de extensão para um caso de uso estendido (caso de uso base), especificando como e quando o comportamento definido no caso de uso de extensão pode ser inserido no caso de uso base (OMG, 2005).

Avaliando a qualidade: O relacionamento de extensão deve ser sempre direcionado

do caso de uso de extensão para o caso de uso estendido (base).



O caso de uso base é definido de forma independente do caso de uso de extensão e é significativo independentemente do caso de uso de extensão.

O comportamento do caso de uso de extensão não necessariamente é significativo por si só. Ele pode definir fragmentos de comportamento que ampliam o comportamento do caso de uso base sob certas condições (OMG, 2005).

Avaliando a qualidade: A extensão não deve especificar um comportamento

crucial para a realização do caso de uso base.



Um mesmo caso de uso de extensão pode estender mais de um caso de uso base.

Quando nenhuma condição é especificada, então a extensão é incondicional (OMG, 2005).

Avaliando a qualidade: Extensões, assim como inclusões, podem ser

incondicionais. Atenção especial deve ser dada a esse fato, pois muitas vezes desenvolvedores assumem que se um comportamento deve ser incondicionalmente adicionado a outro, esse relacionamento deve ser modelado como uma inclusão.



A extensão ocorre em um ou mais pontos de extensão definidos no caso de uso estendido (caso de uso base) (OMG, 2005).

Avaliando a qualidade: A descrição do caso de uso base deve fazer menção

explícita ao ponto de extensão, indicando qual o comportamento do caso de uso de extensão.



Avaliando a qualidade: É uma boa prática modelar os pontos de extensão

explicitamente no diagrama de casos de uso, bem como em que ponto de extensão um caso de uso estendido amplia o comportamento do caso de uso base.

Para casos de uso de extensão com apenas um fluxo de eventos, o nome do ponto de extensão deve ser o nome do próprio caso de uso de extensão.

Para casos de uso de extensão com vários fluxos de eventos, o nome do ponto de extensão deve ser o nome do fluxo de eventos a ser adicionado naquele ponto.


Modelagem Estrutural

A modelagem estrutural visa definir as entidades importantes para um sistema e modelar as estruturas internas capazes de satisfazer os requisitos identificados na especificação de requisitos.

O principal diagrama estrutural da UML usado para esse fim é o diagrama de classes.

Diagramas de classes buscam representar a estrutura estática de um domínio.


Diagrama de Classes Elementos de Modelo tipicamente usados:

Classes Interfaces (design) Atributos

Tipos de dados (design) Visibilidade (design)

Operações Relacionamentos de Generalização / Especialização Relacionamento de Realização de Interface (design) Associações

Multiplicidades Navegabilidades (design) Papéis

Tipos de Associações Agregação (válida apenas para associações binárias) Composição (válida apenas para associações binárias)

Classes de Associação ou Classes Associativas


Modelagem Estrutural: Qualidade de Diagramas de Classes de Análise

Quando produzido na fase de análise (modelagem conceitual), um diagrama de classes não deve introduzir aspectos do domínio da solução (plataforma de implementação), tratando apenas do domínio do problema.

Avaliando a qualidade: As classes do diagrama de classes devem

corresponder a conceitos importantes do domínio do problema, sem considerar aspectos de implementação.

Um diagrama de classes de análise não deve incorporar construções típicas da fase de design.


Qualidade de Diagramas de Classes de Análise: Análise Ontológica

A Análise Ontológica trata do entendimento da natureza dos elementos que existem em um domínio.

A UML não provê construções para diferenciar certos tipos de classes, caracterizando uma imperfeição ontológica (Guizzardi, 2005).

Contudo, a percepção dessas (e outras) distinções pode ajudar na construção de diagramas de classes mais bem formados, tal como na definição de hierarquias de generalização / especialização, na definição de certas associações e na modelagem de papéis.


Análise Ontológica: Classes Propriedades de Classes que ajudam a distinguir

o seu tipo (Guizzardi, 2005): Rigidez: Os objetos que representam instâncias da

classe permanecerão sendo instâncias dessa classe durante toda a sua existência.

Anti-rigidez: Todas as instâncias da classe podem deixar de ser instâncias desse conceito em algum momento de sua existência.

Identidade: A classe possui uma identidade que é única para cada uma das instâncias da classe.

Dependência: Toda instância da classe só existirá se existir uma instância de uma outra classe com a qual a classe da primeira obrigatoriamente se relaciona.


Análise Ontológica: Classes Avaliando a qualidade:

Classes rígidas não podem herdar de classes anti-rígidas.

Uma classe relacionalmente dependente tem de possuir uma associação com outra classe (que representa a condição de restrição de dependência), sendo a multiplicidade mínima >= 1.

Classes sem identidade (misturas ou mixins) têm de ser abstratas.

Classes sem identidade não podem herdar de classes que possuem identidade.


Análise Ontológica: Classes Tipos de Classes Rígidas em OntoUML (Guizzardi,

2005): Tipo (kind): classe rígida, relacionalmente independente

e que possui identidade. Ex.: Animal. Sub-tipo (sub-kind): classe rígida, relacionalmente

independente e que possui identidade, mas essa identidade é dada por um super-tipo que a subjulga. Ex.: Pessoa, subclasse de Animal.

Categoria (category): classe rígida e relacionalmente independente, mas que não possui identidade. É uma mistura (mixin) que agrega um conjunto de propriedades comuns a diferentes tipos/sub-tipos. Ex.: Entidade Racional (generalização de Pessoa e Agente Inteligente).


Análise Ontológica: Classes Tipos de Classes Não Rígidas em OntoUML

(Guizzardi, 2005): Fase (phase): classe anti-rígida e relacionalmente

independente, que possui identidade, dada por um tipo que a subjulga. Ex.: Adulto.

Papel (role): classe anti-rígida e relacionalmente dependente, que possui identidade, dada por um tipo que a subjulga. Ex.: Estudante.

Mistura de Papéis (roleMixin): classe anti-rígida e externamente dependente, que não possui identidade. Mistura (mixin) que agrega um conjunto de propriedades comuns a vários papéis.



Classes rígidas não podem herdar de classes anti-rígidas, logo:

Um tipo / sub-tipo / categoria não pode ser subclasse de um papel, fase ou mistura de papel.

Outras restrições: Um tipo não pode ser subclasse de um sub-tipo. Todo sub-tipo é subclasse de um único tipo. Toda fase é subclasse de um único tipo. Todo papel é subclasse de um único tipo.



Uma classe relacionalmente dependente tem de possuir uma associação com outra classe (que representa a condição de restrição de dependência), sendo a multiplicidade mínima >= 1, logo:

Um papel ou uma mistura de papéis tem de possuir uma associação com outra classe, sendo a multiplicidade mínima >= 1.

Classes sem identidade (misturas ou mixins) têm de ser abstratas, logo:

Categorias e misturas de papéis têm de ser classes abstratas.



Classes sem identidade não podem herdar de classes que possuem identidade, logo:

Categorias e misturas de papéis não podem ser subclasses de tipos, subtipos, fases e papéis.


Análise Ontológica: Relações Relações são entidades que aglutinam outras

entidades (Guizzardi et al., 2008). Tipos de Relações (Guizzardi et al., 2008):

Relações formais: acontecem entre duas ou mais entidades diretamente, sem nenhum outro indivíduo intervindo.

Relações materiais: possuem estrutura material por si próprias.

Para que uma relação material aconteça, uma outra entidade precisa existir para mediar a relação. Essas entidades são denominadas modos relacionais (relators) e são indivíduos com o poder de conectar (mediar) outros indivíduos (Guizzardi et al., 2008).


Análise Ontológica: Relações Avaliando a qualidade:

Relações materiais necessitam de classes representando as entidades mediadoras da relação (modos relacionais – relators).

Muitas vezes essas classes de modos relacionais estão relacionadas a eventos. Ex.: relação “alocado em”, entre Pessoa e Projeto necessita de uma classe de modo relacional Alocação que media a relação entre Pessoa e Projeto, estando essa classe relacionada ao evento Alocação de Pessoa a Projeto.

O uso de classes associativas deve ser feito com cuidado, uma vez que não especifica informações importantes.


Referências OMG, Unified Modeling Language Superstructure,

version 2.0, formal/05-07-04 August 2005. Guizzardi, G., Ontological Foundations for

Structural Conceptual Models, Universal Press, The Netherlands, 2005, ISBN 90-75176-81-3.

Guizzardi, G., Falbo, R.A., Guizzardi, R.S.S., “Grounding Software Domain Ontologies in the Unified Foundational Ontology (UFO): The case of the ODE Software Process Ontology”, Proceedings of the XI Iberoamerican Workshop on Requirements Engineering and Software Environments, Recife, Brazil, 2008.

Documents

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