Revisões de Software
Parte 3
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 Funcional: Qualidade de Modelos de
Casos de Uso
Modelagem Estrutural: Qualidade de Diagramas
de Classes de Análise
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
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ópicos Especiais - Qualidade de Software 2008/2
4
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
5
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
Tópicos Especiais - Qualidade de Software 2008/2
6
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.
Tópicos Especiais - Qualidade de Software 2008/2
7
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.
Tópicos Especiais - Qualidade de Software 2008/2
8
Qualidade de Modelos de Casos de Uso:
Casos de Uso


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.
Tópicos Especiais - Qualidade de Software 2008/2
9
Qualidade de Modelos de Casos de Uso:
Casos de Uso


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.
Tópicos Especiais - Qualidade de Software 2008/2
10
Qualidade de Modelos de Casos de Uso:
Casos de Uso



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.
Tópicos Especiais - Qualidade de Software 2008/2
11
Qualidade de Modelos de Casos de Uso:
Casos de Uso


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.
Tópicos Especiais - Qualidade de Software 2008/2
12
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.
Tópicos Especiais - Qualidade de Software 2008/2
13
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.
Tópicos Especiais - Qualidade de Software 2008/2
14
Qualidade de Modelos de Casos de Uso:
Inclusão de Caso de Uso


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).
Tópicos Especiais - Qualidade de Software 2008/2
15
Qualidade de Modelos de Casos de Uso:
Inclusão de Caso de Uso


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.
Tópicos Especiais - Qualidade de Software 2008/2
16
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).
Tópicos Especiais - Qualidade de Software 2008/2
17
Qualidade de Modelos de Casos de Uso:
Extensão de Caso de Uso



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.
Tópicos Especiais - Qualidade de Software 2008/2
18
Qualidade de Modelos de Casos de Uso:
Extensão de Caso de Uso



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.
Tópicos Especiais - Qualidade de Software 2008/2
19
Qualidade de Modelos de Casos de Uso:
Extensão de Caso de Uso


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.
Tópicos Especiais - Qualidade de Software 2008/2
20
Qualidade de Modelos de Casos de Uso:
Extensão de Caso de Uso

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.
Tópicos Especiais - Qualidade de Software 2008/2
21
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.
Tópicos Especiais - Qualidade de Software 2008/2
22
Diagrama de Classes

Elementos de Modelo tipicamente usados:



Classes
Interfaces (design)
Atributos






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



Tipos de dados (design)
Visibilidade (design)
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
Tópicos Especiais - Qualidade de Software 2008/2
23
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.
Tópicos Especiais - Qualidade de Software 2008/2
24
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.
Tópicos Especiais - Qualidade de Software 2008/2
25
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.
Tópicos Especiais - Qualidade de Software 2008/2
26
Análise Ontológica: Classes

Avaliando a qualidade:




Classes rígidas não podem herdar de classes antirí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.
Tópicos Especiais - Qualidade de Software 2008/2
27
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).
Tópicos Especiais - Qualidade de Software 2008/2
28
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.
Tópicos Especiais - Qualidade de Software 2008/2
29
Análise Ontológica: Classes

Avaliando a qualidade:

Classes rígidas não podem herdar de classes antirí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.
Tópicos Especiais - Qualidade de Software 2008/2
30
Análise Ontológica: Classes

Avaliando a qualidade:

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.
Tópicos Especiais - Qualidade de Software 2008/2
31
Análise Ontológica: Classes

Avaliando a qualidade:

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.
Tópicos Especiais - Qualidade de Software 2008/2
32
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).
Tópicos Especiais - Qualidade de Software 2008/2
33
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.
Tópicos Especiais - Qualidade de Software 2008/2
34
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.
Tópicos Especiais - Qualidade de Software 2008/2
35