Relatório Final V01

(1)

Instituto Tecnológico de Aeronáutica – ITA

EDUARDO MENA BARRETO ALONSO

São José dos Campos, 21 de Junho de 2011

CE-240 - Projeto de Sistemas de Bancos de Dados

Prof. Dr. Adilson Marques da Cunha

(2)

1 - Introdução

1.1 – Motivação

Devido a atual necessidade de diminuir o consumo de energia elétrica e melhorar a qualidade do serviço aos seus clientes, bem como reduzir as emissões de carbono e aumentar a confiabilidade da rede, criou-se o sistema denominado Smart Grid que é um sistema onde é aplicado a tecnologia da informação para o sistema elétrico de potência, integrada aos sistemas de comunicação e infra estrutura de rede automatizada.

Nesse contexto, a aplicação de sistemas computacionais que permitam a análise da utilização e consumo de energia elétrica fornecida através de Smart Grids é uma alternativa viável para permitir a tomada de decisão nos níveis operacional, tático e estratégico.

Assim, a adequação de um sistema de banco de dados para um sistema de smart grid que faça o uso de software especializado para o sensoriamento e medição da energia elétrica utilizada pelos seus consumidores, também conhecido como medidor inteligente ou smart metering, pode oferecer ganhos reais tais como a otimização do fluxo de distribuição da energia, o controle da vida útil dos equipamentos da rede, a manobra automática do fluxo elétrico dos circuitos em caso de interrupções de distribuição etc.

1.2 - Contexto

A fusão das Empresas SPR (Setor Privado) e SPU (Setor Público) resultou na criação de uma Holding denominada Empresa de Sistemas Smart Grids – SSG. Seus serviços abrangem a auxilio na geração, distribuição, coleta e medição de energia, incluindo o controle de utilização de equipamentos, como por exemplo, o controle de acesso do departamento de polícia, câmeras de segurança ou o controle operacional de celas.

Para isso, a SSG utiliza um sistema inteligente de controle de energia que conta com sensores identificados por coordenadas georeferenciadas e equipamentos os quais alimentam o sistema, sendo que tais produtos estão localizados em um determinado local dentro dos departamentos de polícia. Os equipamentos do departamento de polícia possuem um código e integra diversos medidores os quais coletam dados armazenados em séries históricas e podem ser manipulados por um operador.

Cada operador é um funcionário da nova holding SSG, sendo ainda que administradores podem analisar e utilizar os dados das séries históricas, aos quais extraem relatórios gerenciais e estatísticas das informações armazenadas.

1.3 - Objetivo

O objetivo desse relatório final de Projeto é implementar um Protótipo de Aplicativo de BD inserido no contexto de um Sistema de Informações Corporativo baseado na aplicação das técnicas e das tecnologias de Banco de Dados, apresentado em 04 (quatro) diferentes níveis de abstração de: Aplicativos de Banco de Dados (ABD), Banco de Dados Setorial (BDS), Banco de Dados Corporativo (BSC) e Banco de Dados de uma Empresa Holding (BSH).

A heurística do objetivo foi aplicada ao Aplicativo de Banco de Dados da Unidade de Polícia Pacificador Departamento de Policia (ABD-UPP-PO). A heurística pode ser acessada no Anexo I – Heurística do Objetivo para desenvolvimento do ABD-UPP-PO.

https://sites.google.com/site/edumenabarreto/materias/ce240 1.4 - Especificação dos Requisitos

O Protótipo do Sistema de Banco de Dados da Unidade de Polícia Pacificadora do Departamento de Policia (ABD-UPP-PO) deve:

1 Ser capaz de realizar o Gerenciamento do consumo dos aparelhos de ar condicionado; 2 Realizar o Monitoramento do consumo do sitema de iluminação;

(3)

2 – Desenvolvimento

2.1 Aplicativo de Banco de Dados

Nesta seção são apresentados os passos para o desenvolvimento do Aplicativo de Banco de Dados da Unidade de Polícia Pacificadora do Departamento de Policia (ABD-UPP-PO) e os contextos em que esse aplicativo se insere: Setor de Polícia, Corporação de Serviços Públicos e Holding.

2.1.1 Modelo de Dados escolhido

O modelo do banco de dados escolhido foi o modelo Relacional devido ao fato deste modelo ter sido explorado no decorrer da disciplina e nas listas de exercício, mais especificadamente durante a lista de exercícios 4.

