Padrão de Análise de Sistemas
Histórico de Atualizações Versão Data Alterações 1.0 15/03/2007 Definição de boas práticas para a Análise de Sistemas 1.1 30/04/2007 Alteração no diagrama de implementação de classes para componentes. Inclusão da forma de trabalho com documentos replicados na rede. Nomenclatura dos diagramas dentro da especificação (para conter o nome da funcionalidade e não mais apenas fluxo ou especificação ). 1.2 22/05/2007 Adicionado o apêndice no documento contendo diversas orientações rápidas para o desenvolvimento da atividade de análise de sistemas. 2.0 18/09/2007 Padrão de Orientação a Objetos. 2.1 06/12/2007 Adicionado padrão de solicitação ADO. 2.2 03/01/2008 Inclusão de um novo controle nas solicitações ADO e inclusão dos mecanismos para Análise de Impacto. 2.3 08/02/2008 Alterado padrão de solicitação ADO. 2.4 11/02/2008 Inserido Rastreabilidade 2.5 22/02/2008 Inserido Relacionamento Entre Casos de Uso. 20/3/2008 Página 2 de 64
Índice INTRODUÇÃO...5 1. ENTERPRISE ARCHITECT...6 1.1 VISÃO GERAL... 6 1.2 LICENÇAS... 6 1.3 PADRÕES... 6 1.4 CONFIGURAÇÃO... 6 2. DIAGRAMAS, ELEMENTOS E LIGAÇÕES...8 2.1 DIAGRAMAS... 8 2.2 ELEMENTOS E LIGAÇÕES... 10 2.2.1 Caso de Uso... 10 2.2.2 Requisitos... 10 2.2.3 Alterações... 11 2.2.4 Classes... 12 2.2.5 Tabelas... 12 2.2.6 Componentes... 12 2.2.7 Atividades... 13 3. ESTRUTURAS DOS PROJETOS...16 3.1 PADRÕES DE ESTRUTURAS DE PROJETOS... 16 3.1.1 Manutenção... 17 3.1.2 Banco de Dados... 20 3.1.3 Funcionalidades... 20 3.1.4 Requisitos... 24 3.1.5 Implementação... 25 3.1.6 Casos de Uso... 26 3.1.7 Modelo Lógico... 27 3.1.8 Componentes... 28 3.1.9 Distribuição... 29 3.1.10 Relacionamento Entre Casos de Uso... 29 4. PROCEDIMENTOS...31 4.1 LEVANTAMENTO DE REQUISITOS... 32 4.1.1 Identificar requisitos funcionais... 32 4.1.2 Identificar requisitos não funcionais... 33 20/3/2008 Página 3 de 64
4.1.3 Identificar alterações no modelo... 33 4.2 ESPECIFICAÇÃO DO ITEM... 35 4.2.1 Atualizar diagramas de caso de uso, atividades e implementação... 35 4.2.2 Solicitar alterações à ADO e atualizar diagrama de entidades... 36 4.2.3 Atualizar diagrama de atividades... 40 4.3 DOCUMENTAÇÃO INICIAL... 41 4.3.1 Pré-documentação da funcionalidade a ser alterada... 41 4.4 TEMPLATES DISPONÍVEIS... 44 4.4.1 Solicitação à ADO... 45 4.4.2 Protótipo de Tela... 45 4.4.3 Protótipo de Relatório... 46 4.4.4 Caso de Uso... 46 4.5 MECANISMOS DE RASTREABILIDADE... 46 4.5.1 Uso do Elemento... 46 4.5.2 Hierarquia de Uso do Elemento... 47 4.5.3 Matriz de Rastreabilidade... 50 5. APÊNDICE...51 5.1 AGREGAÇÃO... 51 5.2 CONTROLE DE VERSÃO (CVS)... 52 5.3 TRY..CATCH..END... 54 5.4 ADICIONAR AUTORES... 55 5.5 DIAGRAMA DE FONTE DE INCLUDE ( *.CH )... 57 5.6 INCLUIR OPÇÃO DE MENU... 59 5.7 FONTES LOCALIZADOS NA PASTA RAIZ DOS SISTEMAS... 61 5.8 DOCUMENTAÇÃO DE JOB... 61 20/3/2008 Página 4 de 64
Introdução Esse documento tem por objetivo estabelecer as melhores práticas para a elaboração de análises de sistemas na área de Desenvolvimento de Software do SICREDI, através da ferramenta Enterprise Architect (EA). 20/3/2008 Página 5 de 64
1. Enterprise Architect 1.1 Visão geral O Enterprise Arquitect é uma ferramenta CASE (Computer Aided Software Engineering) para desenhar e construir sistemas baseando-se na UML 2.0. 1.2 Licenças O EA possui duas licenças que serão utilizadas: - Corporate: utilizada pelos Analistas de Sistemas para criação dos diagramas. - Lite (viewer): utilizada pelos Programadores e Analistas de Testes para consulta dos diagramas. 1.3 Padrões Serão utilizados dois padrões distintos de projetos no EA: - padrão para linguagens de programação estruturada (PE); - padrão para linguagens orientadas a objetos (OO). 1.4 Configuração Para armazenar a documentação, podemos utilizar duas formas: - Banco de dados: o projeto é armazenado no Oracle (esta opção será utilizada em novos projetos). Para conexão no banco, será utilizado o Oracle Provider for OLE DB, na opção Connect to server..., disponível na tela principal. Nesta opção devem ser configurados o nome do banco e o schema para conectar, conforme exemplos abaixo: 20/3/2008 Página 6 de 64
Telas de conexão no banco de dados Oracle - Master e Réplicas: o projeto fica na rede em um arquivo Design Master e cada Analista cria um arquivo réplica para sincronizar. Para a criação do arquivo Master, já existe um template padrão, que deve ser solicitado à Qualidade de Software (esta opção não será mais utilizada). 20/3/2008 Página 7 de 64
2. Diagramas, Elementos e Ligações 2.1 Diagramas O EA trabalha com os diagramas padrões da UML e outros estendidos que serão utilizados. Os diagramas podem ser incluídos nas views e packages através da opção Add Diagram..., disponível no botão direito do mouse, conforme abaixo: Nos diagramas estruturais da UML, estaremos utilizando os seguintes: - Package: para agrupar diagramas ou outras packages; - Class: para diagramas de classes de sistemas orientado a objetos; - Component: para componentes de software e códigos-fonte; - Deployment: para diagramar as arquiteturas das aplicações. 20/3/2008 Página 8 de 64
Nos diagramas comportamentais da UML, estaremos utilizando os seguintes: - Use Case: para diagramar casos de uso, atores e seus relacionamentos; - Activity: para diagramar o fluxo de atividades dos casos de uso. Nos diagramas estendidos da ferramenta, estaremos utilizando os seguintes: 20/3/2008 Página 9 de 64
- Requirements: para diagramar os requisitos de cada caso de uso (funcionais, não-funcionais, protótipos, tabelas e componentes de software envolvidos, etc.); - Maintenance: para diagramar as alterações (change requests) efetuadas no modelo ou sistema; 2.2 Elementos e Ligações Nesta seção estaremos especificando os tipos de elementos utilizados nos diagramas, suas respectivas ligações e as cores padrões de cada tipo. 2.2.1 Caso de Uso Elemento Objetivo Utilizado nos Diagramas Especificará o caso de Casos de Uso e uso a da Requisitos. funcionalidade. Ligações Casos de uso podem estar ligados entre si através de include ou extend. Observações 2.2.2 Requisitos Os requisitos utilizarão os elementos Requirement, sendo divididos nos tipos abaixo: 20/3/2008 Página 10 de 64
Elemento Objetivo Utilizado nos Diagramas Especifica os requisitos Requisitos e Atividades. de negócio necessários à funcionalidade. Geralmente são apontados na Análise de Negócio. Especifica o layout do relatório da funcionalidade. Especifica o layout de tela da funcionalidade. Especifica o layout do arquivo que o sistema está gerando ou importando. Especifica sugestões de Testes para auxiliar o Analista de Testes na identificação de impactos para validar a implementação. 2.2.3 Alterações Requisitos e Atividades. Requisitos e Atividades. Requisitos e Atividades. Manutenção Ligações Devem ser ligados com realisation no diagrama de requisitos, tendo como origem o caso de uso e destino o requisito, e com dependency no diagrama de atividades, tendo como origem a atividade e destino o requisito. Devem ser ligados com realisation no diagrama de requisitos, tendo como origem o caso de uso e destino o requisito, e com dependency no diagrama de atividades, tendo como origem a atividade e destino o requisito. Devem ser ligados com realisation no diagrama de requisitos, tendo como origem o caso de uso e destino o requisito, e com dependency no diagrama de atividades, tendo como origem a atividade e destino o requisito. Devem ser ligados com realisation no diagrama de requisitos, tendo como origem o caso de uso e destino o requisito, e com dependency no diagrama de atividades, tendo como origem a atividade e destino o requisito. Devem ser ligados com dependency ao change no diagrama de manutenção. Observações Deve possuir um documento vinculado utilizando o template Protótipo de Relatório, através da opção Linked Document. Deve possuir um documento vinculado utilizando o template Protótipo de Tela, através da opção Linked Document. Deve possuir um documento vinculado utilizando o template Protótipo de Arquivo, através da opção Linked Document. Sua utilização é opcional. As alterações utilizarão os elementos Change, conforme abaixo: Elemento Objetivo Utilizado nos Diagramas Especificar as Manutenção alterações realizadas no sistema (change requests). Ligações Devem ser ligadas sempre com trace em todos os diagramas. Observações Podem estar ligadas no caso de uso ou nos requisitos no diagrama de requisitos. 20/3/2008 Página 11 de 64
2.2.4 Classes As classes no padrão OO utilizarão poderão ser importadas de sistemas já existentes via engenharia reversa, e seguirão o padrão da ferramenta usando o elemento Class, conforme abaixo: Elemento Objetivo Utilizado nos Diagramas Especificar as classes Classes dos sistemas orientados a objetos. 2.2.5 Tabelas Ligações Devem ser ligadas entre si com os padrões UML no diagrama de Classes e com dependency nos diagramas de requisitos e atividades. Observações As tabelas e outros objetos do banco de dados utilizarão o elemento do tipo Class com stereotype Table na view Banco de Dados, conforme abaixo: Elemento Objetivo Utilizado nos Diagramas Especificar as tabelas e Classes outros objetos do banco de dados. Ligações Devem ser ligadas entre si e nos outros diagramas com dependency. Observações 2.2.6 Componentes abaixo: Os componentes de software serão documentados utilizando os tipos de elementos Elemento Objetivo Utilizado nos Diagramas Especificar páginas Componentes WEB e outros códigosfontes da camada View da aplicação. Ligações Devem ser ligadas entre si e nos outros diagramas com os padrões UML. Observações Tipo do elemento é Class com stereotype web page. Especificar funções públicas (Clipper,PL/SQL e outras linguagens padrão PE). Especificar arquivos de configuração. Componentes Componentes ou Classe Devem ser ligadas nos diagramas com dependency. Deve ser ligadas através de trace ao change de alteração Deve ser utilizada a tecla F4 para alterar a cor da borda do componente para vermelho. 20/3/2008 Página 12 de 64
2.2.7 Atividades Nos diagramas de atividades serão utilizados os elementos abaixo: Elemento Objetivo Utilizado nos Diagramas ActivityInitial: Atividades Especifica o início do fluxo. ActivityFinal: Especifica Atividades o fim do fluxo. Ligações Control Flow Control Flow Observações FlowFinal: Especifica o encerramento do fluxo antes de chegar no final. Também é utilizado para encerrar iterações de loops. Activity: Especifica a execução de uma atividade no fluxo. Atividades Atividades Control Flow Control Flow Activity: Especifica a execução de uma atividade composta no fluxo, ou seja, redireciona para outro diagrama de atividades. Structured Activity: Especifica atividades compostas e estruturadas, como laços de repetição. Action: Especifica ações no fluxo, como por exemplo, controle de transações. Decision: Especifica desvios condicionais no fluxo (If e Case). Merge: Especifica o agrupamento de várias entradas do fluxo. Object: Especifica o fluxo de dados entre as atividades, como por exemplo, variáveis e arrays. Atividades Control Flow Para criar a atividade composta é utilizada a opção Advanced- >Composite Element, disponível clicando-se com o botão direito no elemento. Atividades Control Flow Para loops deve ser selecionado a opção Loop Node na criação do elemento. Atividades Control Flow Usada para cada passo do controle de transação: BEGIN TRANSACTION, ROLLBACK e COMMIT. Atividades Control Flow Atividades Control Flow Deve ser utilizado antes de um elemento que pode receber mais de uma entrada. Atividades Control Flow Na ligação com Control Flow, a cor do conector deve ser cinza ao invés de preto. A cor deve ser: Red: 210 Green: 230 Blue: 211 Seguem abaixo alguns exemplos de diagramas com seus elementos e ligações: 20/3/2008 Página 13 de 64
Diagrama de requisitos, seus elementos e tipos de ligações. Diagrama de atividades e seus elementos. 20/3/2008 Página 14 de 64
20/3/2008 Página 15 de 64
3. Estruturas dos Projetos 3.1 Padrões de Estruturas de Projetos O projeto conterá todos os sistemas de uma determinada família, e as views para separar os diagramas seguirão os padrões definidos por tipo de linguagem, conforme abaixo: - a estrutura padrão para linguagens de programação estruturada (PE) utilizará as seguintes views: Banco de Dados, Funcionalidades, Implementação, Manutenção e Relacionamento Entre Casos de Uso. - a estrutura padrão para linguagens orientadas a objetos (OO) utilizará as seguintes views: Banco de Dados, Requisitos, Casos de Uso, Modelo Lógico, Componentes, Distribuição e Manutenção. 20/3/2008 Página 16 de 64
O conteúdo de cada view será detalhado a seguir. 3.1.1 Manutenção A view Manutenção possui a finalidade de documentar as alterações (change requests) realizadas no modelo e por conseqüência, no sistema. Abaixo a estrutura no Project Browser: Estrutura da view Manutenção 20/3/2008 Página 17 de 64
Nesta view existirão packages para as versões, itens e Artefatos do PDS, facilitando a localização das implementações dentro do modelo. Para documentar estas alterações, o diagrama utilizado será do tipo Manutenção (Maintenance) e para as alterações serão utilizados os elementos do tipo Change. Segue abaixo exemplo do diagrama de manutenção e como fazer o rastreamento dos elementos. Diagramas de Manutenção com Alterações e Sugestões de Teste Pressionando-se CTRL+U sobre a alteração podemos rastrear os pontos de utilização da alteração, conforme abaixo: Tela de utilização dos elementos nos diferentes diagramas 20/3/2008 Página 18 de 64
Na package Artefatos do PDS será indicado os documentos que serão gerados durante o processo de desenvolvimento de software. AN (Análise de Negócio): independente de serem chamados de PI (projeto de implementação) ou serem anexados no SGDWeb com outro nome, ao entrar para o controle de versões deverão necessariamente receber o prefixo AN_*. CAR (Checklist de Avaliação de Requisitos) FER (Formulário de Entendimento de Requisitos) RAI (Relatório de Análise de Impacto) O objeto CAR deve estar linkado a versão do pacote através de dependency. Para o exemplo abaixo deverão ser utilizados os diagramas do tipo package diagram. Os objetos AN, FER E RAI devem estar linkados através de dependency ao change de manutenção do item. 20/3/2008 Página 19 de 64
3.1.2 Banco de Dados A view Banco de Dados conterá as tabelas e os objetos do banco utilizados pelo sistema. Para documentar estes objetos, o diagrama utilizado será do tipo Classes (Logical) e os elementos serão do tipo Class com stereotype Table. Já existe um objeto customizado com estas características que deverá ser utilizado. Nas tabelas não serão documentados os atributos, somente seus relacionamentos de forma simplificada, pois o modelo ER completo poderá ser solicitado à ADO. Segue abaixo a estrutura no Project Browser: Diagrama da View Banco de Dados 3.1.3 Funcionalidades A view Funcionalidades será utilizada somente no padrão PE e conterá a especificação (requisitos) e fluxo (atividades) de cada funcionalidade do sistema. 20/3/2008 Página 20 de 64
As funcionalidades estarão agrupadas em packages pelo seu tipo específico: Biblioteca, Cadastros, Consultas, Movimentação, Parâmetros, Processamento e Relatórios. Cada funcionalidade conterá sempre duas packages: Especificação e Fluxo. View Funcionalidades Na Especificação, o diagrama utilizado será do tipo Requisitos (Requirements) e os elementos utilizados serão os seguintes: Class,Use Case e Requirements. Além de seus próprios elementos, o diagrama de requisitos possui elementos de outras views ligados no Caso de Uso. O diagrama de requisitos tem como objetivo especificar os requisitos funcionais e não funcionais necessários à funcionalidade, quais os componentes de software que implementam a mesma, quais tabelas serão impactadas e as alterações executadas na funcionalidade. 20/3/2008 Página 21 de 64
Diagrama de Requisitos e seus elementos Podem existir casos em que a funcionalidade que está sendo diagramada esteja duplicada no Legado e em PL/SQL. Somente nestes casos poderão existir dois componentes de software ligados a um Caso de Uso, conforme exemplo abaixo: Funções equivalentes no Legado e em PL/SQL 20/3/2008 Página 22 de 64
No Fluxo, o diagrama utilizado será do tipo Atividade (Activity) e os elementos utilizados serão os descritos na tabela vista anteriormente. Além de seus próprios elementos, o diagrama de atividades ainda poderá conter atividades com requisitos ligados, indicando a execução dos mesmos. Diagrama de atividades, com alguns requisitos vinculados à certas atividades O diagrama de atividades deve ser detalhado o suficiente para que o programador consiga implementar a rotina sem maiores dúvidas. 20/3/2008 Página 23 de 64
3.1.4 Requisitos A view Requisitos será utilizada somente no padrão OO será semelhante à view Funcionalidades, pois conterá a especificação (requisitos) de cada funcionalidade do sistema ou ainda requisitos padrões a todas as funcionalidades (Ex: campos padrões, etc.). As funcionalidades também estarão agrupadas em packages pelo seu tipo específico: Biblioteca, Cadastros, Consultas, Movimentação, Parâmetros, etc. View Requisitos O diagrama utilizado será do tipo Requisitos (Requirements) e os elementos utilizados serão os Requirements. Além de seus próprios elementos, o diagrama de requisitos possuirá elementos de outras views, tais como Class, Use Case e Components. O diagrama de requisitos tem como objetivo especificar os requisitos funcionais e não funcionais necessários à funcionalidade, quais os componentes de software (ou classe) que implementam a mesma, quais tabelas serão impactadas e as alterações executadas na funcionalidade. Diagrama de requisitos de sistemas orientados a objetos 20/3/2008 Página 24 de 64
3.1.5 Implementação A view Implementação será utilizada somente no padrão PE e conterá os fontes do do sistema. Cada código-fonte terá uma package com seu nome e extensão, separadas por packages da estrutura física do projeto. Na Implementação, o diagrama utilizado será do tipo Componentes (Components) e os elementos utilizados serão do tipo Component. Deverão ser documentadas somente as funções e procedures públicas do sistema, pois as estáticas ficaram sobre responsabilidade do codificador. View Implementação com suas packages e componentes Os componentes deverão ter sua cor da borda alterada para vermelho, através da tecla F4 com o componente selecionado. Os componentes serão utilizados para identificar qual função pública implementa um determinado caso de uso, conforme exemplo a seguir: Componente indica qual função implementa o caso de uso 20/3/2008 Página 25 de 64
3.1.6 Casos de Uso A view Casos de Uso será utilizada somente no padrão OO e conterá os Casos de Uso do sistema no padrão UML, somente com relacionamentos entre outros casos de uso e atores, separados em packages de acordo com sua funcionalidade. View Casos de Uso Na view Casos de Uso terá a package Relacionamento Entre Casos de Uso, que armazenará o relacionamento entre Casos de Uso. Nos Casos de Uso, o diagrama utilizado será do tipo Casos de Uso (Use Case) e os elementos utilizados serão do tipo Use Case e Actors. 20/3/2008 Página 26 de 64
Diagrama de Caso de Uso, seus elementos e relacionamentos 3.1.7 Modelo Lógico A view Modelo Lógico será utilizada somente no padrão OO e conterá o Modelo Lógico do sistema no padrão UML, somente com suas classes e os relacionamentos entre elas, separados em packages de acordo com a estrutura do projeto. Nos projetos já existentes pode ser utilizada a opção de engenharia reversa para importar as classes, na opção do Code Engineering -> Import Source Directory do menu do botão direito. View Modelo Lógico 20/3/2008 Página 27 de 64
(Class). No Modelo Lógico, o diagrama e os elementos utilizados serão do tipo Classes Diagrama de Classes 3.1.8 Componentes A view Componentes será utilizada somente no padrão OO será semelhante à view Implementação do padrão PE, contendo o restante dos componentes de software do sistema orientado a objetos (páginas, arquivos XML, fontes PL/SQL, etc.) e a relação destes componentes com as classes e as camadas da aplicação (view, model, controller, etc.), separados em packages de acordo com a estrutura do projeto. View Componentes Nos projetos já existentes, também pode ser utilizada a opção de engenharia reversa para importar os componentes. 20/3/2008 Página 28 de 64
Diagrama de componentes com as camadas da aplicação 3.1.9 Distribuição A view Distribuição será utilizada somente no padrão OO e conterá a visão da arquitetura da aplicação (topologia, servidores, etc.). Esta view não será obrigatória por enquanto, mas é de grande valia para elucidar a arquitetura de produção para novos profissionais. 3.1.10 Relacionamento Entre Casos de Uso A view Relacionamento Entre Casos de Uso será utilizada somente no padrão PE, no padrão OO o Relacionamento Entre Casos de Uso estará na view Casos de Usos. Está view conterá os Relacionamentos entre os Casos de Uso mais importantes do Sistema. O tipo de relacionamento utilizado nos diagrama de Relacionamentos Entre Casos de Uso é dependency. 20/3/2008 Página 29 de 64
Diagrama Relacionamento Entre Casos de Uso 20/3/2008 Página 30 de 64
4. Procedimentos O processo de Análise de Sistemas está composto por duas principais etapas: Levantamento de Requisitos da Análise de Negócio e Especificação do Item para desenvolvimento. Além destas, também pode existir a necessidade de mais uma etapa de Documentação Inicial, caso não exista documentação de Análise de Negócios. act Inicial Funcionalidade documentada [Nao] Documentação inicial [Sim] Levantamento de Requisitos Especificação do item 20/3/2008 Página 31 de 64
4.1 Levantamento de Requisitos act Lev antamento de Requisitos Identificar requisitos funcionais Identificar requisitos nao funcionais Identificar alterações no modelo 4.1.1 Identificar requisitos funcionais Sem dúvida esta é a atividade mais importante da Análise de Sistemas. Identificar os requisitos funcionais pode não ser tão simples quanto parece, pois podem estar escondidos no texto da Análise de Negócio ou, muitas vezes, implícitos. Um requisito pode ser definido como "uma condição ou uma capacidade com a qual o sistema deve estar de acordo". Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar, sem levar em consideração restrições físicas. Especificam, portanto, o comportamento de entrada e saída de um sistema. São documentados na pasta Manutenção como requisito ou alteração (se o requisito já existir deve ser registrada uma alteração). Quando uma alteração é realizada deve ser vinculada com o link Trace ao requisito ou ao caso de uso. Abaixo um exemplo de um requisito de manutenção visando incluir um campo na tela do cadastro de finalidades. 1: ALT-001 é uma mudança do requisito REQ-0037 20/3/2008 Página 32 de 64
4.1.2 Identificar requisitos não funcionais Requisitos não funcionais estabelecem restrições gerais do sistema em termos de usabilidade, performance, confiabilidade, documentação, entre vários outros. Estes podem estar diretamente ligados ao caso de uso (mediante Realisation ) ou a qualquer outro elemento. Abaixo um exemplo de requisitos não funcionais: As linhas vermelhas apontam os requisitos não funcionais. Isto é, os que não evitam que a rotina funcione, mas garantem sua qualidade. 4.1.3 Identificar alterações no modelo Uma vez que os requisitos funcionais e não funcionais foram identificados devem ser vinculados ao modelo existente. Para isto utiliza-se o link Trace. Veja exemplo abaixo: 20/3/2008 Página 33 de 64
Podemos visualizar que, para o item 2296, foi identificado uma alteração na rotina de atualização de base. O requisito de alteração (em verde) está ligado ao requisito funcional Atualização de Base. A leitura deste diagrama é que a Atualização de base da funcionalidade sofreu uma alteração no item 2296. No gráfico acima, observa-se que o item 2298 implementou uma atualização de base (requisito funcional) e uma alteração na tela do cadastro. 20/3/2008 Página 34 de 64
4.2 Especificação do Item 4.2.1 Atualizar diagramas de caso de uso, atividades e implementação Neste ponto já estão todos os requisitos levantados e colocados dentro da pasta de manutenção (no respectivo item e versão) e ligados nos casos de uso impactados. Neste momento devemos detalhar cada implementação utilizando os templates fornecidos na ferramenta e comentários que sejam necessários para garantir que o programador capte o solicitado. Um exemplo de detalhamento por comentários pode ser observado abaixo: req Especificação REQ-0026: tecla [ESC] 20/3/2008 Página 35 de 64
A tela acima pode ser acessada com um duplo-click no requisito (ou em qualquer outro elemento). Quando o requisito for de tela, relatório, alteração de tabela ou algum outro que necessite de uma especificação mais complexa, utilizam-se os templates e documentos vinculados. 4.2.2 Solicitar alterações à ADO e atualizar diagrama de entidades Sempre que existir alteração ou criação de tabelas, deve-se utilizar um requisito de alteração com um documento vinculado através da opção do botão direito Linked Document..., utilizando o template de Solcitação ADO. Veja abaixo um exemplo: 20/3/2008 Página 36 de 64
req item 2298 ALT-0002: Nova tabela A alteração também deve ser ligada à tabela, para rastreamento dos objetos impactados. class ER grupo_empreendimento_ccrpfina «trace» ALT-0002: Nova tabela (from item 2298) Além disto, deve ser adicionada uma tag na change, através do botão direito, seleciondo-se a opção Add e em seguida Tagged Value..., conforme imagem abaixo: 20/3/2008 Página 37 de 64
Na combo box do campo Tag:, deve ser selecionado o valor ADO, que já estará previamente cadastrado, conforme imagem abaixo: No campo Value: deve ser informado o valor TRUE, em letras maiúsculas, conforme imagem abaixo: 20/3/2008 Página 38 de 64
Segue abaixo o template para solicitações à ADO: Para enviar esta solicitação à ADO, deve ser criada uma atividade avulsa no SGD com dos dados abaixo: Padrão que deve estar no campo Descrição da atividade Nome do repositório/equipe: <exemplo: eap_sicredi, eap_sis> Nome da pasta: <ex.:canais de Apoio> Sistema: <sigla do sistema> Versão do sistema: <onde está sendo realizada a alteração> Nº item: <nº do item no SGD que está saindo a alteração> Nº subitem: <nº do subitem da alteração caso exista> Nome do change: <change/requisito de alteração que contém o documento linkado> 20/3/2008 Página 39 de 64
4.2.3 Atualizar diagrama de atividades O diagrama de atividades é o mais importante para o desenvolvedor. Este valida e especifica o caso de uso e seus requisitos. O detalhamento do diagrama depende da necessidade de especificar certa funcionalidade. Exemplo: Observa-se que estão alocados os principais requisitos levantados na especificação e as tabelas impactadas no item. Isto é opcional, mas altamente recomendado. 20/3/2008 Página 40 de 64
4.3 Documentação Inicial act Documentação inicial Lev antamento de requisitos básicos Levantamento de tabelas env olv idas Esboço do protótipo de tela e relatório Atualizar diagrama de implementação Diagrama de ativ idades básico Montar diagrama de caso de uso com seus requisitos 4.3.1 Pré-documentação da funcionalidade a ser alterada As primeiras especificações não terão documentação na ferramenta. Portanto, torna-se necessário realizar um pré-levantamento da funcionalidade impactada. Os diagramas que devem ser criados e mantidos são os mesmos mencionados neste documento, mas de uma forma simplificada evitando um impacto inicial alto. Ao passar do tempo estas análises serão complementadas elevando o nível de detalhamento. O primeiro passo é identificar o fonte e inseri-lo no diagrama de implementação. Depois, monta-se o caso de uso e realiza-se um levantamento básico de requisitos (ações da rotina e outros pontos que sejam relevantes para a alteração proposta pelo item). Realiza-se um mapeamento das principais tabelas envolvidas e criam-se (se ainda não existirem) no diagrama de Entidades. Com tudo isto pronto monta-se o diagrama de atividades básico visando suportar as alterações propostas. Abaixo, um exemplo do cadastro de finalidades do sistema de crédito, onde o item 2298 solicitou um novo campo na tela. 20/3/2008 Página 41 de 64
req item 2298 ALT-0001: Incluir campo para grupo de empreendimento REQ-0039: Os grupos devem ser selecionados mediante um browse ALT-0002: Nova tabela REQ-0049: Atualização de Base 2: levantamento das alterações necessárias para o item 2298 (no diagrama de manutenção) 3: Diagrama de caso de uso e requisitos da rotina. 20/3/2008 Página 42 de 64
20/3/2008 Página 43 de 64
4: Diagrama de atividades inicial da rotina. Observa-se que está simplificado mas esboça perfeitamente seu comportamento. 5: Protótipo básico da tela da rotina 4.4 Templates disponíveis O EA permite a inclusão de templates para facilitar a especificação das funcionalidades. Para vincular um template utilizar a opção Linked Document (ou CTRL+ALT+D) de cada objeto do diagrama. 20/3/2008 Página 44 de 64
Seleção de templates disponíveis 4.4.1 Solicitação à ADO Este template visa documentar as alterações de estrutura de tabelas e a criação/ manutenção de índices. Sempre deve ser vinculado a um requisito de mudança de estrutura ou criação de tabelas/objetos no banco de dados. 4.4.2 Protótipo de Tela Protótipos de tela visam especificar, de forma completa, as telas e campos da funcionalidade. O template deve estar vinculado a um requisito de tela. Requisito de tela em azul no diagrama de requisitos. 20/3/2008 Página 45 de 64
Seleção do Tipo de Requisito 4.4.3 Protótipo de Relatório A especificação funciona da mesma forma que o protótipo de tela, ou seja, é um requisito do tipo relatório e um template vinculado para esta finalidade. 4.4.4 Caso de Uso O caso de uso pode ser estendido vinculando-se a um template de caso de uso, especificando cenários e condições. 4.5 Mecanismos de Rastreabilidade Há três mecanismos de rastreabilidade que são recomendados para fins de análise de impacto ou mesmo entendimento e localização da utilização de elementos (casos de uso, requisitos, tabelas, etc.). 4.5.1 Uso do Elemento É possível rastrear a utilização de um elemento em todos os diagramas que utilizam este elemento. Para isto, basta clicar sobre o elemento e utilizar uma das opções abaixo: Menu Element > Find in diagrams... 20/3/2008 Página 46 de 64
CTRL + U Seleção do Diagrama que está usando o elemento 4.5.2 Hierarquia de Uso do Elemento Sintetizando, permite rastrear a utilização de um elemento segundo as visões: necessário para (needed by), depende de (depends on) e aponta para (links to). Menu View > Hierarchy CTRL + SHIFT + 4 A seguir seguem exemplos do uso deste recurso. 20/3/2008 Página 47 de 64
Hierarquia do objeto com profundidade nível 5 Hierarquia do objeto com profundidade nível 2 20/3/2008 Página 48 de 64
É possível fazer a configuração do nível de profundidade que se deseja adentrar quanto aos elementos relacionados. Quanto maior a profundidade, mais demorado tende a ser a montagem do resultado da pesquisa de hierarquia, contudo, mais ricos serão os resultados em termos de favorecer uma correta análise de impacto. A configuração padrão do EA faz a hierarquia até o 5º nível a partir do elemento pesquisado. Para realizar esta configuração deve-se acessar o menu Tools > Options > aba General > campo Max Hierarchy View Depth. 20/3/2008 Página 49 de 64
4.5.3 Matriz de Rastreabilidade Possibilita visualizar os relacionamentos entre todos os elementos, a partir de um pacote de origem e um pacote destino, sendo de um tipo (caso de uso, requisito, etc) versus outro, contendo ligações do tipo dependência, realização, etc.. Para o caso, recomenda-se que seja feito o uso deste recurso aplicado para o pacote (origem (source) e destino (target)) Caso de Uso > Funcionalidades (do sistema em questão), tipo (type) Use Case versus Use Case, e tipo de ligação (Link Type) dependência (dependency). Isto fará com que a matriz de rastreabilidade seja montada com a finalidade de exibir as dependências entre os casos de uso existentes a partir do pacote de origem e destino. Para fazer uso da matriz e informar estes parâmetros deve-se acessar o menu View > Relationship Matrix. Importante: após configurar e gerar a matriz use o botão Options > Profiles > Save as New Profile para salvar a configuração da matriz do sistema em questão (no exemplo, foi salvo como Matriz Site UFV). Matriz de rastreabilidade de dependências entre casos de uso 20/3/2008 Página 50 de 64
5. Apêndice 5.1 Agregação Um conceito que pode ser utilizado na diagramação é Agregação. Veja exemplo abaixo: act teste Tela do produto 01 Tela do produto 02 Tela do produto 03 Tela principal Funcionalidade Observamos que a tela principal do sistema está composta por três outras telas. Cada uma das três telas deve conter um protótipo de tela vinculado. Este recurso pode ser aplicado praticamente em qualquer elemento. Abaixo outro exemplo com requisitos da funcionalidade: req teste Permitir consulta de associados com [F4] Funcionalidade Seleciona com [Enter] e cancela com [ESC] Permitir consulta de títulos com [F4] 20/3/2008 Página 51 de 64
Selecionar com a tecla [Enter] e canelar com a tecla [ESC] deve ser atendido pelos dois requisitos. 5.2 Controle de Versão (CVS) O Controle de Versão do modelo será realizado via CVS e no mesmo repositório dos sistemas. Ao final de cada pacote, o projeto deve ser exportado para XML e armazenados no CVS, na pasta analise_sistemas de cada sistema. Estrutura do CVS para especificações EA 20/3/2008 Página 52 de 64
Para fazer a exportação os seguintes passos devem ser seguidos: Clicar com o botão direito no modelo do sistema, selecionem a opção Export Model to XMI... Na caixa de diálogo, informar o caminho e nome do arquivo XML a ser criado e na opção XMI Type selecionem UML 2.1 (XMI 2.1). Após clicar no botão Export. Os arquivos gerados devem ser commitados na pasta analise_de_sistemas de cada sistema. 20/3/2008 Página 53 de 64
5.3 Try..Catch..End Para documentar o Try..Catch..End deve ser utilizado o exemplo abaixo: 20/3/2008 Página 54 de 64
5.4 Adicionar Autores Para adicionar autores devem ser seguidos os passos abaixo: Selecionar a opção do menu Settings -> People -> Project Authors Para adicionar o autor nos diagramas, basta clicar no botão New Diagram Notes, e para mudar, clicar com o botão direito no diagrama e depois acessar Properties..., selecionando o autor na combo box. 20/3/2008 Página 55 de 64