ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO SILVANO NOGUEIRA BUBACK ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Vitória

2 SILVANO NOGUEIRA BUBACK ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Monografia apresentada à Universidade Federal do Espírito Santo como requisito parcial para obtenção do título de Bacharel em Ciência da Computação, na área de concentração de Sistemas de Informação. Orientador: Ricardo de Almeida Falbo Vitória Outubro,

3 Silvano Nogueira Buback ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Aprovada em 22 de outubro de COMISSÃO EXAMINADORA Prof. Ricardo de Almeida Falbo, D.Sc. Orientador Prof. Davidson Cury, D.Sc. Prof. Julio César Nardi, M.Sc. 3

4 Agradecimentos principalmente para Deus, pois sem ele nada faria sentido. Aos meus pais, pois deles tive todo o apoio necessário para chegar até aqui. Ao Falbo, pela orientação e paciência. 4

5 RESUMO ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Silvano Nogueira Buback Outubro de 2007 Orientador: Prof. Ricardo de Almeida Falbo A necessidade cada vez mais freqüente por softwares e estes cada vez mais complexos trazem desafios aos engenheiros de software, principalmente no que diz respeito à manutenibilidade desses sistemas. A atividade de documentação visa apoiar a manutenibilidade dos sistemas, porém, para reduzir custos e compensar atrasos, principalmente da fase de desenvolvimento, a documentação é colocada em segundo plano, reduzindo a qualidade do software construído e aumentando o custo da manutenção. O uso de uma ferramenta que apóie a geração dos documentos pode tornar a atividade de documentação mais rápida, além de facilitar a atualização quando tais documentos são alterados. Ainda, a criação de modelos de documento facilita a padronização dos documentos de uma corporação. Neste trabalho foi construída a ferramenta ODEDOC, uma ferramenta de apoio à documentação para o ambiente ODE (Ontology-based software Development Environment). É apresentado como a ferramenta foi construída e mostrado como ela pode facilitar a geração e atualização dos documentos pelo uso de modelos de documentos. Palavras chave: Documentação, Modelos de Documento, Ambiente de Desenvolvimento de Software. 5

6 SUMÁRIO Capítulo 1 - Introdução Objetivo Metodologia Capítulo 2 - Automatização do Processo e Documentação CASE I-CASE Framework de Integração Problemas relacionados à integração Ambientes de Desenvolvimento de Software O Ambiente ODE Documentação de Software Capítulo 3 - Especificação de Requisitos Requisitos Funcionais Caso de Uso Editar Modelo de Documento Caso de Uso Editar Modelo de Seção Caso de Uso Editar Documento Formatado Caso de Uso Editar Seção Caso de Uso Gerar Documento Formatado Especificação de Requisitos Não Funcionais Manutenibilidade Usabilidade Capítulo 4 - Análise Modelo de Classes Pacote Controle Pacote Conhecimento Pacote Documentacao Modelagem comportamental Capítulo 5 - Projeto Plataforma de implementação Arquitetura Pacote Conhecimento.documentacao

7 5.3.1 Pacote cdp Pacote cgd Pacote cgt Pacote cih Pacote cci Pacote Ode.documentacao Pacote cdp Pacote cgd Pacote cgt Pacote cih Pacote cci Implementação Gerar Documento Formatado Testes Capítulo 6 - Conclusões e Perspectivas Futuras Conclusões Perspectivas futuras

8 INDÍCE DE FIGURAS Figura Arquitetura Conceitual de ODE Figura Ontologia de Artefato (NUNES et al., 2004) Figura Ontologia de Documentos de Software Figura Diagrama de Casos de Uso Figura Diagrama de pacotes Figura Diagrama de classes parcial do pacote Ode.ControleProcesso Figura Diagrama de classes do pacote Ode.Conhecimento.Documentacao Figura Diagrama de classes do pacote Ode.Documentacao Figura 4.6 Caso de Uso Exportar Documento Figura Arquitetura em camadas Figura 5.2 Comparação entre modelo MVC e o modelo adotado no Ode Figura Dependência de pacotes de todo o sistema Figura Pacote Conhecimento.documentacao.cdp Figura Pacote Conhecimento.documentacao.cgd Figura Pacote Ode.Conhecimento.Documentacao.Cgt Figura Diagrama de classes do pacote ode.conhecimento.documentacao.cih Figura Janela de seleção dos modelos de documentos Figura Janela de edição dos dados do modelo de documento Figura Janela de edição dos dados do modelo de seção Figura Diagrama de classes do pacote ode.conhecimento.documentacao.cci Figura Pacote documentacao.cdp Figura Pacote documentacao.cgd Figura Pacote documentacao.cgt Figura Diagrama de classes do pacote documentacao.cih Figura Janela de edição dos dados do documento formatado e das seções Figura Diagrama de classes do pacote ode.conhecimento.documentacao.cci

