Figura 4 Workflow para a Fase de Análise

(1)

4. Fase de Análise

A função da fase de Análise, baseada no documento de requisitos, ou seja, no resultado gerado pelo documento do sistema, é identificar as classes de objetos existentes no sistema, descrever os relacionamentos entre elas e definir as operações que poderão ser executadas pelo sistema. A fase de Análise mostra "o que" o sistema faz e não "como" ele é feito, obtendo-se ao final desta fase um "documento de especificações" que permitirá a transição à Fase de Projeto.

A construção de dois principais modelos estáticos são os objetivos da fase de Análise, os quais tratam de aspectos diferentes, sendo a modelagem das classes de objetos e a modelagem dos cenários, os quais possibilitam identificar e derivar as operações do sistema. Assim, esta fase do processo é responsável pelas seguintes descrições: classes de objetos (sem associar quaisquer métodos às classes); relacionamentos entre classes; operações do sistema; sequência permissível de eventos de entrada e saída. No entanto, a proposta de um processo cíclico exige que os requisitos a serem tratados sejam melhor detalhados. Assim, a proposta para a fase de Análise prevê que os requisitos sejam inicialmente refinados modelando-os por Objetivo (Modelo de Requisitos por Objetivo) e adotando-se os Cenários para melhor visualizá-los. A figura 4 oferece uma visualização, através de um workflow, da seqüência de atividades a ser seguida durante a fase de Análise.

(2)

(3)

(4)

4.1. Condução da Fase de Análise

A Fase de Análise deve ser conduzida de forma a transformar as informações coletadas durante a fase de definição de requisitos em modelos que representem as estruturas estáticas do sistema e o comportamento do mesmo em relação ao meio externo. A partir da Fase de Análise o sistema será modelado através de um processo cíclico, isto é, este processo foi estabelecido de forma a viabilizar a construção iterativa e incremental do sistema.

Em função das necessidades dinâmicas dos clientes, o processo cíclico está organizado de forma a atender 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 de Análise prevê a estruturação do ciclo em questão e revisão dos requisitos, o que deve ser feito com o aprimoramento dos requisitos documentados na fase anterior, caraterizando em um refinamento dos requisitos a partir dos objetivos antes brevemente descritos. Com vistas a facilitar a modelagem de classes e operações, antes devem ser detalhados os cenários de funcionamento do sistema. Deve ser modelado o comportamento do sistema de forma a identificar 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 de eventos de entrada e de saída entre o sistema, o qual será tratado em diagramas de 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 modelagem conceitual do sistema, considerando três atividades interdependentes. Inicia-se com uma técnica de modelagem das classes conceituais do sistema, passando-se em seguida à descrição das operações do sistema, as quais serão derivadas dos cenários e farão referência às classes e atributos recém identificados. Por fim, realiza-se uma filtragem das classes no sentido de manter no projeto apenas as classes de objetos relevantes à implementação do software.

4.2. Refinar Requisitos do Ciclo

O primeiro passo ao se iniciar a Fase de Análise é partir dos requisitos documentados na primeira fase do processo linear e aprimorar os conhecimentos sobre cada um deles, dentro de seu respectivo ciclo. Todos requisitos do ciclo devem ser revistos, complementados e validados junto aos clientes e usuários.

O refinamento dos requisitos é feito a partir da Visão de Requisitos, sendo os Esquemas de Requisitos e os Use Cases do ciclo. Serão desenvolvidos os Cenários respectivos aos Use Cases em questão na iteração, sendo estes compostos por uma descrição da seqüência de eventos e de diagramas de seqüência quando necessário.

4.2.1. Refinar Diagramas de Use Case de Sistema

(5)

Cíclico. Deve-se tomar o cuidado para não refiná-los demasiadamente, não confundindo esta atividade com o refinamento dos "velhos" Diagramas de Fluxo de Dados ou Fluxogramas, onde acabava-se por modelar processos de médio e baixo nível a ponto de se chegar à especificação quase algorítmica dos requisitos. Orienta-se para que os use cases sejam identificados em no máximo um nível a mais de detalhamento do que o ocorrido no Processo Linear. Pode-se apresentar o mesmo Diagrama de Use Cases para todos os ciclos, possibilitando a visualização completa do sistema, contudo a ênfase deve estar nos Use Cases que serão tratados no ciclo, sendo melhor diferenciá-los no diagrama ou apresentá-los isoladamente.