Contudo, o fator decisivo para a escolha do modelo relacional é a sua maior interoperabilidade com as ferramentas disponíveis no mercado, dentre elas o sistema gerenciador de banco de dados Oracle 11g Spatial que foi usado ao longo da disciplina.

2.1.2 Descrição dos principais componentes do ABD-UPP-PO

Na lista de exercícios 3, onde foram aplicadas as técnicas de normalização da versão 2 do modelo, o autor concluiu a implementação da versão numero 2 do ABD-UPP-PO utilizando o modelo relacional, ao todo foram definidas 4 entidades que representam:

PO-UPP – Representa as unidades de Polícia Pacificadora; MONITORAR – Representa os equipamentos a seram monitorados;

LOCAL – Representa o local nas unidades de policia pacificadora onde os equipamentos estão instalados;

CONSUMO – Realiza a medição do consumo dos eqipamentos.

As técnicas de normalização e trigramação utilizadas no desenvolvimento encontra-se no Anexo II - Normalização e Trigramação da Unidade PO_UPP

https://sites.google.com/site/edumenabarreto/materias/ce240

2.1.3 Descrição dos Quatro Componentes de Dicionário de Dados

Durante a lista de exercícios 4 foi definida a versão 1 dos componentes dos dicionários de dados do ABD-UPP-PO. De acordo com a 9ª técnica de banco de dados, demonstrada em sala de aula, onde, um dicionário de dados deve possuir pelo menos 04 (quatro) Componentes:

Um Dicionário de Dados (propriamente dito); Um Diretório de Dados;

Um Dicionário de Recursos de Dados; Um Dicionário de Metadados.

Os quatro componentes do dicionário de dados podem ser encontrados no Anexo III – Sistema de dicionário de dados do ABD-UPP-PO.

2.1.4 Apresentação do Modelo Entidade Relacionamento (MER) com suas cardinalidades

O modelo entidade-relacionamento (MER) do ABD-UPP-PO foi construído através da ferramenta ERWIN durante a lista de exercícios 4. Sua representação, contendo suas cardinalidades encontra-se no Anexo IV – Modelo Entidade Relacionamento (MER) do ABD-UPP-PO.

(4)

2.1.5 Massa de Dados

Nessa etapa do trabalho desenvolvida na listex 4, a fim de realizar os testes e validar o modelo entidade relacionamento da ABD-UPP-PO, foram criadas massa de dados para o teste e validação das consultas criadas em linguagem natural e em linguagem estruturada de dados. Os scripts para a criação da massa de dados pode ser encontrado no Anexo V – Criação das Tabelas e da Massa de Dados do ABD-UPP-PO.

2.1.6 Implementação e implantação das 04 consultas operacionais

Após a criação da massa de dados a ser utilizada no ABD-UPP-PO realizada na lista de exercicios 4, foram implementadas e implantadas as consultas operacionais tanto em linguagem natural como em linguagem estruturada de dados. Anexo VI - Implementação e Implantação das Consultas Operacionais do ABD-UPP-PO.

2.2 - Banco de Dados Setorial

Esta seção apresenta informações relativas ao contexto de integração do ABD-UPP-PO no aplicativo de banco de dados setorial do departamento de polícia. Integração essa foi realizada na lista de exercícios 5. Nessa etapa o autor assumiu o papel de Dicionalizador, tendo como responsabilidade, sempre que for necessário, organizar, padronizar, documentar e manter atualizados os 04 (quatro) componentes do Sistema de Dicionário de Dados do BDS, evitando inconsistências, duplicidades, homônimos ou quaisquer outras anomalias e discrepâncias, utilizando a Técnica de Trigramação;

2.2.1 - Extensão do Dicionário de Dados para os elementos incorporados ao ABD-UPP-PO

Nesta fase do trabalho, a ABD-UPP-PO integrou-se a três outros aplicativos de bancos de dados, formando o aplicativo de banco de dados setorial do departamento de polícia.

A extensão do dicionário de dados, considerando esse novo contexto, é detalhada no Anexo VII – Extensão do dicionário de dados para contexto setorial.

2.2.2 - Extensão do Modelo Entidade Relacionamento (MER) com as cardinalidades dos elementos incorporados ao ABD-UPP-PO