9 Capítulo 1 - Introdução A documentação de software tem a finalidade de comunicar informações sobre o sistema de software ao qual ela pertence (FORWARD, 2002). Em outras palavras, documentar é comunicar. Porém a comunicação informal, essencialmente baseada em palavras, não é suficiente. Além da facilidade de ocorrerem distorções na compreensão, termo popularmente conhecido como telefone sem fio, ela não é capaz de resistir ao tempo e não é prática quando a quantidade de pessoas envolvidas no projeto é muito alta ou quando o mesmo tem rotatividade alta. Por isto, um processo formal de documentação se faz necessário. Assim, a documentação assume um papel imprescindível no processo de desenvolvimento de software, visto que a mesma está presente em todas as fases do ciclo de vida do software (PRESSMAN, 2002). Como a demanda por software cresce continuamente, principalmente no que diz respeito a problemas que pedem soluções mais complexas, muitas vezes o trabalho de se documentar torna-se deveras oneroso, sendo usualmente posto de lado em detrimento a outras atividades, tal como a codificação. Contudo, o engenheiro de software deve possuir em mente que, sem uma documentação consistente e detalhada, é praticamente impossível garantir a manutenibilidade. 1.1 Objetivo O objetivo deste trabalho é desenvolver uma ferramenta de apoio à documentação que possa auxiliar na geração da documentação do projeto. O objetivo não é somente gerar a primeira documentação, mas sim auxiliar na manutenção da mesma, permitindo que as alterações feitas no projeto possam ser refletidas nos documentos. Ainda, é fundamental que a geração de documentos seja integrada ao ambiente ODE (Ontology-based software Development Environment) (FALBO et al., 2003), o Ambiente de Desenvolvimento de Software (ADS) em desenvolvimento no Laboratório de Engenharia de Software da Universidade Federal do Espírito Santo (LabES). A integração da ferramenta de apoio à 9

10 documentação a ODE vai permitir que as várias ferramentas do ambiente possam utilizá-la, evitando a construção de soluções isoladas de documentação, o que pode comprometer a integração de ferramentas. Como diferencial em relação aos outros dois trabalhos de pesquisa sobre documentação desenvolvidos para o ODE (SOARES, 2002) (SILVA, 2004), este trabalho tem por objetivo tornar a documentação um processo simples de ser feito, não sendo necessários conhecimentos sobre XML, HTML ou qualquer outra tecnologia. O objetivo é que o gerente de documentação conheça apenas o ADS ODE. 1.2 Metodologia A metodologia adotada no desenvolvimento deste trabalho pode ser dividida em três fases: revisão bibliográfica sobre ferramentas CASE e ADS, definição do escopo do trabalho e desenvolvimento. Ainda na fase de revisão bibliográfica foi delimitado o escopo inicial do trabalho, porém, esse escopo original incluía também a persistência de artefatos em XML para apoiar a ferramenta de gerência de configuração (NUNES, 2005). Na fase de definição do escopo, decidiu-se abandonar essa idéia, concentrando a atenção deste trabalho apenas na documentação de artefatos produzidos internamente a ODE. A motivação para retirar a persistência de artefatos em XML surgiu da separação entre a documentação e a gerência de configuração. A geração dos artefatos em XML permitia atender às duas soluções, porém não atendia de forma razoável a nenhuma das duas. Na documentação, o uso do artefato em XML facilitava a leitura dos dados, porém exigia a construção das folhas de estilo para gerar a apresentação, uma tarefa que exigia um conhecimento técnico sobre XML e tecnologias relacionadas. Na gerência de configuração, as versões antigas dos artefatos não podiam ser manipuladas de forma transparente pelas ferramentas, impedindo que dois usuários fossem capazes de visualizar, através da ferramenta que as gerou, duas versões distintas de um mesmo artefato. 10

