Figura 4 Workflow para a Fase de Análise

Transcrição

1 4. Fase Análise A função da fase Análise, baseada no documento requisitos, ou seja, no resultado gerado pelo documento do sistema, é intificar as classes objetos existentes no sistema, screver os relacionamentos entre elas e finir as operações que porão ser executadas pelo sistema. A fase Análise mostra "o que" o sistema faz e não "como" ele é feito, obtendo-se ao final sta fase um "documento especificações" que permitirá a transição à Fase Projeto. A construção dois principais molos estáticos são os objetivos da fase Análise, os quais tratam aspectos diferentes, sendo a molagem das classes objetos e a molagem dos cenários, os quais possibilitam intificar e rivar as operações do sistema. Assim, esta fase do processo é responsável pelas seguintes scrições: classes objetos (sem associar quaisquer métodos às classes); relacionamentos entre classes; operações do sistema; sequência permissível eventos entrada e saída. No entanto, a proposta um processo cíclico exige que os requisitos a serem tratados sejam melhor talhados. Assim, a proposta para a fase Análise prevê que os requisitos sejam inicialmente refinados molando-os por Objetivo (Molo Requisitos por Objetivo) e adotando-se os Cenários para melhor visualizá-los. A figura 4 oferece uma visualização, através um workflow, da seqüência atividas a ser seguida durante a fase Análise.

2

3 Figura 4 Workflow para a Fase Análise 49

4 4.1. Condução da Fase Análise A Fase Análise ve ser conduzida forma a transformar as informações coletadas durante a fase finição requisitos em molos que representem as estruturas estáticas do sistema e o comportamento do mesmo em relação ao meio externo. A partir da Fase Análise o sistema será molado através um processo cíclico, isto é, este processo foi estabelecido forma a viabilizar a construção iterativa e incremental do sistema. Em função das necessidas dinâmicas dos clientes, o processo cíclico está organizado forma a atenr as mudanças nos requisitos ao longo das diversas iterações durante a construção do software, conforme mostra a figura 4. Desta forma, o primeiro passo da Fase Análise prevê a estruturação do ciclo em questão e revisão dos requisitos, o que ve ser feito com o aprimoramento dos requisitos documentados na fase anterior, caraterizando em um refinamento dos requisitos a partir dos objetivos antes brevemente scritos. Com vistas a facilitar a molagem classes e operações, antes vem ser talhados os cenários funcionamento do sistema. Deve ser molado o comportamento do sistema forma a intificar quais são as interações existentes entre o sistema, durante o(s) use case(s) do ciclo, e o meio em que está inserido. Isto será feito através da representação eventos entrada e saída entre o sistema, o qual será tratado em diagramas seqüência como uma caixa preta, pois não interessa neste momento conhecer a dinâmica interna do mesmo para o cumprimento dos requisitos. A próxima meta a ser alcançada passa a ser a molagem conceitual do sistema, consirando três atividas interpenntes. Inicia-se com uma técnica molagem das classes conceituais do sistema, passando-se em seguida à scrição das operações do sistema, as quais serão rivadas dos cenários e farão referência às classes e atributos recém intificados. Por fim, realiza-se uma filtragem das classes no sentido manter no projeto apenas as classes objetos relevantes à implementação do software Refinar Requisitos do Ciclo O primeiro passo ao se iniciar a Fase Análise é partir dos requisitos documentados na primeira fase do processo linear e aprimorar os conhecimentos sobre cada um les, ntro seu respectivo ciclo. Todos requisitos do ciclo vem ser revistos, complementados e validados junto aos clientes e usuários. O refinamento dos requisitos é feito a partir da Visão Requisitos, sendo os Esquemas Requisitos e os Use Cases do ciclo. Serão senvolvidos os Cenários respectivos aos Use Cases em questão na iteração, sendo estes compostos por uma scrição da seqüência eventos e diagramas seqüência quando necessário Refinar Diagramas Use Case Sistema Os Use Cases pom, conforme as necessidas, ser expandidos neste Processo 50

