Revisões de Software Parte 3

1. Revisões de SoftwareParte 3 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do Espírito Santo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30. Análise Ontológica: Classes • Avaliando a qualidade: • 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. Tópicos Especiais - Qualidade de Software 2008/2

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

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

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

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

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