11 1.3 Organização da monografia Além deste capítulo, esta monografia contém mais cinco capítulos, a saber: Capítulo 2 Automatização do Processo e Documentação: neste capítulo discute-se a evolução das ferramentas CASE até os se chegar aos ADSs. Também é enfatizada a importância da documentação de software, além de uma breve apresentação do ADS ODE; Capítulo 3 Especificação de Requisitos: neste capítulo são apresentados os requisitos funcionais e não-funcionais para o desenvolvimento da ferramenta de apoio à documentação; Capítulo 4 Análise: neste capítulo é apresentada a modelagem de análise da aplicação, com diagramas de classes e de seqüência; Capítulo 5 Projeto: é apresentado o projeto da ferramenta, levando em consideração os aspectos tecnológicos e requisitos. Também neste capítulo são descritas as estratégias de implementação e testes; Capítulo 6 Conclusões e Perspectivas Futuras: neste capítulo é explicado como este trabalho poderá ajudar na atividade de documentação além de melhorias e trabalhos futuros que poderão surgir. 11

12 Capítulo 2 - Automatização do Processo e Documentação Há um provérbio árabe que diz: Conheces um trabalhador pelas tuas ferramentas. Um engenheiro de software, hoje, conhece bem a aplicação desse ditado. Com softwares cada vez mais complexos, prazos mais curtos e a necessidade de custos menores, em função de um mercado cada vez mais competitivo, o desenvolvimento de software tornou-se uma tarefa árdua. Levantar requisitos, gerar documentação, acompanhar cronograma, gerenciar riscos, codificar, testar, implantar são algumas das atividades presentes em qualquer ciclo de desenvolvimento de software que se tornaram praticamente impossíveis de realizar sem o uso de ferramentas adequadas. Neste capítulo examinamos a evolução das ferramentas CASE (Computer-Aided Software Engineering) e a necessidade da documentação de software, terminando com a apresentação do projeto no qual a ferramenta desenvolvida por este trabalho está inserida 2.1 CASE Existem muitas definições para CASE. Segundo (PRESSMAN, 2002), CASE é uma ferramenta de software apoiada por computador, que assiste gerentes e profissionais de engenharia de software em toda atividade associada com o processo de software. Ferramentas CASE automatizam as atividades de gestão de projetos, gerenciam todos os produtos de trabalho produzidos ao longo do processo e assistem os engenheiros em seu trabalho de análise, projeto, codificação e teste. Já o Instituto de Engenharia de Software (Software Engineering Institute SEI) (SEI, 2007) define CASE de uma forma bem direta: CASE é o apoio do computador no processo de desenvolvimento de software. Essencialmente, a definição do SEI é mais ampla, não restringindo o conceito de CASE apenas a software. Em (PRESSMAN, 2002) foi criada uma taxonomia para essas ferramentas, utilizando como critério a função à qual ela é aplicada. A seguir temos uma lista dos grupos de ferramentas: 12

13 Ferramentas de engenharia de processos de negócio; Ferramentas de modelagem e gestão de processo; Ferramentas de planejamento de projeto; Ferramentas de análise de riscos; Ferramentas de gestão de projetos; Ferramentas de rastreamento de requisitos; Ferramentas de métricas e gestão; Ferramentas de documentação; Ferramentas de software básico; Ferramentas de garantia da qualidade; Ferramentas de gestão de bases de dados; Ferramentas de gestão de configuração de software; Ferramentas de análise e projeto; Ferramentas de prototipação / simulação; Ferramentas de projeto e desenvolvimento de interfaces; Ferramentas de programação; Ferramentas de desenvolvimento Web; Ferramentas de integração e testes; Ferramentas de análise estática; Ferramentas de análise dinâmica; Ferramentas de gestão de testes; Ferramentas de teste cliente/servidor; Ferramentas de reengenharia; Apesar da evolução permanente dessas ferramentas, elas não substituem práticas confiáveis de engenharia de software. Elas devem ser utilizadas apenas para complementá-las. Sem um processo de software estabelecido, métodos de engenharia de software e qualidade aprendidos, o uso dessas ferramentas CASE pode vir a prejudicar o bom andamento do projeto, tornando-o burocrático e confuso (PRESSMAN, 2002). 13