5 Cíclico. Deve-se tomar o cuidado para não refiná-los masiadamente, não confundindo esta ativida com o refinamento dos "velhos" Diagramas Fluxo Dados ou Fluxogramas, on acabava-se por molar processos médio e baixo nível a ponto se chegar à especificação quase algorítmica dos requisitos. Orienta-se para que os use cases sejam intificados em no máximo um nível a mais talhamento do que o ocorrido no Processo Linear. Po-se apresentar o mesmo Diagrama Use Cases para todos os ciclos, possibilitando a visualização completa do sistema, contudo a ênfase ve estar nos Use Cases que serão tratados no ciclo, sendo melhor diferenciá-los no diagrama ou apresentá-los isoladamente. Trabalhadores Envolvidos: Engenheiro Software, mais especificamente na qualida analista ou engenheiro requisitos. Clientes. Artefatos Entrada: Molo Molo Molo Molo Visão Visão Visão Visão Objetivos: Esquemas Descrição Objetivos. Objetivos: Diagrama Use Cases Negócio. Requisitos: Diagrama Use Cases Sistema. Requisitos: Esquemas Descrição Requisitos. Artefatos Saída: Molo Visão Requisitos: Diagrama Use Cases Sistema Refinado. Estratégias e Notações para Molagem A técnica para realizar esta ativida difere muito pouco da molagem inicial use cases. A exceção fica a cargo das entradas a serem observadas, que agora passam a ser os artefatos do próprio Molo Visão Requisitos do Processo Linear, além do Molo Visão Objetivos, obviamente. Quanto às notações UML, são as mesmas apresentadas na ativida "Diagramar Use Cases Sistema". Estudo Caso No estudo caso a seguir segue apresentado o refinamento use cases realizado para o primeiro ciclo construção da ferramenta MiniBib, on enfatizamos os use cases "Cadastrar Proprietários" e "Cadastrar Bibliografias", ambos rivados do use case "Cadastrar Proprietários e Bibliografias", o que é um exemplo bastante simples. Para outros exemplos o leitor po analisar os mais ciclos apresentados no apêndice ste guia. Nas mais atividas apresentadas neste guia para o processo cíclico, em geral serão trabalhados estes use cases e, quando for necessário tratar aspectos que um use case cadastro não contempla, poremos fazer uma análise outros use cases ciclos seguintes, como o Controlar Empréstimos Bibliografias. 51

6 Figura 4.1 Caso MiniBib: Diagrama Use Cases Sistema Refinado Refinar Esquemas Requisitos Nesta etapa utiliza-se do mesmo Esquema Requisitos do Processo Linear. Para uma melhor visualização, mostra-se, novamente, os requisitos vistos anteriormente. No entanto, verão ser acrescentados talhes requisitos às tabelas, o que não significa que ve-se refazer o artefato, mas sim complementá-lo com maiores talhes. Novos esquemas, contudo, porão ser necessários, pois eles corresponm à especificação interna dos use cases, os quais, ntro do processo, acabaram ser refinados. Trabalhadores Envolvidos: Engenheiro Software, mais especificamente na qualida analista ou engenheiro requisitos. Clientes. Artefatos Entrada: Molo Molo Molo Molo Visão Visão Visão Visão Objetivos: Esquemas Descrição Objetivos. Objetivos: Diagrama Use Cases Negócio. Requisitos: Esquemas Descrição Requisitos. Requisitos: Diagrama Use Cases Sistema Refinado. 52