O Anexo VII – Extensão do dicionário de dados para contexto setorial – Dicionário de Metadados apresenta o modelo entidade-relacionamento resultante da integração do ABD-UPP-PO com outros três aplicativos de banco de dados, formando o aplicativo de banco de dados setorial do departamento de polícia.

2.2.3 - Extensão da 3ª FN para os elementos incorporados ao ABD-UPP-PO

O Anexo VIII – Extensão da 3ª FN para elementos incorporados ao aplicativo de banco de dados setorial do departamento de polícia https://sites.google.com/site/edumenabarreto/materias/ce240

apresenta os procedimentos de normalização utilizados na integração dos elementos incorporados ao ABD-UPP-PO para composição do aplicativo de banco de dados setorial do departamento de polícia. 2.2.4 - Extensão da Massa de Dados para os elementos incorporados ao ABD-UPP-PO

O Anexo IX: Extensão da Massa de Dados para considerar elementos incorporados ao contexto do BDS,

(5)

apresenta os scripts para extensão da massa de dados necessários para garantir o funcionamento das consultas implementadas no aplicativo de banco de dados setorial do departamento de polícia.

2.2.5 Extensão da Implementação e da Implantação das 4 consultas táticas O Anexo X: Extensão da Implementação e da Implantação das 4 consultas táticas ao BDS

apresenta a criação de quatro novas consultas táticas, considerando o cenário de integração setorial do departamento de polícia.

2.3 Banco de Dados Corporativo

Esta seção apresenta informações relativas ao contexto de integração do aplicativo de banco de dados setorial do departamento de polícia no aplicativo de banco de dados corporativo de serviços públicos. 2.3.1 Extensão do Dicionário de Dados para os elementos incorporados ao ABD-UPP-PO

Nessa etapa da integração dos bancos setoriais de veículos e da policia foi necessária gerar os novos quatro componentes do dicionário de dados do novo banco de dados corporativo. De acordo com a 9ª técnica de banco de dados, demonstrada em sala de aula, durante a 6ª semana de aula, um dicionário de dados deve possuir pelo menos 04 (quatro) Componentes:

Um Dicionário de Dados (propriamente dito); Um Diretório de Dados;

Um Dicionário de Recursos de Dados; Um Dicionário de Metadados;

A extensão do dicionário de dados do aplicativo do ABD-UPP-PO que estava inserido no banco de dados setorial e nesse momento irá compor um banco de dados corporativo se encontra no Anexo XI - Extensão do Dicionário de Dados para os elementos incorporados ao ABD-UPP-PO.

2.3.2 Extensão da 3ª FN para os elementos incorporados ao ABD-UPP-PO

Nessa etapa da integração dos bancos setoriais de veículos e da policia foi necessária gerar a normalização dos modelos para que a integração para se manter a consistência dos dados na nova etapa da integração para que o banco de dados cooperativo pudesse ser operacional sem nenhuma dificuldade. Antes da geração do diagrama do modelo entidade relacionamento, foi necessário normalizar as entidades a fim de obter um modelo ideal para a recuperação, atualização e exclusão de dados com eficácia visando o melhor desempenho na recuperação dos dados. Os passos estão disponíveis no Anexo XII – Extensão da 3ª FN para os elementos incorporados ao ABD-UPP-PO. https://sites.google.com/site/edumenabarreto/materias/ce240

2.3.3 Extensão do Modelo Entidade Relacionamento (MER) com as cardinalidades dos elementos incorporados ao ABD-UPP-PO

O Anexo XIII - Extensão do Modelo Entidade Relacionamento (MER) com as cardinalidades dos elementos incorporados ao ABD-UPP-PO https://sites.google.com/site/edumenabarreto/materias/ce240

apresenta o modelo entidade-relacionamento resultante da integração do dos bancos setoriais 2.3.4 Extensão do Massa de Dados para os elementos incorporados ao ABD-UPP-PO O Anexo XIV - Extensão do Massa de Dados para os elementos incorporados ao ABD-UPP-PO

apresenta os scripts para extensão da massa de dados necessários para garantir o funcionamento das consultas implementadas no aplicativo de banco de dados setorial do departamento de polícia.

(6)

2.3.5 Extensão da Implementação e implantação das 03 consultas estratégicas