14 2.2 I-CASE As etapas de desenvolvimento de software são todas interligadas. Os métodos utilizados para realizar os testes, ao final do processo de desenvolvimento, estão intimamente ligados aos requisitos colhidos no início do projeto. Isso torna necessária uma integração muito ampla por parte das ferramentas CASE. Ferramentas isoladas são muito úteis em determinadas etapas, porém os resultados obtidos pela integração podem ser muito maiores. À ferramenta CASE integrada dá-se o nome de I-CASE (Integrated CASE) (PRESSMAN, 2002). De fato, a integração de ferramentas não é uma tarefa muito simples de ser feita, principalmente, considerando que, apesar do processo de desenvolvimento de software ser todo integrado, significados diferentes são atribuídos às informações durante cada etapa do desenvolvimento. Uma ferramenta CASE totalmente integrada deve refletir todas as peculiaridades do processo de desenvolvimento, enfatizando as necessidades de cada etapa. Apesar do significado que cada informação possui para determinada ferramenta, estas não podem perder o significado global da informação. Por exemplo, um diagrama de classes é feito a partir dos requisitos levantados do sistema. A partir dele pode-se derivar o modelo relacional. Porém, se um requisito a mais for considerado, este pode, por exemplo, implicar na adição de um atributo em alguma classe. O atributo em questão deve ser adicionado ao código fonte e, também, deve ser propagado para o modelo relacional. Apesar dos modelos serem aparentemente diferentes, todos fazem parte do contexto do software que está sendo desenvolvido. As alterações feitas em algum dos modelos têm impacto em muitos outros Framework de Integração Em relação à integração, há dois pontos de visão distintos: o ambiente do ponto de vista do usuário e o ambiente do ponto de vista do construtor. O ambiente do usuário é voltado para interface. Este quer ver o quanto bem integrado está às ferramentas. Já o construtor de ferramentas, preocupa-se 14

15 com o quão fácil é integrar uma ferramenta ao ambiente (THOMAS et al., 1992). De acordo com o modelo de referência proposto em (THOMAS et al., 1992), há quatro dimensões de integração: Integração de dados: é suportada pelo repositório e serviços de integração de dados; Integração de controle: é suportada pela gerência de processos e serviços de mensagens; Integração de apresentação: é suportada pelos serviços de interface com o usuário; Integração de processo: garante que a ferramenta interage efetivamente no apoio a um processo definido. Integração de dados A informação manipulada pelas ferramentas inclui dados persistentes e não-persistentes (que não sobrevivem após a execução das ferramentas e que são compartilhados e trocados entre elas). O objetivo é manter a informação consistente, independentemente de quantas partes estão sendo operadas e transformadas pelas ferramentas (THOMAS et at., 1992). Integração de Controle Para ferramentas compartilharem funcionalidades, elas precisam ser capazes de comunicar as operações que devem ser executadas. Como as operações requerem dados, as ferramentas também devem comunicar ou referenciar dados. Neste contexto, a integração de controle complementa a integração de dados. Integração de dados diz respeito à representação dos dados, conversão e tarefas de armazenamento. Integração de controle diz respeito à transferência, controle e compartilhamento de serviços (THOMAS et at., 1992). Integração de Apresentação O objetivo da integração de apresentação é aumentar a eficiência e a efetividade da interação do usuário com o ambiente, reduzindo o esforço cognitivo (THOMAS et at., 1992). Ela diz respeito à forma como os dados são 15