7 Artefatos Saída: Molo Visão Requisitos: Esquemas Descrição Requisitos Refinados. Estratégias e Notações para Molagem As notações para molagem ste artefato são as mesmas, por enquanto. O que ve-se atentar é para a estratégia refinamento dos Esquemas Requisitos. O ial é que cada requisito seja revisto em talhes com os clientes, e aprovado por estes, uma vez que o processo FILM busca atenr a mudanças requisitos, mas após esta ativida as funcionalidas serão analisadas, projetadas e implementadas, sendo que alterações tardias nestes requisitos provavelmente gerarão custos maiores para os clientes. Além disso, os "novos" use cases refinados verão ter suas scrições corresponntes em esquemas requisitos, apesar que muitas stas informações já se encontram na scrição nível superior. Vale ressaltar que novos Esquemas Requisitos, quando existirem em um nível inferior, substituirão os talhamentos do nível superior. Estudo Caso Este estudo caso, apesar bastante simples e aparentemente sem inovações requisitos, nos mostra no requisito que foi acrescentada a informação exemplares, na cláusula "Anotações". Originalmente não era intenção do "cliente" ste sistema controlar exemplares cada professor, mas sim títulos obras, inpenntemente duplicação livros. Neste momento do processo optou-se por trabalhar com referências exemplares, o que o processo permitiu que fosse feito. Outro aspecto foi a geração dois esquemas requisitos a partir do requisito 1.1 do Processo Linear. Talvez se não fosse por fins didáticos este refinamento poria não ser necessário, mas em várias outras situações será. Então vale observar que todas as informações do requisito 1.1 foram utilizadas na expansão dos requisitos e 1.1.2, além serem complementadas a partir novas entrevistas com os clientes. 53

8 Figura 4.2 Caso MiniBib: Esquemas Descrição Requisitos Refinados Estruturar Cenários Em paralelo à expansão dos requisitos, ve ser molado o comportamento do sistema forma a intificar quais são as interações existentes entre o sistema, durante o(s) use case(s) em questão, e o meio em que está inserido. Isto será feito através da representação eventos entrada e saída entre o sistema, o qual ve ser visto como uma caixa preta, não entrando-se nos talhes internos do mesmo. A construção dos cenários ve partir da especificação requisitos, mais especificamente a partir dos Esquemas Requisitos e dos Use Cases do ciclo, sendo que as seqüências eventos caracterizarão uma complementação cada Esquema Requisitos Descrever Seqüência Típica Eventos Com os requisitos refinados e os Use Cases talhados, são elaborados cenários para representar a interação dos atores com o sistema. As Seqüências Típicas Eventos são as seqüências interação entre um ator (agente externo) e o sistema para completar uma necessida negócio, geralmente consirando-se o melhor caso funcionamento do sistema. Estas ações dos atores pom representar eventos entrada para o sistema, o qual responrá com o resultado esperado para o processamento das informações 54

9 entrada [Larman, 2000]. Pom ser criadas, ainda, diversas seqüências alternativas, principalmente que represente svios ou exceções no fluxo execução do sistema, em geral intificados nos diagramas use cases através dos estereótipos <<inclu>> e <<extend>>. Trabalhadores Envolvidos: Engenheiro Software, mais especificamente na qualida analista ou engenheiro requisitos. Clientes. Artefatos Entrada: Molo Visão Requisitos: Esquemas Descrição Requisitos Refinados. Molo Visão Requisitos: Diagrama Use Cases Sistema Refinado. Artefatos Saída: Molo Visão Requisitos: Seqüência Típica Eventos para Esquema Descrição Requisitos Refinado Estratégias e Notações para Molagem A partir do refinamento requisitos ve ser possível intificar as ações um ator. Na tabela abaixo, são representados os eventos (ações) cada ator e a resposta gerada pelo sistema para cada evento. Em um primeiro momento são intificadas as seqüências típicas eventos ou ações cada ator, proposta esta originada do trabalho [Larman, 2000] e que vem a complementar os Esquemas Descrição Requisitos Refinados. A partir stas seqüências são elaborados os Diagramas Seqüência. A principal orientação para montagem dos Cenários está na intificação dos atores e suas ações, o que po ser feito observando-se as cláusulas dos Esquemas Descrição Requisitos Refinados do ciclo em questão. As principais cláusulas a serem observadas são Ação, Agente e Recurso, on intifica-se, respectivamente, ações do ator, qual agente/ator executa a ação e os recursos/atributos/entradas necessários à ação, isto é, necessários aos eventos entrada. Salienta-se que, em geral, a partir uma ação é possível rivar vários eventos entrada e saída, o que caracteriza o talhamento funcional do requisito. 55