Trabalhadores Envolvidos:

Engenheiro de Software, mais especificamente na qualidade de analista ou engenheiro de requisitos.

Clientes.

Artefatos de Entrada:

Modelo de Visão de Objetivos: Esquemas de Descrição de Objetivos. Modelo de Visão de Objetivos: Diagrama de Use Cases de Negócio. Modelo de Visão de Requisitos: Diagrama de Use Cases de Sistema. Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos.

Artefatos de Saída:

Modelo de Visão de Requisitos: Diagrama de Use Cases de Sistema Refinado.

Estratégias e Notações para Modelagem

A técnica para realizar esta atividade difere muito pouco da modelagem inicial de use cases. A exceção fica a cargo das entradas a serem observadas, que agora passam a ser os artefatos do próprio Modelo de Visão de Requisitos do Processo Linear, além do Modelo de Visão de Objetivos, obviamente. Quanto às notações UML, são as mesmas apresentadas na atividade "Diagramar Use Cases de Sistema".

Estudo de Caso

No estudo de caso a seguir segue apresentado o refinamento de use cases realizado para o primeiro ciclo de construção da ferramenta MiniBib, onde enfatizamos os use cases "Cadastrar Proprietários" e "Cadastrar Bibliografias", ambos derivados do use case "Cadastrar Proprietários e Bibliografias", o que é um exemplo bastante simples. Para outros exemplos o leitor pode analisar os demais ciclos apresentados no apêndice deste guia. Nas demais atividades apresentadas neste guia para o processo cíclico, em geral serão trabalhados estes use cases e, quando for necessário tratar de aspectos que um use case de cadastro não contempla, poderemos fazer uma análise de outros use cases de ciclos seguintes, como o de Controlar Empréstimos de Bibliografias.

(6)

Figura 4.1 – Caso MiniBib: Diagrama de Use Cases de Sistema Refinado

4.2.2. Refinar Esquemas de Requisitos

Nesta etapa utiliza-se do mesmo Esquema de Requisitos do Processo Linear. Para uma melhor visualização, mostra-se, novamente, os requisitos vistos anteriormente. No entanto, deverão ser acrescentados detalhes de requisitos às tabelas, o que não significa que deve-se refazer o artefato, mas sim complementá-lo com maiores detalhes. Novos esquemas, contudo, poderão ser necessários, pois eles correspondem à especificação interna dos use cases, os quais, dentro do processo, acabaram de ser refinados.

Clientes.

Modelo de Visão de Objetivos: Esquemas de Descrição de Objetivos. Modelo de Visão de Objetivos: Diagrama de Use Cases de Negócio. Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos.

(7)

Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos Refinados.

As notações para modelagem deste artefato são as mesmas, por enquanto. O que deve-se atentar é para a estratégia de refinamento dos Esquemas de Requisitos. O ideal é que cada requisito seja revisto em detalhes com os clientes, e aprovado por estes, uma vez que o processo FILM busca atender a mudanças de requisitos, mas após esta atividade as funcionalidades 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 deverão ter suas descrições correspondentes em esquemas de requisitos, apesar que muitas destas informações já se encontram na descrição de nível superior. Vale ressaltar que novos Esquemas de Requisitos, quando existirem em um nível inferior, substituirão os detalhamentos do nível superior.

Estudo de Caso

Este estudo de caso, apesar de bastante simples e aparentemente sem inovações de requisitos, nos mostra no requisito 1.1.2 que foi acrescentada a informação de exemplares, na cláusula "Anotações". Originalmente não era intenção do "cliente" deste sistema controlar exemplares de cada professor, mas sim títulos de obras, independentemente de duplicação de livros. Neste momento do processo optou-se por trabalhar com referências de exemplares, o que o processo permitiu que fosse feito.