16 apresentados e os recursos acessados. A uniformização da apresentação torna o aprendizado de ferramentas novas muito mais rápido e fácil Integração de Processos O objetivo da integração de processo é garantir que as ferramentas interagem de forma eficaz com base em um processo definido. Uma ferramenta incorpora um conjunto de concepções sobre o processo que pode ser usado. Duas ferramentas são bem integradas em relação ao processo se suas concepções são consistentes (THOMAS et at., 1992) Problemas relacionados à integração A maior parte das pesquisas e desenvolvimento de ferramentas CASE integradas está focada na infra-estrutura e mecanismos para integração, como funcionalidades de usuários e mecanismos de troca de dados entre as ferramentas. Não há tantas pesquisas referentes à semântica dos dados, sendo esta o objetivo final da integração: integrar ferramentas sem que elas percam a semântica da informação que está sendo manipulada. Também há problemas de muitas ferramentas CASE não terem sido implementadas em uma arquitetura em que a integração fosse possível. Desta forma, seria necessário remodelar toda ferramenta, o que é, na maioria das vezes, inviável para os negócios da empresa. Questões de estratégia por parte das empresas também impedem a integração real. Muitas empresas já possuem, por meio de suas ferramentas, uma grande parcela do mercado. Não seria interessante para elas permitir que algumas de suas ferramentas possam ser substituídas pelas dos concorrentes. A integração ocorre apenas entre ferramentas da própria empresa desenvolvedora, ou seja, a camada de integração das ferramentas existe, em parte, porém são proprietárias. 2.3 Ambientes de Desenvolvimento de Software Como a integração de ferramentas CASE produzidas sem uma preocupação prévia com esse aspecto revelou-se utópica e a necessidade de ferramentas que apoiassem todas as etapas do desenvolvimento de software 16

17 cresce cada vez mais, começaram a surgir os Ambientes de Desenvolvimento de Software (ADSs). Um ADS apóia todas as etapas do desenvolvimento, consistindo ainda de ferramentas separadas, porém as ferramentas do ADS são construídas sobre um núcleo comum, o que facilita a integração. Um tipo de ADS merece destaque: os Ambientes de Desenvolvimento de Software Centrados em Processo. Esses ambientes exploram uma representação explícita do processo de software para guiar e auxiliar os desenvolvedores no desenvolvimento de software. Os processos são modelados no ADS e a execução dá-se quando os agentes, humanos ou não, executam as atividades decorrentes do processo. 2.4 O Ambiente ODE Ontology-based software Development Environment (ODE) é um ambiente que vem sendo desenvolvido no Laboratório de Engenharia de Software (LABES) da Universidade Federal do Espírito Santo. O ambiente é um ADS Centrado em Processo e baseado em ontologias que possui uma infra-estrutura de gerência do conhecimento. Em ODE, parte-se do pressuposto que, se as ferramentas de um ADS são construídas baseadas em ontologias, a integração delas pode ser facilitada, pois os conceitos envolvidos são bem definidos pelas ontologias (FALBO et al., 2003). Dentre as ontologias que compõem a base ontológica de ODE, tem-se a ontologias de processo de software (BERTOLLO, 2006), de qualidade de software (FALBO et al., 2002) e de artefatos de software (NUNES, 2005), utilizada neste trabalho. Para manter a amarração semântica entre os objetos de ODE e agregar as ontologias ao ambiente, foi proposta uma arquitetura de três níveis (RUY, 2006): Figura Arquitetura Conceitual de ODE 17

18 O Nível Ontológico é responsável pela descrição das ontologias. O pacote Ontologia contém as classes que definem uma ontologia de certo domínio e seus elementos. As instâncias das classes do nível ontológico servem de base para a definição das classes dos outros níveis. O Meta-Nível abriga as classes que descrevem o conhecimento em relação a um domínio de aplicação. Suas classes são derivadas das ontologias e as instâncias dessas classes atuam no papel de conhecimento sobre os objetos do nível base. Elas constituem o conhecimento do ambiente, que pode ser utilizado por qualquer ferramenta que o compõe. O Nível Base define as classes responsáveis por implementar as aplicações no contexto do ambiente (funcionalidades da infraestrutura e suas ferramentas). Essas classes são também derivadas das ontologias, mas tipicamente incorporam detalhes não descritos por elas, necessários para implementar as aplicações. 2.5 Documentação de Software Um documento de software pode ser definido como um artefato cuja finalidade é comunicar uma informação sobre o sistema de software ao qual ele pertence (FORWARD, 2002). Em outras palavras, documentar é comunicar. Segundo Ambler (AMBLER, 2004), do ponto de vista da modelagem ágil, um documento é qualquer artefato externo ao código fonte cujo propósito seja transmitir informação de uma maneira persistente. Já um modelo é uma abstração que descreve um ou mais aspectos de um problema ou de uma solução potencial para resolver um problema. Alguns modelos podem se tornar documentos, ou incluídos como parte deles, ou simplesmente serem descartados quando cumprirem seu papel. Por fim, código fonte é uma seqüência de instruções, incluindo os comentários que descrevem essas 18

