UM PROCESSO DE GERENCIAMENTO DE CONFIGURAC˘AO DE...
176
INPE-15243-TDI/1330 UM PROCESSO DE GERENCIAMENTO DE CONFIGURA ¸ C ˜ AO DE SOFTWARE COM REPOSIT ´ ORIO DE ARTEFATOS DEFINIDOS DINAMICAMENTE Roberta Panzera Tavares Disserta¸c˜ ao de Mestrado do Curso de P´ os-Gradua¸ c˜ aoemComputa¸c˜aoAplicada, orientada pelos Drs. Nilson Sant’Anna e Solon Venˆ ancio de Carvalho, aprovada em 6 de novembro de 2007. O original deste documento est´ a dispon´ ıvel em: <http://urlib.net/sid.inpe.br/mtc-m17@80/2008/02.12.12.07> INPE S˜ ao Jos´ e dos Campos 2007
Transcript of UM PROCESSO DE GERENCIAMENTO DE CONFIGURAC˘AO DE...
INPE-15243-TDI/1330
UM PROCESSO DE GERENCIAMENTO DE
CONFIGURACAO DE SOFTWARE COM REPOSITORIO DE
ARTEFATOS DEFINIDOS DINAMICAMENTE
Roberta Panzera Tavares
Dissertacao de Mestrado do Curso de Pos-Graduacao em Computacao Aplicada,
orientada pelos Drs. Nilson Sant’Anna e Solon Venancio de Carvalho, aprovada em 6 de
novembro de 2007.
O original deste documento esta disponıvel em:
<http://urlib.net/sid.inpe.br/mtc-m17@80/2008/02.12.12.07>
INPE
Sao Jose dos Campos
2007
PUBLICADO POR:
Instituto Nacional de Pesquisas Espaciais - INPE
Gabinete do Diretor (GB)
Servico de Informacao e Documentacao (SID)
Caixa Postal 515 - CEP 12.245-970
Sao Jose dos Campos - SP - Brasil
Tel.:(012) 3945-6911/6923
Fax: (012) 3945-6919
E-mail: [email protected]
CONSELHO DE EDITORACAO:
Presidente:
Dr. Gerald Jean Francis Banon - Coordenacao Observacao da Terra (OBT)
Membros:
Dra Maria do Carmo de Andrade Nono - Conselho de Pos-Graduacao
Dr. Haroldo Fraga de Campos Velho - Centro de Tecnologias Especiais (CTE)
Dra Inez Staciarini Batista - Coordenacao Ciencias Espaciais e Atmosfericas (CEA)
Marciana Leite Ribeiro - Servico de Informacao e Documentacao (SID)
Dr. Ralf Gielow - Centro de Previsao de Tempo e Estudos Climaticos (CPT)
Dr. Wilson Yamaguti - Coordenacao Engenharia e Tecnologia Espacial (ETE)
BIBLIOTECA DIGITAL:
Dr. Gerald Jean Francis Banon - Coordenacao de Observacao da Terra (OBT)
Marciana Leite Ribeiro - Servico de Informacao e Documentacao (SID)
Jefferson Andrade Ancelmo - Servico de Informacao e Documentacao (SID)
Simone A. Del-Ducca Barbedo - Servico de Informacao e Documentacao (SID)
REVISAO E NORMALIZACAO DOCUMENTARIA:
Marciana Leite Ribeiro - Servico de Informacao e Documentacao (SID)
Marilucia Santos Melo Cid - Servico de Informacao e Documentacao (SID)
Yolanda Ribeiro da Silva e Souza - Servico de Informacao e Documentacao (SID)
EDITORACAO ELETRONICA:
Viveca Sant´Ana Lemos - Servico de Informacao e Documentacao (SID)
INPE-15243-TDI/1330
UM PROCESSO DE GERENCIAMENTO DE
CONFIGURACAO DE SOFTWARE COM REPOSITORIO DE
ARTEFATOS DEFINIDOS DINAMICAMENTE
Roberta Panzera Tavares
Dissertacao de Mestrado do Curso de Pos-Graduacao em Computacao Aplicada,
orientada pelos Drs. Nilson Sant’Anna e Solon Venancio de Carvalho, aprovada em 6 de
novembro de 2007.
O original deste documento esta disponıvel em:
<http://urlib.net/sid.inpe.br/mtc-m17@80/2008/02.12.12.07>
INPE
Sao Jose dos Campos
2007
Dados Internacionais de Catalogacao na Publicacao (CIP)
T197u Tavares, Roberta Panzera.Um processo de gerenciamento de configuracao de soft-
ware com repositorio de artefatos definidos dinamicamente/Roberta Panzera Tavares. – Sao Jose dos Campos: INPE,2007.
174p. ; (INPE-15243-TDI/1330)
1. Gerencia de configuracao de software. 2. Itens de con-figuracao. 3. Repositorio de artefatos. 4. Engenharia de soft-ware. 5. Modelos de objetos dinamicos. I. Tıtulo.
CDU 681.3.06
Copyright c© 2007 do MCT/INPE. Nenhuma parte desta publicacao pode ser reprodu-
zida, armazenada em um sistema de recuperacao, ou transmitida sob qualquer forma ou
por qualquer meio, eletronico, mecanico, fotografico, microfılmico, reprografico ou outros,
sem a permissao escrita da Editora, com excecao de qualquer material fornecido especifi-
camente no proposito de ser entrado e executado num sistema computacional, para o uso
exclusivo do leitor da obra.
Copyright c© 2007 by MCT/INPE. No part of this publication may be reproduced, stored
in a retrieval system, or transmitted in any form or by any means, eletronic, mechanical,
photocopying, microfilming, recording or otherwise, without written permission from the
Publisher, with the exception of any material supplied specifically for the purpose of being
entered and executed on a computer system, for exclusive use of the reader of the work.
“Viver é nascer lentamente”.
ANTONIO DE SAINT-EXUPÉRY
A meus pais, PEDRO JOSÉ TAVARES e
ALTIVA MARÍLIA PANZERA TAVARES.
AGRADECIMENTOS
Agradeço primeiramente a Deus por conduzir minha vida sempre para o melhor caminho e nunca me deixar desistir diante dos obstáculos encontrados. Agradeço a todas as pessoas que me ajudaram a vencer mais esta etapa da vida. Ao Instituto Nacional de Pesquisas Espaciais – INPE e ao Laboratório de Computação Aplicada – LAC, pela oportunidade de estudos e utilização de suas instalações. Aos professores do INPE pelo conhecimento compartilhado. Ao meu orientador Prof. Dr.Nilson Sant`Anna, pelo conhecimento passado, pela orientação e apoio na realização deste trabalho e por todas oportunidades a mim oferecidas. Ao professor Prof. Dr. Tatuo Nakaninshi, pela colaboração, sugestões e apoio na realização deste trabalho. Não deixando de agradecer a oportunidade e confiança em meus primeiros passos como professora. Ao professor Dr. Solon Venâncio de Carvalho, pelo apoio, colaboração e conhecimento a mim passado, dentre muitas dicas de melhoria por meio da co-orientação neste trabalho. A todos meus amigos e colegas me apoiaram e entenderam minha ausência. Aos amigos inpeanos que sempre encontram um tempo em meio as suas atividades para fazer com que hoje eu tenha lembranças fantásticas. A meus pais, grandes responsáveis por tudo que sou hoje.
RESUMO
Uma das constantes preocupações no desenvolvimento de software são o armazenamento e controle de informação gerada ao longo do projeto. Armazenar artefatos de software e gerenciá-los ao longo do projeto é um dos grandes objetivos da Gerência de Configuração de Software (GCS), processo previsto nas normas e modelos de maturidade de software. Entende-se por Artefato toda e qualquer informação produzida, consumida ou modificada por um processo, cita-se como exemplos: um pedaço de informação, um documento, um modelo, um código fonte, dentre outros. A base de todo o processo de GCS está em um repositório central onde todos os artefatos devem ser sistematicamente controlados. Controlar artefatos significa manter meta-informação e versionamento, controlar acesso de usuários concorrentes e gerenciar modificações que forem realizadas ao longo do desenvolvimento. Construir um repositório de artefatos exige conhecer características dos artefatos que serão produzidos que podem ser diferentes dependendo de cada projeto em específico. A abordagem de repositório de artefatos clássica estabelece um modelo padrão e inflexível para a definição dos artefatos. Uma abordagem que prevê alta flexibilidade e dinamismo é a utilização de modelos de objetos dinâmicos. Este trabalho apresenta uma forma de aplicação de modelos de objetos dinâmicos para a construção de um repositório de artefatos que proporciona alta flexibilidade e dinamismo na determinação das características de maneira que representem de maneira precisa os artefatos dentro de cada necessidade específica. Como estudo de caso é apresentado um processo de GCS baseado nas práticas definidas no modelo de maturidade Capability Model Maturity Integration (CMMI), que faz uso do repositório de artefatos implementado.
A SOFTWARE CONFIGURATION MANAGEMENT PROCESS WITH ARTIFACT’S REPOSITORY DEFINED DYNAMICALLY
ABSTRACT
Store and control of project’s information have been a permanent important issue in software development. Store and management of software artifacts are the main goals in the Software Configuration Management (SCM) process. Artifacts can be defined as any result produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. The core of the SCM process is a central repository where all artifacts may be formally controlled. The artifact control involves persisting meta-information and version, access control of concurrent users and management changes along the project. Building an artifact repository involves much knowledge about the artifact’s features that can be produced during the project. The classical approach of artifact repository determines an inflexible pattern to artifacts definition. The dynamic object model approach can be used to provide dynamism and flexibility. This dissertation proposes the dynamic object model approach to build a repository to provide high flexibility and dynamism in the definition of specific features to determine the more precise way in the necessity of the project. As a case study presented a SCM process is presented based on the Capability Model Maturity Integration (CMMI) maturity model practices using the dynamic repository developed.
SUMÁRIO
Pág.
LISTA DE FIGURAS.......................................................................................................
LISTA DE TABELAS......................................................................................................
CAPÍTULO 1 .............................................................................................................. 245
INTRODUÇÃO ............................................................................................................ 25 1.1 O Problema............................................................................................................... 26 1.2 Metodologia de Pesquisa .......................................................................................... 27 1.3 Trabalhos Relacionados............................................................................................ 27 1.4 Objetivos................................................................................................................... 30 1.5 Estrutura do Trabalho ............................................................................................... 32
CAPÍTULO 2 ................................................................................................................ 33
PROCESSOS DE SOFTWARE E AUTOMAÇÃO .................................................. 33 2.1 Processos de Software .............................................................................................. 33 2.2 Elementos básicos de um processo de software ....................................................... 34 2.3 Automação de processos .......................................................................................... 36 2.4 O Ambiente de Engenharia de Software e-WebProject® ........................................ 38 2.5 Considerações Sobre Processos de Software e Automação ..................................... 39
CAPÍTULO 3 ................................................................................................................ 41
PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE.............. 41 3.1 Processo de Gerência de Configuração de Software ................................................ 42 3.1.1 Conceitos básicos .................................................................................................. 43 3.2 Modelo check in/check out ....................................................................................... 44 3.2.1 Operações de Acesso............................................................................................. 44 3.3 Versão e Configuração de Artefatos......................................................................... 46 3.3.1 Desenvolvimento Paralelo ou Branch ................................................................... 47 3.3.2 Junções ou Merge .................................................................................................. 48 3.3.3 Agregações ou Configurações ............................................................................... 49 3.4 Atividades do processo de GCS ............................................................................... 50 3.4.1 SG1 – Estabelecer Baselines ................................................................................. 51 3.4.2 SG2 – Rastrear e Controlar Mudanças .................................................................. 52 3.4.3 SG3 – Estabelecer a Integridade............................................................................ 52 3.5 Ferramentas de apoio ao processo de GCS .............................................................. 53 3.6 Considerações Sobre o Processo de GCS e Ferramentas ......................................... 57
CAPÍTULO 4 ................................................................................................................ 59
OBJETOS DINÂMICOS (DYNAMIC OBJECT MODEL-DOM) ......................... 59 4.1 Padrões TypeObject Pattern e Property Pattern ....................................................... 59 4.1.1 Arquitetura TypeSquare......................................................................................... 61 4.2 Considerações sobre DOM....................................................................................... 63
CAPÍTULO 5 ................................................................................................................ 65
UM MODELO PARA REPOSITÓRIO DINÂMICO .............................................. 65 5.1 Artefatos dinâmicos.................................................................................................. 65 5.1.1 Definição da Classe do Artefato............................................................................ 66 5.1.2 Definição do Artefato ............................................................................................ 66
CAPÍTULO 6 ................................................................................................................ 73
UM PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO UTILIZANDO O REPOSITÓRIO DINÂMICO DE ARTEFATOS ..................................................... 73 6.1 Papeis Definidos....................................................................................................... 73 6.2 Fluxo de Trabalho..................................................................................................... 80 6.2.1 Fluxo de Trabalho Definir Classe de Artefato ...................................................... 81 6.2.2 Fluxo de Trabalho Definir Itens de Configuração................................................. 82 6.2.3 Fluxo de Trabalho Rastrear e Controlar Mudanças............................................... 84 6.2.4 Fluxo de Trabalho Definir Template da Configuração.......................................... 87 6.2.5 Fluxo de Trabalho Propor um Novo IC................................................................. 88 6.3 Ciclo de Vida de Artefatos e Versões....................................................................... 90 6.4 Ciclo de Vida de um Artefato................................................................................... 91 6.5 Ciclo de vida das Versões do Artefato ..................................................................... 94 6.6 Visibilidade e Versionamento de Artefatos.............................................................. 97 6.6.1 Visibilidade dos Artefatos ..................................................................................... 97 6.6.2 Determinando o Tipo de Versionamento .............................................................. 97
CAPÍTULO 7 ................................................................................................................ 99
ESTUDO DE CASO ..................................................................................................... 99 7.1 Atividade de Definição de Classe Artefato. ............................................................. 99 7.2 Atividade de Criação de Classe Artefato................................................................ 100 7.3 Atividade para definição do IC............................................................................... 101 7.4 Atividade para Permitir a Criação .......................................................................... 103 7.5 Atividade para Criação de Versão do IC................................................................ 103 7.6 Atividade para Avaliar IC....................................................................................... 105 7.7 Atividade para Fazer Check-in ............................................................................... 106 7.8 Atividade para Visualização das Versões no Repositório ...................................... 107 7.9 Atividade de Proposta de Mudança ........................................................................ 108 7.10 Atividade de Análise de Proposta de Mudança .................................................... 109 7.11 Atividade de Permissão de Check-out .................................................................. 111
CAPÍTULO 8 .............................................................................................................. 113
CONCLUSÕES........................................................................................................... 113 8.1 Contribuições.......................................................................................................... 113 8.2 Trabalhos Futuros ................................................................................................... 120
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 121
APÊNDICE A DOCUMENTAÇÃO DOS CASOS DE USO DO SISTEMA ....... 125 A1 Administrador da Configuração ............................................................................. 125 A1.1 Caso de Uso Manter Categoria de Template de Configurações .......................... 125
A1.2 Caso de Uso Manter Grau de Relacionamento.................................................... 127 A1.3 Caso de Uso Manter Tipo de Versionamento...................................................... 128 A1.4 Caso de Uso Manter Prefixo................................................................................ 130 A2 Ator Engenheiro de Artefatos................................................................................. 131 A2.1 Caso de Uso Manter Artefato Padrão .................................................................. 132 A2.2 Caso de Uso Manter Classe de Artefato .............................................................. 134 A2.3 Caso de Uso Definir Atributos da Classe Artefato.............................................. 135 A2.4 Caso de Uso Definir Composição da Classe Artefato ......................................... 136 A2.5 Definir Template de Configuração ...................................................................... 137 A2.6 Selecionar Artefatos ............................................................................................ 139 A3 Ator Engenheiro da Configuração .......................................................................... 139 A3.1 Caso de Uso Manter Configuração...................................................................... 140 A3.2 Manter Versão da Configuração.......................................................................... 142 A3.3 Selecionar I.C. ..................................................................................................... 142 A3.4 Caso de Uso Manter Releases.............................................................................. 143 A3.5 Caso de Uso Manter Lista de Distribuição.......................................................... 145 A3.6 Caso de Uso Selecionar Clientes ......................................................................... 146 A4 Ator Gerente da Configuração................................................................................ 147 A4.1 Caso de Uso Visualizar Check-out’s autorizados................................................ 148 A4.2 Caso de Uso Visualizar Evolução dos Artefatos ................................................. 149 A4.3 Caso de Uso Manter Repositório......................................................................... 149 A4.4 Caso de Uso Selecionar Baseline do Projeto....................................................... 150 A4.5 Caso de Uso Definir IC do Projeto ...................................................................... 150 A4.6 Caso de Uso Manter Versões dos Artefatos ........................................................ 151 A4.7 Caso de Uso Manter Visibilidade ........................................................................ 152 A4.8 Caso de Uso Manter Dependência....................................................................... 152 A4.9 Caso de Uso Visualizar Histórico de Operação................................................... 153 A4.10 Caso de Uso Manter Visibilidade ...................................................................... 153 A4.11 Caso de Uso Realizar Lock/UnLock .................................................................. 154 A4.12 Caso de Uso Permitir Check-out ....................................................................... 154 A4.13 Caso de Uso Analisar Proposta de Artefato ...................................................... 155 A4.14 Caso de Uso Visualizar Artefatos Propostos ..................................................... 155 A5 Ator Engenheiro de Mudanças ............................................................................... 156 A5.1 Caso de Uso Realizar Check-in ........................................................................... 157 A5.2 Caso de Uso Analisar Proposta de Mudança....................................................... 158 A6 Ator Desenvolvedor................................................................................................ 159 A6.1 Caso de Uso Propor Artefato............................................................................... 159 A6.2 Caso de Uso Manter Proposta de Mudança......................................................... 160 A6.3 Caso de Uso Visualizar Check-outs Permitidos .................................................. 160 A6.4 Caso de Uso Visualizar Artefatos para Modificação........................................... 161 A6.5 Caso de Uso Visualizar Repositório de Artefatos ............................................... 161 A7 Ator Gerente de Acompanhamento de Projeto (GCM) .......................................... 162 A7.1 Caso de Uso Permitir Criação ............................................................................. 163 A8 Ator Engenheiro da Qualidade (GCM)................................................................... 163 A8.1 Caso de Uso Aprovar Artefatos........................................................................... 164
APÊNDICE B MODELO RELACIONAL DO SISTEMA .................................... 165
LISTA DE FIGURAS
2.1 Elementos básicos de um processo de software FONTE: Acuñ (2001)................... 36 2.2 Componentes e camada conceitual do ambiente. FONTE: Sant´Anna (2000) ........ 39 3.1 Modelo check-in/check-out....................................................................................... 45 3.2 Controle de Versão. FONTE: Abdala (2003)........................................................... 47 3.3 Desenvolvimento paralelo. FONTE: Mackay (1995)............................................... 48 4.1 TypeObject Pattern, exemplo FONTE: Adaptada de Yoder (2001). ....................... 60 4.2 Property Pattern, exemplo FONTE: Adaptada de Yoder (2001). ........................... 61 4.3 Arquitetura TypeSquar FONTE: Adaptada de Yoder (2001).................................. 61 4.4 Modelagem convencional da classe Planeta............................................................. 62 5.1 Arquitetura de Definição do Artefato. ...................................................................... 68 5.2 Diagrama de objetos para a definição da estrutura dos artefatos. ............................ 69 5.3 Diagrama de Objetos definição do Artefato. ............................................................ 70 6.1 Casos de Uso do Papel Administrados da Configuração. ........................................ 74 6.2 Casos de Uso do Papel Engenheiro de Artefatos. .................................................... 75 6.3 Casos de Uso do Papel Engenheiro da Configuração............................................... 76 6.4 Casos de Uso do Papel Gerente da Configuração. ................................................... 77 6.5 Casos de Uso do Papel Engenheiro de Mudanças.................................................... 78 6.6 Casos de Uso do Papel Desenvolvedor. ................................................................... 79 6.7 Casos de Uso do Papel Gerente de Acompanhamento de Projeto. .......................... 80 6.8 Casos de Uso do Papel Engenheiro da Qualidade.................................................... 80 6.9 Fluxo de Trabalho Definir Classe Artefato. ............................................................. 81 6.10 Fluxo de Trabalho Definir Itens de Configuração.................................................. 82 6.11 Fluxo de Trabalho Rastrear e Controlar Mudanças................................................ 85 6.12 Fluxo de Trabalho Definir Template de Configuração........................................... 87 6.13 Fluxo de Trabalho Propor Novo IC........................................................................ 89 6.14 Diagrama de Estados do Ciclo de Vida do Artefato............................................... 92 6.15 Diagrama de Estados do Ciclo de Vida da Versão................................................. 95 7.1 Caso de Uso Definição de Classe Artefatos. ............................................................ 99 7.2 Formulário de Criação de Classe Artefato. ............................................................ 100 7.3 Interface de Acesso ao Repositório de Artefatos.................................................... 101 7.4 Formulário de Definição do IC para o Projeto. ...................................................... 102 7.5 Formulário para Permitir a Criação do IC. ............................................................. 103 7.6 Tela de Check-outs Permitidos do usuário. ............................................................ 103 7.7 Tela de Manipulação de Informações do IC........................................................... 104 7.8 Formulário de Avaliação do IC. ............................................................................. 105 7.9 Formulário de Check-in. ......................................................................................... 106 7.10 Tela de Visualização das versões dos IC.............................................................. 107 7.11 Formulário de Proposta de Alteração. .................................................................. 108 7.12 Interface Analisar Proposta de Mudança.............................................................. 109 7.13 Interface para Relatar a Análise da Proposta........................................................ 110 7.14 Interface de Permissão de Check-out.................................................................... 111 A.1 Casos de Uso do Administrador da Configuração................................................. 125
A.2 Casos de Uso do Engenheiro de Artefatos. ........................................................... 132 A.3 Casos de Uso do Engenheiro da Configuração...................................................... 140 A.4 Caso de Uso Gerente da Configuração.................................................................. 148 A.5 Caso de Uso Engenheiro de Mudanças ................................................................. 157 A.6 Caso de Uso Desenvolvedor.................................................................................. 159 A.7 Caso de Uso Gerente de Acompanhamento de Projeto ......................................... 163 A.8 Caso de Uso Engenheiro da Qualidade ................................................................. 163 B.1 Modelo Relacional do Sistema – Parte 1 ............................................................... 165 B.2 Modelo Relacional do Sistema – Parte 2 ............................................................... 166 B.3 Modelo Relacional do Sistema – Parte 3 ............................................................... 167 B.4 Modelo Relacional do Sistema – Parte 4 ............................................................... 168 B.5 Modelo Relacional do Sistema – Parte 5 ............................................................... 169 B.6 Modelo Relacional do Sistema – Parte 6 ............................................................... 170 B.7 Modelo Relacional do Sistema – Parte 7 ............................................................... 171 B.8 Modelo Relacional do Sistema – Parte 8 ............................................................... 172 B.9 Modelo Relacional do Sistema – Parte 9 ............................................................... 173 B.10 Modelo Relacional do Sistema – Parte 10 ........................................................... 174
LISTA DE TABELAS
3.1 – Objetivos e práticas do processo de GCS no CMMI............................................. 50 8.1 Comparação entre atividades do CMMI e suportadas no trabalho......................... 115
LISTA DE SIGLAS E ABREVIATURAS
SP -Specific Practices – Práticas Específicas
SG -Specific Goals – Objetivos Específicos
RCS -Revision Control System – Sistema de Controle de Revisões
PSEE -Process centered Software Engineering Environment - Ambientes de Engenharia de Software Centrado em Processo
MPSBr -Melhoria de Processo do Software Brasileiro
ISO/IEC -International Organization for Standardization International Electro technical Commission
INPE -Instituto Nacional de Pesquisas Espaciais
IC -Item de Configuração
GCS -Gerência de Configuração de Software
DOM -Dynamic Object Model – Modelos de Objetos Dinâmicos
CVS -Concurrent Versions System – Sistema de Versões Concorrentes
CMMI -Capability Model Maturity Integration
CCC -Comitê de Controle de Configuração
CASE -Computer-Aided Software Engineering – Engenharia de Software Auxiliada por Computador
25
CAPÍTULO 1
INTRODUÇÃO
Durante os últimos anos, o desenvolvimento de software vem se tornando uma tarefa
que necessita cada vez maior rigor devido ao aumento da complexidade e da exigência
de qualidade do software. O que antes poderia ser uma tarefa simples e com poucas
pessoas envolvidas, devido ao aumento da complexidade de desenvolvimento torna-se
necessário um maior controle e acompanhamento sistemático do que se produz de modo
a garantir o sucesso e a qualidade do produto (HUMPHREY,1988).
Ao longo de vários anos, a comunidade de desenvolvimento vem adotando modelos e
métodos de engenharia de Software visando alcançar qualidade, confiabilidade e
produtividade nos produtos desenvolvidos, como por exemplo, a gestão de qualidade e
gestão de configuração (SANT`ANNA,2000).
Os esforços feitos no intuito de desenvolver produtos de software com qualidade deram
origem a diversas normas e padrões de qualidade, nos quais são definidos processos
para organizar e controlar as atividades do desenvolvimento. Dentre as mais conhecidas
podemos citar International Organization for Standardization International
Electrotechnical Commission (ISO/IEC) com padrões 12207 e 15504
(ISO/IEC12207,1995; ISO/IEC 15504-2,1998), modelos de maturidade como
Capability Model Maturity Integration (CMMI,2002) e Melhoria de Processo do
Software Brasileiro (MPSBr)(SOFTEX,2005).
A adoção apenas de normas e das abordagens apresentadas acima, não garante a
eficiência do processo. A utilização de um ambiente que proporcione o trabalho
cooperativo e distribuído, a gestão integrada do conhecimento e dos eventos ocorridos
no projeto e a participação ativa de agentes autônomos computacionais poderão tornar
esses processos mais eficientes (SANT`ANNA,2000).
26
Um dos processos definidos nas normas e modelos de maturidade é o processo de
Gerenciamento de Configuração que objetiva manter a integridade dos produtos
produzidos e consumidos ao longo do desenvolvimento do software (CMMI,2002). A
base de todo o processo de Gerenciamento da Configuração está em um repositório
central de artefatos onde estão todos os produtos que devem ser sistematicamente
controlados pelo processo. Neste trabalho chamaremos de artefatos os produtos
construídos a partir das atividades de um processo e chamaremos de modelo de artefato
a estrutura de um produto que define suas características.
1.1 O Problema
Assim como a maneira de organizar o processo é diferente em cada organização,
também são diferentes os produtos que são controlados em cada projeto, não sendo
possível prever um modelo padrão de artefatos a todos os projetos.
Atualmente existe uma grande diversidade de áreas de negócio (e.g. espacial, comercial,
acadêmica, médica, dentre outras) que automatizam suas atividades através de uma
ferramenta ou sistema de software, sendo cada sistema de software, com sua
complexidade e nível de qualidade exigindo diferentes processos de desenvolvimento e
diferentes modelos de artefatos. Desenvolver software para cada uma dessas diferentes
situações implica em trabalhar com projetos diferentes que manipulam informações
diferentes de acordo com cada caso em questão. Todas as informações manipuladas em
um projeto de software precisam ser armazenadas e controladas ao longo do
desenvolvimento bem como suas alterações através de um processo de gerenciamento
de configurações.
Embora os conceitos da GCS sejam bastante maduros e diversas ferramentas já tenham
sido desenvolvidas para suportar suas atividades, em sua maioria as ferramentas
convencionais tem seu objetivo focado no controle de códigos-fonte, sendo que um
sistema de arquivos é suficiente para representar os artefatos a serem controlados.
Embora essa abordagem seja suficiente para controlar mudanças em códigos-fonte não é
tão representativa para abranger as diversidades de informações entre artefatos.
27
Outro problema encontrado é a situação onde frequentemente não existe uma definição
clara e prévia dos artefatos que serão controlados pelo repositório, sendo estes possíveis
de serem identificados apenas no decorrer do projeto. Neste caso as características
armazenadas no repositório para o novo artefato deveriam ser determinadas no
momento de sua descoberta.
1.2 Metodologia de Pesquisa
Uma das maneiras para resolver estes problemas é manter um repositório de artefatos
dinâmico onde a estrutura de armazenamento de um artefato pode ser definida em
tempo de execução para um determinado projeto e/ou organização.
Uma tecnologia que nos permite construir e modificar objetos em tempo de execução é
o DOM (Dynamic Object Model ou Modelagem Dinâmica de Objetos). Isto inclui
adicionar novos tipos, modificar os já existentes e manter os relacionamentos entre eles
(RIEHLE, 2000).
Como referência para o processo de Gerência de Configuração de Software foi utilizado
o modelo de maturidade CMMI e as atividades (práticas e objetivos) definidas para o
processo.
Para o desenvolvimento da ferramenta de apoio ao processo foi estudada e
implementada a arquitetura de desenvolvimento em 3 camadas para aplicações WEB
com Java, Servlet e Java Server Pages (JSP).
1.3 Trabalhos Relacionados
Podem-se citar como trabalhos relacionados ao tema desta dissertação estudos
realizados no INPE na área de controle de configuração. Segundo o artigo de Cunha e
Nakanishi (1993) para manter um controle mais eficiente dos elementos do projeto fez-
se necessário estabelecer além do repositório de produtos um repositório de
características de produtos. Entende-se como repositório de produtos o local onde se
armazena o produto propriamente dito (i.e. programas, sub-rotinas, dentre outras) e o
repositório de características (i.e. autor, revisor, subsistema), de partes de produtos (i.e.
28
variáveis globais, arquivos include, parâmetros de rotinas) e de relacionamentos desses
produtos (parte_de, referência, composição).
As principais vantagens deste modelo segundo os autores é proporcionar um controle
mais rígido e de nível de granularidade mais refinado dos produtos do projeto
necessários para se obter software de alto nível de qualidade.
O nível de granularidade mais refinado se dá pelo fato de que cada elemento pode ser
controlado em seu formato mais especifico, ou seja, ao invés de controlar um programa
ou um subsistema como um todo (nível muito alto de granularidade), pode-se chegar ao
controle de partes de produtos (nível de granularidade mais baixo) e fazer o
relacionamento entre eles. Dessa forma, um conjunto de partes e de características pode
formar uma sub-rotina, um conjunto de sub-rotinas pode formar um programa e um
conjunto de programas pode formar um sistema.
O controle mais rígido é garantido pelo modelo pelo fato de possibilitar que a cada
alteração a tarefa de analise de impacto identifique com mais precisão quais elementos
serão afetados. Essa informação é obtida através dos relacionamentos e de partes
descritos de cada elemento (i.e. um programa armazenado poderia ter informações de
quais bibliotecas ou quais sub-rotinas estaria usando, ou até mesmo os parâmetros de
entrada e saída).
Outro aspecto vantajoso deste modelo e não menos importante é poder gerar relatórios
das informações sobre os elementos controlados, capas de documentos, fichas de
identificação, dentre outros formulários com mais facilidade e confiabilidade.
Uma limitação observada neste trabalho é a falta de dinamismo do modelo uma vez que
as características dos artefatos do repositório são definidas no modelo de banco de
dados. Este modelo de repositório apresenta limitação em duas situações:
• - Para projetos diferentes que necessitam de informações diferentes sobre cada
artefato será necessário criar bancos de dados diferentes com tabelas e/ou
atributos diferentes;
29
• - Tipos de artefatos não definidos previamente não poderão ser inseridos após o
sistema entrar em operação. Neste caso seria necessário interromper a operação
do sistema para alterar o banco de dados.
Outros exemplos de trabalhos relacionados podem ser citados como (LOPES et al,
2005; MURTA, 2006) que realizaram estudos na área de gerenciamento de
configurações com o foco em componentes de software. Segundo os autores as
ferramentas de configuração de software existentes não fornecem suporte adequado para
o paradigma de Desenvolvimento Baseando em Componentes (DBC), sendo as
principais deficiências a ausência de informações necessárias tais como informações dos
consumidores dos componentes e dados contratuais; e a falta de flexibilidade no
processo sendo que para este propósito não seria possível uma manutenção do
componente que desrespeitasse as normas e obrigações contratuais.
Segundo os autores, o processo de modificação de um componente se diferencia dos
demais artefatos pelo fato de que a decisão de quem irá fazer a manutenção de um
componente de software (equipe produtora ou equipe consumidora) é baseada nos dados
do produtor e do contrato de manutenção do componente. Outro aspecto mencionado
pelos autores é o fato de que se deve levar em consideração quem são os interessados (e
devem ser notificados) no caso de uma modificação (e quem tem por direito essa nova
versão).
A solução adotada pelos autores para esses problemas foi criar uma abordagem onde os
processos possam ser modelados e executados, tornando o processo flexível atendendo
assim as particularidades do processo de manutenção de componentes. Para flexibilizar
também a coleta das informações sobre componentes, a abordagem permite que durante
a modelagem de processos seja criado e associado a cada atividade um formulário.
Durante a execução do processo o formulário definido para cada atividade seria o
responsável por definir a entrada de dados. Ao final de cada atividade é gerado um
documento contendo todas as informações coletadas e este documento é então associado
à modificação do componente.
30
Apesar de a solução ser bastante flexível quanto ao processo (modelagem, execução e
monitoração), nesta abordagem a definição das características sobre os artefatos
controlados é pouco dinâmica (adaptável em tempo de execução). Depois que o
formulário de coleta de dados é associado às atividades e o modelo de processo é então
instanciado, as informações não podem ser alteradas em tempo de execução. Neste caso
todas as informações necessárias à coleta de dados teriam de ser definidas previamente,
não atendendo ao caso de precisar inseri-las durante o desenvolvimento. Entretanto,
diferente do trabalho apresentado nesta dissertação, este dinamismo não se torna
necessário para os objetivos do trabalho desenvolvido pelos autores.
1.4 Objetivos
Destaca-se como objetivo geral deste trabalho a construção de uma ferramenta de apoio
ao processo de Gerenciamento de Configuração de Software tendo como elemento
principal um repositório de artefatos dinâmico e flexível. No contexto deste trabalho,
define como característica flexível a capacidade de adaptar o repositório a cada
necessidade especifica (artefatos e projetos diferentes); e dinâmico, a capacidade de
definir em tempo de execução as características e relacionamentos do repositório. Esta
ferramenta deve trabalhar de forma integrada ao ambiente de engenharia de software e-
WebProject®.
Para o objetivo geral do trabalho ser gradativamente atingido, foram definidas algumas
características a serem cumpridas descritas a seguir:
• – Permitir a definição de quais informações serão mantidas sobre cada artefato: a
abordagem, deverá permitir que para cada situação e/ou negócio sejam definidos
quais informações serão mantidas sobre cada artefato;
• – Permitir estabelecer o nível de granularidade a ser mantido pelo repositório: a
abordagem deverá permitir que seja decidido qual o nível de granularidade as
informações serão armazenadas, de acordo com o nível de qualidade exigido no
projeto;
31
• – Permitir que essas características anteriores sejam realizadas em tempo de
execução: a abordagem deverá ser capaz de permitir que as alterações sejam
realizadas dinamicamente sem que seja necessário interromper o funcionamento
do sistema para tais alterações;
• – Permitir que alterações nas definições do repositório sejam feitas de forma
transparente não sendo necessário reescrever o sistema: a abordagem deverá ser
capaz de permitir uma alteração em alto nível, ou seja, as alterações serão
realizadas por um usuário do sistema sem que para isso seja necessário
reescrever ou modificar o código-fonte;
• – Construir uma ferramenta para apoiar o processo de GCS: a abordagem deverá
ser apoiada por uma ferramenta de GCS desenvolvida para atender além das
atividades do processo de GCS, as características citadas nos objetivos acima;
• – Manter controle de versões dos artefatos: a ferramenta deverá manter controle
de versão dos artefatos definidos dinamicamente;
• – Manter controle de configuração dos artefatos: a ferramenta deverá manter
controle de configuração dos artefatos definidos dinamicamente;
• – Manter controle do processo de alteração dos artefatos: a ferramenta deverá
manter controle de alteração dos artefatos definidos dinamicamente;
• – Acompanhar a situação de cada versão dos artefatos em cada fase do processo:
a ferramenta deverá permitir que para cada versão de artefato, seja identificado
sua situação dentro do processo (e.g. controlada, em alteração, dentre outros);
• – Integrar o repositório dinâmico com a ferramenta de GCS: a ferramenta deverá
trabalhar de forma integrada com o repositório dinâmico apresentado neste
trabalho;
32
• – Integrar a ferramenta de GCS ao ambiente de engenharia de software e-
WebProject®: a ferramenta de GCS deverá ser integrada ao ambiente e-
WebProject® para controlar seus papeis, permissões e controle de acesso.
1.5 Estrutura do Trabalho
Esta dissertação está organizada em 8 capítulos, conforme descrição a seguir:
CAPÍTULO 2 – PROCESSOS DE SOFTWARE E AUTOMAÇÃO: aborda o tema
processos de software, automação de processos e ambientes de engenharia de software
para apoio à processos.
CAPÍTULO 3 – PROCESSOS DE GERÊNCIA DE CONFIGURAÇÃO DE
SOFTWARE: aborda o processo de gerência de configuração de software, seus
conceitos básicos, atividades principais, atividades de acordo com o modelo de
maturidade CMMI e ferramentas d apoio ao processo.
CAPÍTULO 4 – OBJETOS DINÂMICOS (DYNAMIC OBJECT MODEL-DOM):
aborda o tema da tecnologia de modelos de objetos dinâmicos e seus padrões.
CAPÍTULO 5 – UM MODELO PARA REPOSITÓRIO DINÂMICO: aborda o modelo
do repositório de artefatos dinâmico desenvolvido no trabalho com a utilização da
tecnologia DOM.
CAPÍTULO 6 – UM PROCESSO DE GERENCIA DE CONFIGURAÇÃO
UTILIZANDO O REPOSITÓRIO DINÂMICO DE ARTEFATOS: apresenta o
processo de configuração de software através da ferramenta desenvolvida neste trabalho
utilizando o repositório dinâmico.
CAPÍTULO 7 – ESTUDO DE CASO: apresenta um estudo de caso com a utilização da
ferramenta de GCS desenvolvida.
CAPÍTULO 8 – CONCLUSÃO: apresenta a conclusão e resultado obtidos com o
desenvolvimento do trabalho.
33
CAPÍTULO 2
PROCESSOS DE SOFTWARE E AUTOMAÇÃO
O propósito da engenharia de software está na aplicação de técnicas, metodologias e
ferramentas para produzir software com qualidade, minimizando tempo e custo. Para
atingir este objetivo é necessário fazer uma distinção cuidadosa entre produto de
software e processo de software. Produto de software é o que é visível para o cliente e
processo de software é como os objetivos são alcançados. Entretanto é através da
aplicação de processo de software que a qualidade é injetada no produto (CUNGOLLA,
1998).
Segundo Kellner e Gregory (1988), a qualidade de um produto de software está
diretamente determinada pela qualidade do processo empregado para o seu
desenvolvimento e manutenção.
As citações acima, ajudam a enfatizar a importância do processo de software dentro da
engenharia de software bem como seu papel fundamental na determinação da qualidade
do produto desenvolvido.
2.1 Processos de Software
Segundo Sant`Anna (2000), nos primeiros anos da engenharia de software o termo
“processo” era utilizado para denotar o “processo de desenvolvimento” de software
como um todo. Mais recentemente, o termo “processo” ou “processo de software” foi
empregado na definição de outros processos importantes que estão presentes no
“processo de desenvolvimento” de software (e.g. processo de gerenciamento, processo
de garantia da qualidade, etc.).
Muitas são as definições para processos de software, dentre elas se destacam:
“Um processo de software é composto de um conjunto de processos capazes de
conduzir a organização envolvida com a construção de produtos de software com
34
qualidade e custos previsíveis, de forma eficiente, gerenciada e com a possibilidade de
melhoria constante” (SANT’ANNA, 2000).
"Processo de Software é um conjunto de atividades parcialmente ordenadas para
gerenciar, desenvolver e manter um sistema de software" (ACUÑA, 2001).
“O processo de software é uma seqüência de estágios para desenvolver ou manter o
software, apresentando estruturas técnicas e de gerenciamento para o uso de métodos e
ferramentas, e incluindo pessoas para as tarefas do sistema” (HUMPHREY, 1995).
“Processo de software é um conjunto de atividades e resultados associados que geram
um produto de software ou controlam a sua produção” (SOMMERVILLE, 2003).
Para este trabalho iremos considerar que processos de software são constituídos de
atividades de alguma forma controladas e gerenciadas, com objetivos bem definidos,
fazendo uso de recursos (e.g. ferramentas, recursos físicos ou humanos, etc.),
consumindo, modificando ou produzindo algum tipo de artefato (e.g. documentos,
programas, relatórios, etc.), seguindo algumas políticas previamente definidas
(restrições que deve ser satisfeita pelas atividades ou processo antes ou depois de sua
execução) com a finalidade de gerar um produto de software com qualidade.
Ao longo deste trabalho iremos encontrar os termos artefato, produto, produto de
software e work product. Segundo o modelo de maturidade CMMI (2002), um artefato
ou work product é definido como qualquer informação gerada ao longo do processo de
desenvolvimento e produto é definido como sendo um work product que é entregue ao
cliente. Neste trabalho, considera-se os termos artefato, work product e produto como
sinônimos, sendo todos considerados qualquer informação manipulada ao longo do
desenvolvimento e para se referir á um produto entregue ao cliente, utilizar-se o termo
produto de software.
2.2 Elementos básicos de um processo de software
Diferentes características do processo precisam ser consideradas na definição de um
processo de software (e.g. artefatos, papeis, atores, entre outros) e diferentes
35
nomenclaturas podem ser utilizadas por autores diferentes. Entretanto alguns elementos
são comuns a todo processo: agente ou atores, papeis, atividades e artefato ou produto
(ACUNÃ, 2001).
• Agentes ou Atores: é uma entidade que executa um processo. Um ator pode é
caracterizado pelo papel que pode assumir.
• Papeis: papeis descrevem um conjunto de responsabilidades, riscos e
habilidades necessárias para execução de uma determinada atividade do
processo de software.
• Atividades: atividade é uma fase do processo que produz uma mudança visível
no estado do produto de software. Uma atividade pode ter entradas, saídas e
alguns resultados intermediários, denominados artefatos ou produtos (e.g. classe,
cronograma, relatório, etc.). Uma atividade inclui e implementa procedimentos,
regras, políticas e objetivos para gerar ou modificar um determinado conjunto de
artefatos. Uma atividade pode ser associada a um papel, outras atividades e
artefatos.
• Artefato ou produto: artefato ou produto é a matéria-prima e/ou resultado de
um processo. Pode ser um pedaço de informação, um documento, um modelo,
um código fonte. Um artefato produzido por um processo pode ser utilizado
mais tarde como entrada para um outro processo para gerar um novo artefato.
Um artefato pode ter diversas versões e pode ser composto de outros artefatos.
Um artefato pode ser criado, acessado, modificado durante uma atividade do
processo.
A Figura 2.1 abaixo apresenta o relacionamento entre os elementos do processo de
software. Um ator exerce um determinado papel, uma atividade é executada por um
determinado papel, uma atividade possui produtos como entrada e produz produtos
como saída e finalmente um produto pode ser composto de outros produtos.
36
FIGURA 2.1 Elementos básicos de um processo de software
FONTE: Acuña (2001)
O foco deste trabalho está nos artefatos manipulados pelos processos.
2.3 Automação de processos
A implantação de processos em uma organização não é uma tarefa simples, pois
envolve mudança de comportamento das pessoas envolvidas, adoção de novas
ferramentas e metodologias de trabalho. Segundo Kruchten (2003), mudança de
processos pode afetar as convicções fundamentais e valores de uma organização bem
como o modo como os indivíduos percebem e valorizam seu trabalho.
O uso de ferramentas pode ajudar a minimizar o impacto de implantação de processos.
Diversas ferramentas para apoiar os processos de software já foram desenvolvidas,
entretanto, quando usadas de maneira isoladas as ferramentas trabalham de maneira
independente, cada qual cumprindo o objetivo para qual foi estabelecida. Quando as
ferramentas trabalham de forma integrada, o grau de eficiência torna-se
expressivamente mais elevado.
A utilização de um ambiente que proporcione o trabalho cooperativo e distribuído, a
gestão integrada do conhecimento e dos eventos ocorridos no projeto e a participação
ativa de agentes autônomos computacionais, pode tornar esses processos mais eficientes
(SANT'ANNA, 2000).
37
Os esforços gastos para proporcionar um ambiente que seja capaz de trabalhar com os
processos de maneira eficiente, deram origem aos chamados Ambientes de Engenharia
de Software Centrado em Processo, ou Process Centered Software Engineering
Environment –(PSEE) (AMBRIOLA et al.; 1997; FUGGETTA, 2000). Esses ambientes
se propõem a executar de um processo definido explicitamente através de um modelo de
processos.
Um Modelo de Processo pode ser definido como uma representação simplificada e
abstrata de um processo de software, ou seja, a representação de um processo de
software através de uma linguagem específica (gráfica ou não), descrevendo todos os
elementos envolvidos no processo. Um modelo de processo determina: a seqüência de
atividades que deve ser realizada, as ferramentas a serem utilizadas, os produtos e
documentos que são manipulados, os papeis e as pessoas responsáveis no
desenvolvimento do software (GRUHN, 2002).
Um PSEE pode também ser um forte aliado para organizações que desejam manter um
diferencial através de certificações, normas ou modelos de maturidade uma vez que os
processos podem ser definidos, gerenciados e controlados de maneira integrada e
adaptados às necessidades e futuras melhorias.
Para Reis (2001) a utilização da tecnologia PSEE contribui para uma melhor
comunicação entre as pessoas envolvidas e consistência do que está sendo feito;
realização de algumas ações automáticas, permitindo que os seus usuários não realizem
tarefas repetitivas; fornecimento de informações sobre o andamento do processo quando
necessário; possibilidade de reutilização de processo de software e a coleta automática
de métricas importantes para o controle e aperfeiçoamento de processos.
O núcleo de um PSEE é a máquina de processos que tem como objetivo conduzir e
apoiar as pessoas na execução das diferentes atividades que fazem parte do processo e
automatiza as atividades que não necessitam de intervenção humana (CUGOLA, 1998).
38
2.4 O Ambiente de Engenharia de Software e-WebProject®
O e-WebProject® (SANT´ANNA et al., 2002) é um ambiente de engenharia de
software centrado em processos originado do trabalho de pesquisa “Um Ambiente
Integrado para o Apoio ao Desenvolvimento e Gestão de Projetos de Software para
Sistemas de Controle de Satélite - AMBGES” (SANT´ANNA, 2000) desenvolvido no
Instituto Nacional de Pesquisas Espaciais - INPE. Posteriormente este ambiente foi
comercializado e adaptado com tecnologias e metodologias com uso de padrões de
desenvolvimento WEB para atender as tendências de mercado.
O principal objetivo do ambiente é fornecer um conjunto de ferramentas integradas para
trabalho cooperativo, suporte à execução de processos de engenharia de software,
gestão do conhecimento organizacional e apoio à infra-estrutura organizacional.
Segundo Sant’Anna (2000), a arquitetura do ambiente esta organizada em 3 principais
classes de componentes: armazenamento, serviço e interação com o usuário.
• Camada de armazenamento e recuperação: responsável pelo armazenamento
e recuperação das informações de projeto.
• Camada de serviços: vários elementos são necessários para que os indivíduos
trabalhem de forma cooperativa. Para atender ao desenvolvimento de software,
vários serviços podem ser prestados pelo ambiente de modo a atender os
requisitos especificados. Estes serviços utilizam os elementos da camada de
armazenamento e recuperação para obtenção das informações.
• Camada de interação com o usuário: o usuário deverá obter acesso ao
ambiente a partir de qualquer ponto de uma rede de computadores. A utilização
de navegadores (browsers) permite tal facilidade, haja vista a capacidade de
operação em modo gráfico e ambiente de janelas, possibilitando interação fácil e
eficaz; além disso, existem navegadores para todas as plataformas existentes
atualmente.
39
A Figura 2.2 a seguir representa a arquitetura conceitual do e-WebProject® mostrando
as camadas e os componentes proposto pelo autor.
FIGURA 2.2 Componentes e camada conceitual do ambiente.
FONTE: Sant´Anna (2000)
Diversos trabalhos (CEREJA JR., 2004; BORREGO, 2003; GENVIGIR, 2004;
ABDALA, 2004, LAHOZ, 2004) deram continuidade ao trabalho desenvolvido por
Sant`Anna (2000), e tiveram como base esse ambiente, agregando módulos e serviços
proporcionando um ambiente cada vez maior e mais robusto.
2.5 Considerações Sobre Processos de Software e Automação
O capitulo 2 apresentou dois conceitos fundamentais na definição deste trabalho
Processos de Software e Automação através de ferramentas e Ambientes de Engenharia
de Software.
Para este trabalho, o processo de software é um fator importante por duas razões:
1) Manipulação de artefatos. Os artefatos manipulados pelas atividades dos
processos são elementos de estudo para este trabalho por apresentarem uma
40
diversidade de tipos e informações e por sofrerem alterações ao longo do
processo.
2) Processo de Gerenciamento de Configuração. Um dos processos de softwares
bastante conhecido é o processo de gerenciamento de software no qual será
explicado de forma detalhada no próximo capítulo. No contexto deste trabalho
sua relação é a definição das atividades que devem ser suportadas para manter a
integridade dos artefatos e por possuir como elemento principal um repositório
de artefatos (foco principal deste trabalho).
A automação de processos foi estudada neste trabalho pelo beneficio de utilização de
ferramentas para apoiar os processos de software e por este trabalho estar inserido
dentro de um ambiente de engenharia de software denominado e-WebProject®.
41
CAPÍTULO 3
PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Durante todo o processo de desenvolvimento de software é gerada uma grande
quantidade de artefatos. Os tipos de artefatos variam dependendo do processo que esta
sendo modelado (CMMI, 2002) uma vez que cada processo manipula informações
específicas (muitas vezes diferentes) para execução de suas atividades.
As mudanças nos artefatos durante o processo de desenvolvimento são constantes e
necessárias. Um artefato pode ser alterado por 4 principais razões:
• Corretiva: quando um problema é constatado no artefato e é necessária sua
correção;
• Adaptativa: quando a modificação é feita para adaptar o artefato para uma
necessidade especifica (muitas vezes exigidas pelos clientes);
• Preventiva: quando é identificado um risco de falha no artefato e a modificação
é feita de modo a prevenir futuras falhas;
• Evolutiva: quando a modificação ocorre para evolução de algum artefato, ou
seja, inclusão de novas características além das originais definidas pelo cliente.
Ambientes de desenvolvimento que não controlam mudanças são rapidamente
conduzidos ao caos (PRESSMAN, 2006).
O controle das modificações de um artefato deve ser capaz de evitar com que a
alteração de um artefato possa comprometer a integridade dos demais artefatos a ele
associados.
No contexto deste trabalho gerenciar artefatos envolve o gerenciamento de versões e o
gerenciamento das configurações do sistema, ou seja, a utilização de mecanismos para
42
manter armazenadas as informações sobre o artefato, as informações sobre cada versão
do artefato, determinar quais versões fazem parte de qual configuração além de
controlar quem, quando e porque uma alteração foi realizada.
É impossível falar sobre gerenciamento de artefatos sem mencionar o processo de
gerência de configuração de software. O processo de gerência de configuração de
software fornece as técnicas, métodos e procedimentos para manter a integridade dos
artefatos envolvidos durante todo o processo de desenvolvimento de software bem
como das configurações, através do controle sistemático de suas modificações e de seu
armazenamento controlado, provendo informações sobre a situação do produto de
software a todos os envolvidos.
3.1 Processo de Gerência de Configuração de Software
Conforme o modelo de maturidade CMMI (2002), o propósito do Gerenciamento de
Configuração é para estabelecer e manter a integridade de artefatos usando a
identificação de configuração, controle de configuração, situação de configuração, e
auditorias de configuração.
Para Pressman (2006) , o processo de GCS pode ser definido como uma maneira de
identificar, organizar e controlar modificações no software que está sendo construído
por uma equipe de desenvolvimento.
Estublier (2000) define o processo de GCS como o controle da evolução de sistemas
complexos, ou de forma mais pragmática, como a disciplina que permite manter os
produtos de software em evolução, e, portanto, contribuindo para satisfazer restrições de
qualidade e cronograma.
O processo de GCS é aplicado ao longo de todo processo de desenvolvimento de
software consistindo em um conjunto de atividades de acompanhamento e controle que
começam no início do projeto e só terminam quando o software é retirado de operação.
Portanto, não se deve confundir o processo de GCS como uma atividade de
manutenção, que ocorre depois da entrega do software.
43
3.1.1 Conceitos básicos
A seguir são apresentados os conceitos fundamentais da gerência de configuração:
• Item de Configuração (IC): Cada um dos elementos de informação que são
criados durante o desenvolvimento de um produto de software, ou que para este
desenvolvimento sejam necessários, que são identificados de maneira única e
cuja evolução é passível de rastreamento (PRESSMAN, 2006).
• Artefato X Item de Configuração
Artefatos e itens de configuração são duas definições frequentemente encontradas na
literatura (PRESSMAN, 2006; CMMI, 2002; ISO/IEC 12207, 1995; ISO/IEC
15504-2, 1998) e estão intimamente relacionadas, podendo muitas vezes serem
confundidas.
A diferença principal entre um artefato e um item de configuração é que o primeiro
não precisa estar formalmente controlado enquanto que o segundo é um produto
controlado sistematicamente pelo processo de GCS.
Artefato é toda e qualquer informação produzida ao longo do desenvolvimento por
uma, ou mais, atividades e poderá, ou não, ter suas alterações (e evolução)
controladas (e.g. casos de teste: pode ou não ser controlados, dependendo da
organização).
Item de Configuração é um artefato controlado que compõe uma ou mais versões do
sistema. Dependendo do projeto, um artefato poderá ou não ser um item de
configuração (e.g. documento de especificação e códigos-fonte: normalmente
controlados).
• Configuração-base ou baseline: Entende-se por configuração-base (baseline)
um conjunto bem definido de itens de configuração que foi formalmente
revisado e aceito, e que serve como base do sistema para desenvolvimento
posterior (Leon, 2000).
44
• Distribuição ou releases: Entende-se por distribuição (release) uma
configuração do sistema que foi testada, aprovada e liberada para um cliente
(LEON, 2000).
3.2 Modelo check in/check out
Um assunto intimamente relacionado ao processo de gerência de configuração é o
controle de versões. Um dos mais antigos e mais difundidos modelos para controle de
versão é o modelo check in/check out. O modelo check in/check out determina a forma
com que os usuários (desenvolvedores e/ou equipe de desenvolvimento) interagem com
os arquivos controlados. Os arquivos mantidos sob controle são tratados de forma
individual em um local denominado Repositório de Artefatos.
Itens mantidos sob controle nunca poderão ser diretamente alterados, alterações devem
ser previamente aprovadas e novas versões destes itens poderão ser criadas. Cada
artefato pode ter diferentes versões para um mesmo original, porém cada versão deve
ser tratada como um item individual e como tal será identificado podendo ser extraído e
usado de forma independente (HASS, 2000).
Quando um artefato é desenvolvido, este deve ser mantido sobre controle em um
repositório centralizado e controlado para garantir que os demais membros da equipe de
desenvolvimento possam fazer uso daquele artefato cuja integridade está garantida.
3.2.1 Operações de Acesso
Para que o modelo seja capaz de garantir a integridade dos elementos sob seu controle,
várias operações são definidas para possibilitar a manipulação dos artefatos:
• Check-out: permite que uma determinada versão de artefato seja extraída do
repositório. Existem dois tipos de check-out: com permissão para alteração ou
somente leitura (também conhecida como operação “get”). Quando a versão do
artefato é extraída para edição é recomendado que seja feito o bloqueio dessa
versão (com a operação lock), para garantir que os check-outs seguintes sejam
somente para leitura até que a versão do artefato volte a estar controlada.
45
• Check-out exclusivo: quando um usuário faz uma operação de check-out nada
impede que um outro usuário também execute a operação de check-out para a
mesma versão do artefato. Quando isso acontece, o usuário que atualizar (e
executar a operação de check-in) por último descartará as alterações feitas pelos
anteriores. Para evitar esse tipo de situação a operação de check-out exclusivo
permite que uma versão de artefato seja extraída do repositório por apenas um
usuário, não permitindo que outro usuário execute também a operação de check-
out para a mesma versão.
• Check-in: a operação de check-in pode ser feita em duas situações: para criar o
artefato no repositório pela primeira vez ou para criar uma nova versão do
artefato quando este passar por uma modificação.
• Lock: esta operação bloqueia o artefato não permitindo que qualquer operação
(nem para leitura) seja feita sobre ele até que o desbloqueio seja feito pelo
mesmo usuário. Em algumas ferramentas, esta operação é combinada com a
operação de check-out para fazer o check-out exclusivo.
• Unlock: esta operação permite que o artefato seja desbloqueado pelo usuário
que efetuou seu bloqueio.
FIGURA 3.1 Modelo check-in/check-out
A Figura 3.1 apresenta o funcionamento do modelo check-in/check-out. Um artefato
existente começa a ser controlado pelo sistema a partir da execução do primeiro check-
in. A partir desse momento, o sistema irá manter um histórico de todas as operações
dono
CHECK-IN
CHECK-OUT
CONTROLE DE ACESSO
DESENVOLVEDOR ELEMENTO
elemento modificado
info. da avaliação
unlock
lock
elemento congelado e modificado
elemento controlado
elemento extraido
46
realizadas com o artefato. Quando um artefato que está sob o controle do repositório
precisa ser alterado, é realizada uma operação de check-out especificando qual versão se
deseja extrair. A operação de check-out (combinada com a operação de lock) permite
que um dado desenvolvedor extraia o artefato para ser modificado. Uma vez alterado e
passado pela avaliação de qualidade, o artefato é novamente enviado para o repositório
através da operação de check-in combinada com a operação unlock. Este artefato passa
então a ter uma nova versão no repositório voltando a estar controlado.
3.3 Versão e Configuração de Artefatos
Os artefatos passam por vários estados ao longo do desenvolvimento. Isto implica em
diversas modificações, gerando uma versão de artefato a cada modificação.
A cada operação de check-in executada sob um artefato é criada uma nova versão do
mesmo no repositório. Isto possibilita gerar um histórico da evolução dos artefatos
permitindo voltar a uma versão anterior a qualquer momento.
O controle de versões possibilita: rastrear automaticamente os artefatos; garantir a
integridade quando no acesso compartilhado; recuperar versões anteriores; criar linhas
de desenvolvimento paralelo e registrar um histórico de operações durante o
desenvolvimento do artefato (quem, quando, o quê e por que foi modificado).
Cada versão de artefato no repositório deve possuir uma identificação única e não
ambígua. Para tanto se torna necessário estabelecer um esquema para representar e
identificar a evolução das versões dos artefatos. Uma das maneiras mais utilizadas para
identificar o versionamento de artefatos é utilizar identificação em forma de árvore que
permite ramificações a partir de qualquer versão.
Uma das maneiras mais usuais de identificação de versões em árvore é a utilização de
um identificador principal e identificador secundário separados por um ponto:
<ident_principal>.<ident_secundario>.
47
1.0 1.1 1.2 2.1 1.3 2.0
Arquivo ARQ
Versão • Quem • Quando • Porque
Modificações
FIGURA 3.2 Controle de Versão.
FONTE: Abdala (2003).
A Figura 3.2 apresenta uma forma de versionamento de um artefato (ou arquivo).
Quando um artefato é adicionado ao repositório pela primeira vez ele é identificado com
uma versão inicial (e.g. versão 1.0). A partir deste ponto, a cada modificação realizada
no artefato é gerada uma nova versão que pode ser obtida, por exemplo, através do
incremento de seu identificador secundário (e.g. versão 1.1) e assim sucessivamente.
Desta maneira podemos manter o histórico da evolução do artefato através de seu
versionamento permitindo saber que o artefato de versão 1.3 é derivado de uma
modificação no artefato de versão 1.2..
O tipo de versionamento, bem como a quantidade de seu incremento pode variar de
acordo com a necessidade de cada caso. Pode-se, por exemplo, estabelecer uma política
que determina que as versões sejam incrementas de 1 no identificador secundário
quando o artefato não estiver ainda distribuído para um cliente, ou seja, ainda estiver
sob desenvolvimento e quando o artefato já estiver sido distribuído o incremento será de
100 em seu identificador principal para identificar que a versão pertencerá a um novo
release.
3.3.1 Desenvolvimento Paralelo ou Branch
A maioria das ferramentas de controle de versão permite o desenvolvimento paralelo
(também conhecido como branch), que são derivações a partir de uma determinada
versão de artefato gerando caminhos paralelos ao caminho principal de
desenvolvimento. Esse tipo de evolução é bastante utilizado quando se deseja incorporar
48
características particulares em determinadas versões e não em outras ou também para
gerar versões de testes com modificações que poderão, ou não, ser integradas às demais
versões.
O desenvolvimento paralelo permite que um artefato siga paralelamente diversos
caminhos de desenvolvimento podendo ser desenvolvido para atender objetivos
diferentes (MACKAY, 1995).
FIGURA 3.3 Desenvolvimento paralelo. FONTE: Mackay (1995).
A Figura 3.3 apresenta o desenvolvimento paralelo de um artefato. Neste exemplo o
artefato segue diferentes caminhos, sendo cada caminho criado para atender diferentes
plataformas.
3.3.2 Junções ou Merge
Junção ou merge possibilita a junção entre duas versões (que foram ramificadas),
baseando-se na versão original que gerou o branch. A estratégia adotada é a seguinte:
as linhas presentes na versão original e não modificadas nas versões subseqüentes são
naturalmente adicionadas na nova versão. Uma linha que aparece na versão original e
em somente uma das versões posteriores caracteriza uma modificação no código (a
correção de um erro ou a melhoria de uma função); esta modificação deve ser
incorporada na nova versão, portanto a linha diferente será utilizada. Uma linha
modificada nas duas versões (ambas diferentes da original) gera um conflito; o
repositório não tem como saber qual linha deve ser incorporada na nova versão. Cabe,
então, ao usuário resolver o problema.
49
3.3.3 Agregações ou Configurações
Outro mecanismo utilizado no controle de versões é a agregação. A agregação permite
que várias versões de artefatos diferentes (de alguma maneira relacionada) sejam
agregadas, referenciadas e obtidas em conjunto. Este mecanismo consiste na atribuição
de um rótulo comum a cada versão de arquivo que integra o conjunto que se deseja
caracterizar.
As operações básicas de manipulação dos elementos do repositório (check-in, check-out
e get) se aplicam também às agregações, sendo aplicadas a todos os elementos do
conjunto.
O mecanismo de agregação possibilita a implementação dos conceitos de configurações,
configurações-base e distribuições.
A Figura 3.4 apresenta no quadro esquerdo a evolução de versões de cada artefato A, B,
C e D. No quadro a direita observam-se duas configurações sendo que cada uma delas
contém diferentes versões de cada artefato.
FIGURA 3.4 Agregações. FONTE: Oliveira et al. (2001).
50
3.4 Atividades do processo de GCS
Além do controle de versões e configurações, o processo de GCS envolve outras
atividades importantes. A definição para essas atividades pode ser encontrada nas
normas e modelo de maturidade dentre as quais podemos citar ISO/IEC com os padrões
12207 e 15504 (ISO/IEC12207, 1995; ISO/IEC 15504-2, 1998), os modelos de
maturidade como o CMMI (CMMI, 2002) e o MPSBr (SOFTEX, 2005). As definições
encontradas podem variar de modelo para modelo, entretanto o objetivo de todos é
manter a integridade dos artefatos sob controle do processo de GCS.
Segundo Pressman (2006), o processo de GCS tem 4 principais objetivos: identificar os
itens de configuração; gerir as modificações nos itens de configuração; facilitar a
construção de diferentes versões do sistema de software; e garantir que a qualidade do
software seja mantida à medida que a configuração evolui ao longo do tempo.
Para a definição das atividades do processo de GCS utilizadas neste trabalho, foram
utilizadas como base, as definições do modelo de maturidade CMMI (2002). Nem todas
as atividades definidas no modelo foram abrangidas neste trabalho.
A Tabela Erro! A origem da referência não foi encontrada. apresenta os SG –
(Specific Goals) Objetivos específicos com as SP – (Specific Practices) Práticas
específicas definidas no CMMI (2002) para o processo de GCS.
TABELA 3.1 – Objetivos e práticas do processo de GCS no CMMI.
SG - Objetivos específicos SP - Práticas específicas
SP 1.1 - Identificar os itens de configuração SP 1.2 - Estabelecer um sistema de controle de Configuração SG 1 - Estabelecer baselines SP 1.3 - Criar ou Distribuir Baselines SP 2.1 - Rastrear as Requisições de Mudanças SG 2 - Rastrear e Controlar as MudançasSP 2.2 - Controlar os Itens de Configuração SP 3.1 - Estabelecer um registro do Gerenciamento da Configuração SG 3 - Estabelecer Integridade SP 3.2 - Executar Auditoria da Configuração
51
3.4.1 SG1 – Estabelecer Baselines
Este objetivo define uma série de práticas com o intuito de definir quais componentes e
produtos de trabalho (work products) relacionados ficarão sob o gerenciamento da
configuração.
As práticas específicas que são definidas para este objetivo são:
• SP 1.1 - Atividade de Identificação dos Itens de Configuração: Uma das
etapas iniciais do processo é a definição dos produtos que serão controlados,
definidos como item de configuração (IC). Esta atividade envolve atribuir um
identificador único para os ICs; determinar as informações importantes
associadas a cada IC; especificar seus relacionamentos com o mundo exterior e
com outros ICs; determinar quando um IC deverá ser colocado sob a gerência da
configuração; e determinar quem é o responsável por cada IC. A identificação
dos itens de configuração deve ser compatível com o nível de formalidade
desejável para o desenvolvimento de um determinado sistema, ou seja, quanto
maior o nível de qualidade do sistema, maior deve ser a formalidade das
atividades de desenvolvimento e mais refinamentos serão necessários dos itens a
serem controlados para a montagem das versões do sistema.
• SP 1.2 - Estabelecer um sistema de controle de Configuração: Visa
estabelecer e manter sistemas de gerenciamento da configuração e de
gerenciamento de mudanças para controlar produtos de trabalho. Esta atividade
envolve determinar o nível de controle (mais ou menos formal) que será
necessário dependendo dos riscos do projeto; definir um mecanismo para
armazenar e recuperar os ICs bem como suas versões; manter registros e
disponibilizar relatórios sobre as informações da gerência de configuração; e
preservar as informações (backups) de gerência da configuração.
• SP 1.3 - Criar ou Distribuir Baselines: Visa definir mecanismos para criar
baselines e suas distribuições (releases) para os clientes. Esta atividade envolve
obter autorização do Comitê de Controle de Configuração (CCC) para criar ou
52
distribuir uma baseline; criar baselines somente a partir de IC sob o controle da
gerência da configuração; documentar cada IC pertencente a uma baseline; e
distribuir baselines para os clientes.
3.4.2 SG2 – Rastrear e Controlar Mudanças
Este objetivo define uma série de práticas com o intuito de definir um processo formal
para alterações de IC. Uma solicitação de alteração de um IC pode estar associada desde
uma alteração de requisitos até uma falha ou defeitos no produto. Os pedidos de
alteração devem ser analisados para medir o impacto que aquela alteração provocará no
cronograma, no custo ou em outros IC.
As práticas específicas que são definidas para este objetivo são:
• SP 2.1 - Rastrear as Requisições de Mudanças: Visa estabelecer um
mecanismo para controlar e rastrear as requisições de mudança nos IC. Esta
atividade envolve identificar todos os pedidos de mudança que forem
solicitados; analisar o impacto das alterações e correções propostas; revisar os
pedidos de mudança junto aos responsáveis pelas baselines para obter
aprovação; e rastrear o pedido de mudança desde seu inicio até sua conclusão.
• SP 2.2 - Controlar os Itens de Configuração: Visa estabelecer mecanismos
para manter o controle dos IC bem como rastrear sua evolução, ou seja,
controlar o ciclo de vida do IC. Esta atividade envolve controlar as alterações
nos IC durante todo seu ciclo de vida; obter autorização antes de incluir um IC
modificado no sistema de gerência de configuração; fazer check-in e check-out
dos IC para manter a integridade dos ICs; fazer revisão das alterações realizadas;
e registrar as alterações nos IC bem como suas justificativas.
3.4.3 SG3 – Estabelecer a Integridade
Este objetivo define uma série de práticas para manter a integridade dos artefatos sob
controle do processo de GCS.
53
As práticas específicas que são definidas para este objetivo são:
• SP 3.1 - Estabelecer um registro do Gerenciamento da Configuração: Visa
manter um registro das ações realizadas no gerenciamento da configuração. Esta
atividade envolve: registrar as ações em um nível de detalhe que permita
visualizar o estado atual da configuração e recuperar suas versões anteriores;
garantir que os interessados tenham acesso às informações das configurações e
dos ICs; especificar a versão atual da baseline; especificar quais versões dos ICs
compõem a baseline; descrever as diferenças entre as baselines sucessivas; e
revisar o estado e o histórico de alterações de cada IC.
• SP 3.2 - Executar Auditoria da Configuração: Auditorias confirmam que as
linhas e base e a documentação resultantes do gerenciamento da configuração
estão conformes a padrões e requisitos especificados. Se necessário, os
resultados da auditoria devem ser registrados. Esta atividade envolve: avaliar a
integridade das baselines; confirmar que os registros do gerenciamento da
configuração identificam corretamente os ICs; rever a estrutura e a integridade
dos ICs; e confirmar a completude e o acerto dos ICs.
3.5 Ferramentas de apoio ao processo de GCS
Não é de hoje que o uso de ferramentas CASE para auxiliar as tarefas de engenharia de
software tem demonstrado resultados positivos à comunidade de desenvolvimento
aumentando a produtividade e facilitando o uso de metodologias, técnicas e padrões.
Uma grande quantidade de ferramentas CASE estão disponíveis no mercado,
oferecendo os mais diferenciados tipos de serviço às várias fases do processo de
desenvolvimento (e.g. auxilio a programação, análise, gerenciamento de projetos,
suporte a comunicação, dentre outras).
Gerenciar o processo de GCS de forma manual torna-se complicado à medida que a
complexidade dos parâmetros que o norteiam aumenta. Por esse motivo, torna-se
necessário a utilização de ferramentas para auxiliar no processo de GCS, sendo que,
54
melhor seria se esta ferramenta provesse o suporte a todas as atividades do processo de
GCS (as atividades do processo de GCS são discutidas no item 3.4).
Existem algumas ferramentas de apoio ao processo de GCS disponíveis no mercado,
sendo que as mais modernas trabalham em conjunto com um repositório de artefatos e
dão suporte a uma ou mais atividades do processo de GCS. De uma forma geral essas
ferramentas podem ser divididas em três grupos: as ferramentas que dão suporte ao
controle de versão e configuração, as ferramentas que dão suporte ao acompanhamento
de modificações, e por fim, as que oferecem a integração de duas (ou mais) ferramentas
para proporcionar um ambiente capaz de manter um controle mais rigoroso.
Dentre as ferramentas mais conhecidas que dão suporte ao controle de versão e
configuração podemos citar o RCS (Revision Control System), o Concurrent Versions
System (CVS) e o IBM - ClearCase.
• RCS − (Revision Control System − Sistema de Controle de Revisões). O RCS
(Tichy, 1985) é um sistema capaz de gerenciar a evolução de arquivos de texto e
as modificações criadas a partir destes. O RCS utiliza o modelo check-out/check-
in para gerenciar o compartilhamento dos arquivos e a criação de novas versões,
não permite o desenvolvimento paralelo simultâneo (mas pode ser simulado com
a utilização de branches, seguidos da instrução merge), não permite a criação de
diretórios dentro do mesmo repositório e permite o gerenciamento de
configuração.
• Concurrent Versions System (CVS) – O CVS (BERLINER, 1990) é uma das
ferramentas mais utilizadas para controle de versão de código aberto. Possui as
mesmas características que o RCS, uma vez que foi derivado dele, porém
implementa algumas melhorias sendo a principal delas, a possibilidade de
desenvolvimento paralelo entre dois usuários simultâneos.
• Rational ClearCase – O Rational ClearCase (IBM, 2007) é uma ferramenta
proprietária da IBM que fornece gerenciamento de ciclo de vida e controle de
recursos de desenvolvimento de software. Possui controle de versão integrado,
55
suporte a desenvolvimento paralelo, gerenciamento de configuração e
gerenciamento de construção e release. Permite integração com outras
ferramentas da IBM para fornecer uma solução completa dos demais processos.
As ferramentas citadas acima foram desenvolvidas com o objetivo principal de dar
apoio ao gerenciamento de versões, não cobrindo todas as atividades previstas no
processo de GCS. Por exemplo, ambas não implementam um processo de controle de
modificações (e.g. solicitação de modificação, acompanhamento de modificações, etc.).
Como exemplo de ferramenta disponível no mercado que oferece controle e
acompanhamento de modificações podemos citar o Bugzilla e o IBM ClearQuest.
• Bugzilla - Uma das ferramentas mais conhecidas e mais utilizadas em projetos
de software livre é o Bugzilla (Barnson et al., 2003)(Reis, 2002). Essa
ferramenta surgiu com o objetivo inicial de controlar o desenvolvimento do
browser Mozilla e atualmente é usada em vários projetos de software livre e
proprietário. O Bugzilla reúne funcionalidades para acompanhar um ciclo
completo de alteração de código efetuada no projeto desde sua solicitação até
sua conclusão além de oferecer busca detalhada de modificações, criação de
relacionamentos entre modificações, relatórios para análise das informações
armazenadas e preocupação constante com o desempenho da ferramenta.
Permite também a integração com a ferramenta CVS.
• Rational ClearQuest – O Rational ClearQuest (IBM, 2007b) é uma ferramenta
proprietária da IBM que fornece mecanismos para monitoramento de alteração e
defeitos. Permite integração com outras ferramentas da IBM para fornecer uma
solução completa dos demais processos.
As ferramentas citadas acima podem ser utilizadas de maneira integradas quando
este recurso for suportado. Esse é o caso, por exemplo, das ferramentas proprietárias
IBM ClearCase e IBM ClearQuest e das ferramentas de software livre CVS e
Bugzilla, que quando utilizadas em conjunto conseguem atender ao processo de
GCS de maneira mais abrangente.
56
Embora os conceitos da GCS sejam bastante maduros e diversas ferramentas já tenham
sido desenvolvidas para suportar suas atividades, em sua maioria as ferramentas
convencionais tem seu objetivo focado no controle de códigos-fonte, sendo que um
sistema de arquivos é suficiente para representar os artefatos a serem controlados.
Embora essa abordagem seja suficiente para controlar mudanças em códigos-fonte não é
tão representativa para abranger as diversidades de informações entre artefatos.
Muitas ferramentas oferecem um grau de formalismo muito baixo e inadequado e para
manter o processo de forma manual é necessário um elevado grau de formalismo.
Poucas ferramentas são flexíveis o suficiente para possibilitar a escolha do grau de
formalismo que se deseja de acordo com os diferentes tipos de artefatos estabelecidos
(HASS, 2000).
Um Fator bastante importante na escolha de uma ferramenta de GCS é definir
cuidadosamente os critérios de interesse para o projeto/organização. Para Agelina
(2001), uma ferramenta de GCS pode ser avaliada segundo muitos critérios. Cabe ao
avaliador adotar aqueles critérios que julgar mais adequados a uma situação em
particular e a cada critério escolhido associar um peso relativo.
Para este trabalho foram consideradas como critérios de avaliação as seguintes
características: apoio a processo e capacidade de adaptação na forma de armazenar as
diferentes características dos artefatos.
Ambas as ferramentas estudadas implementam apenas uma parte do processo de GCS,
sendo necessário integrá-las com outra ferramenta para que o processo possa ser
totalmente apoiado.
A forma de armazenamento de ambas as ferramentas estudadas são pouco flexíveis
sendo que as meta-informação dos artefatos armazenados são idênticas para todos. Esta
forma de tratar os artefatos pode ser interessante no sentido de que permite armazenar
qualquer artefato (uma vez que sob a forma de arquivo do sistema operacional), mas em
contrapartida não é possível determinar as características que se deseja manter sob cada
artefato em particular.
57
3.6 Considerações Sobre o Processo de GCS e Ferramentas
Este Capítulo apresentou conceitos básicos sobre o processo de gerenciamento de
configuração de software, bem como gerenciamento de versões e configurações e
alteração de artefatos. Tais conceitos são fundamentais na definição deste trabalho para
compreensão dos termos e técnicas utilizadas e posteriormente.
Também são apresentadas neste capítulo as atividades no qual o modelo de maturidade
CMMI (2002) organiza suas metas e práticas para o processo de GCS. Estas atividades
foram tomadas como base para organização e determinação das atividades abordadas
neste trabalho.
As ferramentas relacionadas neste Capítulo serviram como base para análise das
características, limitações e forma de trabalho das ferramentas existentes numa tentativa
de reunir as melhores características e minimização das limitações na ferramenta
implementada para validação deste trabalho.
58
59
CAPÍTULO 4
OBJETOS DINÂMICOS (DYNAMIC OBJECT MODEL-DOM)
O uso de sistemas com DOM permite que tipos de objetos sejam modificados em tempo
de execução. Isto inclui adicionar novos tipos, modificar os já existentes e manter os
relacionamentos entre eles (RIEHLE, 2000).
Em um sistema orientado a objetos convencional, um objeto é caracterizado através de
uma classe que define a estrutura e o comportamento do objeto, ou seja, para cada tipo
de objeto existe uma classe. A criação de novos tipos implica na necessidade de criação
de novas classes. Com DOM o sistema pode ser representado através de um modelo de
meta dados de classes, atributos e relacionamentos, permitindo a definição de novos
tipos de objetos em tempo de execução.
A escolha pela utilização de sistemas baseados em arquiteturas dinâmicas neste
trabalho, se dá pela característica de flexibilidade e dinamismo que poderão ser obtidos
nas aplicações conforme estudos realizados por (ALMEIDA, 2005 ; CARDOSO, 2005).
4.1 Padrões TypeObject Pattern e Property Pattern
Arquiteturas de modelos de objetos adaptativos são normalmente baseadas nos padrões
TypeObject Pattern e Property Pattern (YODER, 2001).
Na metodologia orientada a objetos, estruturamos o sistema com um conjunto de classes
que define as características e comportamento dos objetos. Normalmente utilizam-se
classes separadas para definir cada tipo de objeto. Mas o que fazer quando as
características do objeto não são totalmente conhecidas ou o número de subclasses é
muito grande?
TypeObject Pattern provê uma maneira dinâmica de definir novas entidades de negócio
para o sistema em tempo real, fazendo com que as subclasses não conhecidas sejam
60
simples instâncias de classes genéricas conforme apresentado na figura 4.1 (YODER,
2001).
FIGURA 4.1 TypeObject Pattern, exemplo
FONTE: Adaptada de Yoder (2001).
Os atributos de um objeto são normalmente implementados nas instâncias das classes.
Uma vez que as classes passam a ser genéricas, sendo todos os objetos da mesma
instância de classe, é necessário estabelecer uma forma de implementar e definir os
atributos dos objetos. A solução é implementar os atributos de maneira diferente
também.
A Figura 4.1 mostra que um relacionamento de herança poderia ser modelado através do
padrão TypeObject criando as classes entidade e tipo entidade.
O Property Pattern ao invés de definir cada atributo como uma variável, utiliza uma
única variável para armazenar uma coleção de atributos.
61
FIGURA 4.2 Property Pattern, exemplo
FONTE: Adaptada de Yoder (2001).
A Figura 4.2 mostra a separação dos atributos de uma classe Entidade através do uso do
padrão Property.
4.1.1 Arquitetura TypeSquare
A aplicação em conjunto de dois padrões definidos TypeObject e Property, resulta em
uma estrutura de arquitetura chamada TypeSquare (YODER, 2001).
Na arquitetura TypeSquare, o padrão TypeObject é aplicado duas vezes. A primeira vez
para fazer a separação de uma Entity e uma EntityType, e a segunda vez para separar os
atributos. O padrão Property é aplicado para implementar os atributos das entidades
(YODER, 2001).
A Figura 4.3 representa a estrutura TypeSquare após a aplicação dos dois padrões.
FIGURA 4.3 Arquitetura TypeSquar
FONTE: Adaptada de Yoder (2001).
62
Para entender melhor essa estrutura, vamos usar um exemplo: Suponha que você precise
desenvolver um sistema para controlar elementos observados no espaço, sendo
“planeta” um dos objetos a ser utilizado pela aplicação. Se a modelagem fosse feita de
forma convencional, no modelo seria colocada uma classe para representar o planeta e
nessa classe seriam definidos todos os atributos conforme a Figura 4.4 .
FIGURA 4.4 Modelagem convencional da classe Planeta.
Considere agora que o sistema foi modelado utilizando o padrão TypeSquare, sendo
assim, o modelo de classes é exatamente como o definido na figura 4.3 . Torna-se
necessário estabelecer uma maneira de criar os objetos necessários para seu negócio em
tempo de execução.
Para isso temos que seguir 4 passos: definir a Entidade, definir os TipoEntidades,
definir a Propriedade e definir os TiposPropriedade.
• Definir TipoEntidade: Primeiro teremos que informar ao sistema que será
preciso a utilização de uma classe Planeta. A criação desta classe deve ser feita
criando uma instância da classe “TipoEntidade”.
• Definir TipoPropriedade: para definir quais os atributos serão necessários
para a nossa “classe” Planeta. No nosso exemplo um planeta deverá ter os
seguintes atributos: código, nome, raioOrbitalMedio, periodoOrbital e
velocidadeOrbitalMedia. Cada um desses atributos deverá ser definido através
de instancia da classe “TipoPropriedade”.
Até este momento construímos de forma dinâmica a classe e seus atributos. Agora é
preciso definir objetos para essas classes. Voltando ao exemplo da modelagem
convencional usada na figura 4.4 poderíamos criar objetos Planeta da seguinte
63
maneira: Planeta planeta1 = new Planeta(); sendo que para cada
objeto poderíamos definir os atributos através dos seus métodos de acesso:
planeta1.setCodigo(100); . Agora vamos ver como esses objetos seriam
definidos e os valores de seus atributos atribuídos com a utilização de DOM.
• Definir Entidade: Para criar os objetos do tipo Planeta (e.g. planeta1, planeta2,
planeta3) é necessário criar uma instância da classe “Entidade” para cada objeto.
Cada objeto “Entidade” criado deve se relacionar com um objeto
“TipoEntidade” para determinar de qual classe aquele objeto pertence.
• Definir Propriedade: Cada valor de atributo será um objeto da classe
“Propriedade” e este objeto será relacionado aos objetos “TipoPropriedade” e
“TipoEntidade” para determinar a qual objeto e qual atributo respectivamente o
valor pertence..
O exemplo descrito anterior justificaria a utilização de um modelo dinâmico, pois
muitos elementos a serem observados no espaço possuem características diferentes
sendo que alguns elementos podem ser descobertos depois de o sistema estar em
operação (neste caso não seria necessária a modificação na modelagem do sistema). Do
mesmo modo os itens de configuração manipulados durante um projeto podem possuir
características diferentes e durante o projeto surgir a necessidade de controlar novos
itens não previstos previamente.
A tecnologia de DOM define outros padrões não apresentados neste aqui. A omissão
destes padrões dá-se ao fato de não serem necessário para atender o objetivo definido
para o trabalho.
4.2 Considerações sobre DOM
Neste Capítulo foi apresentado a tecnologia de modelagem de objetos dinâmicos
utilizando a arquitetura TypeSquare que no contexto deste trabalho foi utilizada para a
construção de itens de configuração do sistema, permitindo a criação do mesmo em
tempo de execução.
64
65
CAPÍTULO 5
UM MODELO PARA REPOSITÓRIO DINÂMICO
5.1 Artefatos dinâmicos
Baseado na modelagem dinâmica de objetos e na utilização da arquitetura TypeSquare,
está sem proposto neste trabalho, um novo modelo para a definição dos (itens de
configuração) IC controlados no sistema, permitindo que organizações e/ou projetos
diferentes possam definir seus próprios IC e meta-informação em tempo de execução.
Algumas adaptações fizeram-se necessárias neste novo modelo para atender algumas
características do processo de Gerenciamento da Configuração. A característica de
versionamento dos itens de configuração torna necessária a inclusão no modelo de uma
nova entidade denominada VersãoArtefato.
Neste trabalho considerou-se que um item de configuração deve ser tratado de duas
maneiras diferentes, sendo a primeira referente à definição da estrutura das meta-
informação (modelo ou classe que define os atributos) e a segunda referente ao seu
conteúdo (instância de uma classe de artefato que contém o conteúdo do artefato
propriamente dito).
Em ambos os casos, podem ser estabelecidos relacionamentos, ou seja, podemos criar
relacionamentos que se referem à estrutura do IC (e.g. relacionamento de classes) como
também podemos criar relacionamentos referentes às versões dos IC’s (e.g. uma versão
se relacionando com outra). Os relacionamentos referentes à estrutura do IC podem ser
utilizados, por exemplo, para a geração de interfaces de entrada de dados dinâmicas
onde os relacionamentos são usados para verificar se a criação do IC requer a criação de
outros IC’s a ele relacionados. Um bom exemplo para esse caso seria o relacionamento
66
todo-parte1, onde um IC poderá ter um relacionamento de todo-parte que força a criação
de todos os IC’s “parte” junto com o IC “todo”.
5.1.1 Definição da Classe do Artefato
Uma classe de artefato define um “tipo” genérico de artefato através do qual podemos
criar artefatos reais. Por exemplo, podemos definir uma classe de artefato denominada
“Documento de Requisitos”. Essa classe é apenas uma abstração (um conceito genérico)
e representa qualquer documento de requisitos (de qualquer projeto). Um artefato real
poderia ser criado a partir das especificações dessa classe, por exemplo, um artefato
denominado “Documento de Requisitos do Projeto SIVAM”.
Ao definir uma classe de artefato podemos definir quais atributos pertencerão a ele. A
definição dos atributos especificados para uma dada classe de artefato é também
considerada para todas as instâncias dela derivada. Dessa maneira, conforme no
exemplo anterior, todos os atributos definidos para a classe de artefato “Documento de
Requisitos” estarão também presentes nos artefatos “Documento de Requisitos do
Projeto SIVAM” e “Documento de Requisitos do Projeto CBERS”.
Na definição da classe de artefato podemos também definir os possíveis
relacionamentos que definem sua estrutura, ou seja, definir de quais outras classes de
artefato ela é composta. Por exemplo, a classe “Documento de Requisitos” poderá ser
composta de outras classes de artefatos como “Diagrama de Atividades”, “Diagrama de
Casos de Uso”.
5.1.2 Definição do Artefato
Uma vez definida a estrutura do artefato (classe), podemos definir agora o artefato
propriamente dito (artefato real). Ao definir o artefato é preciso associá-lo a uma classe
de artefato para que as características definidas para a classe sejam aplicadas a ele, ou
seja, os atributos e relacionamentos deste artefato serão definidos pela classe no qual
1 Relacionamentos todo-parte é tão forte que as partes não podem existir individualmente.
67
está associado. Uma vez que o artefato real seja definido as versões dele podão ser
geradas.
A definição do artefato em si consiste apenas em definir as características de
identificação do artefato no repositório, tais como nome, uma descrição textual, data de
criação e algumas observações que se fizerem necessárias. Essas informações são as
mesmas denominadas metadados no sistema tradicional de alguns autores
(PRESSMAN, 2006; ABDALA, 2004).
Entretanto, os artefatos mantidos no repositório passam, em geral, por constantes
modificações ao longo do projeto. O que muda de uma alteração para outra do artefato
são sintetizadas em versões do artefato. Cada versão pode conter diferentes informações
sobre o artefato. Portanto, em cada versão de artefato são armazenados os valores de
cada atributo definidos em sua classe.
Outro fator que deve ser levado em consideração é o relacionamento existente entre as
versões de artefato. Uma versão de artefato pode se relacionar com outra para
representar a evolução de suas modificações (permitindo a rastreabilidade), ou para
representar quaisquer outros tipos de relacionamentos (e.g. composição, dependência,
entre outros). Manter sob controle esses relacionamentos é necessário para analisar, por
exemplo, o impacto de uma modificação em um dado artefato.
Por exemplo, a versão 1.0 do “Documento de Requisitos do Projeto CBERS” poderá ser
modificada necessitando que uma nova versão seja criada. Nesse caso o “Documento de
Requisitos do Projeto CBERS versão 1.0” seria relacionado ao “Documento de
Requisitos do Projeto CBERS versão 1.1”.
Os relacionamentos entre versões não precisam ser necessariamente entre versões de
artefatos de uma mesma classe de artefato (caso do exemplo cita acima), ou seja,
podemos ter versões de artefatos diferentes sendo relacionados. Por exemplo, para gerar
um documento de Testes é necessário se basear nas informações do documento de
requisitos, pois podemos gerar vários casos de testes para cada requisito contido no
documento de requisitos. Sendo assim o “Documento de Requisitos do Projeto CBERS
68
versão 1.1” pode ser utilizado para produzir o “Documento de Testes do Projeto
CBERS versão 1.0”, isto significa que uma modificação no “Documento de Requisitos
do Projeto CBERS 1.1” irá afetar o “Documento de Testes do Projeto CBERS 1.0”.
Os conceitos apresentados acima podem ser implementados através do modelo abaixo:
cd ert
ClasseArtefato
- id: long- nome: String- descricao: String- observacao: String
PropriedadesArtefato
- id: long- nome: String- descricao: String- observacao: String
AtributosArtefato
- id: long- valor: String
Artefato
- id: long- nome: String- descricao: String- dataCriacao: Date- observacao: String
VersaoArtefato
- id: long- versao: String- data: Date
GrauRelacionamento
- id: long- nome: String- descricao: String- observacao: String
ClasseArtefatoRel
- id: long
VersaoArtefatoRel
- id: long
0..* 1
1 0..*
1
0..*1
0..*
1 0..*
1
0..*
0..*
relacionado
1
0..*
1
0..*
relacionado
1
0..* 1
1
0..*
FIGURA 5.1 Arquitetura de Definição do Artefato.
A Figura 5.1 apresenta a utilização do DOM aplicado à definição dos artefatos do
repositório. As classes do modelo se referem à definição da estrutura de meta-
informação do artefato, de suas instâncias e seus relacionamentos.
Para a definição da estrutura das metas-informação dos artefatos têm-se: ClasseArtefato
(define uma classe para o artefato), PropriedadeArtefato (define os atributos para uma
determinada classe de artefato) e ClasseArtefatoRel (define o relacionamento da
estrutura da classe).
O diagrama de objetos na Figura 5.2 , nos permite entender melhor o que seria a
definição da estrutura de um artefato.
69
FIGURA 5.2 Diagrama de objetos para a definição da estrutura dos artefatos.
Na Figura 5.2 temos alguns objetos criados em tempo de execução:
• classe1 e classe2: esses objetos são instâncias das classes “ClasseArtefato”, ou
seja, estamos definindo em tempo de execução que nossa aplicação vai possuir
duas classes denominadas classe1 e classe2.
• atributo1, atributo2 e atributo 3: são objetos da classe “PropriedadeArtefato”,
ou seja, estamos definindo em tempo de execução os atributos que nossas
classes vão possuir. Neste caso temo que: a classe1 possui o atributo3 e que a
classe2 possui os atributos: atributos1 e atributo2.
• relac1 e grau1: esses objetos são das classes “ClasseArtefatoRel” e
“GrauRelacionamento” respectivamente. Esses objetos servem para criar os
relacionamentos existentes entre as classes, ou seja, neste caso estamos
relacionando em tempo de execução a classe1 com a classe2.
classe1 : ClasseArtefato id = 02 nome = “Diagrama de Contexto” descricao = “caso de uso contexto” observacao = null propriedades = [atributo3]
id = 01nome = “Documento de Requisitos” descricao = “requisitos de negócio” observacao = null propriedades = [atributo1, atributo2]
classe2 : ClasseArtefatoatributo1 : PropriedadesArtefato
id = 01 nome = “titulo” descricao = “título do documento” observacao = “acrescentar o prefixo”
atributo2 : PropriedadesArtefato
id = 02 nome = “descrição do negócio” descricao = “descreve o negocio” observacao = “em português”
atributo3 : PropriedadesArtefato
id = 03 nome = “imagem” descricao = “arquivo com a imagem” observacao = “extensão GIF”
relac1 : ClasseArtefatoRel
id = 01 classe = classe 2 classeRelacionada = classe1 grauRelacionamento = grau1
grau1 : GrauRelacionamento
id = 01 nome = “composto de” descricao = “relação de composição” observacao = null
70
Todos esses objetos apresentados no exemplo anterior, referem-se à definição de
estrutura das meta-informações. Se comparado com a modelagem orientada a objetos
tradicional, teríamos apenas definido as classes a serem usadas na aplicação, seus
atributos e relacionamentos. Entretanto, com a utilização do DOM todas as classes,
atributos e relacionamentos do exemplo são criadas em tempo de execução.
Ainda na Figura 5.1 temos classes para definir os artefatos propriamente ditos, suas
versões e valores. Para a definição de uma instância de artefato temos: Artefato (define
a instância do artefato), VersaoArtefato (define uma versão para um artefato),
AtributosArtefato (define o conteúdo dos atributos para uma versão de artefato) e
VersaoArtefatoRel (define relacionamentos entre versões de artefatos).
O diagrama de objetos na Figura 5.3 apresenta a definição de um artefato e sua versão.
FIGURA 5.3 Diagrama de Objetos definição do Artefato.
Na Figura 5.3 podemos observar alguns objetos criados para definir os artefatos e
versões:
71
• art1: objeto da classe “Artefato” que define um artefato a ser usado na
aplicação. Este artefato possui (implicitamente) os atributos descritos em sua
classe, ou seja, os atributos “atributi1” e “atributo2” definidos para a “classe1”.
• ver1: objeto da classe “VersãoArtefato” que define qual a versão em que um
determinado artefato se encontra. Neste exemplo, temos que o artefato “art1”
possui uma versão “ver1”.
• verart1: objeto da classe “AtributoArtefato” que determina os valores atribuídos
a cada um dos campos de uma determinada versão de artefato. Neste exemplo, o
atributo “atributo1” da versão “ver1” possui valor definido no objeto “verart1”.
A primeira fase deste trabalho foi desenvolver o repositório dinâmico utilizando a
tecnologia de DOM assim como apresentado neste capítulo. Com a utilização deste
modelo conseguiu-se atingir um diferencial de flexibilidade e dinamismo não
encontrados nas ferramentas convencionais. A segunda fase deste trabalho consiste
na integração deste repositório em uma ferramenta de GCS que deve abranger, pelo
menos, as atividades mais importantes do processo de GCS.
72
73
CAPÍTULO 6
UM PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO UTILIZANDO O
REPOSITÓRIO DINÂMICO DE ARTEFATOS
Este capítulo apresenta um processo de GCS com a utilização da ferramenta
desenvolvida, consolidando todos os conceitos apresentados neste trabalho. O objetivo
da ferramenta é manter a integridade de qualquer tipo de artefato necessário ao projeto,
sendo que estes artefatos serão definidos em tempo de execução, característica esta
permitida com a implementação do repositório dinâmico citado no Capitulo 5. A
ferramenta foi implementada para suprir as duas principais características das
ferramentas que apóiam o processo de GCS, o controle de artefatos e suas versões e o
controle de modificações.
A ferramenta foi desenvolvida em arquitetura web, implementada com linguagens Java,
Java Server Page – JSP e Servlet e tendo como banco de dados PostgreSQL. O modelo
de arquitetura e tecnologia utilizado segue o definido para o ambiente e-WebProject®
apresentado no Capitulo 2.
6.1 Papeis Definidos
Segundo Paula Filho (2000), durante o projeto surgem alguns participantes que sempre
estão envolvidos em alguma fase do ciclo de vida do processo e estes participantes
interagem com o serviço em uma dada fase do processo. Esses participantes podem ser
definidos como papeis que são executados pelos usuários em cada atividade do
processo. Esse é um dos conceitos utilizados no e-WebProject®, a utilização de papeis
para definir as responsabilidades e permissões dentro do ambiente. O acesso dos
usuários ao sistema é feito através de um controle de acesso implementado no ambiente
permitindo restringir a visão sobre as informações apenas aos interessados e destinar
cada atividade de um (ou mais) processo(s) ao responsável por sua execução.
74
Seguindo esse mesmo conceito de implementação, alguns papéis foram estabelecidos
para definir as responsabilidades e permissões de cada usuário dentro do processo de
GCS suportado pela ferramenta Dynamic Artifact Integrity. A seguir tem-se uma
descrição sobre as responsabilidades de cada um dos papeis definidos:
• Administrador da Configuração: Este papel permite ao usuário fazer as
configurações básicas inicias necessárias para o funcionamento do sistema. Para
que a ferramenta esteja em condições de uso, torna-se necessário algumas
configurações básicas tais como valores pré-definidos de categorias que devem
estar devidamente cadastrados no sistema antes da operação efetiva. Estas
configurações são atribuídas como responsabilidades do papel denominado
Administrador da Configuração.
A Figura 6.1 apresenta o diagrama de casos de uso com as respectivas
responsabilidades do papel administrador da configuração.
ud RepositorioDeArtefatos
Administrador da Configuração
Manter GrauDeRelacionamento
Manter Categoria de Template de
Configuracao
Manter Tipo de Versionamento
Manter Prefixo
FIGURA 6.1 Casos de Uso do Papel Administrados da Configuração.
• Engenheiro de Artefatos: Este papel permite ao usuário definir a estrutura dos
artefatos, ou seja, determinar os tipos de artefatos que deverão existir no projeto
75
(classes artefatos) e seus respectivos valores a serem mantidos (atributos). É
responsabilidade deste papel também definir templates de configurações que
poderão ser utilizados para definir os artefatos nos novos projetos visando a
reutilização de um conjunto de definições de artefatos.
A Figura 6.2 apresenta o diagrama de casos de uso com as respectivas
responsabilidades do papel de engenheiro de artefatos.
ud RepositorioDeArtefatos
Engenheiro da Artefatos
Definir Classe de Artefato
Definir Atributos da Classe de
Artefato
Definir Composição da
Classe de Artefato
Definir Template de Configurações
Selecionar Artefatos
Estes artefatos podem ser genericos para toda a empresa....Eles podem ser selecionados para serem usados em algum projeto especifico
Manter Artefato Padrão
Esse IC nao esta relacionado a nenhum projeto especifico
«include»
«extend»
«include»
FIGURA 6.2 Casos de Uso do Papel Engenheiro de Artefatos.
• Engenheiro da Configuração: Este papel permite ao usuário manter as
informações sob as configurações do sistema, definir a lista de distribuições e
montar e distribuir as releases. Também é de responsabilidade deste papel
manter as versões de configurações bem como notificar aos interessados
quaisquer mudanças nas configurações e/ou releases.
A Figura 6.3 apresenta o diagrama de casos de uso com as respectivas
responsabilidades do papel de engenheiro da configuração.
76
ud RepositorioDeArtefatos
Manter Configurações
Manter Releases Selecionar IC da Configuração
Selecionar Clientes
Engenheiro da Configuracao
Manter Lista de Distribuição
Manter v ersao da configuracao«extend»
«include»
«include»
FIGURA 6.3 Casos de Uso do Papel Engenheiro da Configuração.
• Gerente da Configuração: Este papel tem a responsabilidade de manter um
controle sobre os itens do repositório, podendo definir IC que serão controlados
por cada projeto, bloquear/desbloquear IC e editar os valores de relacionamento
entre os IC.
A Figura 6.4 apresenta o diagrama de casos de uso com as respectivas
responsabilidades do papel de gerente da configuração.
77
ud RepositorioDeArtefatos
Selecionar Baseline do
Projeto
Manter Versões de Artefatos
Manter Dependencia
Visualizar Historico de Operações
Manter Repositorio
Criar IC do Projeto
Gerente da Configuracao
Realizar Lock / Unlock
Manter v isibilidade
Permitir Checkout
Selecionar Usuário
Analisar Proposta de Artefato
Visualizar Ev olução dos
Artefatos
Visualizar Check-out's autorizados
Visualizar Artefatos Propostos
«extend»
«extend»
«extend»
«extend»
«extend»
«include»
«extend»
«extend»
«extend»
FIGURA 6.4 Casos de Uso do Papel Gerente da Configuração.
• Engenheiro de Mudanças: Este papel permite ao usuário manter todas as
informações referentes às alterações nos IC mantidos sob controle do
repositório. È de responsabilidade do Engenheiro de mudanças analisar todas as
requisições de mudanças enviadas, fazer a analise de impacto e permitir ou não a
implementação da alteração.
A Figura 6.5 apresenta o diagrama de casos de uso com as respectivas
responsabilidades do papel de engenheiro de mudanças.
78
ud RepositorioDeArtefatos
Engenheiro de
Mudanças
Manter Repositorio
Analisar Proposta de Mudança
Analisar Dependencias
Alocar Desenv olv edor para alteração
Defirnir IC para alteração
Analisar instruções de
alteração
Relatar Pedido de Mudança
Realizar Check in
Definir Versao
Analisar Proposta de Artefato
«include»
«include»
«extend»
«include»
«include»
«include»
FIGURA 6.5 Casos de Uso do Papel Engenheiro de Mudanças.
• Desenvolvedor: Este papel determina as responsabilidades dos
desenvolvedores/programadores dentro de um processo de GCS. Este papel
permite aos usuários visualizarem os IC no repositório (desde que os IC sejam
públicos), enviar solicitações de mudanças quando desejarem por algum motivo
alterar um IC, enviar propostas para definir um novo IC não definido no projeto
e implementar as alterações quando essas forem aceitas e atribuídas a ele a
responsabilidade de sua alteração.
A Figura 6.6 apresenta o diagrama de casos de uso com as respectivas
responsabilidades do papel de desenvolvedor.
79
ud RepositorioDeArtefatos
Desenv olv edor
Manter Proposta de Mudança
Compor Proposta de Mudança
Selecionar Artefato para
alteraçao
Verificar Situação da Proposta
Fazer Checkou de Artefatos
Permitidos
Visualizar Repositorio de
ArtefatosFazer GET
Env iar para Qualidade
Visualizar Checkout Permitidos
Env iar Proposta
Visualizar Artefatos para
Modificação
Desenv olv er artefatos
Propor Artefato
«extend»
«extend»
«extend»
«extend»
«extend»
«include»«include»
«extend»
FIGURA 6.6 Casos de Uso do Papel Desenvolvedor.
Gerente de Acompanhamento de Projetos: Este papel permite ao gerente de projetos
determinar o usuário responsável por realizar a ação de criação do IC e posteriormente
de determinar o usuário responsável por um check-out.
A Figura 6.7 apresenta o diagrama de casos de uso com as respectivas responsabilidades
do papel de gerente de acompanhamento de projetos.
80
ud RepositorioDeArtefatos
Visualizar Check-out's autorizados
Gerente de Acompanhamento de Projeto (GCM)
Permitir Criação
FIGURA 6.7 Casos de Uso do Papel Gerente de Acompanhamento de Projeto.
Engenheiro da Qualidade: Este papel permite a avaliação de um IC que será
controlado no repositório.
A Figura 6.8 apresenta o diagrama de casos de uso com as respectivas responsabilidades
do papel de engenheiro da qualidade.
ud RepositorioDeArtefatos
Engenheiro da
Qualidade (GCM)
Av aliar Artefatos
FIGURA 6.8 Casos de Uso do Papel Engenheiro da Qualidade.
Através da definição deste papeis pode-se garantir maior integridade nas informações
uma vez que cada papel só poderá ter acesso a uma parte restrita da informação (quando
não permitido ao papel) e a separação das responsabilidades em cada fase das atividades
envolvidas no processo de GCS por cada papel.
6.2 Fluxo de Trabalho
Assim como qualquer processo, a execução das atividades do processo de GCS precisa
obedecer a uma ordem (ou restrições) para que o fluxo de trabalho possa ser realizado.
Neste trabalho o fluxo de trabalho das atividades é guiado através dos estados dos
81
artefatos e de suas versões como definido anteriormente. A cada atividade realizada no
processo os artefatos e/ou versões passam por alterações de estados que decidem por
qual caminho o fluxo deve seguir.
A seguir serão representados os principais fluxos de trabalho realizados para esta
disseração para atender as atividades do processo de GCS bem como o fluxo de objetos
(e seus estados) durante sua execução.
6.2.1 Fluxo de Trabalho Definir Classe de Artefato
O fluxo de trabalho definir classe de artefato é o primeiro passo do processo de GCS
apresentado nesta dissertação. Esse fluxo determina a criação das classes de artefatos
que serão posteriormente utilizadas para criar os artefatos propriamente ditos.
FIGURA 6.9 Fluxo de Trabalho Definir Classe Artefato.
A Figura 6.9 ilustra as duas atividades envolvidas no fluxo de trabalho Definir classe
artefato. Um engenheiro de artefatos deverá definir a Classe Artefato determinando
também quais os atributos essa classe deverá possuir. Após definida a classe artefato
estará disponível para que os artefatos sejam criados a partir dela.
82
6.2.2 Fluxo de Trabalho Definir Itens de Configuração
O fluxo de trabalho definir IC inicia na atividade de definição do item de configuração e
só termina quando a versão deste IC está sob controle do repositório de artefatos.
FIGURA 6.10 Fluxo de Trabalho Definir Itens de Configuração.
A Figura 6.10 ilustra o fluxo de trabalho definir itens de configuração que se inicia
quando o Gerente do GCM define o artefato que deverá ser controlado no sistema. O
artefato definido no repositório permanece no estado “em definição” até que o gerente
finalize sua definição executando a atividade de publicação do artefato que altera o
estado do artefato para “definido”.
83
Os artefatos com estado “definido” são visíveis para o gerente de acompanhamento de
projetos que executa a atividade de permitir criação determinando qual desenvolvedor
vai ser responsável pela criação de uma versão do artefato. Ao executar esta atividade
uma versão de artefato é criada e seu estado definido como “permitido”.
As versões de artefatos com estado “permitido” são visíveis para os desenvolvedores.
Cada desenvolvedor visualiza as versões de artefatos que foram a ele permitidas e
executa a atividade de fazer check-out (falso). Ao executar esta atividade a versão de
artefato é enviada para a área de trabalho do desenvolvedor com o estado “em
elaboração”. Após finalizar a elaboração da versão do artefato, o desenvolvedor executa
a atividade de enviar para a o processo de qualidade sendo o estado da versão do
artefato alterada para “aguardando aprovação”.
As versões de artefatos com estado “aguardando aprovação” são visíveis para o
engenheiro da qualidade que executa a atividade de analisar artefato alterando o estado
da versão de artefato para “em analise”. A versão de artefato permanece neste estado até
que uma decisão seja tomada. Se o engenheiro da qualidade reprovar a versão de
artefato seu estado passa a ser “reprovado” e se aprovar o estado passa a ser
“aguardando check-in”.
As versões de artefatos com estado “reprovado” são visíveis para os desenvolvedores
que as elaboraram. Os desenvolvedores poderão executar a atividade de fazer check-out
(falso) para que a versão do artefato possa ser corrigida segundo as especificações do
engenheiro da qualidade. Nesta atividade o estado da versão passa para “em elaboração”
novamente, seguindo o mesmo fluxo definido anteriormente.
As versões de artefatos com estado “aguardando check-in” são visíveis para o
engenheiro de mudanças que executa a atividade de check-in alterando o estado da
versão para “controlada” e deixando-a disponível no repositório de artefatos.
84
6.2.3 Fluxo de Trabalho Rastrear e Controlar Mudanças
Este fluxo de trabalho se inicia no momento em que um desenvolvedor elabora uma
proposta de alteração e termina com o artefato sendo novamente controlado.
85
FIGURA 6.11 Fluxo de Trabalho Rastrear e Controlar Mudanças.
86
O fluxo de trabalho representado na Figura 6.11 se inicia quando o desenvolvedor
elabora uma proposta de alteração no qual especifica qual versão de artefato deseja
alterar, o motivo da alteração, detalhes sobre o que será alterado, etc. A proposta fica no
estado “em definição” até que o desenvolvedor finalize-a. Ao finalizar a proposta o
desenvolvedor a envia para análise e o estado passa a ser “enviada”.
As propostas de mudança com estado “enviada” são visíveis pelo engenheiro de
mudanças que irá analisá-las sendo o estado alterado para “em análise”. O engenheiro
de mudanças vai analisar a proposta de mudança, verificar o impacto da alteração e
definir quais outros artefatos serão necessários alterar. A proposta se mantém no estado
“em analise” até que uma decisão seja tomada. O engenheiro de mudanças poderá
recusar a proposta, sendo neste caso seu estado alterado para “reprovada” ou aceitar a
proposta sendo seu estado alterado para “aprovada”.
As propostas de mudanças com estado “aprovadas” são visíveis pelo gerente do GCM
que será responsável por liberar a permissão de alteração para o desenvolvedor
apropriado. Uma vez concedida a permissão de alteração, a versão do artefato atual
(cuja proposta solicitou a alteração) mudará seu estado para “reservado” impedindo
assim que novas permissões de alterações sejam concedidas para a mesma versão de
artefato (check-out exclusivo). Em paralelo, uma nova versão será criada para o artefato
com o estado “permitido” sendo visível ao desenvolvedor que é responsável por sua
alteração.
Os próximos passos apresentados no fluxo de trabalho são idênticos ao descritos no
fluxo de trabalho anterior (6.3.1 Fluxo de Trabalho Definir IC). A única diferença é que
ao final do fluxo de trabalho quando o engenheiro de mudanças realiza a atividade de
check-in ambas as versões (versão atual que foi alterada e a nova versão do artefato) são
colocadas no estado de “controlada” e a proposta de mudança é colocada no estado
“concluída”.
87
6.2.4 Fluxo de Trabalho Definir Template da Configuração
O Fluxo de Trabalho de definição de templates de Configuração permite ao usuário
definir um conjunto de artefatos que poderá ser reaproveitado em novos projetos. Por
exemplo, todo novo projeto envolve a atividade de identificar os IC que serão mantidos
sob controle no repositório, entretanto alguns artefatos já são comuns a todos os projetos
(i.g. plano de projetos, documento de requisitos, modelo descritivo, dentre outro). Para
evitar que a cada novo projeto seja necessário definir esses IC, define-se um (ou mais)
conjunto(s) que contenha esses artefatos e ao criar um novo projeto faz-se a associação
do template de configuração ao novo projeto, sendo que os artefatos definidos no
template serão automaticamente definidos no novo projeto sem a necessidade de
redefini-los.
FIGURA 6.12 Fluxo de Trabalho Definir Template de Configuração.
A Figura 6.12 apresenta o fluxo de trabalho Definir Template de Configuração. Esse
fluxo de trabalho inicia-se quando o engenheiro de artefatos define um conjunto de
artefatos padrões. O engenheiro de artefatos executa a atividade de criar template de
88
configuração podendo selecionar dentre os artefatos padrões definidos, quais farão parte
daquele template de configuração.
6.2.5 Fluxo de Trabalho Propor um Novo IC
Esta funcionalidade permite que um desenvolvedor submeta uma proposta de
identificação de um novo IC.
Em um projeto real dificilmente todos os IC conseguem ser identificados no inicio do
planejamento sendo que muitos deles só serão identificados no decorrer do andamento
do projeto. O gerente da configuração é o responsável pela identificação dos IC do
projeto, entretanto muitas vezes quem descobre a necessidade de um IC ainda não
definido são os desenvolvedores e analistas. Quando essa situação ocorre, o
desenvolvedor poderá enviar uma proposta de identificação de um novo IC. Esta
proposta será analisada.
89
FIGURA 6.13 Fluxo de Trabalho Propor Novo IC.
90
A Figura 6.13 apresenta o fluxo de trabalho para propor um novo IC. Esse fluxo de
trabalho inicia-se quando o desenvolvedor executa a atividade de elaborar proposta de
um novo IC. Esta atividade gera uma proposta de IC que permanece no estado de “em
definição” até que o desenvolvedor conclua sua elaboração e execute a atividade de
envio da proposta que modifica o estado para “enviada”.
As propostas de IC em estado “definida” são visíveis apenas aos usuários com papel de
gerente da configuração que irão analisar cada proposta recebida tornando seu estado
“em analise”. As propostas de IC analisadas pelo gerente da configuração permanecem
no estado “em analise” até que uma decisão seja tomada alterando seu estado. Quando o
gerente recusa uma proposta de IC o estado se modifica para “rejeitada” e quando o
gerente aceita a proposta de IC ela entra no estado de “aceita”.
As propostas de IC com estado “aceita” são visíveis em uma lista para que o gerente
possa definir os IC efetivos do projeto. Ao definir um novo IC no repositório seu estado
é definido como “em definição” e permanece nesse estado até que o gerente execute a
atividade de publicação do artefato que altera o estado para “definido” podendo ser
visível nas próximas fases de outras atividades.
6.3 Ciclo de Vida de Artefatos e Versões
O controle e acompanhamento dos estados dos artefatos e versões é uma atividade
importante no processo de GCS, pois é através dela que conseguimos saber a situação
real e a fase que se encontra o artefato e suas diferentes versões. Um artefato pode
originar várias versões que devem ser tratadas e identificadas individualmente como
visto anteriormente (Capítulo 3) e cada versão segue um ciclo de vida individual das
demais.
Cada uma das versões de um artefato pode ter estados diferentes. Por exemplo: O
artefato “Usuário.java” poderá ter em um dado momento duas versões: “Usuário.java
versão 1.0” e “Usuário.java versão 1.1”. Cada uma das versões desse artefato poderá
91
estar em uma fase diferente do processo: a versão 1.0 poderá estar sob análise pela
qualidade, enquanto a versão 1.1 é modificada. Pelo fato de que cada versão tem seu
ciclo de vida individual, torna-se necessário um controle diferenciado dos estados dos
artefatos e de cada uma de suas versões.
6.4 Ciclo de Vida de um Artefato
O ciclo de vida de um artefato poderá começar em duas situações diferentes: quando foi
feita uma proposta de artefato por um desenvolvedor ou quando o artefato for definido
diretamente pelo gerente do GCS no repositório (essas atividades são descritas no
Capitulo 3).
A Figura 6.14 abaixo apresenta o diagrama de estados para o artefato onde a passagem
de cada estado para outro é representada. A explicação detalhada de cada um dos
estados é descrita em seguida.
92
sm Diagrama de Estado Artefato
inicio do ciclo de vida do artefato
Definido
Proposto
inicio a partir de uma proposta
descartado
Disponiv el
em definição
em definição de proposta
em analise de proposta
proposta aceita
proposta rejeitada
fim
fim
proposta foi aceitapara definir artefato
proposta foianalisada
proposta foi analisada
proposta é totalmente definida
artefato é descartado
desenvolvedor elabora a proposta (ainda não pronto)
proposta sendo analisada
artefato é completamente definido no repositorio
versão é criada
artefato esta sendo definido (ainda não pronto)
FIGURA 6.14 Diagrama de Estados do Ciclo de Vida do Artefato.
Primeiro vamos acompanhar o ciclo de vida de um artefato partindo de sua definição
direta no repositório.
O ciclo de vida de inicia com o desenvolvedor definindo a proposta e depois segue para
cada um dos demais estados. Segue abaixo a descrição detalhada de cada estado:
Em definição de proposta: este estado significa que uma proposta para o artefato esta
sendo definida pelo desenvolvedor. Entretanto essa definição ainda não foi submetida
(ainda não está pronta) para análise, estando ainda sob controle do desenvolvedor.
Proposto: este estado significa que uma proposta de artefato já foi totalmente definida e
concluída, ou seja, o desenvolvedor após o término da definição enviou a proposta para
93
ser analisada. Neste estado o desenvolvedor passa a não ter mais o controle sob a
proposta, podendo apenas visualizar sua situação.
Em análise da proposta: este estado indica que o gerente de mudanças já esta
analisando a proposta enviada, entretanto ainda não foi possível determinar uma
decisão. Deste estado o artefato poderá seguir para um dos dois estados: proposta aceita
ou proposta rejeitada, conforme a decisão tomada na análise.
Proposta Rejeitada: neste estado a proposta para o novo artefato foi rejeitada na
análise e seu ciclo de vida chega ao fim, ou seja, o artefato não vai passar para nenhuma
outra fase.
Proposta Aceita: neste estado a proposta para o novo artefato foi aprovada na análise e
esta aguardando até que possa ser definida no repositório e seguir para as próximas
fases. Neste estado o artefato aceito fica aguardando em uma lista até que o responsável
possa defini-lo corretamente no repositório.
Em definição: neste estado o responsável pela definição dos artefatos no repositório
verifica a lista de artefatos que estão aguardando a definição e começa a defini-los. Este
estado significa que o artefato esta sendo definido, mas ainda não esta totalmente
concluída (não está pronto). Esta distinção entre os estados “em definição” e “definido”
é importante para que um artefato que não está totalmente definido não seja visível
pelas fases seguintes.
Definido: neste estado o artefato encontra-se totalmente definido no repositório
podendo seguir as fases adiante e inclusive ter suas versões criadas.
A partir de uma proposta de artefato feita pelo usuário vamos acompanhar o ciclo de
vida de um artefato.
Disponível: neste estado o artefato possui ao menos uma versão disponível no
repositório. Como cada versão poderá seguir seu próprio ciclo de vida, o artefato
permanece no estado disponível por todo restante de sua vida, até que em um
determinado momento, por algum motivo, seja explicitamente descartado.
94
Descartado: neste estado o artefato deixa de ser um artefato “válido”, ou seja, torna-se
obsoleto. A criação de uma nova versão para o artefato não descarta a versão anterior,
apenas cria uma versão diferente para o mesmo artefato. Para que o artefato seja
descartado é necessária uma operação explícita do gerente do GCS. O descarte de um
artefato faz com que todas as suas versões sejam automaticamente descartadas.
A única diferença do ciclo de vida do artefato quando não iniciado por uma proposta, é
que seu inicio é representado pelo estado de “em definição” e a partir daí segue os
demais estados da mesma maneira descrita anteriormente.
6.5 Ciclo de vida das Versões do Artefato
O ciclo de vida de uma versão inicia-se a partir de uma permissão concedida a um
desenvolvedor para que este possa manipular as informações (o conteúdo) da versão.
Existem dois momentos em que uma versão é criada: na criação da versão inicial do
artefato e na modificação de uma versão existente. Na situação de criação de uma
versão inicial, ainda não existe uma versão definida para o artefato e o desenvolvedor
estará criando a primeira versão (deixando o artefato no estado disponível). A segunda
situação é quando o desenvolvedor deseja modificar uma versão que já existe e para isso
cria a versão seguinte (nesse caso o processo de modificação deve ser seguido).
A realidade é que toda versão criada será sempre nova, ou seja, quando criamos uma
versão não estamos alterando as informações do artefato que já existe, estamos apenas
fazendo com que em sua versão seguinte as informações sejam diferentes (com as
modificações necessárias).
A Figura 6.15 apresenta o ciclo de vida de uma versão demonstrando os diversos
estados pela qual a versão passa ao longo de sua vida.
95
FIGURA 6.15 Diagrama de Estados do Ciclo de Vida da Versão.
O ciclo de vida de uma versão começa com a concessão de uma permissão para sua
criação, a partir deste ponto a versão segue para os demais estados. A seguir tem-se a
descrição detalhada de cada um dos estados:
Permitido: neste estado uma permissão de manipulação da versão foi concedida. Duas
situações podem levar a este estado: criar a primeira versão do artefato ou modificar
uma versão já existente. No caso de uma alteração, o gerente de projeto faz um “check-
out real”, ou seja, a operação de check-out propriamente dita é executada pelo gerente
de projetos e uma versão temporária é criada e destinada para uma lista de check-outs
permitidos do desenvolvedor.
Em elaboração: neste estado o desenvolvedor fez o check-out parcial da versão que
estava em sua lista de check-outs permitidos. O check-out falso não executa a operação
de check-out propriamente dita, apenas modifica o estado da versão para ela seja
disponibilizada na área de trabalho do desenvolvedor, dando a falsa idéia de que o
check-out foi feito naquele momento (por isso o nome check-out parcial). Uma vez
neste estado, a versão aparece na área de trabalho do desenvolvedor e permite que ele
faça as alterações necessárias.
96
Aguardando aprovação: neste estado o desenvolvedor já concluiu totalmente as
alterações necessárias e enviou para aprovação. Este estado significa que a versão foi
enviada, mas ainda não foi analisada.
Em análise: neste estado a versão que foi enviada para aprovação esta sendo analisada
por um responsável. Este estado indica que a versão esta sob análise, mas ainda não esta
totalmente concluída, podendo permanecer neste estado enquanto durar o tempo de
análise.
Reprovado: neste estado a análise da versão foi reprovada e requer novas
modificações. As versões que estão neste estado são visíveis na lista de check-outs
permitidos do desenvolvedor com a sinalização de correção, ou seja, o desenvolvedor
terá de fazer um check-out falso para que esta versão esteja novamente em sua área de
trabalho e seja modificada para só então ser reenviada para nova análise.
Aguardando Check-in: neste estado a análise da versão foi aprovada e foi
encaminhada para o responsável por efetuar o check-in. As versões que estão neste
estado aparecem na lista de check-ins a serem feitos e aguarda até que o gerente de
mudanças o faça.
Controlado: neste estado a operação de check-in já foi realizada para a versão e ela
encontra-se controlada no repositório.
Reservado: neste estado a versão este impedida de ser feita check-out, ou seja, uma
modificação nesta versão foi solicitada por alguém e enquanto a nova versão não for
controlada no repositório a versão anterior (para a qual foi solicitada a modificação)
permanece com restrição de alteração. Este mecanismo implementa o conceito de
check-out exclusivo onde apenas um usuário por vez pode solicitar a alteração de uma
versão.
Bloqueado: neste estado a versão por algum motivo está impedida de ser manipulada.
Nenhuma operação poderá ser realizada sob esta versão enquanto o desbloqueio não for
realizado.
97
Descartado: neste estado a versão foi explicitamente obsoletada e passa a não ter mais
“validade”. Para que este estado seja estabelecido o gerente do GCS precisa
explicitamente realizar a operação de descarte. Vale ressaltar que a criação de uma nova
versão não descarta a anterior.
6.6 Visibilidade e Versionamento de Artefatos
Outras duas características importantes implementadas neste trabalho são: o nível de
visibilidade dos IC’s e a forma na qual as versões são definidas. Essas duas
características são configuráveis de acordo com a necessidade de cada projeto e são
descritas a seguir neste capítulo.
6.6.1 Visibilidade dos Artefatos
Para garantir maior segurança nas informações mantidas no repositório, implementa-se
o conceito de visibilidade para os artefatos. Esse mecanismo permite que alguns
artefatos do repositório possam ser visíveis a todos os usuários do sistema enquanto
outros artefatos, por algum motivo, sejam visíveis apenas a um grupo restrito de usuário
com permissão de hierarquia mais elevada.
Os níveis de visibilidade definidos para o sistema são descritos abaixo:
• Públicos: os artefatos definidos com visibilidade pública são visíveis a todos os
usuários do sistema, não tendo restrições.
• Privados: os artefatos definidos com visibilidade privada são visíveis apenas
aos usuários com papel de Gerente de Configuração. Nenhum outro usuário
poderá visualizar esses artefatos no repositório até que eles sejam públicos.
6.6.2 Determinando o Tipo de Versionamento
Uma das maneiras mais comuns de numeração de versão é incrementando o segundo
numero após o ponto (e.g.: 1.1, 1.2 e 1.3) sendo esta a maneira padrão na qual o sistema
adota. Entretanto pode-se haver a necessidade de configurar a forma como será feita a
98
numeração das versões. Essa configuração é oferecida através da opção de tipos de
versionamentos do sistema.
Um tipo de versionamento é uma configuração pré-estabelecida que determina a forma
que o incremento da versão será feito (antes ou após a vírgula). Um tipo de
versionamento é composto por um nome que identifica o tipo de versionamento, a regra
de versionamento (antes ou depois da vírgula) e de quanto será o incremento.
Um exemplo de aplicação deste mecanismo é poder estabelecer o número das versões
de acordo com a alteração ou revisões realizadas. Supondo que temos um IC na versão
1.0 e uma alteração for realizada podemos versioná-la para 2.0, mas se for realizada
uma revisão podemos versioná-la para 1.1. Ou ainda definir incrementos maiores para
destacar níveis diferentes de alterações (e.g.: 10.1, 20.1, 30.1).
99
CAPÍTULO 7
ESTUDO DE CASO
Este Capítulo apresenta um estudo de caso que visa ilustrar parte do processo
utilizando a ferramenta desenvolvida neste trabalho. O exemplo utilizado para esse
estudo consiste em criar um IC no repositório, definir suas características e gerar a
versão inicial 1.0. Posteriormente este estudo ilustra o processo de alteração da
versão criada. Também são apresentadas algumas telas onde os gerentes podem
visualizar as informações.
7.1 Atividade de Definição de Classe Artefato.
FIGURA 7.1 Caso de Uso Definição de Classe Artefatos.
A Figura 7.1 apresenta a tela principal para a manipulação das Classes Artefatos. No
canto esquerdo desta interface o usuário poderá realizar uma busca por palavra chave, e
os resultados serão apresentados ao lado direito da mesma tela. Esta interface permite
ainda ao usuário criar, excluir, visualizar ou atualizar um registro de Classe Artefato.
Botões criar/excluir link para visualização permite edição dos dados
Busca
100
7.2 Atividade de Criação de Classe Artefato
FIGURA 7.2 Formulário de Criação de Classe Artefato.
A Figura 7.2 apresenta o formulário de criação da Classe Artefato onde o usuário
poderá definir a Classe Artefato, bem como os atributos que a compõem. O formulário
permite a navegação através das abas na parte superior que dão acesso ao formulário
com as características de identificação da Classe Artefato, atributos e relacionamentos.
Para este exemplo foi criada uma Classe Artefato, denominada Documento de
Requisitos com os atributos nome, descrição e observação.
Dados para identificação da nova Classe Artefato.
Dados para identificação dos atributos.
Atributos já definidos
101
7.3 Atividade para definição do IC
FIGURA 7.3 Interface de Acesso ao Repositório de Artefatos.
A Figura 7.3 apresenta a interface de acesso ao repositório onde o usuário poderá
manipular os IC de acordo com o projeto. Ao lado esquerdo é apresentada uma árvore
de Classes Artefatos com seus respectivos IC definidos para cada projeto. A interface
permite ainda uma busca por palavra chave, um botão para definição dos IC através de
um template pré-definido, um botão para definição de IC (independente de templates) e
um botão para excluir os IC (dependendo do caso).
Arvore de IC do projeto Definir novo IC para o projeto
102
FIGURA 7.4 Formulário de Definição do IC para o Projeto.
A Figura 7.4 apresenta o formulário para a definição do IC para o Projeto. Neste
exemplo foi criado um IC denominado DREQ - Dissertação Mestrado que é um IC da
Classe Artefato Documento de Requisitos. Após definir o IC a interface disponibiliza
um botão para que o usuário possa publicar o artefato como definido.
Publica o IC como definido
103
7.4 Atividade para Permitir a Criação
FIGURA 7.5 Formulário para Permitir a Criação do IC.
A Figura 7.5 apresenta a interface onde o usuário define a pessoa que será responsável
pela criação de uma versão para o IC definido anteriormente.
7.5 Atividade para Criação de Versão do IC
FIGURA 7.6 Tela de Check-outs Permitidos do usuário.
A Figura 7.6 apresenta a tela onde são identificados os IC que estão permitidos para o
usuário fazer a operação de check-out. Nesta interface o usuário deverá fazer o check-
out (check-out falso) para que o IC seja disponibilizado em sua área pessoal de trabalho.
Faz o check-out para a área pessoal
104
FIGURA 7.7 Tela de Manipulação de Informações do IC.
A Figura 7.7 apresenta o formulário onde o usuário permitido vai manipular as
informações referentes ao IC. Cada Campo apresentado nesta interface é montado
dinamicamente de acordo com as definições de sua Classe Artefato. O usuário poderá
apenas salvar as informações e enviar para a qualidade depois ou salvar e já enviar.
Atributos definidos na Classe Artefato.
Relacionamentos definidos na Classe Artefato.
105
7.6 Atividade para Avaliar IC
FIGURA 7.8 Formulário de Avaliação do IC.
A Figura 7.8 apresenta o formulário de avaliação do IC enviado à qualidade. Nesta tela
é possível visualizar todas as informações sobre o IC bem como seus relacionamentos.
106
7.7 Atividade para Fazer Check-in
FIGURA 7.9 Formulário de Check-in.
A Figura 7.9 apresenta o formulário para realização de Check-in. Nesta interface o
usuário faz o check-in e seleciona o tipo de versionamento de acordo com a pré-
configuração que pode ser realizada no modo de configuração da ferramenta.
107
7.8 Atividade para Visualização das Versões no Repositório
FIGURA 7.10 Tela de Visualização das versões dos IC.
A Figura 7.10 apresenta a interface de visualização das versões existentes de cada IC no
repositório. Neste exemplo podemos visualizar a versão 0.1 que foi criada para o IC
ART -13 DREQ – Dissertação de Mestrado. Podemos para cada versão realizar as
operações de check-out (dependente de proposta de modificação), ver histórico,
bloquear, desbloquear, alterar a visibilidade ou editar informações.
A partir de agora esta versão estará disponível para ser visualizada e utilizada pelos
membros da equipe do projeto. Caso seja necessário realizar alguma modificação nela,
deve-se seguir formalmente o processo de alteração. As interfaces a seguir apresentam
um exemplo do processo de modificação desta versão;
Versões existentes do IC “DREQ – Dissertação Mestrado” Operações disponíveis para a versão
108
7.9 Atividade de Proposta de Mudança
FIGURA 7.11 Formulário de Proposta de Alteração.
A Figura 7.11 apresenta o formulário para elaboração da proposta de alteração de um
artefato quando este se encontra controlado e visível para os usuários. Em uma mesma
proposta poderão ser enviadas várias alterações para artefatos diferentes. Uma proposta
poderá ser associada a um problema levantado pelo processo de resolução de
problemas. Este processo foi implementado no ambiente e-WebProject® e integrado a
ferramenta de GCS desenvolvida.
Vincular a um problema
Características do artefato a ser alterado
Escolher o artefato a ser alterado
Características da Proposta
109
7.10 Atividade de Análise de Proposta de Mudança
FIGURA 7.12 Interface Analisar Proposta de Mudança.
A Figura 7.12 apresenta o formulário para analise da proposta de modificação de
artefato enviada por um desenvolvedor. Nesta proposta de modificação poderão ser
adicionadas diversas solicitações de modificação para diferentes artefatos. Neste caso, a
análise será realizada para cada artefato separadamente.
Dados da analise da proposta
Analise de cada artefato
110
FIGURA 7.13 Interface para Relatar a Análise da Proposta.
A Figura 7.13 apresenta a interface para registrar a análise dos artefatos solicitados para
modificação na proposta. Para cada artefato será registrado o resultado da análise e
posteriormente serão definidos os artefatos que serão alterados. Para uma mesma
solicitação pode ser necessário alterar mais de um artefato (dependendo dos
relacionamentos entre os artefatos), e é neste momento que isso será definido.
Registro da analise para modificação do artefato
Definição dos artefatos que serão modificados
111
7.11 Atividade de Permissão de Check-out
FIGURA 7.14 Interface de Permissão de Check-out.
A Figura 7.14 apresenta a interface para a atividade de permissão de check-out. Após as
propostas de mudanças serem analisadas e aceitas, faz-se necessário definir o
responsável pela alteração efetiva do artefato. Essa atividade dá a permissão ao usuário
definido de realizar o check-out do artefato para alteração.
Após o check-out ser permitido, o usuário irá visualizar o artefato para ser modificado
em sua área (vide figura 7.6). A partir deste ponto o processo segue o mesmo fluxo
descrito na atividade de criação da versão do artefato.
Definir o usuário responsável pelo
Proposta de mudança aceita
112
113
CAPÍTULO 8
CONCLUSÕES
A abordagem apresentada neste trabalho mostra que com a utilização de modelos de
objetos dinâmicos é possível construir um repositório de artefatos capaz de determinar
no decorrer da execução do processo as características específicas para os artefatos.
Alguns benefícios podem ser observados como a qualidade das informações mantidas
sobre os artefatos, a flexibilidade de adaptação às diferentes necessidades e o
dinamismo com o qual as informações podem ser manipuladas a partir de meta-
informação do artefato.
Outra vantagem observada é que esta forma de estruturação do repositório, possibilita a
definição de modelos para os artefatos vindo a estar em conformidade com a tendência
das organizações que desenvolvem software e que adotam modelos de maturidade ou
gestão (CMMI, ISO12207, MPSBr) em definir modelos de documentos (templates) e
documentos que especifiquem as regras para elaboração dos artefatos (ex. padronização
de programas em JAVA).
Entretanto, algumas desvantagens podem ser observadas como a complexidade do
modelo, complexidade de implementação e a necessidade do envolvimento de uma
pessoa cujo conhecimento sobre artefatos seja profundo o suficiente para saber como
eles devem ser estruturados no repositório de modo a definir as classes dos artefatos.
A prototipação do processo de GCS contribuiu para consolidar alguns conceitos e
validar a conformidade de atividades já estabelecidas no processo com utilização do
repositório dinâmico.
8.1 Contribuições
De acordo com os objetivos e características definidas para este trabalho de dissertação
de mestrado segue abaixo a descrição das contribuições:
114
• Permitir definir quais informações serão mantidas sobre cada artefato;
A abordagem apresentada neste trabalho possibilita a definição das características
que serão mantidas sobre cada artefato através da definição de uma Classe de
artefato para a qual são definidos os atributos e através da qual são construídos os
artefatos.
• Permitir estabelecer o nível de granularidade a ser mantido pelo repositório;
O nível de granularidade pode ser definido através dos relacionamentos entre as
classes de artefatos criadas. A abordagem permite definir tanto um nível alto de
granularidade (e.g. definindo a classe artefato como “ClasseJava” e colocando como
seu atributo apenas um campo para upload do arquivo do código-fonte) quanto um
nível detalhado de granularidade(e.g. definir duas classes de artefato denominadas
“ClasseJava” e “MetodosJava” com seus respectivos atributos e atribuir
relacionamento entre elas).
• Permitir que as configurações acima sejam decididas em tempo de execução;
Permitir que alterações nas definições do repositório sejam feitas de forma
transparente não sendo necessário reescrever o sistema;
Através da utilização de DOM foi possível o cumprimento destes dois objetivos
sendo que a definição de novas classes de artefatos (atributos e relacionamentos)
não necessita da interrupção e nem de alteração no código-fonte da ferramenta.
• Construir uma ferramenta para apoiar o processo de GCS; Manter controle de
versões dos artefatos dinâmicos; Manter controle de configuração dos artefatos
dinâmicos; Manter controle do processo de alteração dos artefatos dinâmicos;
Acompanhar a situação de cada versão dos artefatos em cada fase do processo;
Integrar o repositório dinâmico com a ferramenta de GCS;
Através da ferramenta desenvolvida neste trabalho é possível fazer controle de
versões e configurações; controle do processo de modificação bem como
acompanhar os estados de cada artefato, atendendo a todos estes objetivos acima.
115
• Integrar a ferramenta de GCS ao ambiente de engenharia de software e-
WebProject®.
A ferramenta de GCS desenvolvida trabalha de maneira integrada ao ambiente de
engenharia de software e-WebProject® , sendo este a base de controle de acesso e
permissões dos papeis assumidos pelos usuários.
Como contribuição deste trabalho destaca-se também a implementação das atividades
definidas para o CMMI. Segue abaixo uma comparação entre as atividades definidas no
CMMI e as atividades implementadas neste trabalho.
TABELA 8.1 Comparação entre atividades do CMMI e suportadas no trabalho.
Meta específica
Prática específica
Sub-Práticas CMMI Atende Observação
SG 1 - Estabelecer baselines
SP 1.1 - Identificar os itens de configuração
Selecionar os itens de configuração e os produtos de trabalho associados segundo um critério
documentado
sim Ao criar uma configuração é
possível selecionar os IC que farão parte
dela.
Atribuir um identificador único para o IC
sim Para cada IC é definido um prefixo e
um código de identificação.
Especificar as características
importantes de cada IC
sim Para cada IC podem-se definir quais
características serão mantidas
Especificar quando um IC deve
ser colocado sobre a gerência de configuração
sim O mecanismo de WorkFlow
determinada que o IC é colocado sob
controle pela atividade de Check-in após ser encaminhado e aceito
pelo processo de qualidade.
Identificar um proprietário responsável por cada IC
parcial Os IC são associados a um projeto, e cada operação realizada sob as versões é
registrada e identifica quem a realizou.
Continua
116
SP 1.2 - Estabelecer um
sistema de controle de
Configuração
Estabelecer um mecanismo para gerenciar
múltiplos níveis de controle na gestão da
configuração
sim O nível de controle que se deseja pode
ser definido através da granularidade definida nas classes artefatos. A privacidade pode
ser garantida através da visibilidade e
papeis do sistema. Armazenar e recuperar
itens de configuração em um sistema de gerenciamento
sim Através do repositório podemos colocar um
ítem sob controle (seguindo o workflow) e recupera-lo sempre
que ele esteja disponível.
Compartilhar e transferir itens de configuração
dentro de um sistema de gerenciamento da
configuração.
sim O repositório público que permite o
compartilhamento dos IC, possibilitando aos desenvolvedores a manipulação (com restrição) dos IC
controlados. Armazenar e recuperar
versões arquivadas de itens de configuração
sim A cada check-in realizado, uma nova versão é criada no
repositório. A versão (quando disponível) pode ser recuperada
no Repositório. Armazenar, atualizar e
recuperar registros de gerenciamento da
configuração.
sim Os registros de cada IC podem ser
acompanhados através do histórico de
suas operações. Criar relatórios de
gerenciamento da configuração
sim É possível retirar relatórios sobre a situação dos IC’s,
sobre as configurações.
Preservar o conteúdo do sistema de gerenciamento
da configuração
sim Este mecanismo é fornecido pela ferramenta e-
WebProject, através de backups, e
mecanismos de recuperação de falhas.
Revisar a estrutura do processo de
gerenciamento da configuração caso
necessário
não Uma vez que o processo é modelado e executado através de uma maquina de
processos, essa atividade será
atendida pelos ajustes
Tabela 8.1 - Continuação
Continua
117
no modelo de processo.
SP 1.3 - Criar ou Distribuir Baselines
Obter autorização do comitê de controle da
configuração (CCC) antes de criar ou liberar linhas
de bases de itens de configuração
sim Os IC’s só podem ser criados por um papel
responsável. Caso um desenvolvedor queira criar um artefato, uma proposta deverá ser
submetida a aprovação.
Criar ou liberar linhas de bases somente a partir de itens de configuração sob
gerenciamento de configuração
sim As releases poderão ser criadas apenas a
partir de IC pertencentes a configurações previamente controladas.
Documentar o conjunto de itens de configuração que formam uma linha de base
parcial A documentação pode ser feita através dos
campos determinados na criação da Configuração.
(documentação pobre em detalhes)
Tornar público o atual conjunto de linhas de
bases
sim Através do repositório podemos definir a
visibilidade dos itens controlados deixando-os ou não visíveis a
todos. SG 2 -
Rastrear e Controlar as Mudanças
SP 2.1 - Rastrear as Requisições de Mudanças
Registrar os pedidos de alterações em uma base de pedidos de alterações
sim As mudanças devem passar por um
processo formal através de uma
proposta enviada ao responsável.
Analisar o impacto das alterações e correções
propostas
sim As propostas são analisadas e o
impacto de suas correções é analisado
através dos relacionamentos
mantidos entre os IC. Revisar pedidos de
alterações com o profissional responsável
pelas linhas de base para obter sua aprovação
parcial Pode ser considerado através do papel
definido para o pela analise das propostas
de mudanças. Rastrear o estado do
pedido de alteração até a sua conclusão
sim As propostas de mudanças passam por diferentes estados que
podem ser visualizados para
definir qual a fase se
Tabela 8.1 - Continuação
Continua
118
encontra.
SP 2.2 - Controlar os Itens de
Configuração
Controlar as alterações nos itens de configuração durante o ciclo de vida dos
produtos
sim Cada IC é mantido sob controle e quando uma alteração precisa ser feita ela passa por todo processo formal de mudança e o IC é
versionado. Obter autorização antes
introduzir um item de configuração modificado
no sistema de gerenciamento de
configuração
sim Através das permissões
concedidas ao papeis apenas o papel responsável tem
permissão de fazer o checkin para introduzir um IC modificado no
repositório. Fazer “Check-in” e “check-
out” dos itens de configuração no sistema
de gerenciamento de configuração de maneira a
manter o acerto e a integridade dos itens de
configuração
sim O sistema implementa o modelo Check-in /
Check-out
Realizar revisões para garantir que as alterações
não tenham causado defeitos imprevistos na linha de base. (e.g., que
não ameacem a segurança ou a proteção
do sistema)
sim Garantido pelo analise de impacto feito
através dos relacionamentos dos
IC.
Registrar as alterações nos itens de configuração, bem como as justificativas
para elas.
sim Para cada operação realizada sob uma versão é registrado um histórico (quem,
quando, onde e porque)
SG 3 - Estabelecer Integridade
SP 3.1 - Estabelecer um
registro do Gerenciamento da Configuração
Registrar as ações do gerenciamento da
configuração em um nível de detalhe suficiente de
modo a que o conteúdo e o estado de cada item de
configuração sejam conhecidos e que versões
anteriores possam ser recuperadas.
sim Cada versão é tratada individualmente,
sendo que o estado e as informações sobre cada uma delas são
mantidos, possibilitando
recuperar qualquer informação sobre qualquer versão.
Garantir que os interessados tenham
acesso e conhecimento do estado da configuração
dos itens de
sim Através dos papéis que definem as
permissões e através da visibilidade dos IC podemos garantir o
Tabela 8.1 - Continuação
Continua
119
configuração acesso aos interessados aos IC.
Especificar a versão atual das linhas de base
sim Assim como os IC uma configuração
pode ser versionada. Identificar a versão dos
itens de configuração que constituem uma linha de
base específica
sim Para cada configuração pode-se
determinar qual versão de qual IC será
incluída. Descrever as diferenças
entre linhas de base sucessivas
parcial Apenas é possível verificar as diferenças
entre versões que compõe uma ou outra
configuração. Revisar o estado e o
histórico de alterações de cada item de configuração
sim Através do Histórico das versões podem-se verificar as operações
que foram feitas ao longo de sua vida.
SP 3.2 - Executar Auditoria da
Configuração
Avaliar a integridade das linhas de base
não
Confirmar que os registros do gerenciamento da
configuração identificam corretamente os itens de
configuração
não
Rever a estrutura e a integridade dos itens no
sistema de gerenciamento de configuração
não
Confirmar a completude e o acerto dos itens no
sistema de gerenciamento da configuração
não
Confirmar a conformidade com a aplicação dos
padrões e procedimentos definidos
não
Rastrear as ações dos itens da auditoria até a
sua conclusão
não
Atividades não suportadas pela
ferramenta, entretanto a ferramenta fornece informações para a realização dessas
atividades.
Conforme apresentado na Tabela 6.1 a maioria das atividades definidas no modelo
CMMI (2002) são suportadas neste trabalho.
Outra contribuição importante é a capacidade de rastreabilidade dos artefatos. A
ferramenta permite rastrear a evolução de cada artefato armazenada no repositório
Tabela 8.1 - Conclusão
120
através de seus relacionamentos. È possível, por exemplo, rastrear a origem de um
artefato, sua composição bem como suas modificações ao longo do tempo.
8.2 Trabalhos Futuros
Como trabalho futuro propõe-se melhorar o modelo utilizado para versionar as classes
de artefatos, possibilitando desta forma a adição ou remoção de características definidas
nas classes, sem que estas alterações sejam necessariamente incorporadas aos IC já
definidos. Embora a solução para esse problema já tenha sido pensada, estes aspectos
não foram implementados na solução atual pelo impacto das alterações no tempo
pretendido.
Outra proposta interessante de continuidade deste trabalho é a integração do repositório
dinâmico com a máquina de processos permitindo que ao definir um modelo de
processos sejam definidos também os artefatos de entrada e saída de cada atividade. O
ambiente de engenharia de software e-WebProject®, no qual a ferramenta está inserida,
está em constante evolução e diversos trabalhos tem sido realizados no intuito de
aprimorá-lo. Alguns trabalhos desenvolvidos (CEREJA, 2004 ; CASILLO, 2006)
apresentam propostas de implantação de agentes autônomos para controlar a máquina
de processos do e-WebProject®.
121
REFERÊNCIAS BIBLIOGRÁFICAS
ABDALA, M. A. D. Uma abordagem para a gerência das modificações e da configuração em um ambiente integrado para o desenvolvimento e gestão de projetos de software. 2004-06-29. 292 p. (INPE-14099-TDI/1078). Dissertação de Mestrado - Instituto Nacional de Pesquisas Espaciais, São José dos Campos. 2004. Disponível em: <http://urlib.net/sid.inpe.br/jeferson/2004/10.01.16.56>. Acesso em: 02 maio 2008.
ACUÑA, S. T. Software process modelling, In: WORLD MULTICONFERENCE ON SYSTEMICS, CIBERNETICS AND INFORMATICS (SCI 2001), 5.,. 2001, Orlando, Florida. Proceedings... Orlando: ISAS/ICI, 2001.
ALMEIDA, W. R. Uma abordagem para a persistência dos modelos de objetos de sistemas configuráveis e adaptáveis. Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, São José dos Campos. 2005.
AMBRIOLA, V.; CONARDI, R.; FUNGGETTA, A. Assessing process centered software engineering environments. Transactions on Software Engineering and Methodology, v. 6, n. 3, p. 283-328, 1997
BERLINER, B. CVS II: Parallelizing Software Development. In: WINTER 1990 USENIX TECHNICAL CONFERENCE, 1990, Washington, DC. Proceedings … Washington: USENIX, 1990
BRUNT, E. V. Implementing a flexible software configuration management process. Software Engineering II , 1996. Disponível em: citeseer.ist.psu.edu/vanbrunt96implementing.html. Acesso em: 02 maio 2008.
BARNSON, M. P.; STEENHAGEN, J. The Bugzilla guide – 2.17.5 development release. [S.l]: The Bugzilla Team, 2003.
CAPABILITY MATURITY MODEL INTEGRATION (CMMI). CMMI for Systems Engineering software, integreted product and process development, and supplier sourcing. Pittsburgh PA:CMMI-SE/SW/IPPD/SS, v1.1), 2002.
CARDOSO, P. E. Uma nova arquitetura para a representação das regras de negócio em modelos de objetos dinâmicos. 2005-03-01. 135 p. (INPE-13044-TDI/1020). Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, São José dos Campos. 2005. Disponível em: <http://urlib.net/sid.inpe.br/iris@1913/2005/04.11.13.31>. Acesso em: 02 maio 2008.
CEREJA JR., M. G. S. A.; N.; BORREGO FILHO, L.F.; GENVIGIR, E.C.; LUQUE, L.; TAVARES, R.P.; CASILLO, B.H. (PDE) Process Definition Environment: uma ferramenta para apoio à definição de processos de software no ambiente e-WebProject.
122
In: CONGRESSO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE.14., 2003, Curitiba. Proceedings… Curitiba: CITS, 2003.
CONRADI, R.; JACCHERI, M.L. Process modelling languages., In: Derniame, J. C.; Ali Kaba, B.; Wastel, D. (eds.) Software process: principles, methodology, and technology. New York: Springer Verlag, 1998. Lecture Notes in Computer Science 1500.
CUGOLA G.; GHEZZI, C. Software processes: a retrospective and a path to the future. In: INTERNATIONAL CONFERENCE ON SOFTWARE PROCESS, 5., 1998, Lisle. Proceedings… Lisle: [s.n], 1998.
ESTUBLIER, J. Software configuration management: a roadmap. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, THE FUTURE OF SOFTWARE ENGINEERING, 22, Limerick. Proceedings... Limerick, Ireland, 2000. p. 279-289.
FIGUEIREDO, S.; SANTOS, G.; ROCHA, A. R. Gerência de configuração em ambientes de desenvolvimento de software orientados à organização In.: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 3., 2004, Brasília, DF, Brasil. Anais... Brasília: [s.n], 2004.
FUGGETTA. A. Software process: a roadmap. In: Finkelstein, A. (ed.). The future of software engineering. [S.l]: ACM Press, 2000.
GENVIGIR, E. C. Um modelo de processo da engenharia de requisitos aplicáveis a ambientes de engenharia de software centrados em processos. 2004-05-27. 258 p. (INPE-14630-TDI/1201). Dissertação de Mestrado - Instituto Nacional de Pesquisas Espaciais, São José dos Campos. 2004. Disponível em: <http://urlib.net/sid.inpe.br/jeferson/2004/07.05.16.17>. Acesso em: 02 maio 2008.
GRUHN, V. Process-centered software engineering environments: a brief history and future chalenges. Anals of Software Engineering, v.14, p. 363-382, 2002.
HASS, A. Configuration management principles and price. New York: Addison Wesley Professional, 2002.
HUMPHREY, W. S; Kellner, M. I. Software process modeling. Pittsburgh, Pennsylvania: Carnegie Mellon University- SEI Software Engineering Institute ,1988.
IBM. IBM rational ClearCase. 2007. Disponível em: http://www-306.ibm.com/software/awdtools/clearcase . Acesso em: 29/maio/2007.
IBM. IBM rational ClearQuest. 2007b. Disponível em: http://www-306.ibm.com/software/awdtools/clearquest .Acesso em: 29/maio/2007.
INTERNACIONAL ORGANIZATION OF STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL (ISO/IEC). ISO/IEC15504-2. Software
123
Process Assessment – A reference model for processes and process capability- Part 2”. Geneva, Switzerland, 1998.
INTERNACIONAL ORGANIZATION OF STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMMISION.(ISO/IEC). ISO/IEC12207. International standard for information technology - software life cycle processes. Pittsburgh, Pennsylvania, 1995.
LAHOZ, C. H. N. Uma abordagem para a gerência da qualidade em um ambiente de engenharia de software centrado em processo. 2004-03-19. 309 p. (INPE-11550-TDI/958). Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, São José dos Campos. 2004. Disponível em: <http://urlib.net/sid.inpe.br/jeferson/2004/05.06.14.08>. Acesso em: 02 maio 2008.
LOPES, L. G. B.; MURTA, L. G. P.; WERNER, C. M. L. Controle de modificações em software no desenvolvimento baseado em componentes. In: WORKSHOP DE MANUTENÇÃO DE SOFTWARE MODERNA (WMSWM), 2005, Manaus, AM. Anais… Manaus: [s.n.], 2005.
KELLNER, M. I. H.; GREGORY, A. Software process modeling. Pennsylvania: Carnegie Mellon University.. 1988.
KRUCHTEN, P. Introdução ao RUP: Rational Unified Process. Rio de Janeiro: Ciência Moderna, 2003.
LEON, A. A guide to software configuration management. Norwood, MA: Artech House Publishers, 2000.
MACKAY, S. E. The state of the art in concurrent, distributed configuration management. In: NTERNATIONAL WORKSHOP ON SOFTWARE CONFIGURATION MANAGEMENT (SCM5), 5., 1995, Seattle, WA. Proceedings… Seattle: [s.n], p. 180-193. Disponível em: http://citeseer.ist.psu.edu/mackay95state.html. Acesso em: 02 maio 2008.
MURTA, L. G. P., Gerência de configuração no desenvolvimento baseado em componentes. Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2006.
OLIVEIRA, A.A.C. P.; PRIMO F.F.; CRUZ, J.L.; MARTINO, W.R. Gerência de configuração de software – evolução do software sob controle. São Paulo: Instituto Nacional de Tecnologia da Informação, Laboratório de Avaliação e Melhoria de Processo de Software, 2001. Relatório Técnico.
PRESSMAN, R. S. Engenharia de software. São Paulo: Editora Makron Books, 2006.
REIS, C. A. L. APSEE - uma abordagem baseada em conhecimento para gerência de processos de software evolutivos. Porto Alegre: Universidade Federal do Rio Grande do Sul, 2001. Proposta de Tese.
124
REIS, C. R. Uma visão geral do Bugzilla, uma ferramenta de acompanhamento de alterações. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE – SBES, 16., 2002, Gramado RS. Anais... Gramado: SBC, 2002. Sessão de Ferramentas.
RIEHLE, D. T.; M.; Johnson, R. Dynamic object model. In: CONFERENCE ON PATTERNS LANGUAGES OF PROGRAMS, 2000, Whasington. Proceedins… Washington: Washington University Departament of Computer Science, 2000.
SANT'ANNA, N. Um ambiente integrado para o apoio ao desenvolvimento e gestao de projetos de software para sistemas de controle de satélite. 2000-09. 225 p. (INPE-8306-TDI/765). Tese (Doutorado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, Sao Jose dos Campos. 2000. Disponível em: <http://urlib.net/dpi.inpe.br/lise/2002/03.28.20.03>. Acesso em: 02 maio 2008.
SANT'ANNA, N.; CEREJA JR., M. G.; BORREGO FILHO, L. F.; LUQUE, L.; CASILLO, B. H. e-WebProject: um ambiente integrado para apoio ao desenvolvimento e gestão de projetos de softare. In: CONFERÊNCIA INTERNACIONAL DE TECNOLOGIA DE SOFTWARE: QUALIDADE E PRODUTIVIDADE NO GERENCIAMENTO DE PROJETOS, 13., 2002, Curitiba, BR. Anais... 2002. p. 163-175.
SOCIEDADE SOFTEX. MPS.BR – Melhoria de processo do software brasileiro[S.l]: Softex-Associação para Promoção da Excelência do Software Brasileiro, 2005. (MPS.BR-Guia Geral).
SOMMERVILLE, I. Engenharia de software. São Paulo: Editora Addison Wesley. 2003.
TICHY, W. RCS – a system for version control, Software - practice & experience, v.15, p 637-654. 1985
YODER, J. W. B., F.; JOHNSON, R. Architecture and design of adaptive object models. In: CONFERENCE ON OBJECT ORIENTED PROGRAMING SYSTEMS, 2001, Tampa Bay, Florida. Proceedings… Tampa Bay: OOPSLA, 2001.
125
APÊNDICE A
DOCUMENTAÇÃO DOS CASOS DE USO DO SISTEMA
Neste Apêndice será descrito cada caso de uso detalhadamente, separados por seus
papeis.
A1 Administrador da Configuração
Este papel permite ao usuário fazer as configurações básicas inicias necessárias para o
funcionamento do sistema. Para que a ferramenta esteja em condições de uso, tornam-se
necessárias algumas configurações básicas tais como valores pré-definidos de categorias
que devem estar devidamente cadastrados no sistema antes da operação efetiva. Estas
configurações são atribuídas como responsabilidades do papel denominado
Administrador da Configuração.
ud RepositorioDeArtefatos
Administrador da
Configuração
Manter GrauDeRelacionamento
Manter Categoria de Template de
Configuracao
Manter Tipo de Versionamento
Manter Prefixo
FIGURA A.1 Casos de Uso do Administrador da Configuração.
A1.1 Caso de Uso Manter Categoria de Template de Configurações Identificador do Caso de Uso UC-GCM-1.1 Nome do Caso de Uso Manter Categoria de Template de Configuração
126
Atores Administrador da Configuração Pré Condição Um usuário com perfil de Administrador da Configuração
deve ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre as
categorias dos templates das configurações. O usuário poderá definir quais os tipos de categorias devem ser utilizados para categorizar os templates de configuração.
Primeiro Cenário – Criar Nova Categoria de Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter categorias de template de configurações; 2.- O sistema apresentará uma lista com todos as categorias de template de configurações disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à categorias de template de configurações, como nome, descrição e observação; 5.- O usuário entra com os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Categoria de Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter categorias de template de configurações; 2.- O sistema apresentará uma lista com todos as categorias de template de configurações disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais da categoria de template de configurações, como nome, descrição e observação; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Excluir Categoria de Template da Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter categorias de template de configurações; 2.- O sistema apresentará uma lista com todos as categorias de template de configurações disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados;
127
5.- O sistema verifica as informações e exclui da base de dados. Fluxos Alternativos
No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Categoria de Template da Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter categorias de template de configurações; 2.- O sistema apresentará uma lista com todos as categorias de template de configurações disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre a categoria de template de configurações.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A1.2 Caso de Uso Manter Grau de Relacionamento Identificador do Caso de Uso UC-GCM-1.2 Nome do Caso de Uso Manter Grau de Relacionamento Atores Administrador da Configuração Pré Condição Um usuário com perfil de Administrador da Configuração
deve ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre os graus
de relacionamento. O usuário poderá definir quais os tipos de relacionamento devem existir entre os artefatos armazenados no repositório.
Primeiro Cenário – Criar Novo Grau de Relacionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter grau de relacionamento; 2.- O sistema apresentará uma lista com todos os registros de grau de relacionamento disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de grau de relacionamento, como nome, descrição e observação; 5.- O usuário entra com os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Grau de Relacionamento Fluxo de Eventos:
128
Fluxo Principal 1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter grau de relacionamento; 2.- O sistema apresentará uma lista com todos os registro de grau de relacionamento disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do grau de relacionamento, como nome, descrição e observação; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Excluir Grau de Relacionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter grau de relacionamento; 2.- O sistema apresentará uma lista com todos os registros de grau de relacionamento disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Grau de Relacionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter grau de relacionamento; 2.- O sistema apresentará uma lista com todos os registros de grau de relacionamento disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o grau de relacionamento.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A1.3 Caso de Uso Manter Tipo de Versionamento Identificador do Caso de Uso UC-GCM-1.3 Nome do Caso de Uso Manter Tipo de Versionamento Atores Administrador da Configuração Pré Condição Um usuário com perfil de Administrador da Configuração
deve ter sido validado pelo sistema.
129
Descrição Possibilita a manutenção das informações sobre os tipos de versionamento. O usuário poderá definir como serão versionados os artefatos e qual o valor de seu incremento.
Primeiro Cenário – Criar Novo Tipo de Versionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter tipo de versionamento; 2.- O sistema apresentará uma lista com todos os registros de tipo de versionamento disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de tipo de versionamento, como nome, descrição, observação, valor do incremento e posição do incremento (antes ou depois do ponto); 5.- O usuário entra com os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Tipo de Versionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter tipo de versionamento; 2.- O sistema apresentará uma lista com todos os registro de tipo de versionamento disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do tipo de versionamento, como nome, descrição, observação, valor do incremento e posição do incremento (antes ou depois do ponto); 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Excluir Tipo de Versionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter tipo de versionamento; 2.- O sistema apresentará uma lista com todos os registros de tipo de versionamento disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
130
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Tipo de Versionamento Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter tipo de versionamento; 2.- O sistema apresentará uma lista com todos os registros de tipo de versionamento disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o tipo de versionamento.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A1.4 Caso de Uso Manter Prefixo Identificador do Caso de Uso UC-GCM-1.4 Nome do Caso de Uso Manter Prefixo Atores Administrador da Configuração Pré Condição Um usuário com perfil de Administrador da Configuração
deve ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre os
prefixos de identificação dos artefatos. O usuário poderá definir prefixos de identificação por projetos.
Primeiro Cenário – Criar Novo Prefixo Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter prefixo; 2.- O sistema apresentará uma lista com todos os registros de prefixos disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4 – O sistema apresenta uma opção de escolha do projeto. 5 - O usuário seleciona o projeto para o qual deseja criar o prefixo. 6.- O sistema apresenta um formulário com os dados referentes à um novo registro de prefixo, como nome, descrição, observação e o projeto selecionado previamente; 7.- O usuário entra com os dados; 8.- O usuário submete as informações; 9.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Prefixo Fluxo de Eventos: Fluxo Principal
131
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter prefixo; 2.- O sistema apresentará uma lista com todos os registro de prefixos disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do prefixo, como nome, descrição, observação, e projeto; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Excluir Prefixo Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter prefixo; 2.- O sistema apresentará uma lista com todos os registros de prefixo disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Prefixo Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter prefixo; 2.- O sistema apresentará uma lista com todos os registros de prefixos disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o prefixo.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A2 Ator Engenheiro de Artefatos
Este papel permite ao usuário definir a estrutura dos artefatos, ou seja, determinar os
tipos de artefatos que deverão existir no projeto (classes artefatos) e seus respectivos
valores a serem mantidos (atributos). É responsabilidade deste papel também definir
templates de configurações que poderão ser utilizados para definir os artefatos nos
novos projetos visando a reutilização de um conjunto de definições de artefatos.
132
ud RepositorioDeArtefatos
Engenheiro da Artefatos
Definir Classe de Artefato
Definir Atributos da Classe de
Artefato
Definir Composição da
Classe de Artefato
Definir Template de Configurações
Selecionar Artefatos
Estes artefatos podem ser genericos para toda a empresa....Eles podem ser selecionados para serem usados em algum projeto especifico
Manter Artefato Padrão
Esse IC nao esta relacionado a nenhum projeto especifico
«include»
«include»
«extend»
FIGURA A.2 Casos de Uso do Engenheiro de Artefatos.
A2.1 Caso de Uso Manter Artefato Padrão Identificador do Caso de Uso UC-GCM-2.1 Nome do Caso de Uso Manter Artefato Padrão Atores Engenheiro de Artefatos Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre os
artefatos padrões. Artefato padrão são aqueles artefatos que são comuns a qualquer projeto. Os artefatos definidos neste caso de uso poderão ser reutilizados para definir os artefatos dos novos projetos, sem a necessidade de ter que redefini-los, um por um, em cada novo projeto.
Primeiro Cenário – Criar Novo Artefato Padrão Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter artefato padrão; 2.- O sistema apresentará uma lista com todos os registros de artefato padrão disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4 – O sistema apresenta uma caixa de seleção contendo as classes de artefato; 5 – O usuário seleciona a classe de artefato no qual o artefato padrão será baseado e clica no botão “OK” ; 6.- O sistema apresenta um formulário com os dados referentes à um novo registro de artefato padrão, como nome, data, descrição, observação e a classe de artefato(já selecionada previamente); 7.- O usuário entra com os dados; 8.- O usuário submete as informações; 9.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos
133
No passo 8, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Artefato Padrão Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter artefato padrão; 2.- O sistema apresentará uma lista com todos os registro de artefato padrão disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do artefato padrão, como nome, data, descrição, observação e classe de artefato; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Excluir Artefato Padrão Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter artefato padrão; 2.- O sistema apresentará uma lista com todos os registros de artefato padrão disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Artefato Padrão Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter artefato padrão; 2.- O sistema apresentará uma lista com todos os registros de artefato padrão disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o artefato padrão.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
134
A2.2 Caso de Uso Manter Classe de Artefato Identificador do Caso de Uso UC-GCM-2.2 Nome do Caso de Uso Manter Classe de Artefato Atores Engenheiro de Artefatos Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre as
classes de artefatos. Uma classe de artefato contém a definição da estrutura de um artefato. Na classe de artefato definem-se os atributos e relacionamentos de composição de um artefato.
Primeiro Cenário – Criar Nova Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter classe de artefato; 2.- O sistema apresentará uma lista com todos os registros de classe de artefato disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de classe de artefato, como nome, descrição e observação; 5.- O usuário entra com os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O caso de uso UC-GCM-2.3 deverá ser executado.
Segundo Cenário – Editar Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter classe de artefato; 2.- O sistema apresentará uma lista com todos os registro de classe de artefato disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do classe de artefato, como nome, data, descrição, observação e classe de artefato; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O caso de uso UC-GCM-2.3 deverá ser executado.
Terceiro Cenário – Excluir Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter classe de
135
artefato; 2.- O sistema apresentará uma lista com todos os registros de classe de artefato disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter classe de artefato; 2.- O sistema apresentará uma lista com todos os registros de classe de artefato disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 5.- O sistema verifica disponibiliza uma tela com as informações sobre o classe de artefato.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A2.3 Caso de Uso Definir Atributos da Classe Artefato Identificador do Caso de Uso UC-GCM-2.3 Nome do Caso de Uso Definir Atributos da Classe de Artefato Atores Engenheiro de Artefatos Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. Estar editando uma classe de artefato.
Descrição Possibilita a definição dos atributos de uma classe artefato.
Primeiro Cenário – Criar Novo Atributo da Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para definir um atributo da classe de artefato; 2.- O sistema apresenta um formulário com os dados referentes à um novo registro de atributo da classe de artefato, como nome, descrição, observação e tipo de dado. O sistema apresentará também ao final do formulário uma lista com todos os registros de atributos da classe de artefato que já foram previamente inseridos; 3.- O usuário entra com os dados; 4.- O usuário submete as informações; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: Um formulário em branco é apresentado na tela e o novo atributo da classe artefato é adicionado à lista de registro ao final do formulário.
136
Segundo Cenário – Excluir Atributo da Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter atributo da classe de artefato; 2.- O sistema apresentará um formulário em branco. Ao final do formulário o sistema apresentará a lista com todos os registros de atributo da classe de artefato disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Visualizar Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter atributo da classe de artefato; 2.- O sistema apresentará um formulário em branco. Ao final do formulário o sistema apresentará a lista com todos os registros de atributo da classe de artefato disponíveis oferecendo um “link” sobre cada um dos registros. 3.- O usuário clica sobre o registro que deseja visualizar; 5.- O sistema verifica disponibiliza uma tela com as informações sobre o classe de artefato.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A2.4 Caso de Uso Definir Composição da Classe Artefato Identificador do Caso de Uso UC-GCM-2.4 Nome do Caso de Uso Definir Composição da Classe de Artefato Atores Engenheiro de Artefatos Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. Estar editando uma classe de artefato.
Descrição Possibilita a definição do relacionamento de composição da classe artefato com outras classes de artefato. Uma classe de artefato poderá ser composta de uma ou mais classes de artefato.
Primeiro Cenário – Criar Nova Composição da Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para definir um relacionamento de composição da classe de artefato; 2.- O sistema apresenta um formulário com duas caixas de seleção: sendo a primeira preenchida com todas as classes de artefatos já definidas no sistema e a segunda caixa vazia; 3.- O usuário seleciona na primeira caixa de seleção os registros de classe de artefato que são componentes e seleciona o botão “>>”;
137
4 – Os registros selecionados são transferidos da primeira para a segunda caixa; 5 – O usuário seleciona o botão “INSERIR”; 6 - O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Excluir Atributo da Classe de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para definir um relacionamento de composição da classe de artefato; 2.- O sistema apresenta um formulário com duas caixas de seleção: sendo a primeira preenchida com todas as classes de artefatos já definidas no sistema e que não são componentes e a segunda caixa preenchida com os registros de classe de artefato que já foram inseridas como componente; 3.- O usuário seleciona na segunda caixa de seleção os registros de classe de artefato que deseja excluir e seleciona o botão “<<”; 4 – Os registros selecionados são transferidos da segunda para a primeira caixa; 5 – O usuário seleciona o botão “ATUALIZAR”; 6 - O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A2.5 Definir Template de Configuração Identificador do Caso de Uso UC-GCM-2.5 Nome do Caso de Uso Definir Template de Configuração Atores Engenheiro de Artefatos Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. Descrição Possibilita a definição de templates de configuração que
poderão ser reutilizados para definição de novos projetos. Um template de configuração reúne várias definições de artefatos para serem definidas para o novo projeto.
Primeiro Cenário – Criar Novo Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter template de configuração; 2.- O sistema apresentará uma lista com todos os registros de template de configurações disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de template de configuração, como nome, data, descrição, observação e a categoria; 5.- O usuário entra com os dados; 6.- O usuário submete as informações;
138
7.- O sistema verifica as informações e salva na base de dados. Fluxos Alternativos
No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema deverá executar o caso de uso UC-GCM-2.6.
Segundo Cenário – Editar um Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter de template de configuração; 2.- O sistema apresentará uma lista com todos os registro de template de configuração disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do template de configuração, como nome, data, descrição, observação e categoria; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema deverá executar o caso de uso UC-GCM-2.6.
Terceiro Cenário – Excluir um Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter template de configuração; 2.- O sistema apresentará uma lista com todos os registros de template de configuração disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter template de configuração; 2.- O sistema apresentará uma lista com todos os registros de template de configuração disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o template de configuração.
Fluxos Alternativos Não há.
Pós Condição:
139
O sistema apresentará a tela com as informações e um botão para retornar.
A2.6 Selecionar Artefatos Identificador do Caso de Uso UC-GCM-2.6 Nome do Caso de Uso Selecionar Artefatos Atores Engenheiro de Artefatos Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. O caso de uso UC-GCM-2.5 ter sido executado.
Descrição Possibilita a seleção dos artefatos que pertencerão ao template de configuração.
Primeiro Cenário – Criar Novo Seleção de Artefatos para o Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para selecionar os artefatos de um template de configuração; 2.- O sistema apresentará uma caixa de seleção com todos os registros de artefatos disponíveis apresentando a opção “>>” que adiciona os artefatos selecionados; 3.- O usuário seleciona a os artefatos e clica no botão “>>”; 4.- O usuário submete as informações; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar uma Seleção de Artefatos para o Template de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para editar uma seleção de artefatos de template de configuração; 2.- O sistema apresentará duas caixas de seleção: uma com todos os registros de artefatos disponíveis apresentando (que ainda não foram selecionados) e outra com todos os artefatos selecionados para o template de configuração 3.- O usuário seleciona a os artefatos que deseja adicionar e clica no botão “>>”; 4.- O usuário seleciona a os artefatos que deseja excluir do template da configuração e clica no botão “<<”; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A3 Ator Engenheiro da Configuração
Este papel permite ao usuário manter as informações sob as configurações do sistema,
definir a lista de distribuições e montar e distribuir as releases. Também é de
140
responsabilidade deste papel manter as versões de configurações bem como notificar
aos interessados quaisquer mudanças nas configurações e/ou releases.
ud RepositorioDeArtefatos
Manter Configurações
Selecionar IC
Manter Releases Selecionar IC da Configuração
Selecionar Clientes
Engenheiro da Configuracao
Manter Lista de Distribuição
Manter v ersao da configuracao
«include»
«include»
«extend»
«include»
FIGURA A.3 Casos de Uso do Engenheiro da Configuração.
A3.1 Caso de Uso Manter Configuração Identificador do Caso de Uso UC-GCM-3.1 Nome do Caso de Uso Manter Configurações Atores Engenheiro da Configuração Pré Condição Um usuário com perfil de Engenheiro da Configuração
deve ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre as
configurações. Permite ao usuário criar as configurações e selecionar quais versões de artefatos irão fazer parte dela. O usuário pode também alterar o status da configuração e manter as versões das configurações.
Primeiro Cenário – Criar Nova Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter configurações; 2.- O sistema apresentará uma lista com todos os registros de configurações disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de configurações, como nome, descrição e observação;
141
5.- O usuário entra com os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema deverá executar opcionalmente o UC-GCM-3.2.
Segundo Cenário – Editar Configurações Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter configurações; 2.- O sistema apresentará uma lista com todos os registro de configurações disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do configurações, como nome, descrição e observação; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema deverá executar opcionalmente o UC-GCM-3.2.
Terceiro Cenário – Excluir Configurações Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter configurações; 2.- O sistema apresentará uma lista com todos os registros de configurações disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Configurações Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter configurações; 2.- O sistema apresentará uma lista com todos os registros de configurações disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o configurações.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
142
A3.2 Manter Versão da Configuração. Identificador do Caso de Uso UC-GCM-3.2 Nome do Caso de Uso Manter Versão da Configuração Atores Engenheiro da Configuração Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. O caso de uso UC-GCM-3.1 ter sido executado.
Descrição Possibilita manter a versão de uma configuração. Primeiro Cenário – Criar Nova Versão de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para criar nova versão de configurão; 2 – O sistema apresentará uma tela com todas as versões de configuração disponíveis; 3 – O usuário clica no botão “INSERIR”; 4.- O sistema apresentará o formulário para selecionar IC conforme descrito no UC-GCM-3.3 5.- O usuário submete as informações; 6.- O sistema verifica as informações e salva na base de dados criando uma versão.
Fluxos Alternativos No passo 5, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema executará o UC-GCM-3.3. Uma nova versão será criada no sistema
Segundo Cenário – Editar Versão de Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para editar uma versão de configuração; 2.- O sistema apresentará uma tela com os IC conforme descrito no caso de uso UC-GCM-3.3 3.- O usuário atualiza os dados; 4.- O usuário submete as informações; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A3.3 Selecionar I.C. Identificador do Caso de Uso UC-GCM-3.3 Nome do Caso de Uso Selecionar IC Atores Engenheiro da Configuração Pré Condição Um usuário com perfil de Engenheiro de Artefatos deve
ter sido validado pelo sistema. O caso de uso UC-GCM-3.3 ter sido executado.
Descrição Possibilita a seleção dos artefatos que pertencerão à configuração.
Primeiro Cenário – Criar Nova Seleção de IC para uma Configuração Fluxo de Eventos:
143
Fluxo Principal 1.- Este caso de uso inicia-se quando o usuário aciona a interface para selecionar os IC de uma configuração; 2.- O sistema apresentará uma caixa de seleção com todos os registros de IC disponíveis apresentando a opção “>>” que adiciona os IC selecionados; 3.- O usuário seleciona a os IC e clica no botão “>>”; 4.- O usuário submete as informações; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar uma Seleção de IC para uma Configuração Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para editar uma seleção de IC para uma configuração; 2.- O sistema apresentará duas caixas de seleção: uma com todos os registros de IC disponíveis apresentando (que ainda não foram selecionados) e outra com todos os IC selecionados para a configuração 3.- O usuário seleciona a os IC que deseja adicionar e clica no botão “>>”; 4.- O usuário seleciona a os IC que deseja excluir da configuração e clica no botão “<<”; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A3.4 Caso de Uso Manter Releases Identificador do Caso de Uso UC-GCM-3.4 Nome do Caso de Uso Manter Release Atores Engenheiro da Configuração Pré Condição Um usuário com perfil de Engenheiro da Configuração
deve ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre as
releases. Permite ao usuário associar quais clientes irão receber quais releases.
Primeiro Cenário – Criar Nova Release Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter releases; 2.- O sistema apresentará uma lista com todos os registros de releases disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de releases, como nome, descrição e observação; 5 – O usuário seleciona os clientes que irão receber a release; 6.- O usuário entra com os dados;
144
7.- O usuário submete as informações; 8.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 7, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema executar o caso de uso UC-GCM-3.4.
Segundo Cenário – Editar Release Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter releases; 2.- O sistema apresentará uma lista com todos os registro de releases disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do releases, como nome, descrição, observação e uma lista de clientes; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema executar o caso de uso UC-GCM-3.4.
Terceiro Cenário – Excluir Release Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter releases; 2.- O sistema apresentará uma lista com todos os registros de releases disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Release Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter releases; 2.- O sistema apresentará uma lista com todos os registros de releases disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o releases.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
145
A3.5 Caso de Uso Manter Lista de Distribuição Identificador do Caso de Uso UC-GCM-3.5 Nome do Caso de Uso Manter Lista de Distribuição Atores Engenheiro da Configuração Pré Condição Um usuário com perfil de Engenheiro da Configuração
deve ter sido validado pelo sistema. Descrição Possibilita a manutenção das informações sobre as listas
de distribuições. Permite ao usuário definir os clientes para receber as releases
Primeiro Cenário – Criar Nova Lista de Distribuição Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter lista de distribuição; 2.- O sistema apresentará uma lista com todos os registros de lista de distribuição disponíveis apresentando a opção “INSERIR”; 3.- O usuário seleciona a opção “INSERIR”; 4.- O sistema apresenta um formulário com os dados referentes à um novo registro de lista de distribuição, como nome, descrição e observação; 5.- O usuário entra com os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Lista de Distribuição Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter lista de distribuição; 2.- O sistema apresentará uma lista com todos os registro de lista de distribuição disponíveis apresentando a opção “EDITAR”; 3.- O usuário seleciona a opção “EDITAR”; 4.- O sistema apresenta um formulário com os dados atuais do lista de distribuição, como nome, descrição e observação; 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Terceiro Cenário – Excluir Lista de Distribuição Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter lista de distribuição; 2.- O sistema apresentará uma lista com todos os registros de lista de distribuição
146
disponíveis oferecendo caixas de seleção para exclusão do tipo “checkbox”; 3.- O usuário seleciona o registro que deseja excluir; 4.- O usuário seleciona a opção “EXCLUIR” submetendo os dados; 5.- O sistema verifica as informações e exclui da base de dados.
Fluxos Alternativos No passo 5, se ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Quarto Cenário – Visualizar Lista de Distribuição Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter lista de distribuição; 2.- O sistema apresentará uma lista com todos os registros de lista de distribuição disponíveis oferecendo um “link” sobre cada um dos registros ; 3.- O usuário clica sobre o registro que deseja visualizar; 4.- O sistema verifica disponibiliza uma tela com as informações sobre o lista de distribuição.
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a tela com as informações e um botão para retornar.
A3.6 Caso de Uso Selecionar Clientes Identificador do Caso de Uso UC-GCM-3.6 Nome do Caso de Uso Selecionar Clientes Atores Engenheiro da Configuração Pré Condição Um usuário com perfil de Engenheiro da Configuração
deve ter sido validado pelo sistema. O Caso de uso UC-GCM-3.5 deve ter sido executado.
Descrição Possibilita a selecionar os clientes que vão fazer parte da lista de distribuição criada.
Primeiro Cenário – Criar Nova Lista de Distribuição Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para selecionar clientes; 2.- O sistema apresentará duas caixas de seleção, sendo uma com todos os registros de cliente disponíveis e a outra vazia; 3.- O usuário seleciona na primeira caixa os clientes que devem fazer parte da lista de distribuição e clica no botão “>>”; 4.- O usuário submete as informações; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Segundo Cenário – Editar Clientes Selecionados Fluxo de Eventos: Fluxo Principal
147
1.- Este caso de uso inicia-se quando o usuário aciona a interface para selecionar os clientes para uma lista de distribuição; 2.- O sistema apresentará duas caixas de seleção: uma com os cliente não selecionados para a lista de distribuição e a outra com os cliente que já foram anteriormente selecionados; 3.- O usuário seleciona os clientes na primeira caixa de seleção que deseja adicionar e clica no botão “>>” 4.- O usuário seleciona os clientes na segunda caixa de seleção que deseja excluir e clica no botão “<<” 5.- O usuário atualiza os dados; 6.- O usuário submete as informações; 7.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4 Ator Gerente da Configuração
Este papel tem a responsabilidade de manter um controle sobre os itens do repositório,
podendo definir IC que serão controlados por cada projeto, bloquear/desbloquear IC e
editar os valores de relacionamento entre os IC.
148
ud RepositorioDeArtefatos
Selecionar Baseline do
Projeto
Manter Versões de Artefatos
Manter Dependencia
Visualizar Historico de Operações
Manter Repositorio
Criar IC do Projeto
Gerente da Configuracao
Realizar Lock / Unlock
Manter v isibilidade
Permitir Checkout
Selecionar Usuário
Analisar Proposta de Artefato
Visualizar Ev olução dos
Artefatos
Visualizar Check-out's autorizados
Visualizar Artefatos Propostos
«extend»
«extend»
«extend» «extend»
«extend»
«include»
«extend»
«extend»
«extend»
FIGURA A.4 Caso de Uso Gerente da Configuração
A4.1 Caso de Uso Visualizar Check-out’s autorizados Identificador do Caso de Uso UC-GCM-4.1 Nome do Caso de Uso Visualizar Check-out’s autorizados Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Descrição Possibilita visualizar os Check-outs que precisam ser
feitos, ou seja, aqueles check-outs que foram aprovados na analise de mudança e que precisam ser realizados.
Primeiro Cenário – Permitir Check-out’s autorizado Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter visualizar Check-out’s autorizados; 2.- O sistema apresentará uma lista com todos os registros de versões de artefatos que foram autorizados para fazer o check-out; 3.- O usuário seleciona o artefato que deseja fazer check-out e clica no ícone “Check-out”; 4.- O sistema apresenta um formulário com os dados referentes a versão atual e uma opção
149
para selecionar o usuário que deverá ser o responsável por modificar o artefato; 5.- O usuário submete as informações; 6.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 5, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.2 Caso de Uso Visualizar Evolução dos Artefatos Identificador do Caso de Uso UC-GCM-4.2 Nome do Caso de Uso Visualizar Evolução dos Artefatos Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Descrição Possibilita visualizar a evolução das versões de um
determinado artefato. Primeiro Cenário – Permitir Check-out’s autorizado Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para visualizar evolução dos artefatos; 2.- O sistema apresentará uma lista com todos os registros de artefatos disponíveis; 3.- O usuário seleciona o artefato que deseja visualizar e clica sobre seu nome; 4.- O sistema apresenta uma tela com a evolução das versões do artefato, ou seja, cada versão criada em forma de arvora;
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará a evolução do artefato na tela.
A4.3 Caso de Uso Manter Repositório Identificador do Caso de Uso UC-GCM-4.3 Nome do Caso de Uso Manter Repositório Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Descrição Possibilita criar e manipular todos os artefatos dentro do
repositório. Primeiro Cenário – Manter Repositório Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter repositório; 2.- O sistema apresentará uma lista com todos os registros de artefatos disponíveis para cada um dos projetos; 3.- O usuário seleciona o projeto para verificar os artefatos que deseja manipular; 4.- O sistema apresenta uma tela com todas as versões de cada artefato do projeto e possibilita para cada um realizar as operações de bloquear, desbloquear,visualizar histórico, permitir check-out, modificar visibilidade e editar os relacionamento;
Fluxos Alternativos Não há.
150
Pós Condição: O sistema apresentará todos os artefatos e versões por projeto.
A4.4 Caso de Uso Selecionar Baseline do Projeto Identificador do Caso de Uso UC-GCM-4.4 Nome do Caso de Uso Selecionar Baselines do Projeto Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. O caso de uso UC-GCM-4.3 ter sido executado
Descrição Possibilita selecionar um template de baseline com as definições de artefatos para o projeto.
Primeiro Cenário –Adicionar Baselines ao Projeto Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para selecionar baseline do projeto; 2.- O sistema apresentará uma caixa de seleção com todas os registros de baselines disponíveis; 3.- O usuário seleciona a baseline que deseja adicionar ao projeto e clica no botão “>>”; 4.- O usuário submete os dados; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 5, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.5 Caso de Uso Definir IC do Projeto Identificador do Caso de Uso UC-GCM-4.5 Nome do Caso de Uso Definir IC do Projeto Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. O caso de uso UC-GCM-4.3 ter sido executado
Descrição Possibilita definir os IC que serão controlados pelo projeto.
Primeiro Cenário –Definir IC do Projeto Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para definir IC do Projeto; 2.- O sistema apresentará uma caixa de seleção com todos os registros de classes de artefatos existentes; 3.- O usuário seleciona a classe artefato que deseja criar o IC; 4 – O sistema apresenta um formulário para a definição do IC com as informações de nome, descrição, observação e a classe já selecionada. 5.- O usuário submete os dados; 6.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 5, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
151
Pós Condição: O sistema apresentará mensagem de sucesso da operação e o status do IC será “em definição”.
Segundo Cenário –Editar Definição do IC do Projeto Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para editar IC do Projeto; 2.- O sistema apresenta um formulário com as informações de nome, descrição, observação e a classe já preenchidas. 3 – O usuário edita as informações do formulário e clica no botão “ATUALIZAR” 4.- O usuário submete os dados; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação e o status do IC será “em definição”.
Terceiro Cenário –Publicar IC do Projeto Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para editar IC do Projeto; 2.- O sistema apresenta um formulário com as informações de nome, descrição, observação e a classe já preenchidas. 3 – O usuário confere/atualiza as informações do formulário e clica no botão “DEFINIR COMO PUBLICO” 4.- O usuário submete os dados; 5.- O sistema verifica as informações e salva na base de dados.
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação e o status do IC será “definido”.
A4.6 Caso de Uso Manter Versões dos Artefatos Identificador do Caso de Uso UC-GCM-4.6 Nome do Caso de Uso Manter Versões dos Artefatos Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. O caso de uso UC-GCM-4.3 ter sido executado
Descrição Possibilita manipular cada versão dos artefatos do repositório.
Primeiro Cenário – Manter Versões dos Artefatos Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona a interface para manter versões de artefatos; 2.- O sistema apresentará todos os registros de versões para cada artefato disponíveis; 3.- Para cada versão o usuário poderá fazer as operações definidas no repositório;
152
Fluxos Alternativos Não há.
Pós Condição: O sistema apresentará os registros de cada versão.
A4.7 Caso de Uso Manter Visibilidade Identificador do Caso de Uso UC-GCM-4.7 Nome do Caso de Uso Manter Visibilidade Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. O caso de uso UC-GCM-4.6 ter sido executado
Descrição Possibilita modificar o nível de visibilidade da versão de artefato.
Primeiro Cenário – Editar Visibilidade Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para manter visibilidade dos artefatos; 2.- O sistema apresentará uma tela com todas as informações sobre a versão de artefato e uma caixa de seleção para modificar a visibilidade do artefato; 3 – O usuário seleciona o nível de visibilidade (publico/privado) e clica no botão “ATUALIZAR”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.8 Caso de Uso Manter Dependência Identificador do Caso de Uso UC-GCM-4.8 Nome do Caso de Uso Manter Dependência Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. As versões de artefatos que serão dependentes deverão estar previamente cadastradas e controladas.
Descrição Relaciona uma versão de artefato com outra. Primeiro Cenário – Manter Depedência Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para manter dependência em alguma versão controlada; 2.- O sistema apresentará uma tela com todas as informações sobre a versão de artefato e um formulário onde o usuário poderá selecionar uma versão no qual será relacionada a versão atual (que foi clicada) e selecionar o grau do relacionamento (associação, composição, dentre outros); 3 – O usuário clica no botão “OK”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos
153
No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.9 Caso de Uso Visualizar Histórico de Operação Identificador do Caso de Uso UC-GCM-4.9 Nome do Caso de Uso Visualizar Histórico de Operação Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Algumas operações terem sido efetuadas para uma versão de artefato.
Descrição Permite visualizar as operações executadas com uma versão de artefato.
Primeiro Cenário – Visualizar Histórico de Operação Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para visualizar histórico de operação em alguma versão controlada; 2.- O sistema apresentará uma tela com todas as informações sobre a versão de artefato e todas as operações que foram realizadas ao longo do tempo de vida da versão, tais como, operação, data e motivo;
Fluxos Alternativos Não há..
Pós Condição: Não há.
A4.10 Caso de Uso Manter Visibilidade Identificador do Caso de Uso UC-GCM-4.10 Nome do Caso de Uso Manter Visibilidade Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. O caso de uso UC-GCM-4.6 ter sido executado
Descrição Possibilita modificar o nível de visibilidade da versão de artefato.
Primeiro Cenário – Editar Visibilidade Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para manter visibilidade dos artefatos; 2.- O sistema apresentará uma tela com todas as informações sobre a versão de artefato e uma caixa de seleção para modificar a visibilidade do artefato; 3 – O usuário seleciona o nível de visibilidade (publico/privado) e clica no botão “ATUALIZAR”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição:
154
O sistema apresentará mensagem de sucesso da operação.
A4.11 Caso de Uso Realizar Lock/UnLock Identificador do Caso de Uso UC-GCM-4.11 Nome do Caso de Uso Realizar Lock/Unlock Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. As versões de artefatos deverão existir previamente.
Descrição Realiza o bloqueio e desbloqueio de versões de artefatos. Primeiro Cenário – Realizar Lock Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para realizar lock em alguma versão controlada; 2.- O sistema apresentará uma tela com todas as informações sobre a versão de artefato e um formulário com um campo texto para digitar o motivo do bloqueio da versão; 3 – O usuário clica no botão “OK”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Primeiro Cenário – Realizar UnLock Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para realizar unlock em alguma versão controlada que esteja bloqueada pelo usuário; 2.- O sistema apresentará uma tela com todas as informações sobre a versão de artefato e um formulário com um campo texto para digitar o motivo do desbloqueio da versão; 3 – O usuário clica no botão “OK”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.12 Caso de Uso Permitir Check-out Identificador do Caso de Uso UC-GCM-4.12 Nome do Caso de Uso Permitir Checkout Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Uma versão de artefato deve ter sido autorizada através de uma proposta de alteração a ser permitida para checkout.
Descrição Permite autorizar um usuário para realizar a operação de checkout sob uma versão de artefato.
155
Primeiro Cenário – Permitir Checkout Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Permitir Check-out; 2.- O sistema apresentará uma tela com as versões de artefato disponíveis para permitir o checkout (autorizadas através de uma proposta de mudança); 3 – O usuário seleciona o usuário no qual será autorizado a fazer o checkout e clica no botão “INSERIR”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.13 Caso de Uso Analisar Proposta de Artefato Identificador do Caso de Uso UC-GCM-4.13 Nome do Caso de Uso Analisar Proposta de Artefato Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Uma proposta de artefato deve ter sido enviada.
Descrição Permite ao usuário analisar as propostas de novos de artefatos que foram enviadas.
Primeiro Cenário – Analisar Proposta de Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Analisar Proposta de Artefato; 2.- O sistema apresentará uma tela com as informações sobre a proposta de artefato e um campo para o usuário digitar as informações da análise; 3 – O usuário decide sobre a aceitação ou não da proposta e clica no botão “ACEITAR” ou “REJEITAR”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A4.14 Caso de Uso Visualizar Artefatos Propostos Identificador do Caso de Uso UC-GCM-4.14 Nome do Caso de Uso Visualizar Artefatos Propostos Atores Gerente da Configuração Pré Condição Um usuário com perfil de Gerente da Configuração deve
ter sido validado pelo sistema. Uma proposta de artefato deve ter sido aceita.
Descrição Permite ao usuário criar os artefatos que foram aceitos na proposta.
Primeiro Cenário – Visualizar Artefatos Propostos
156
Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Visualizar Artefatos Propostos; 2.- O sistema apresentará uma tela com as informações sobre os artefatos que foram propostos e aceitos; 3 – O usuário seleciona o artefato que deseja criar; 4 – O usuário seleciona o projeto no qual o artefato será criado e clica no botão “DEFINIR”; 5.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 5, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A5 Ator Engenheiro de Mudanças
Este papel permite ao usuário manter todas as informações referentes às alterações nos
IC mantidos sob controle do repositório. È de responsabilidade do Engenheiro de
mudanças analisar todas as requisições de mudanças enviadas, fazer a analise de
impacto e permitir ou não a implementação da alteração.
157
ud RepositorioDeArtefatos
Engenheiro de Mudanças Analisar Proposta
de Mudança
Analisar Dependencias
Alocar Desenv olv edor para alteração
Defirnir IC para alteração
Analisar instruções de
alteração
Relatar Pedido de Mudança
Realizar Check in Definir Versao
Analisar Proposta de Artefato
Visualizar Check-out's autorizados
Visualizar Artefatos Propostos
Manter Repositório
«include»
«extend»
«include»
«include»
«include»
«include»
FIGURA A.5 Caso de Uso Engenheiro de Mudanças
A5.1 Caso de Uso Realizar Check-in Identificador do Caso de Uso UC-GCM-5.1 Nome do Caso de Uso Realizar Check-in Atores Engenheiro de Mudanças Pré Condição Um usuário com perfil de Engenheiro de Mudanças deve
ter sido validado pelo sistema. Uma versão de artefato deve ter sido aceita pelo processo de qualidade e submetida para realização de check-in. Ter configurado no sistema pelo menos um tipo de versionamento.
Descrição Permite ao usuário fazer check-in de uma versão no repositório, gerando uma nova versão.
Primeiro Cenário – Realizar Check-in Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Realizar Check-in;
158
2.- O sistema apresentará uma tela com as versões de artefato cujo status se encontra “aguardando check-in”; 3 – O usuário seleciona a versão no qual deseja fazer o check-in; 4 – O sistema apresenta as informações sobre a versão atual e seus valores, relacionamento com as demais versões e um opção para que o usuário escolha qual o tipo de versionamento deseja realizar (a documentação do o tipo versionamento pode ser encontrada acima neste documento); 5 – O usuário seleciona o tipo de versionamento que deseja e clica no botão “OK”; 6.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 6, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A5.2 Caso de Uso Analisar Proposta de Mudança Identificador do Caso de Uso UC-GCM-5.2 Nome do Caso de Uso Analisar Proposta de Mudança Atores Engenheiro de Mudanças Pré Condição Um usuário com perfil de Engenheiro de Mudanças deve
ter sido validado pelo sistema. Uma proposta de mudança ter sido enviada por um usuário do sistema.
Descrição Permite ao usuário analisar a proposta de mudança de uma versão de artefato.
Primeiro Cenário – Analisar Proposta de Mudança Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Analisar Proposta de Mudança; 2.- O sistema apresentará uma tela com as proposta de mudança que foram submetidas; 3 – O usuário seleciona a proposta na qual deseja analisar; 4 – O sistema apresenta as informações sobre a proposta, o motivo, e as versões de artefatos que foram solicitadas na alteração; 5 – O usuário analisa a proposta e relata sua decisão, escolhe quais outras versões de artefatos devem ser alteradas em conjunto e quais os usuários indicados para a alteração; 6 - O usuário clica no botão “aceitar” ou “rejeitar” conforme sua analise; 7.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 7, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
Obs.: Os demais casos de uso foram documentados anteriormente quando realizado
também por outros papéis.
159
A6 Ator Desenvolvedor
Este papel determina as responsabilidades dos desenvolvedores/programadores dentro
de um processo de GCS. Este papel permite aos usuários visualizarem os IC no
repositório (desde que os IC sejam públicos), enviar solicitações de mudanças quando
desejarem por algum motivo alterar um IC, enviar propostas para definir um novo IC
não definido no projeto e implementar as alterações quando essas forem aceitas e
atribuídas a ele a responsabilidade de sua alteração.
ud RepositorioDeArtefatos
Desenv olv edor
Manter Proposta de Mudança
Compor Proposta de Mudança
Selecionar Artefato para
alteraçao
Verificar Situação da Proposta
Fazer Checkou de Artefatos
Permitidos
Visualizar Repositorio de
ArtefatosFazer GET
Env iar para Qualidade
Visualizar Checkout Permitidos
Env iar Proposta
Visualizar Artefatos para
Modificação
Realizar Modificações
Propor Artefato
«extend»
«include»
«extend»
«extend»
«include»
«extend»
«extend»
«extend»
FIGURA A.6 Caso de Uso Desenvolvedor
A6.1 Caso de Uso Propor Artefato Identificador do Caso de Uso UC-GCM-6.1 Nome do Caso de Uso Propor artefato Atores Desenvolvedor
160
Pré Condição Um usuário com perfil de Desenvolvedor deve ter sido validado pelo sistema.
Descrição Permite ao usuário fazer uma proposta de um novo artefato no projeto.
Primeiro Cenário – Propor Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Propor Artefato e seleciona a opção inserir nova proposta; 2.- O sistema apresentará uma tela com um formulário no qual o usuário deverá preencher com as informações (nome, descrição, observação, tipo artefato) sobre o novo artefato proposto e o motivo de sua proposta; 3 – O usuário clica no botão “enviar proposta’; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A6.2 Caso de Uso Manter Proposta de Mudança Identificador do Caso de Uso UC-GCM-6.2 Nome do Caso de Uso Propor de Mudança Atores Desenvolvedor Pré Condição Um usuário com perfil de Desenvolvedor deve ter sido
validado pelo sistema. Descrição Permite ao usuário fazer uma proposta de alteração para
uma versão de artefato do projeto. Primeiro Cenário – Propor Mudança Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Proposta de Mudança e seleciona a opção inserir nova proposta; 2.- O sistema apresentará uma tela com um formulário no qual o usuário deverá selecionar qual versão de artefato deseja alterar, o motivo de sua alteração e a alteração que será realizada; 3 – O usuário clica no botão “enviar proposta’; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação.
A6.3 Caso de Uso Visualizar Check-outs Permitidos Identificador do Caso de Uso UC-GCM-6.3 Nome do Caso de Uso Propor artefato Atores Desenvolvedor Pré Condição Um usuário com perfil de Desenvolvedor deve ter sido
validado pelo sistema. Descrição Permite ao usuário visualizar as versões de artefatos que
161
foram a ele permitidas para realizar o check-out. Primeiro Cenário – Realizar Check-out Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Check-out’s Permitidos; 2.- O sistema apresentará uma tela com todas as versões de artefatos que foram permitidas para que o usuário realizasse o check-out; 3 – O usuário clica no ícone de check-out do artefato que deseja realizar o check-out; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação. A versão de artefato é copiada para a área de trabalho do usuário;
A6.4 Caso de Uso Visualizar Artefatos para Modificação Identificador do Caso de Uso UC-GCM-6.4 Nome do Caso de Uso Propor artefato Atores Desenvolvedor Pré Condição Um usuário com perfil de Desenvolvedor deve ter sido
validado pelo sistema. Descrição Permite ao usuário visualizar as versões de artefatos que
estão em sua área de trabalho e que podem ser alteradas por ele.
Primeiro Cenário – Artefatos para modificação Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Visualizar Artefatos para Modificação; 2.- O sistema apresentará uma tela com todas as versões de artefatos que foram realizadas check-out e copiadas para a área de trabalho do usuário; 3 – O usuário seleciona a versão que deseja alterar, preenche as informações (de acordo com cada tipo de artefato identificado no sistema) e clica no botão “enviar para qualidade”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação. A versão de artefato é alterada para o status “enviada para qualidade” onde será visível apenas no caso de uso de avaliação da qualidade;
A6.5 Caso de Uso Visualizar Repositório de Artefatos Identificador do Caso de Uso UC-GCM-6.5 Nome do Caso de Uso Propor artefato Atores Desenvolvedor Pré Condição Um usuário com perfil de Desenvolvedor deve ter sido
validado pelo sistema. Descrição Permite ao usuário visualizar todas as versões de
162
artefatos controladas no repositório e que possuam visibilidade pública.
Primeiro Cenário – Visualizar Repositório de Artefatos Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Visualizar Repositório de Artefatos; 2.- O sistema apresentará uma tela com todas as versões de artefatos que foram são públicas e que estejam controladas no repositório; 3 – O usuário seleciona uma versão de artefato; 4 – O sistema exibe uma tela com todas as informações sobre aquela versão de artefato;
Fluxos Alternativos Não há.
Pós Condição: Não há.
Primeiro Cenário – Realizar operação de GET Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Visualizar Repositório de Artefatos; 2.- O sistema apresentará uma tela com todas as versões de artefatos que foram são públicas e que estejam controladas no repositório; 3 – O usuário seleciona uma versão de artefato e clica no ícone da operação “get”; 4 – O usuário seleciona o nome e local em sua máquina onde o documento será armazenado; 5 – O sistema gera um documento PDF contendo as informações sobre a versão de artefato com o nome e no local indicado;
Fluxos Alternativos Não há.
Pós Condição: Documento PDF gerado com as informações sobre a versão de artefato selecionada.
A7 Ator Gerente de Acompanhamento de Projeto (GCM)
Este papel permite ao gerente de projetos determinar o usuário responsável por realizar
a ação de criação do IC e posteriormente de determinar o usuário responsável por um
check-out.
ud RepositorioDeArtefatos
Visualizar Check-out's autorizados
Gerente de Acompanhamento de Projeto (GCM)
Permitir Criação
163
FIGURA A.7 Caso de Uso Gerente de Acompanhamento de Projeto
A7.1 Caso de Uso Permitir Criação Identificador do Caso de Uso UC-GCM-7.1
Nome do Caso de Uso Permitir Criação Atores Gerente de Acompanhamento de Projeto Pré Condição Um usuário com perfil de Gerente de Acompanhamento
de Projeto deve ter sido validado pelo sistema. Descrição Permite ao usuário autorizar o usuário que vai fazer a
criação da primeira versão do artefato. Primeiro Cenário – Permitir Criação Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Permitir Criação; 2.- O sistema apresentará uma tela com todas as versões de artefatos que foram definidas pelo gerente da Configuração e que estão prontas para serem criadas; 3 – O usuário seleciona a versão que deseja autorizar, seleciona o usuário que deverá ser autorizado a cria-la e clica no botão “OK”; 4.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 4, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação. A versão de artefato é alterada para o status “permitida” onde será visível apenas no caso de uso de check-out’s permitidos na tela do usuário autorizado;
Obs.: Os demais casos de uso foram anteriormente documentados para outros papeis
que compartilham sua responsabilidade.
A8 Ator Engenheiro da Qualidade (GCM)
Este papel permite a avaliação de um IC que será controlado no repositório.
ud RepositorioDeArtefatos
Engenheiro da
Qualidade (GCM)
Aprov ar Artefatos
FIGURA A.8 Caso de Uso Engenheiro da Qualidade
164
A8.1 Caso de Uso Aprovar Artefatos Identificador do Caso de Uso UC-GCM-8.1
Nome do Caso de Uso Aprovar Artefatos Atores Engenheiro da Qualidade Pré Condição Um usuário com perfil de Engenheiro da Qualidade deve
ter sido validado pelo sistema. Descrição Permite ao usuário avaliar a qualidade de uma versão de
artefato submetido ao repositório. Primeiro Cenário – Avaliar Versão Artefato Fluxo de Eventos: Fluxo Principal
1.- Este caso de uso inicia-se quando o usuário aciona na interface o ícone para Avaliar Artefatos; 2.- O sistema apresentará uma tela com todas as versões de artefatos que foram enviadas para o controle de qualidade; 3 – O usuário seleciona a versão que deseja analisar e preenche relata sua analise; 4 – O usuário clica no botão “APROVAR” ou “REJEITAR” conforme sua análise; 5.- O sistema verifica as informações e atualiza o banco de dados;
Fluxos Alternativos No passo 5, se o sistema verificar que algum campo obrigatório não foi informado ou ocorrer alguma operação ilegal, o sistema apresentará mensagem de erro ao usuário.
Pós Condição: O sistema apresentará mensagem de sucesso da operação. A versão de artefato é alterada para o status “aguardando check-in” onde será visível apenas no caso de uso realizar check-in;
165
APÊNDICE B
MODELO RELACIONAL DO SISTEMA
Segue abaixo as figuras do modelo relacional do sistema dividida em partes.
cd BD-GCM
GCM_PropostaMudanca
*PK «column» gpm_id: bigint* «column» gpm_titulo: varchar(150) «column» gpm_observacao: varchar(2000)* «column» gpm_data: timestamp*FK «column» gcm_PropostaMudancaStatus: bigint*FK «column» hrm_division_x_people: bigint*FK «column» gcm_prioridade: bigint «column» gpm_descricao: varchar(5000) FK «column» ppr_problem: bigint* «column» gpm_codigo: varchar(50)
+ «FK» FK_GCM_PropostaMudanca_GCM_Prioridade(varchar)+ «FK» FK_GCM_PropostaMudanca_GCM_PropostaMudancaStatus(bigint)+ «FK» FK_GCM_PropostaMudanca_HRM_USER(bigint)+ «FK» FK_GCM_PropostaMudanca_PPR_PROBLEM(bigint)+ «PK» PK_GCM_PropostaMudanca(bigint)
GCM_PropostaMudancaStatus
*PK «column» gps_id: bigint* «column» gps_nome: varchar(150) «column» gps_descricao: varchar(500) «column» gps_observacao: varchar(500)
+ «PK» PK_GCM_PropostaMudancaStatus(bigint)
GCM_ArtefatoPropostaAnalise
*PK «column» gpr_id: bigint*FK «column» gcm_versaoArtefato: bigint*FK «column» gcm_PropostaMudanca: bigint* «column» gpr_modificacao: varchar(5000)* «column» gpr_motivo: varchar(5000) «column» gpr_observacao: varchar(5000)
+ «FK» FK_GCM_ArtefatoPropostaAnalise_GCM_AnalisePropostaMudanca(bigint)+ «FK» FK_GCM_ArtefatoPropostaAnalise_GCM_PropostaMudanca(bigint)+ «FK» FK_GCM_ArtefatoPropostaAnalise_GCM_VersaoArtefato(bigint)+ «PK» PK_GCM_ArtefatoPropostaAnalise(bigint)
GCM_Prioridade
*PK «column» gpc_id: bigint* «column» gpc_nome: varchar(150)* «column» gpc_descricao: varchar(200) «column» gpc_observacao: varchar(200)
+ «PK» PK_GCM_Prioridade(bigint)
GCM_ArtefatosParaModificacao
*PK «column» gfd_id: bigint* «column» gfd_data: timestamp*FK «column» gcm_prioridade: bigint*FK «column» gcm_AnalisePropostaMudanca: bigint FK «column» gcm_VersaoArtefato: bigint*FK «column» hrm_division_x_people: bigint* «column» gfd_modificacao: varchar(5000) «column» gfd_observacao: varchar(5000)
+ «FK» FK_GCM_ArtefatosParaModificacao_GCM_AnalisePropostaMudanca(bigint)+ «FK» FK_GCM_ArtefatosParaModificacao_GCM_Prioridade(varchar)+ «FK» FK_GCM_ArtefatosParaModificacao_GCM_VersaoArtefato(bigint)+ «FK» FK_GCM_ArtefatosParaModificacao_HRM_USER(bigint)+ «PK» PK_GCM_ArtefatosParaModificacao(bigint)
PPR_PROBLEM
*PK «column» ppp_id: bigint «column» ppp_title: varchar(150)
+ «PK» PK_PPR_PROBLEM(bigint)
0..*
1
0..*
1
0..*
1
0..*
1
FIGURA B.1 Modelo Relacional do Sistema – Parte 1
166
cd BD-GCM
GCM_TemplateConfiguracoes
*PK «column» gcb_id: bigint* «column» gcb_nome: varchar(50)* «column» gcb_data: timestamp «column» gcb_descricao: varchar(500) «column» gcb_observacao: varchar(500)*FK «column» gcm_TemplateConfiguracoesCategoria: bigint
+ «FK» FK_GCM_TemplateConfiguracoes_GCM_TemplateConfiguracoesCategoria(bigint)+ «index» IDX_GCM_TemplateConfiguracoes(bigint)+ «PK» FK_GCM_TemplateConfiguracoesArtefato_GCM_Artefat(bigint)
GCM_TemplateConfiguracoesArtefato
*PK «column» gcs_id: bigint*FK «column» gcm_Artefato: bigint*FK «column» gcm_TemplateConfiguracoes: bigint
+ «FK» FK_GCM_TemplateConfiguracoesArtefato_GCM_Artefato(bigint)+ «FK» FK_GCM_TemplateConfiguracoesArtefato_GCM_TemplateConfiguracoes(bigint)+ «index» IDX_GCM_TemplateConfiguracoesArtefato(bigint)+ «PK» PK_GCM_TemplateConfiguracoesArtefato(bigint)
GCM_TemplateConfiguracoesCategoria
*PK «column» gcc_id: bigint* «column» gcc_nome: varchar(150) «column» gcc_descricao: varchar(500) «column» gcc_observacao: varchar(500)
+ «PK» PK_GCM_TemplateConfiguracoesCategoria(bigint)
GCM_TemplateConfiguracoesProjeto
*PK «column» gcp_id: bigint*FK «column» gcm_TemplateConfiguracoes: bigint*FK «column» org_projeto: bigint
+ «FK» FK_GCM_TemplateConfiguracoesProjeto_GCM_TemplateConfiguracoes(bigint)+ «FK» FK_GCM_TemplateConfiguracoesProjeto_ORG_PROJECT(bigint)+ «PK» PK_GCM_TemplateConfiguracoesProjeto(bigint)
GCM_AnalisePropostaMudanca
*PK «column» gsp_id: bigint* «column» gsp_data: timestamp* «column» gsp_analise: varchar(5000) «column» gsp_observacao: varchar(5000)*FK «column» hrm_division_x_people: bigint*FK «column» gcm_ArtefatoPropostaAnalise: bigint*FK «column» gcm_analisePropostaMudancaStatus: bigint
+ «FK» FK_GCM_AnalisePropostaMudanca_GCM_ArtefatoPropostaAnalise(bigint)+ «FK» FK_GCM_AnalisePropostaMudanca_GcmAnalisePropostaMudancaStatus(bigint)+ «FK» FK_GCM_AnalisePropostaMudanca_HRM_USER(bigint)+ «PK» PK_GCM_AnalisePropostaMudanca(bigint)
Gcm_AnalisePropostaMudancaStatus
*PK «column» gtt_id: bigint* «column» gtt_nome: varchar(150) «column» gtt_descricao: varchar(200)
+ «PK» PK_GcmAnalisePropostaMudancaStatus(bigint)
0..*
10..*
1
0..*
1
0..*
1
FIGURA B.2 Modelo Relacional do Sistema – Parte 2
167
cd BD-GCM
GCM_Artefato
*PK «column» gcf_id: bigint* «column» gcf_nome: varchar(150) «column» gcf_descricao: varchar(500) «column» gcf_dataCriacao: timestamp «column» gcf_observacao: varchar(500)*FK «column» gcm_TipoArtefato: bigint*FK «column» gcm_ArtefatoStatus: bigint FK «column» gcm_artefatoRel: bigint* «column» gcf_codigo: integer*FK «column» gcm_prefixo: bigint
+ «FK» FK_Artefato_ArtefatoStatus(varchar)+ «FK» FK_Artefato_TipoArtefato(varchar)+ «FK» FK_GCM_Artefato_GCM_Artefato(bigint)+ «FK» FK_GCM_Artefato_GCM_PREFIXO(bigint)+ «index» IDX_Artefato(bigint)+ «index» IDX_Artefato(bigint, bigint)+ «index» IDX_GCM_Artefato(bigint, bigint, integer)+ «PK» PK_Artefato(bigint)
GCM_ArtefatoStatus
*PK «column» gcr_id: bigint* «column» gcr_nome: varchar(150) «column» gcr_descricao: varchar(500) «column» gcr_observacao: varchar(500)
+ «index» IDX_ArtefatoStatus(varchar)+ «PK» PK_ArtefatoStatus(bigint)
ORG_PROJECT
*PK «column» orp_id: bigint
+ «PK» PK_ORG_PROJECT(bigint)
GCM_ArtefatoProjeto
*PK «column» gcj_id: bigint*FK «column» org_projeto: bigint*FK «column» gcm_artefato: bigint
+ «FK» FK_GCM_ArtefatoProjeto_ORG_PROJECT(bigint)+ «FK» FK_Gcm_AtributoArtefatoFile_GCM_PropriedadeArtefato(bigint)+ «PK» PK_GCM_ArtefatoProjeto(bigint)
GCM_ArtefatoRelacionamento
*PK «column» grr_id: bigint*FK «column» gcm_artefato: bigint*FK «column» gcm_artefatoRel: bigint
+ «FK» FK_GCM_ArtefatoRelacionamento_GCM_Artefato(bigint)+ «FK» FK_GCM_ArtefatoRelacionamento_GCM_ArtefatoRel(bigint)+ «PK» PK_GCM_ArtefatoRelacionamento(bigint)
GCM_PREFIXO
*PK «column» gpx_id: bigint* «column» gpx_prefixo: varchar(50)*FK «column» org_project: bigint
+ «FK» FK_GCM_PREFIXO_ORG_PROJECT(bigint)+ «PK» PK_GCM_PREFIXO(bigint)
0..*1
0..*
10..*
1
0..*
1
0..*
1
0..*
1
0..*
1
FIGURA B.3 Modelo Relacional do Sistema – Parte 3
168
cd BD-GCM
GCM_TipoArtefato
*PK «column» gct_id: bigint* «column» gct_nome: varchar(150) «column» gct_descricao: varchar(500) «column» gct_observacao: varchar(500)
+ «index» IDX_TipoArtefato(varchar)+ «PK» PK_TipoArtefato(bigint)
HRM_DIVISION_X_PEOPLE
*PK «column» hdp_id: bigint
+ «PK» PK_HRM_USER(bigint)
GCM_ConfigurarVersionamento
*PK «column» gcn_id: bigint* «column» gcn_nome: varchar(150) «column» gcn_descricao: varchar(200) «column» gcn_observacao: varchar(50)* «column» gcn_incremento: integer* «column» gcn_casa: integer
+ «index» IDX_GCM_ConfigurarVersionamento(varchar)+ «PK» PK_GCM_ConfigurarVersionamento(bigint)
GCM_PropostaArtefato
*PK «column» ggg_id: bigint* «column» ggg_data: timestamp* «column» ggg_motivo: varchar(50) «column» ggg_observacao: varchar(50)*FK «column» hrm_division_x_people: bigint*FK «column» gcm_artefato: bigint «column» ggg_analise: varchar(50)* «column» ggg_codigo: bigint
+ «FK» FK_GCM_PropostaArtefato_GCM_Artefato(bigint)+ «FK» FK_GCM_PropostaArtefato_HRM_DIVISION_X_PEOPLE(bigint)+ «index» IDX_GCM_PropostaArtefato(bigint)+ «PK» PK_GCM_PropostaArtefato(bigint)
0..*
1
FIGURA B.4 Modelo Relacional do Sistema – Parte 4
169
cd BD-GCM
GCM_TipoRelacionamento
*PK «column» gct_id: bigint*FK «column» gcm_tipoArtefato: bigint*FK «column» gcm_grauRelacionamento: bigint*FK «column» gcm_tipoArtefatoRel: bigint
+ «FK» FK_GCM_TemplateConfiguracoesArtefato_GCM_Artefat(bigint)+ «FK» FK_GCM_TipoRelacionamento_GCM_GrauRelacionamento(bigint)+ «FK» FK_GCM_TipoRelacionamento_GCM_TipoArtefato2(bigint)+ «PK» PK_GCM_TipoRelacionamento(bigint)
GCM_PermissaoVersaoArtefatoUsuario
*PK «column» gcs_id: bigint*FK «column» gcm_versaoArtefato: bigint*FK «column» hrm_division_x_people: bigint*FK «column» gcm_permissaoStatus: bigint
+ «FK» FK_GCM_PermissaoVersaoArtefatoUsuario_GCM_PermissaoStatus(bigint)+ «FK» FK_GCM_PermissaoVersaoArtefatoUsuario_GCM_VersaoArtefato(bigint)+ «FK» FK_GCM_PermissaoVersaoArtefatoUsuario_HRM_USER(bigint)+ «PK» PK_GCM_PermissaoVersaoArtefatoUsuario(bigint)
GCM_PermissaoStatus
*PK «column» gss_id: bigint* «column» gss_nome: varchar(150) «column» gss_descricao: varchar(200)
+ «PK» PK_GCM_PermissaoStatus(bigint)
GCM_PropostaArtefato-sem v alidade
*PK «column» gpr_id: bigint* «column» gpr_codigo: varchar(10)* «column» gpr_titulo: varchar(150)* «column» gpr_motivo: varchar(500) «column» gpr_observacao: varchar(500)* «column» gpr_nome_artefato: varchar(150)* «column» gpr_descricao_artefato: varchar(500)*FK «column» gcm_tipoartefato: bigint*FK «column» hrm_division_x_people: bigint*FK «column» gcm_propostaArtefatoStatus: bigint
+ «FK» FK_GCM_PropostaArtefato_GCM_PropostaArtefatoStatus(bigint)+ «FK» FK_GCM_PropostaArtefato_GCM_TipoArtefato(bigint)+ «FK» FK_GCM_PropostaArtefato_HRM_USER(bigint)+ «PK» PK_GCM_PropostaArtefato(bigint)
GCM_PropostaArtefatoStatus
*PK «column» gps_id: bigint* «column» gps_nome: varchar(150) «column» gps_descricao: varchar(500) «column» gps_observacao: varchar(500)
+ «PK» PK_GCM_PropostaArtefatoStatus(bigint)
0..*
1
0..*
1
FIGURA B.5 Modelo Relacional do Sistema – Parte 5
170
cd BD-GCM
GCM_VersaoArtefato
*PK «column» gcl_id: bigint* «column» gcl_versao: varchar(15)* «column» gcl_data: timestamp «column» gcl_observacao: varchar(500)*FK «column» gcm_Artefato: bigint*FK «column» gcm_Visibil idade: bigint*FK «column» gcm_VersaoArtefatoStatus: bigint FK «column» gcm_VersaoArtefato: bigint
+ «FK» FK_GCM_VersaoArtefato_GCM_VersaoArtefato(bigint)+ «FK» FK_VersaoArtefato_Artefato(bigint)+ «FK» FK_VersaoArtefato_VersaoArtefatoStatus(bigint)+ «FK» FK_VersaoArtefato_Visibilidade(varchar)+ «index» IDX_VersaoArtefato(varchar)+ «index» IDX_VersaoArtefato(varchar, bigint)+ «index» IDX_VersaoArtefato(varchar, bigint, bigint)+ «index» IDX_VersaoArtefato(varchar, bigint, bigint, bigint)+ «PK» PK_VersaoArtefato(bigint)
GCM_TipoPropriedadeArtefato
*PK «column» gcp_id: bigint* «column» gcp_nome: varchar(150) «column» gcp_descricao: varchar(500) «column» gcp_observacao: varchar(500)
+ «index» IDX_TipoPropriedadeArtefato(varchar)+ «PK» PK_TipoPropriedadeArtefato(bigint)
GCM_VersaoArtefatoStatus
*PK «column» gcs_id: bigint* «column» gcs_nome: varchar(150) «column» gcs_descricao: varchar(500) «column» gcs_observacao: varchar(500)
+ «index» IDX_VersaoArtefatoStatus(varchar)+ «PK» PK_VersaoArtefatoStatus(bigint)
GCM_Visibilidade
*PK «column» gcv_id: bigint* «column» gcv_nome: varchar(150) «column» gcv_descricao: varchar(500) «column» gcv_observacao: varchar(50)
+ «index» IDX_Visibil idade(varchar)+ «PK» PK_Visibil idade(bigint)
GCM_Operacao
*PK «column» gcp_id: bigint* «column» gcp_nome: varchar(150) «column» gcp_descricao: varchar(500) «column» gcp_observacao: varchar(500)
+ «PK» PK_GCM_Operacao(bigint)
GCM_HistoricoOperacao
*PK «column» gch_id: bigint* «column» gch_data: timestamp* «column» gch_descricao: varchar(500)*FK «column» gcm_operacao: bigint*FK «column» gcm_versaoArtefato: bigint*FK «column» hrm_division_x_people: bigint
+ «FK» FK_GCM_HistoricoOperacao_GCM_Operacao(bigint)+ «FK» FK_GCM_HistoricoOperacao_GCM_VersaoArtefato(bigint)+ «FK» FK_GCM_HistoricoOperacao_HRM_USER(bigint)+ «PK» PK_GCM_HistoricoOperacao(bigint)
0..*
1
0..*
1
0..*1
0..*
1
FIGURA B.6 Modelo Relacional do Sistema – Parte 6
171
cd BD-GCM
GCM_PropriedadeArtefato
*PK «column» gcc_id: bigint* «column» gcc_nome: varchar(150) «column» gcc_descricao: varchar(500) «column» gcc_observacao: varchar(500)*FK «column» gcm_TipoArtefato: bigint*FK «column» gcm_TipoPropriedadeArtefato: bigint
+ «FK» FK_PropriedadeArtefato_TipoArtefato(varchar)+ «FK» FK_PropriedadeArtefato_TipoPropriedadeArtefato(varchar)+ «index» IDX_PropriedadeArtefato(bigint)+ «index» IDX_PropriedadeArtefato(bigint, bigint)+ «index» IDX_PropriedadeArtefato(bigint, bigint, bigint)+ «PK» PK_PropriedadeArtefato(bigint)
GCM_AtributosArtefatoInteiro
*PK «column» gcn_id: bigint* «column» gcn_valor: bigint*FK «column» gcm_VersaoArtefato: bigint*FK «column» gcm_PropriedadeArtefato: bigint
+ «FK» FK_AtributosArtefatoInteiro_PropriedadeArtefato(bigint)+ «FK» FK_GCM_BaselineProjeto_ORG_PROJECT(bigint)+ «index» IDX_AtributosArtefatoInteiro(bigint)+ «index» IDX_AtributosArtefatoInteiro(bigint, bigint)+ «PK» PK_AtributosArtefatoInteiro(bigint)
Gcm_AtributosArtefatoFile
*PK «column» grf_id: bigint* «column» grf_file_name: varchar(150)* «column» grf_content_type: varchar(150)* «column» grf_length: numeric(10,2)* «column» grf_file: bytea*FK «column» gcm_PropriedadeArtefato: bigint FK «column» gcm_VersaoArtefato: bigint
+ «FK» FK_Gcm_AtributosArtefatoFile_GCM_PropriedadeArtefato(bigint)+ «FK» FK_Gcm_AtributosArtefatoFile_GCM_VersaoArtefato(bigint)+ «PK» PK_Gcm_AtributosArtefatoFile(bigint)
0..*
1
0..*
1
FIGURA B.7 Modelo Relacional do Sistema – Parte 7
172
cd BD-GCM
GCM_Cliente
*PK «column» gss_id: bigint* «column» gss_nome: varchar(200)
+ «PK» PK_GCM_Cliente(bigint)
GCM_VersaoRelease
*PK «column» grc_id: bigint*FK «column» gcm_release: bigint*FK «column» gcm_versaoArtefatoVersaoConfiguracao: bigint
+ «FK» FK_GCM_VersaoRelease_GCM_Release(bigint)+ «FK» FK_GCM_VersaoRelease_GCM_VersaoArtefatoVersaoConfiguracao(bigint)+ «PK» PK_GCM_VersaoRelease(bigint)
GCM_Release
*PK «column» grl_id: bigint* «column» grl_nome: varchar(200)* «column» grl_data: timestamp «column» grl_descricao: varchar(500)*FK «column» gcm_releaseStatus: bigint
+ «FK» FK_GCM_Release_GCM_ReleaseStatus(bigint)+ «PK» PK_GCM_Release(bigint)
GCM_ReleaseStatus
*PK «column» grs_id: bigint* «column» grs_nome: varchar(200) «column» grs_descricao: varchar(500) «column» grs_observacao: varchar(500)
+ «PK» PK_GCM_ReleaseStatus(bigint)
GCM_CLIENTE_RELEASE
*PK «column» glr_id: bigint*FK «column» gcm_cliente: bigint*FK «column» gcm_release: bigint
+ «FK» FK_GCM_CLIENTE_RELEASE_GCM_Cliente(bigint)+ «FK» FK_GCM_CLIENTE_RELEASE_GCM_Release(bigint)+ «PK» PK_GCM_CLIENTE_RELEASE(bigint)
GCM_QUALIDADE
*PK «column» gqq_id: bigint* «column» gqq_texto: varchar(50)*FK «column» gcm_versaoartefato: bigint
+ «FK» FK_GCM_QULIDADE_GCM_VersaoArtefato(bigint)+ «PK» PK_GCM_QULIDADE(bigint)
0..*
1
0..*
1
0..*1
0..*
1
FIGURA B.8 Modelo Relacional do Sistema – Parte 8
173
cd BD-GCM
GCM_RelacionamentoVersaoArtefato
*PK «column» gcr_id: bigint*FK «column» gcm_GrauRelacionamento: bigint*FK «column» gcm_VersaoArtefato: bigint*FK «column» gcm_VersaoArtefatoRel: bigint
+ «FK» FK_GCM_RelacionamentoVersaoArtefato_GCM_GrauRelacionamento(bigint)+ «FK» FK_GCM_RelacionamentoVersaoArtefato_GCM_VersaoArtefato(bigint)+ «FK» FK_GCM_RelacionamentoVersaoArtefato_GCM_VersaoArtefatoRel(bigint)+ «PK» PK_GCM_RelacionamentoVersaoArtefato(bigint)
GCM_VersaoArtefatoVersaoConfiguracao
*FK «column» gcm_VersaoArtefato: bigint*FK «column» gcm_VersaoConfiguracao: bigint*PK «column» gvv_id: bigint
+ «FK» FK_GCM_VersaoArtefatoVersaoConfiguracao_GCM_VersaoArtefato(bigint)+ «FK» FK_GCM_VersaoArtefatoVersaoConfiguracao_GCM_VersaoConfiguracao(bigint)+ «PK» PK_GCM_VersaoArtefatoVersaoConfiguracao(bigint)
FIGURA B.9 Modelo Relacional do Sistema – Parte 9
174
cd BD-GCM
GCM_AtributosArtefatoString
*PK «column» gcg_id: bigint* «column» gcg_valor: varchar(500)*FK «column» gcm_PropriedadeArtefato: bigint*FK «column» gcm_VersaoArtefato: bigint
+ «FK» FK_AtributosArtefatoString_PropriedadeArtefato(bigint)+ «FK» FK_AtributosArtefatoString_VersaoArtefato(bigint)+ «index» IDX_AtributosArtefatoString(bigint)+ «index» IDX_AtributosArtefatoString(bigint, bigint)+ «PK» PK_AtributosArtefatoString(bigint)
GCM_GrauRelacionamento
*PK «column» gcn_id: bigint «column» gcn_nome: varchar(150) «column» gcn_descricao: varchar(500) «column» gcn_observacao: varchar(500)
+ «PK» PK_GcmGrauRelacionamento(bigint)
GCM_Configuracao
*PK «column» gnf_id: bigint* «column» gnf_nome: varchar(150) «column» gnf_descricao: varchar(500) «column» gnf_observacao: varchar(500)
+ «index» IDX_GCM_Configuracao(varchar)+ «PK» PK_GCM_Configuracao(bigint)
GCM_VersaoConfiguracao
*PK «column» gvc_id: bigint* «column» gvc_versao: varchar(50)* «column» gvc_data: timestamp*FK «column» gcm_configuracao: bigint*FK «column» gcm_VersaoConfiguracaoStatus: bigint
+ «FK» FK_GCM_VersaoConfiguracao_GCM_Configuracao(bigint)+ «FK» FK_GCM_VersaoConfiguracao_GCM_VersaoConfiguracaoStatus(bigint)+ «index» IDX_GCM_VersaoConfiguracao(varchar)+ «PK» PK_GCM_VersaoConfiguracao(bigint)
GCM_VersaoConfiguracaoStatus
*PK «column» gvs_id: bigint «column» gvs_nome: varchar(150) «column» gvs_descricao: varchar(500) «column» gvs_observacao: varchar(500)
+ «PK» PK_GCM_VersaoConfiguracaoStatus(bigint)
0..*
+FK_GCM_VersaoConfiguracao_GCM_Configuracao(gcm_configuracao = gnf_id)
1
+PK_GCM_Configuracao
0..*+FK_GCM_VersaoConfiguracao_GCM_VersaoConfiguraca...
(gcm_VersaoConfiguracaoStatus = gvs_id)
1+PK_GCM_VersaoConfiguracaoStatus
FIGURA B.10 Modelo Relacional do Sistema – Parte 10