Nessa etapa foram testadas e validadas as consultas estratégicas implementadas e implantadas na lista de exercícios cinco, as consultas e os resultados encontrados estão disponíveis no Anexo XV – Extensão da Implementação e implantação das 03 consultas estratégicas.

2.4 Exercício de Simulação de Jogos de Empresas

O exercício de simulação de jogos de empresas trata de um cenário fictício envolvendo a fusão de duas empresas, SPR (Setor Privado) e SPU (Setor Publico), em uma empresa Holding denominada Empresa de Sistemas Smart Grids – SSG. Sua contextualização e requisitos se encontram na introdução deste relatório.

Para melhor execução das atividades necessárias ao processo de integração, foram mantidos os papéis criados na iteração anterior.

O autor manteve o papel de Normalizador, ficando responsável por organizar, padronizar, documentar, normalizar, renormalizar e manter atualizado: os Modelos Conceituais ou Modelos Entidades Relacionamentos (MER); os Modelos de Dados Setoriais - MDS ou Subject Data Model – SDM; e as suas cardinalidades, mantendo o número de atributos por Entidade menor ou igual a sete.

2.4.1 Motivação, Contexto, Objetivo e Especificação de Requisitos

Nessa etapa da integração dos bancos corporativos, foi necessário recontextualizar toda a empresa holding, para isso o grupo de alunos que assumiram a posição de Integradores, criaram a recontextualização, que pode ser acompanhada no anexo.

2.4.2 Extensão do Dicionário de Dados para os elementos incorporados ao ABD-UPP-PO

Nessa etapa da integração dos bancos corporativos, tanto do setor publico quanto do privado, foi gerado um intenso debate tanto presencialmente quanto através das listas de discussão para a geração do dicionário de dados. De acordo com a 9ª técnica de banco de dados, demonstrada em sala de aula, durante a 6ª semana de aula, um dicionário de dados deve possuir pelo menos 04 (quatro) Componentes: Um Dicionário de Dados (propriamente dito);

Um Diretório de Dados;

Um Dicionário de Recursos de Dados; Um Dicionário de Metadados;

A extensão do dicionário de dados do aplicativo do ABD-UPP-PO para o banco de dados da holding se encontra no Anexo XVI - Extensão do Dicionário de Dados para os elementos incorporados ao ABD-UPP-PO ao BDH.

2.4.3 Extensão da 3ª FN para os elementos incorporados ao ABD-UPP-PO

Nessa etapa da integração dos bancos corporativos do setor privado e do setor publico necessária gerar a normalização dos modelos para que a integração em um banco de dados holding, possa manter a consistência dos dados na nova etapa da integração para que o banco de dados cooperativo pudesse ser operacional sem nenhuma dificuldade. Antes da geração do diagrama do modelo entidade relacionamento, foi necessário normalizar as entidades a fim de obter um modelo ideal para a recuperação, atualização e exclusão de dados com eficácia visando o melhor desempenho na recuperação dos dados. Os passos estão disponíveis no Anexo XVII - Extensão da 3ª FN para os elementos incorporados ao ABD-UPP-PO ao BDH.

2.4.4 Extensão do Modelo Entidade Relacionamento (MER) com as cardinalidades dos elementos incorporados ao ABD-UPP-PO

O Anexo XVIII - Extensão do Modelo Entidade Relacionamento (MER) com as cardinalidades dos elementos incorporados ao ABD-UPP-PO ao BDH https://sites.google.com/site/edumenabarreto/materias/ce240

(7)

2.4.5 Extensão do Massa de Dados para os elementos incorporados ao ABD-UPP-PO O Anexo XIX - Extensão do Massa de Dados para os elementos incorporados ao ABD-UPP-PO ao BDH,

apresenta os scripts de criação das tabelas e extensão da massa de dados necessários para garantir o funcionamento das consultas a serem implementadas.

2.4.6 Extensão da Implementação e implantação das 03 consultas estratégicas

2.4.6.1 Consulta Operacional - Envolvendo uma Relação do ABD-UPP-PO e duas Relações Novas ou/de um ABD diferente, que esteja fora BDC do Setor Público.

Linguagem Natural: Listar as transações que a unidade de policia pacificadora do alemão forneceu energia a outros consumidores

SQL: SELECT

DEPARTAMENTO_POLICIA.DPP_UNIDADE_PARTICIPANTE, TRANSACAO.TRA_VALOR,