19 instruções, para um sistema de computador. O termo documentação inclui documentos e comentários de código fonte. O objetivo deste trabalho é desenvolver uma ferramenta de apoio à documentação em ODE. Como foi dito anteriormente, ODE é um ADS baseado em ontologias. As ontologias são a base para a integração das ferramentas em ODE. Assim, é natural que uma ferramenta de documentação inserida no contexto de ODE seja apoiada por uma ontologia de documentos, que, por sua vez, é parte da ontologia de artefatos (NUNES et al., 2004), parcialmente mostrada na Figura 2.2. produto +super-artefato 0..* 0..* <<Conceito>> Atividade (from Ontologia de Processo) 0..* insumo dependência 0..* 0..* <<Conceito>> 0..* Artefato +sub-artefato 0..* 0..* 0..* aprovação <<Conceito>> Recurso Humano (from Ontologia de Processo) 0..* <<Conceito>> Documento <<Conceito>> Diagrama <<Conceito>> Artefato de Código <<Conceito>> Componente de Software <<Conceito>> Produto de Software Figura Ontologia de Artefato (NUNES et al., 2004) Segundo (NUNES et al., 2004), documentos são artefatos de software não passíveis de execução, constituídos tipicamente de declarações textuais, normalmente associados a padrões organizacionais (roteiros) que definem a forma como eles devem ser produzidos. Exemplos de documentos incluem documentos de especificação de requisitos, planos de projeto, planos de qualidade, relatórios de avaliação de qualidade, entre outros. A Figura 2.3 apresenta a ontologia de documento de software proposta em (NUNES et al., 2004). Os conceitos de Artefato, Procedimento e Roteiro foram importados da ontologia de processo de software (BERTOLLO, 2006), indicando a integração entre essas ontologias. 19

20 <<Conceito>> Procedimento (from Ontologia de Processo) 0..* +super-artefato +sub-artefato 0..* <<Conceito>> Artefato 0..* 0..* 0..* dependência <<Conceito>> Diretriz (from Ontologia de Processo) 0..* <<Conceito>> Roteiro (f rom Ontologia de Processo) aplicação +sub-modelo-documento <<Conceito>> Documento 1 0..* <<Conceito>> Modelo Documento 1 0..* 0..* +super-modelo-documento 0..* super-seção 0..* <<Conceito>> Seção 0..* +sub-seção 0..* correspondência * <<Conceito>> Modelo Seção opcional +modelo-super-seção 0..1 Figura Ontologia de Documentos de Software. +modelo-sub-seção 0..* De acordo com a arquitetura de ODE, apresentada na Figura 2.1, a ontologia acima vai deu origem a classes nos níveis de conhecimento e base, conforme discutido no Capítulo 5. 20

21 Capítulo 3 - Especificação de Requisitos Neste capítulo são apresentados os requisitos funcionais e nãofuncionais para o desenvolvimento da ferramenta de apoio à documentação do ambiente ODE, denominada ODEDoc. Esses requisitos foram adaptados e reformulados a partir dos requisitos de uma outra ferramenta de apoio à documentação, XMLDoc, desenvolvida em (SILVA, 2004) e (SOARES, 2002). Na seção 3.1 tratamos dos requisitos funcionais, ou seja, das necessidades do sistema. Na seção 3.2 são tratados os requisitos não-funcionais. 3.1 Requisitos Funcionais Em se tratando de requisitos funcionais, os modelos de casos de uso, juntamente com suas descrições, fornecem uma eficiente forma de modelar esses requisitos. Tais modelos dão ao desenvolvedor uma visão externa do problema a ser capturado, mostrando a interação entre o usuário e o sistema. Os casos de uso possuem dois importantes papéis (FALBO, 2000): Capturar os requisitos funcionais do sistema. Um modelo de caso de uso define o comportamento de um software (e a informação associada) através de um conjunto de casos de uso. O ambiente do sistema é definido pela descrição dos diferentes atores. Esses atores utilizam o sistema através de um número de casos de uso; Oferecer uma abordagem para a modelagem de sistemas. Para gerenciar a complexidade de sistemas reais, é comum apresentar os modelos do sistema em um número de diferentes visões. Em uma abordagem guiada por casos de uso, pode-se construir uma visão para cada caso de uso, isto é, em cada visão são modelados apenas aqueles elementos que participam de um caso de uso específico. Isto 21