Outro aspecto foi a geração de dois esquemas de requisitos a partir do requisito 1.1 do Processo Linear. Talvez se não fosse por fins didáticos este refinamento poderia 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 1.1.1 e 1.1.2, além de serem complementadas a partir de novas entrevistas com os clientes.

(8)

Figura 4.2 – Caso MiniBib: Esquemas de Descrição de Requisitos Refinados

4.2.3. Estruturar Cenários

Em paralelo à expansão dos requisitos, deve ser modelado o comportamento do sistema de forma a identificar 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 de eventos de entrada e de saída entre o sistema, o qual deve ser visto como uma “caixa preta”, não entrando-se nos detalhes internos do mesmo. A construção dos cenários deve partir da especificação de requisitos, mais especificamente a partir dos Esquemas de Requisitos e dos Use Cases do ciclo, sendo que as seqüências de eventos caracterizarão uma complementação de cada Esquema de Requisitos.

4.2.3.1. Descrever Seqüência Típica de Eventos

Com os requisitos refinados e os Use Cases detalhados, são elaborados cenários para representar a interação dos atores com o sistema. As Seqüências Típicas de Eventos são as seqüências de interação entre um ator (agente externo) e o sistema para completar uma necessidade de negócio, geralmente considerando-se o melhor caso de funcionamento do sistema. Estas ações dos atores podem representar eventos de entrada para o sistema, o qual responderá com o resultado esperado para o processamento das informações de

(9)

entrada [Larman, 2000]. Podem ser criadas, ainda, diversas seqüências alternativas, principalmente que represente desvios ou exceções no fluxo de execução do sistema, em geral identificados nos diagramas de use cases através dos estereótipos <<include>> e <<extend>>.

Clientes.

Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos Refinados. Modelo de Visão de Requisitos: Diagrama de Use Cases de Sistema Refinado.

Modelo de Visão de Requisitos: Seqüência Típica de Eventos para Esquema de Descrição de Requisitos Refinado

A partir do refinamento de requisitos deve ser possível identificar as ações de um ator. Na tabela abaixo, são representados os eventos (ações) de cada ator e a resposta gerada pelo sistema para cada evento. Em um primeiro momento são identificadas as seqüências típicas de eventos ou ações de cada ator, proposta esta originada do trabalho de [Larman, 2000] e que vem a complementar os Esquemas de Descrição de Requisitos Refinados. A partir destas seqüências são elaborados os Diagramas de Seqüência. A principal orientação para montagem dos Cenários está na identificação dos atores e suas ações, o que pode ser feito observando-se as cláusulas dos Esquemas de Descrição de Requisitos Refinados do ciclo em questão. As principais cláusulas a serem observadas são “Ação”, “Agente” e “Recurso”, onde identifica-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 de entrada. Salienta-se que, em geral, a partir de uma ação é possível derivar vários eventos de entrada e saída, o que caracteriza o detalhamento funcional do requisito.

(10)

Figura 4.3 – Estrutura Sugerida para Descrição da Seqüência Típica de Eventos

Estudo de Caso

Figura 4.4 – Caso MiniBib: Seqüência Típica de Eventos para os Esquemas de Requisitos Refinados 1.1.1 e 1.1.2

(11)

4.2.3.2. Esboçar Diagramas de Seqüência

Com os eventos (ações) dos atores tendo sido identificados, torna-se mais fácil modelar visualmente os Diagramas de Seqüência do Sistema. Dentro da Fase de Análise, a construção dos Cenários tem como finalidade identificar a interação dos atores com o sistema, em um alto nível através da seqüência permissível de ações para cada use case que representa os requisitos do sistema. Poderia-se concluir, entretanto, que seria suficiente a descrição textual realizada na seqüência típica de eventos e, no máximo, um esboço em papel de alguns diagramas no sentido de facilitar a compreensão por parte dos clientes. Então, neste momento do processo, também podemos utilizar de princípio de Agile Modeling [Ambler, 2002] e tornar descartáveis os diagramas de seqüência.