10 Figura 4.3 Estrutura Sugerida para Descrição da Seqüência Típica Eventos Estudo Caso Figura 4.4 Caso MiniBib: Seqüência Típica Eventos para os Esquemas Requisitos Refinados e

11 Esboçar Diagramas Seqüência Com os eventos (ações) dos atores tendo sido intificados, torna-se mais fácil molar visualmente os Diagramas Seqüência do Sistema. Dentro da Fase Análise, a construção dos Cenários tem como finalida intificar a interação dos atores com o sistema, em um alto nível através da seqüência permissível ações para cada use case que representa os requisitos do sistema. Poria-se concluir, entretanto, que seria suficiente a scrição textual realizada na seqüência típica eventos e, no máximo, um esboço em papel alguns diagramas no sentido facilitar a compreensão por parte dos clientes. Então, neste momento do processo, também pomos utilizar princípio Agile Moling [Ambler, 2002] e tornar scartáveis os diagramas seqüência. Em muitos casos, porém, estão sendo necessárias as ferramentas CASE para molagem artefatos UML. A automatização dos Diagramas Seqüência, sem preocupação com a arquitetura do software e com o sistema sendo molado como uma "caixa preta" neste momento do processo, permite a criação das assinaturas das operações, caracterizando a intificação dos primeiros métodos do sistema, apesar ainda não os associarmos a classes. Assim, no momento propício, será muito mais simples mapear estas assinaturas para as suas classes objetos, além viabilizar uma prototipação mais efetiva e útil para a implementação do software. Ressalta-se que estes aspectos são mais aquados quando utiliza-se ferramentas apoio ao senvolvimento software que suportem a UML e integrem os diversos diagramas, principalmente Diagramas Seqüência com Diagramas Classes. Trabalhadores Envolvidos: Engenheiro Software. Artefatos Entrada: Molo Visão Requisitos: Esquemas Descrição Requisitos Refinados. Molo Visão Requisitos: Diagrama Use Cases Sistema Refinado. Molo Visão Requisitos: Seqüência Típica Eventos para Esquema Descrição Requisitos Refinado Artefatos Saída: Molo Visão Requisitos: Diagrama Seqüência para Seqüência Típica Eventos Estratégias e Notações para Molagem Esta ativida é facilmente realizada a partir das seqüências eventos anteriormente scritas, ainda mais levando-se em consiração que o sistema será tratado forma bastante abstrata, apenas recebendo eventos entrada e produzindo eventos saída, sem nos preocuparmos em como é realizado o trabalho interno para cumprir suas 57

12 responsabilidas. A tarefa inicial é gerar pelo menos um Diagrama Seqüência, sendo este um padrão notacional UML, para cada esquema scrição requisitos refinados e, conseqüentemente, para cada seqüência eventos. Cada evento entrada se transforma em uma seta entrada no diagrama, com origem em um dos atores intificados, e que terá uma assinatura criada pelo analista, a qual será tratada daqui para frente como o nome uma operação do sistema. Esta assinatura ve ser criada como um método do sistema, on serão relacionados, inclusive, os atributos necessários ao sistema. É snecessário, contudo, preocupar-se com a totalida dos atributos e seus tipos, valendo muito mais, neste momento, que os atributos sejam empacotados em um tipo abstrato. Cada evento saída será gerado pelo sistema com stino a um dos atores relacionados, pondo haver mais um evento saída como resposta a um evento entrada. Abaixo segue uma representação um Diagrama Seqüência, porém é possível relacionarmos mais um ator em um mesmo diagrama. Figura 4.5 Cenários com notação UML Diagrama Sequência 58

13 Estudo Caso 59