22 significa que um modelo de sistema completo só é visto através de um conjunto de visões. A Figura 3.1 mostra o diagrama de casos de uso para o desenvolvimento de ODEDoc. O ator Desenvolvedor pode criar um documento formatado e solicitar a geração dos documentos formatados do projeto. Os documentos formatados são gerados seguindo as instruções de modelos de documento, criados pelo Gerente de Documentação. Figura Diagrama de Casos de Uso. A seguir são apresentadas as descrições dos casos de uso Caso de Uso Editar Modelo de Documento Este caso de uso é realizado pelo gerente de documentação e é responsável por criar, alterar e excluir um modelo de documento. Os cenários Criar Modelo de Documento, Alterar Modelo de Documento e Excluir Modelo de Documento compõem este caso de uso. 22

23 Cursos Normais Criar Modelo de Documento O gerente de documentação informa o nome, uma descrição, o título, o corpo do preâmbulo e o tipo de artefato ao qual se aplica o modelo de documento. Caso os dados sejam válidos, um novo modelo de documento é criado. O cenário Criar Modelo de Seção do caso de uso Editar Modelo de Seção é chamado. Alterar Modelo de Documento O gerente de documentação informa o modelo de documento que deseja alterar e os novos dados. Caso os dados sejam válidos, a alteração é registrada. Cenários do caso de uso Editar Modelo de Seção podem ser chamados. Excluir Modelo de Documento O gerente de documentação informa o modelo de documento que deseja excluir. Uma confirmação para a operação é solicitada. Se a exclusão for confirmada, o modelo de documento e seus modelos de seção são excluídos. Não é permitida a exclusão de modelos de documento que possuam documentos formatados associados. Cursos Alternativos Criar/Alterar Modelo de Documento Dados inválidos: Uma mensagem de erro é exibida solicitando correção dos dados. Excluir Modelo de Documento Existe um ou mais documentos formatados associados ao modelo de documento: Uma mensagem de erro é exibida, informando ao gerente de documentação que existem documentos formatados associados ao modelo de documento e a exclusão não pode ser realizada. 23

24 3.1.2 Caso de Uso Editar Modelo de Seção Este caso de uso permite criar, alterar e excluir modelos de seção de um modelo de documento. Os cenários Criar Modelo de Seção, Alterar Modelo de Seção e Excluir Modelo de Seção compõem esse caso de uso. Cursos Normais Criar Modelo de Seção O gerente de documentação informa o modelo de seção pai, caso a seção a ser criada seja subseção de uma outra, o título, se a existência de seções desse tipo nos documentos a serem gerados é obrigatória ou opcional, o corpo de texto básico da seção e, opcionalmente, o tipo de artefato que deverá compor o corpo do modelo de seção. Caso os dados sejam válidos, um novo modelo de seção é criado. Caso o modelo de seção não tenha um modelo de seção pai, ele é adicionado como a última seção do modelo de documento. Caso contrário, a nova seção deve ser adicionada ao final da lista de subseções do modelo de seção pai do mesmo. Alterar Modelo de Seção O gerente de documentação informa o modelo de seção que deseja alterar e os novos dados. Caso os dados sejam válidos a alteração é registrada. Excluir Modelo de Seção O gerente de documentação informa o modelo de seção que deseja excluir. Os dados são apresentados e é solicitada uma confirmação. Se a exclusão for confirmada, o modelo de seção e todas as suas subseções são excluídos. Não é permitida a exclusão de um modelo de seção que tenha seções em documentos formatados associados. Cursos Alternativos Criar Modelo de Seção/Alterar Modelo de Seção Dados inválidos: Uma mensagem de erro é exibida solicitando a correção dos dados. 24