Em muitos casos, porém, estão sendo necessárias as ferramentas CASE para modelagem de artefatos UML. A automatização dos Diagramas de Seqüência, sem preocupação com a arquitetura do software e com o sistema sendo modelado como uma "caixa preta" neste momento do processo, permite a criação das assinaturas das operações, caracterizando a identificação dos primeiros métodos do sistema, apesar de ainda não os associarmos a classes. Assim, no momento propício, será muito mais simples mapear estas assinaturas para as suas classes de objetos, além de viabilizar uma prototipação mais efetiva e útil para a implementação do software. Ressalta-se que estes aspectos são mais adequados quando utiliza-se ferramentas de apoio ao desenvolvimento de software que suportem a UML e integrem os diversos diagramas, principalmente Diagramas de Seqüência com Diagramas de Classes.

Engenheiro de Software.

Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos Refinados. Modelo de Visão de Requisitos: Diagrama de Use Cases de Sistema Refinado. Modelo de Visão de Requisitos: Seqüência Típica de Eventos para Esquema de Descrição de Requisitos Refinado

Modelo de Visão de Requisitos: Diagrama de Seqüência para Seqüência Típica de Eventos

Esta atividade é facilmente realizada a partir das seqüências de eventos anteriormente descritas, ainda mais levando-se em consideração que o sistema será tratado de forma bastante abstrata, apenas recebendo eventos de entrada e produzindo eventos de saída, sem nos preocuparmos em como é realizado o trabalho interno para cumprir suas

(12)

responsabilidades.

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

(13)

Estudo de Caso

(14)

Figura 4.6 – Caso MiniBib: Diagramas de Seqüência para os Esquemas de Requisitos Refinados 1.1.1 e 1.1.2

4.3. Modelo Conceitual

A abordagem do modelo de objetos, assim originalmente denominado no método Fusion em [Coleman, 1996], visa representar as classes de objetos através de conceitos identificados nas informações até então documentadas. Estes conceitos serão modelados como classes de objetos que se relacionam entre si através de associações e restrições de cardinalidades. São identificados também os primeiros atributos de cada classe de 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 de produção de software.

(15)

4.3.1. Modelar Classes Conceituais

A modelagem das classes de objetos depende 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 de desenvolvimento, vale lembrar a necessidade em observar os diagramas de classes de sistema refinados já construídos, pois pode-se reutilizar e evoluir as classes de objetos já modeladas.

Uma das tarefas mais complicadas no início da modelagem de classes de objetos é a identificação das mesmas. Várias são as técnicas utilizadas para sua modelagem, no entanto não existe nenhuma fórmula mágica para este fim. Desta forma, neste trabalho estaremos tratando esta atividade em dois tempos: primeiro oferecer uma técnica já conhecida para localizar candidatos a classes e atributos; segundo, passar à diagramação das classes de objetos e suas associações e cardinalidades. Com a experiência adquirida pelo engenheiro de software, muito provavelmente na maioria dos projetos será possível realizar de forma direta a tarefa de construir o Diagrama de Classes Conceituais.

Durante o restante do Processo FILM, a tarefa de construir o Modelo de Classes será realizada em três etapas por ciclo. Não somente por questões didáticas, mas também por motivos de estruturação do modelo, é útil neste momento que as classes de objetos sejam tratadas de forma conceitual, isto é, nem todas as classes aqui identificadas deverão ser implementadas. Por este motivo chama-se classes conceituais, termo este que não é tratado na UML, mas esta atividade auxiliará em muito a descoberta das classes reais do software a ser implementado.

Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos Refinados. Modelo de Visão de Requisitos: Seqüência Típica de Eventos para Esquema de Descrição de Requisitos Refinado

Diagrama de Classes Conceituais

O procedimento inicial para se modelar as classes de objetos é partir das especificações de requisitos correspondentes ao ciclo em questão. Nossa sugestão é utilizar

(16)

de duas técnicas em conjunto para identificação de candidatos a classes e atributos de objetos, sendo a técnica gramatical de Booch [Booch, 1994] e de uma lista de categorias sugerida em [Larman, 2000].