14 Figura 4.6 Caso MiniBib: Diagramas Seqüência para os Esquemas Requisitos Refinados e Molo Conceitual A abordagem do molo objetos, assim originalmente nominado no método Fusion em [Coleman, 1996], visa representar as classes objetos através conceitos intificados nas informações até então documentadas. Estes conceitos serão molados como classes objetos que se relacionam entre si através associações e restrições cardinalidas. São intificados também os primeiros atributos cada classe objeto. A sugestão inicial é que as associações (relacionamentos) sejam simples, protelando-se associações dos tipos agregações, generalizações e especializações para um momento mais propício neste processo produção software. 60

15 Molar Classes Conceituais A molagem das classes objetos pen dos requisitos até então coletados para o ciclo em questão. Devem ser observados os requisitos do ciclo e seus respectivos cenários. A partir do segundo ciclo senvolvimento, vale lembrar a necessida em observar os diagramas classes sistema refinados já construídos, pois po-se reutilizar e evoluir as classes objetos já moladas. Uma das tarefas mais complicadas no início da molagem classes objetos é a intificação das mesmas. Várias são as técnicas utilizadas para sua molagem, no entanto não existe nenhuma fórmula mágica para este fim. Desta forma, neste trabalho estaremos tratando esta ativida em dois tempos: primeiro oferecer uma técnica já conhecida para localizar candidatos a classes e atributos; segundo, passar à diagramação das classes objetos e suas associações e cardinalidas. Com a experiência adquirida pelo engenheiro software, muito provavelmente na maioria dos projetos será possível realizar forma direta a tarefa construir o Diagrama Classes Conceituais. Durante o restante do Processo FILM, a tarefa construir o Molo Classes será realizada em três etapas por ciclo. Não somente por questões didáticas, mas também por motivos estruturação do molo, é útil neste momento que as classes objetos sejam tratadas forma conceitual, isto é, nem todas as classes aqui intificadas verão ser implementadas. Por este motivo chama-se classes conceituais, termo este que não é tratado na UML, mas esta ativida auxiliará em muito a scoberta das classes reais do software a ser implementado. Trabalhadores Envolvidos: Engenheiro Software. Artefatos Entrada: Molo Visão Requisitos: Esquemas Descrição Requisitos Refinados. Molo Visão Requisitos: Seqüência Típica Eventos para Esquema Descrição Requisitos Refinado Artefatos Saída: Diagrama Classes Conceituais Estratégias e Notações para Molagem O procedimento inicial para se molar as classes objetos é partir das especificações requisitos corresponntes ao ciclo em questão. Nossa sugestão é utilizar 61

16 duas técnicas em conjunto para intificação candidatos a classes e atributos objetos, sendo a técnica gramatical Booch [Booch, 1994] e uma lista categorias sugerida em [Larman, 2000]. A primeira tarefa é formar uma lista dos substantivos encontrados ao longo da especificação requisitos, os quais serão candidatos a classes objetos ou atributos. A partir daí ve-se buscar sua intificação nas tabelas categorias [Larman, 2000] qualificando o conceito como classe objeto, atributo ou scartando-o. A lista substantivos gerada, como um esboço classes e atributos que po estar relacionado em uma tabela como a da figura 4.7, também facilita a eliminação redundâncias (conceitos objetos semelhantes ou repetidos). Busque não molar chaves (primárias, estrangeiras,...) como em bancos dados. Isto verá ser feito no momento mapear as classes objetos para uma estrutura dados persistentes, voltando a enfatizar que estaremos molando a camada negócios, isto é, a camada classes objetos transientes do sistema. A molagem das classes objetos prevê a finição atributos para cada classe. Estes atributos são propriedas que caracterizam uma classe objetos. Uma classe objetos sem atributos, geralmente, não tem nenhuma serventia no contexto da Fase Análise, diferente do que será visto na Fase Projeto. Neste momento, ve-se intificar estas propriedas e tentar atribuí-las às suas classes objetos. Estas propriedas também serão consiradas como candidatas a atributos. Lembre-se, existem atributos que são intuitivos. Não ignore este fato. Por exemplo, se estivermos molando uma classe objetos para Pessoas, em geral existem os atributos nome e ida, mesmo que não tenham sido explicitados nos requisitos. Figura 4.7 Molo Classes com Notações UML do Diagrama Classes A partir da consolidação classes e atributos, o próximo passo é estruturar o Diagrama Classes Conceituais com suas respectivas associações e restrições cardinalida. Para intificação das associações também é possível utilizar das técnicas mencionadas acima, contudo esta técnica não é o escopo ste trabalho e verá ser buscado nas fontes apropriadas. Observando-se a lista candidatas a classes, atributos e métodos, bem como, os Cenários e os Molos Operações, ve-se criar um molo preliminar diagrama classes contendo, obviamente, as classes com os seus atributos. Este Diagrama Classes é o primeiro a ser feito e representa, forma substancial, a parte mais importante da análise. Isto ocorre porque o Diagrama Classes representa o molo 62