TRANSACAO.TRA_DATAHORA, TRANSACAO.TRA_QT_ENERGIA

FROM UNIDADE, DEPARTAMENTO_POLICIA, TRANSACAO WHERE DEPARTAMENTO_POLICIA.UNI_ID = UNIDADE.uni_id AND TRANSACAO.UNI_FORNECEDOR = UNIDADE.uni_id

2.4.6.2 Consulta Tática - Envolvendo uma Relação do ABD-UPP-PO e duas Relações Novas ou de dois diferentes Aplicativos de BD, cada um pertencendo a um BDS diferente, que não seja do seu BDC do Setor Público.

Linguagem Natural: Listar o histórico de consumo dos departamentos de polícia que contenham áreas restritas

SQL: SELECT DEPARTAMENTO_POLICIA.DPP_UNIDADE_PARTICIPANTE, HISTORICO.* FROM UNIDADE, SETOR, HISTORICO, DEPARTAMENTO_POLICIA

(8)

AND SETOR.UNI_ID = UNIDADE.UNI_ID

AND DEPARTAMENTO_POLICIA.UNI_ID = UNIDADE.uni_id AND HISTORICO.UNI_ID = UNIDADE.UNI_ID;

2.4.6.3 Consulta Estratégica - Envolvendo uma Relação do ABD-UPP-PO e duas Relações Novas ou de dois diferentes Aplicativos de BD, cada umpertencendo a um Banco de Dados Setorial diferente, que não seja do seu BD Corporativo.

Linguagem Natural: Listar todas as formas de geração de energia disponíveis nas delegacias de polícia SQL: SELECT DEPARTAMENTO_POLICIA.DPP_UNIDADE_PARTICIPANTE,

GERADOR.GER_DESCRICAO

FROM UNIDADE, GERADOR, DEPARTAMENTO_POLICIA WHERE UNIDADE.UNI_ID = GERADOR.UNI_ID

(9)

2.4.7 Visão

Essa etapa consiste na criação de uma visão (VIEW) envolvendo no mínimo o ABD-UPP-PO dentro do BD Corporativo do Setor Publico com um outro um banco de dados setorial do outro banco de dados corporativo do setor privado.

Requisito: Listar os geradores das de cuja capacidade de geração de energia seja superior ao consumo das máquinas

2.4.7.1 Criação

CREATE OR REPLACE VIEW GEADOR_CONSUMO_MAIOR_MAQUINA AS

SELECT DISTINCT GERADOR.GER_ID, UNIDADE.UNI_NOME, GERADOR.GER_TIPO_ENERGIA, GERADOR.GER_DESCRICAO

FROM GERADOR, UNIDADE, INDUSTRIA, PRODUCAO, PRODUTO, MAQUINA, MEDIDOR, CONSUMO

WHERE PRODUCAO.pdc_datahora = CONSUMO.con_datahora AND PRODUCAO.pdc_medicao > CONSUMO.con_qt

AND UNIDADE.uni_id = INDUSTRIA.uni_id AND UNIDADE.uni_id = PRODUTO.uni_id AND PRODUTO.pro_id = MAQUINA.pro_id AND PRODUTO.mdd_id = MEDIDOR.mdd_id AND CONSUMO.mdd_id = MEDIDOR.mdd_id AND GERADOR.uni_id = UNIDADE.uni_id AND PRODUCAO.ger_id = GERADOR.ger_id;

2.4.7.2 Uso

(10)

2.4.8 Trigger

Essa etapa consiste na criação de um gatilho (Trigger) envolvendo no mínimo o ABD-UPP-PO dentro do BD Corporativo do Setor Publico com um outro um banco de dados setorial do outro banco de dados corporativo do setor privado.

Requisito: Criar o novo nome de um departamento de polícia baseado no registro da chave do banco concatenando com as siglas DP.

2.4.8.1 Criação

create or replace trigger CRIA_NUMERO_UNIDADE_POLICIA before insert on DEPARTAMENTO_POLICIA

for each row begin

if (:new.DPP_UNIDADE_PARTICIPANTE is null) then

select :new.UNI_ID || ' ' || 'DP' into :new.DPP_UNIDADE_PARTICIPANTE from DUAL; end if;

(11)

2.4.8.2 Uso

2.4.9 Stored Procedure Georreferenciada