A primeira tarefa é formar uma lista dos substantivos encontrados ao longo da especificação de requisitos, os quais serão candidatos a classes de objetos ou atributos. A partir daí deve-se buscar sua identificação nas tabelas de categorias de [Larman, 2000] qualificando o conceito como classe de objeto, atributo ou descartando-o. A lista de substantivos gerada, como um esboço de classes e atributos que pode estar relacionado em uma tabela como a da figura 4.7, também facilita a eliminação de redundâncias (conceitos de objetos semelhantes ou repetidos). Busque não modelar chaves (primárias, estrangeiras, ...) como em bancos de dados. Isto deverá ser feito no momento de mapear as classes de objetos para uma estrutura de dados persistentes, voltando a enfatizar que estaremos modelando a camada de negócios, isto é, a camada de classes de objetos transientes do sistema.

A modelagem das classes de objetos prevê a definição de atributos para cada classe. Estes atributos são propriedades que caracterizam uma classe de objetos. Uma classe de objetos sem atributos, geralmente, não tem nenhuma serventia no contexto da Fase de Análise, diferente do que será visto na Fase de Projeto.

Neste momento, deve-se identificar estas propriedades e tentar atribuí-las às suas classes de objetos. Estas propriedades também serão consideradas como candidatas a atributos. Lembre-se, existem atributos que são intuitivos. Não ignore este fato. Por exemplo, se estivermos modelando uma classe de objetos para Pessoas, em geral existem os atributos

nome e idade, mesmo que não tenham sido explicitados nos requisitos.

Figura 4.7 – Modelo de Classes com Notações UML do Diagrama de Classes A partir da consolidação de classes e atributos, o próximo passo é estruturar o Diagrama de Classes Conceituais com suas respectivas associações e restrições de cardinalidade. Para identificação das associações também é possível utilizar das técnicas mencionadas acima, contudo esta técnica não é o escopo deste trabalho e deverá ser buscado nas fontes apropriadas.

Observando-se a lista de candidatas a classes, atributos e métodos, bem como, os Cenários e os Modelos de Operações, deve-se criar um modelo preliminar de diagrama de classes contendo, obviamente, as classes com os seus atributos. Este Diagrama de Classes é o primeiro a ser feito e representa, de forma substancial, a parte mais importante da análise. Isto ocorre porque o Diagrama de Classes representa o modelo

(17)

conceitual do sistema. Até este momento, através deste modelo conceitual tem-se uma idéia inicial da forma que o sistema terá no momento de sua implementação. Este modelo conceitual será refinado na Fase de Projeto e provavelmente sofrerá alterações.

Especifique neste Diagrama de Classes todas as classes com os seus atributos, sem pensar em identificar métodos de classes neste momento. Especifique também as associações entre as classes, lembrando que associações devem ter rótulos de identificação, caso contrário perde-se compreensão semântica do modelo e dificulta-se o aperfeiçoamento do mesmo na Fase de Projeto. Lembre-se da importância de especificar a cardinalidade para as associações entre as classes, conforme padrão UML (componentes notacionais seguem na figura 4.8). A precisão dos tipos de dados e valores iniciais para os atributos devem ser melhor observador apenas na Fase de Projeto.

(18)

Estudo de Caso

(19)

Figura 4.10 – Caso MiniBib: Candidatos a Classes e Atributos e Diagrama de Classes Conceituais

4.3.2. Descrever Esquemas de Operações

A construção do modelo de 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 modeladas através de fichas com um conjunto de cláusulas. Cada cláusula tem seu propósito de transformar os requisitos do objetivo em referências às estruturas até então modeladas como classes de objetos. Portanto, cada evento de entrada se transformará em uma operação, merecendo uma ficha/esquema de modelagem, a partir da qual serão documentadas as responsabilidades 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 de classe;

-Alterar atributos de objetos existentes/instanciados; -Criar/eliminar “tuplas” de relacionamentos;

-Enviar um evento de saída a um agente.

(20)

Modelo de Visão de Requisitos: Esquemas de Descrição de Requisitos Refinados. Modelo de Visão de Requisitos: Seqüência Típica de Eventos para Esquema de Descrição de Requisitos Refinado

Diagrama de Classes Conceituais

Esquemas de Operações