17 conceitual do sistema. Até este momento, através ste molo conceitual tem-se uma idéia inicial da forma que o sistema terá no momento sua implementação. Este molo conceitual será refinado na Fase Projeto e provavelmente sofrerá alterações. Especifique neste Diagrama Classes todas as classes com os seus atributos, sem pensar em intificar métodos classes neste momento. Especifique também as associações entre as classes, lembrando que associações vem ter rótulos intificação, caso contrário per-se compreensão semântica do molo e dificulta-se o aperfeiçoamento do mesmo na Fase Projeto. Lembre-se da importância especificar a cardinalida para as associações entre as classes, conforme padrão UML (componentes notacionais seguem na figura 4.8). A precisão dos tipos dados e valores iniciais para os atributos vem ser melhor observador apenas na Fase Projeto. Figura 4.8 Componentes Notacionais UML para Diagramas Classes 63

18 Estudo Caso 64

19 Figura 4.10 Caso MiniBib: Candidatos a Classes e Atributos e Diagrama Classes Conceituais Descrever Esquemas Operações A construção do molo operações marca o momento do processo em que se começa a investigar as estruturas internas do sistema em construção. As operações serão moladas através fichas com um conjunto cláusulas. Cada cláusula tem seu propósito transformar os requisitos do objetivo em referências às estruturas até então moladas como classes objetos. Portanto, cada evento entrada se transformará em uma operação, merecendo uma ficha/esquema molagem, a partir da qual serão documentadas as responsabilidas da operação e os efeitos causados ao sistema após sua execução. Possíveis resultados associados a uma operação do sistema, são: -Criar uma nova instância classe; -Alterar atributos objetos existentes/instanciados; -Criar/eliminar tuplas relacionamentos; -Enviar um evento saída a um agente. Trabalhadores Envolvidos: Engenheiro Software. 65

20 Artefatos Entrada: Molo Visão Requisitos: Esquemas Descrição Requisitos Refinados. Molo Visão Requisitos: Seqüência Típica Eventos para Esquema Descrição Requisitos Refinado Diagrama Classes Conceituais Artefatos Saída: Esquemas Operações Estratégias e Notações para Molagem A construção do Molo Operações pen praticamente todas as informações documentadas até então para o ciclo em questão. A base da molagem das operações parte dos Diagramas Classes Conceituais e das especificações dos requisitos. A estratégia para molagem das operações ve iniciar observando-se os Cenários do Sistemas, transformando cada evento entrada em uma ficha operação. A partir disso, as tarefas restantes terão o propósito preencher as mais cláusulas do esquema operações. A molagem das operações é feita forma clarativa, adotando-se cláusulas mecanismos contratos, adaptados [Larman, 2000], originalmente fundamentados nos cartões CRC (Class-Responsability-Colaboration), Kent Beck. As cláusulas vem estar dispostas em um esquema operação, conforme molo da figura 4.11 a seguir. 66