Essa etapa consiste na criação de uma stored procedure georreferenciada envolvendo no mínimo o ABD-UPP-PO dentro do BD Corporativo do Setor Publico com um banco de dados setorial do outro banco de dados corporativo do setor privado. Essa stored procedure recupera a capacidade da bateria de um veiculo pela licença dentro do território de atuação do empresa holding SSG.

2.4.9.1 Criação

CREATE OR REPLACE PROCEDURE CAPACIDADE_BATERIA(VeiculoID IN NUMBER) AS CAPACIDADE NUMBER;

BEGIN

SELECT DISTINCT BATERIA.BAT_CAPACIDADE INTO CAPACIDADE FROM BATERIA, VEICULO, UNIDADE, INDUSTRIA, LOCAL

WHERE sdo_inside(LOCAL.loc_spatial, MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, SDO_ELEM_INFO_ARRAY (1,1003,3),

SDO_ORDINATE_ARRAY (-33.752061377,-73.994423393, 5.271806856, -28.835883971))) = 'TRUE' AND BATERIA.uni_id = VEICULO.uni_id

AND VEICULO.uni_possuidora = UNIDADE.uni_id AND UNIDADE.uni_id = INDUSTRIA.uni_id AND VEICULO.VEI_LICENCA = VeiculoID; End CAPACIDADE_BATERIA;

(12)

2.5 Relatório da Disciplina CE-245

O aplicativo de banco de dados para o sistema smart grid (SSG) desenvolvido pelos alunos da disciplina CE240 – Projeto de Sistemas de Banco de Dados serviu como infraestrutura de back-end para realização das atividades dos alunos que cursaram a disciplina CE245 – Tecnologias da Informação produzirem as interfaces de visualização e camada de negócios do sistema, resultando em um portal internet, que pode ser acessado para inserção, edição e recuperação das informações armazenadas.

O processo utilizado para desenvolvimento deste portal foi uma customização do framework de processo SCRUM, onde as prioridades de desenvolvimento foram discutidas com o integrante que fez o papel de Product Owner, neste caso, o professor da disciplina e, posteriormente, os sprints quinzenais eram planejados, detalhados e suas tarefas distribuídas entre todos os integrantes do grupo, que se tornavam responsáveis pela entrega dessas atividades ao final do Sprint.

A cerimônia de daily meeting (reunião diária) não foi utilizada devido à dispersão geográfica dos integrantes desse grupo, mas reuniões semanais de posicionamento de status entre os integrantes da equipe aconteciam presencialmente, além da realização de diversos comunicados apoiados em ferramentas como e-mail e/ou outras tecnologias da comunicação que permitiram a realização do trabalho de forma colaborativa (instant messenger, subversion, google docs, etc).

O framework de processo SCRUM, utilizado como base para execução do processo de trabalho que originou o portal do SSG, é apresentada abaixo:

(13)

Durante as fases iniciais de construção do portal, foi aberta uma discussão para avaliarmos quais seriam as tecnologias da informação empregadas na construção do portal. Devido ao conhecimento multidisciplinar dos integrantes da equipe de desenvolvimento do portal, várias alternativas foram apresentadas e, ao final de um processo inicial de triagem, foram apresentadas as plataformas tecnológicas java + hibernate + jsf + servlets, python + django e ruby + rails para votação. O grupo entendeu que utilização da plataforma Ruby On Rails traria grandes ganhos com relação à padronização e produtividade para desenvolvimento e escolheu essa opção.

A plataforma Ruby On Rails é baseada na arquitetura MVC (Model View Controller), onde as responsabilidades de cada camada da aplicação são claramente estruturadas:

Model: Camada responsável por armazenar o modelo de domínio da solução. É onde as regras de negócio são armazenadas.

View: Camada responsável pela geração das interfaces homem-máquina do sistema Nesta camada o usuário vê o estado do modelo (Model) e pode manipular a interface, para ativar comportamentos dos objetos de negócio.

Controller: Camada responsável por transformar eventos gerados pela interface em ações de negócio, alterando o modelo. São o meio de ligação entre as visões (Views) e modelos (Models).

(14)

Arquitetura de solução MVC – Utilizada no portal do SSG