A construção do Modelo de Operações depende praticamente de todas as informações documentadas até então para o ciclo em questão. A base da modelagem das operações parte dos Diagramas de Classes Conceituais e das especificações dos requisitos. A estratégia para modelagem das operações deve iniciar observando-se os Cenários do Sistemas, transformando cada evento de entrada em uma ficha de operação. A partir disso, as tarefas restantes terão o propósito de preencher as demais cláusulas do esquema de operações. A modelagem das operações é feita de forma declarativa, adotando-se cláusulas de mecanismos de contratos, adaptados de [Larman, 2000], originalmente fundamentados nos cartões CRC (Class-Responsability-Colaboration), de Kent Beck. As cláusulas devem estar dispostas em um “esquema de operação”, conforme modelo da figura 4.11 a seguir.

(21)

(22)

(23)

(24)

Figura 4.12 – Caso MiniBib: Esquemas de Operações para os Requisitos do Ciclo

4.3.3. Filtrar Classes Conceituais do Sistema

(25)

“Um Diagrama de Classes Conceitual apresenta um modelo do domínio do problema. Assim, as classes e os relacionamentos podem especificar conceitos pertencentes ao ambiente externo ao sistema, bem como os inerentes ao próprio sistema" [Coleman, 1996]. Já um Diagrama de Classes do Sistema representa um subconjunto do diagrama modelado anteriormentepara o sistema a ser construído. O diagrama a ser produzido nesta atividade, portanto, será derivado do Diagrama de 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].

Diagrama de Classes Conceituais. Esquemas de Operações .

Diagrama de Classes Conceituais do Sistema.

O Diagrama de Classes Conceitual do Sistema está diretamente vinculado ao Diagrama de Classes Conceitual, devendo-se também observar informações de requisitos que identifiquem agentes do sistema, como Cenários e Esquemas de Operações.

Observando-se os Cenários e os Esquemas de Operações, deve-se filtrar os Diagramas de Classes Conceituais de 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 de fronteira, através de uma linha pontilhada, delimitando os objetos do sistema e os agentes. No entanto, com a UML poderemos utilizar a notação para agentes/atores, através de bonecos-palito, e os objetos que não forem nem agentes nem objetos do sistema, serão excluídos deste “novo” modelo.

As notações a serem utilizadas nesta atividade seguem o padrão UML para diagramação de classes, sendo acrescentada uma diferença semântica em que se sugere a substituição de algumas classes-agentes por bonecos-palito na função de atores/agentes, sendo este último um padrão UML mais utilizado nos Diagramas de Use Case, o que nas ferramentas CASE costuma ser viabilizado a partir de estereótipos do tipo <<ator>>, visualizado ou não como boneco-palito.

(26)

Estudo de Caso

Neste diagrama do estudo de caso, referente ao primeiro ciclo do porjeto MiniBib, não há diferenças aparentes na modelagem em relação do diagrama da atividade anterior. Contudo, em diversas outras situações isto pode ocorrer, como pode ser visto nos demais ciclos do caso MiniBib presentes no Apêndice A.

Figura 4.13 – Caso MiniBib: Diagrama de Classes Conceituais de Sistema

4.4. Inspeção dos Artefatos da Fase de Análise

Seguindo as orientações de [Coleman, 1996], nesta seção serão apresentadas algumas diretrizes para a verificação dos modelos de análise no que se refere à inteireza e à consistência em relação aos requisitos.

Inteireza com requisitos: releia com cuidado o documento de 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 de vida; Todas as operações do sistema foram definidas com o uso de um esquema de operações;

Todas as informações estáticas foram capturadas pelo modelo de objetos do sistema; Todas as outras informações estão documentadas no glossário de termos.

(27)

Consistência: essas verificações relacionam-se com a sobreposição entre os modelos

de análise. Verifique se:

Todas as classes, relacionamentos e atributos mencionados no modelo de operações aparecem no modelo de objetos do sistema.

Todos os outros conceitos devem estar definidos no glossário de termos ou em alguma outra fonte de referência;

A fronteira do modelo de objetos do sistema é consistente com a interface do sistema fornecida pelo modelo ciclo-de-vida;

Todas as operações do sistema, presentes no modelo ciclo-de-vida, possuem um esquema de operações;

Todos os identificados utilizados em todos modelos se encontram do glossário de termos.