21 Figura 4.11 Estrutura do Esquema Operação 67

22 Estudo Caso 68

23 69

24 Figura 4.12 Caso MiniBib: Esquemas Operações para os Requisitos do Ciclo Filtrar Classes Conceituais do Sistema 70

25 Um Diagrama Classes Conceitual apresenta um molo do domínio do problema. Assim, as classes e os relacionamentos pom especificar conceitos pertencentes ao ambiente externo ao sistema, bem como os inerentes ao próprio sistema" [Coleman, 1996]. Já um Diagrama Classes do Sistema representa um subconjunto do diagrama molado anteriormentepara o sistema a ser construído. O diagrama a ser produzido nesta ativida, portanto, será rivado do Diagrama Classes Conceitual excluindo-se as classes e relacionamentos que pertençam unicamente ao ambiente externo ao sistema e não ao próprio sistema [Coleman, 1996]. Trabalhadores Envolvidos: Engenheiro Software. Artefatos Entrada: Diagrama Classes Conceituais. Esquemas Operações. Artefatos Saída: Diagrama Classes Conceituais do Sistema. Estratégias e Notações para Molagem O Diagrama Classes Conceitual do Sistema está diretamente vinculado ao Diagrama Classes Conceitual, vendo-se também observar informações requisitos que intifiquem agentes do sistema, como Cenários e Esquemas Operações. Observando-se os Cenários e os Esquemas Operações, ve-se filtrar os Diagramas Classes Conceituais forma a manter apenas classes necessárias à própria estrutura interna do sistema. O método Fusion orienta para que seja criada uma espécie fronteira, através uma linha pontilhada, limitando os objetos do sistema e os agentes. No entanto, com a UML poremos utilizar a notação para agentes/atores, através bonecospalito, e os objetos que não forem nem agentes nem objetos do sistema, serão excluídos ste novo molo. As notações a serem utilizadas nesta ativida seguem o padrão UML para diagramação classes, sendo acrescentada uma diferença semântica em que se sugere a substituição algumas classes-agentes por bonecos-palito na função atores/agentes, sendo este último um padrão UML mais utilizado nos Diagramas Use Case, o que nas ferramentas CASE costuma ser viabilizado a partir estereótipos do tipo <<ator>>, visualizado ou não como boneco-palito. 71

26 Estudo Caso Neste diagrama do estudo caso, referente ao primeiro ciclo do porjeto MiniBib, não há diferenças aparentes na molagem em relação do diagrama da ativida anterior. Contudo, em diversas outras situações isto po ocorrer, como po ser visto nos mais ciclos do caso MiniBib presentes no Apêndice A. Figura 4.13 Caso MiniBib: Diagrama Classes Conceituais Sistema 4.4. Inspeção dos Artefatos da Fase Análise Seguindo as orientações [Coleman, 1996], nesta seção serão apresentadas algumas diretrizes para a verificação dos molos análise no que se refere à inteireza e à consistência em relação aos requisitos. Inteireza com requisitos: releia com cuidado o documento requisitos e resolva quaisquer dúvidas com o cliente/usuários. Em seguida, verifique se: Todos os cenários possíveis foram tratados pelo ciclo vida; Todas as operações do sistema foram finidas com o uso um esquema operações; Todas as informações estáticas foram capturadas pelo molo objetos do sistema; Todas as outras informações estão documentadas no glossário termos. 72

27 Consistência: essas verificações relacionam-se com a sobreposição entre os molos análise. Verifique se: Todas as classes, relacionamentos e atributos mencionados no molo operações aparecem no molo objetos do sistema. Todos os outros conceitos vem estar finidos no glossário termos ou em alguma outra fonte referência; A fronteira do molo objetos do sistema é consistente com a interface do sistema fornecida pelo molo ciclo--vida; Todas as operações do sistema, presentes no molo ciclo--vida, possuem um esquema operações; Todos os intificados utilizados em todos molos se encontram do glossário termos. 73