Para entendimento e registro das necessidades de negócio a serem atendidas pelo portal do SSG, alguns artefatos foram produzidos visando esclarecer a visão sobre o produto, seus casos de uso, casos de testes e um glossário com a terminologia utilizada na documentação. Tais artefatos são classificados e podem ser encontrados nos endereços abaixo:

Documento de Visão: Contém a definição sobre as necessidades e características de nível superior do Sistema de Smart Grid. Tem enfoque nos recursos de que os envolvidos e usuários-alvo precisam e

mostra por que essas necessidades existem:

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVwYXRvfGd4OjZhM

Tg4MmViZjIzN2Y3Mjg

Modelo de Casos de Uso: Consiste em apresentar a organização entre os atores, casos de uso e seus relacionamentos, que devem ser implementados no SSG:

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVwYXRvfGd4OjNiN

WFkNDRmZGE2OTUyYzc

Modelo de Casos de Teste: Descreve a sequencia de ações a serem executadas e resultados esperados que correspondam a um roteiro para realização da bateria de testes:

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVwYXRvfGd4OjcwN

GQ1MTMwYzYyZjVkY2E

Glossário: Apresenta as siglas, abreviaturas e definições que aparecem nos documentos de visão, caso de uso e caso de teste da unidade de software de computador Sistema Smart Grid:

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVwYXRvfGd4OjE1M

(15)

Após a consolidação de um conjunto básico de artefatos que permitiu o entendimento das principais funcionalidades do sistema SSG, suas atividades foram priorizadas nos sprints de execução e desenvolvidas. Neste processo, alguns artefatos técnicos foram produzidos:

Código Fonte do Sistema: https://sites.google.com/site/rpepato/ce-245/listex3/SSG.rar?attredirects=0&d=1 Documentação do Sistema: https://sites.google.com/site/rpepato/ce-245/listex4/app.zip?attredirects=0&d=1

Documentação da Plataforma Ruby On Rails: https://sites.google.com/site/rpepato/ce-245/listex4/api.zip?attredirects=0&d=1

No momento de geração da documentação do sistema, a utilização da plataforma Ruby On Rails se mostrou um componente facilitador do trabalho pois esta é capaz de gerar documentação em um formato padrão (html) a partir de comentários no código da aplicação. Para geração da documentação da aplicação foi utilizado o comando rake doc:app e para geração da documentação da plataforma, foi utilizado o comando rake doc:rails. Rake é um aplicativo automatizador de tarefas para a plataforma RubyOnRails, similar aos aplicativos makefile para linguagem C e ant para plataforma Java.

Após a construção e testes unitários e funcionais do sistema, ele foi disponibilizado para uso nas dependências do ITA. A visão completa dos instantâneos do sistema, encontra-se disponível em

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxycGVwYXRvfGd4OjM4Z TEzZTcxNmEyYjlmMGM

3 - Conclusão

3.1 CE-240: Projetos de Sistemas de Banco de Dados

Durante o período letivo da disciplina CE-240 (Projetos de Sistemas de Banco de Dados), este autor obteve contato com diversas técnicas direcionadas à contextualização, modelagem, normalização, dicionariazação e implementação de aplicativos de banco de dados.

A realização de atividades de maneira colaborativa, conforme preconizado pelo framework de processo ágil SCRUM aplicado parcialmente em sala de aual, foi possível perceber que as adaptações necessárias no decorrer do projeto puderam ser executadas sem prejuízo das entregas pelas quais o grupo se comprometeu. Durante a execução dos trabalhos, os pilares de colaboração, inspeção e transparência ficaram evidentes.

Os tópicos abaixo caracterizam os princpais grupos de conhecimento a que este autor foi exposto, e que pode absorver e utilizar durante seu desenvolvimento acadêmico e profissional:

Analisou soluções utilizando o método de análise APA;

Aprendeu e utilizou heurísticas sobre definição de problemas e objetivos, o que também o auxiliou na proposta de pesquisa em nível de mestrado;

Trabalhou em grupo com o objetivo de integrar bancos de dados legados; e Auxiliou a divulgação e aprendeu mais sobre os princípios do desenvolvimento ágil.

Foi apresentado e aplicou novas tecnologias, dentre elas o georreferenciamento, no desenvolvimento de um Sistema de Banco de Dados.

Finalmente, ao final do desenvolvimento do projeto final, o aluno concluiu que:

É perfeitamente possível modelar, academicamente e profissionalmente, exercícios de Jogos de Empresa, utilizando-se, inicialmente, as Técnicas e as Tecnologias de banco de dados disponíveis, e integrar essas disciplinas a outras disciplinas relacionadas ao desenvolvimento de software;

É possível utilizar as Tecnologias de banco de dados corporativos Georreferenciados, Administrativos, Operacionais e de Infra-estrutura em Cenários de Jogos de Empresa; e

A utilização de praticas do desenvolvimento ágil no ensino e aplicação de jogos de empresa são viáveis. A participação como aluno da disciplina CE240 – Projeto de Sistemas de Banco de Dados agregou uma série de novas informações, técnicas e heurísticas ao conjunto de conhecimentos deste autor, facilitando

(16)

a realização de atividades de construção de aplicativos de banco de dados, academicamente e profissionalmente.

3.2 Recomendações

A utilização do framework de processo SCRUM promoveu uma grande interação e envolvimento de alunos das disciplinas CE240 e CE245. Sugere-se a utilização de novas práticas de desenvolvimento ágil, visando ampliar o conhecimento no assunto e promover maior iteração entre alunos das várias disciplinas relacionadas como por exemplo, testes.

A realização de atividades de tunning de desempenho é frequentemente necessária em aplicativos com grande volume de dados. O autor recomenda a exposição dos alunos à técnicas para melhoria de desempenho, visando propiciar aos alunos capacitação na análise e melhoria de performance de aplicativos de banco de dados.

O autor sugere também que o tema smart grids seja estendida a outras disciplinas e que se avalie a possibilidade da utilização de ferramentas de mercado que são utilizadas especificadamente para a gerenciamento de facilities como sistemas de informação geográfica e suas extensões. Alguns exemplos dessa categoria de software são: ArcMap, ArcFM e Smallworld.

3.3 CE-245: Tecnologias da Informação

Durante a realização, como aluno, da disciplina CE245 – Tecnologias da Informação, esse aluno pode participar do desenvolvimento de um portal, construído através do framework de processo ágil SCRUM. Durante a execução do curso, pode-se observar que a adoção do SCRUM, promovida pelo professor da turma e alguns alunos entusiastas foi bem aceita pelo grupo de alunos. Nem todas as cerimônias de SCRUM foram realizadas, mas os seus princípios e valores estiveram presentes e foram utilizados durante todo o desenvolvimento da disciplina, resultando em um produto iterativo e de valor agregado. O desenvolvimento do produto de software resultado dos exercícios aplicados na disciplina se deu através da utilização da plataforma RubyOnRails que forneceu uma arquitetura de desenvolvimento consistente, de alta produtividade e de fácil aprendizado. Este autor pode perceber que a escolha de uma tecnologia de simples implementação foi determinante para obtenção de êxito na implantação do sistema. A utilização de um tema de projeto focado em redes inteligente (smart grids) como objeto de ensino se mostrou um tema muito interessante pois, apesar de contextualmente simples, possui implementação complexa e permitiu uma série de desdobramentos técnicos permitindo a esse autor discutir ideias com os colegas de turma e realizar um diverso número de implementações distintas, agregando novos conhecimentos.

A utilização de métodos ágeis para desenvolvimento de software se mostrou fundamental para atender ao cenário de mudanças de requisitos proposto na disciplina. A iteração entre alunos e professores foi constante e permitiu a esse autor um desenvolvimento de competências técnicas e inter-pessoais (comunicação, negociação, etc).

3.4 Recomendações

Esse autor constatou que a implementação de boas técnicas da engenharia de software aliada a boas práticas da gestão ágil de projetos trouxe benefícios durante a execução das listas de exercícios e portanto recomenda a utilização de novas práticas que possam facilitar a integração desta com outras disciplinas. Algumas práticas sugeridas para implementação no próximo período letivo desta disciplina são: Testes Unitários Automatizados, Estórias de Usuário (User Storiers), Programação em Par e Integração Contínua.

A utilização da plataforma RubyOnRails foi bem recebida pelos alunos que realizaram a disciplina. Sugere-se que, nos próximos desenvolvimentos de aplicativos baseados em internet (aplicativos web), seja considerado o aprofundamento na utilizaçãodesta tecnologia, ou na utilização de linguagens dinâmicas e tecnologias similares como por exemplo: linguagem python e framework django ou linguagem groovy e framework grails.