Individual 4º Sem
-
Upload
adrianomachado -
Category
Documents
-
view
7 -
download
0
description
Transcript of Individual 4º Sem
Canoas2015
ADRIANO DA SILVA MACHADO
SISTEMA DE ENSINO PRESENCIAL CONECTADOANALISE E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO
GESTÃO DO PROCESSO DE DESENVOLVIMENTO I
Canoas2015
GESTÃO DO PROCESSO DE DESENVOLVIMENTO I
Trabalho de Fundamentos da Informação apresentado à Universidade Norte do Paraná – UNOPAR.
ADRIANO DA SILVA MACHADO
SUMÁRIO
2 INTRODUÇÃO...........................................................................................3
4. DESENVOLVIMENTO...............................................................................5
4.1.1 Gerenciamento de Riscos.......................................................................5
7. CONCLUSÃO........................................................................................................36
8. Bibliografia ........................ ........................................................... ......................14
2 INTRODUÇÃO
O desenvolvimento de software é uma atividade complexa,
envolvendo inúmeros fatores que não raro são imprevisíveis e de difícil controle,
como inovações tecnológicas e mudanças constantes nos requisitos do cliente
dentre muitos outros. Esta complexidade faz com que grande parte dos projetos de
desenvolvimento de software exceda o prazo e o orçamento previstos, além de não
atender às expectativas do cliente em termos de funcionalidades e qualidade. Diante
deste cenário, um gerenciamento eficaz tem-se evidenciado como de fundamental
importância para o sucesso de projetos de software. Neste trabalho em específico
vamos discorrer sobre as áreas de risco, escopo, fornecedores e partes
interessadas conforme o guia PMBOK.
3
3. OBJETIVO
Este trabalho tem por objetivo ampliar o conhecimento sobre o uso de frameworks no ambiente Java, conhecer algumas áreas segundo o guia PMBOK e entender a visão do autor Ian Sommerville, mais especificamente a respeito dos capítulos 11, 12, 13 e 29 da oitava edição do livro engenharia de software.
4
4.DESENVOLVIMENTO
4.1.1 Gerenciamento de Riscos
O Gerenciamento de Riscos no PMBOK descreve o conhecimento e
as melhores práticas em gerenciamento de projetos. De acordo com o PMBOK, o
conhecimento necessário para gerenciar projetos está dividido em nove áreas:
Gerência de Integração, Gerência de Escopo, Gerência de Tempo, Gerência de
Custo, Gerência de Qualidade, Gerência de Recursos Humanos, Gerência de
Comunicação, Gerência de Riscos e Gerência de Aquisições. A gerência de riscos
do projeto inclui os processos referentes ao planejamento da gerência de riscos, à
identificação, à análise, ao planejamento das respostas e ao controle e à
monitoração dos riscos em um projeto. Esses processos interagem entre si e com os
processos das outras áreas do conhecimento. Os objetivos da gerência de risco são
aumentar a probabilidade de ocorrência e os impactos de eventos positivos e
diminuir a probabilidade e os impactos dos eventos adversos aos objetivos do
projeto. Os processos da gerência de risco são [PMBOK, 2000]:
• Planejamento da gerência de riscos: planejar as atividades de
gerência de risco a serem realizadas para o projeto.
• Identificação dos riscos: identificar os riscos que podem afetar o
projeto, documentando suas características.
• Análise qualitativa dos riscos: analisar qualitativamente os riscos,
priorizando seus efeitos no projeto.
• Análise quantitativa dos riscos: mensurar a probabilidade de
ocorrência dos riscos e suas consequências e estimar as implicações no projeto.
• Planejamento da resposta aos riscos: gerar procedimentos e
técnicas para avaliar oportunidades, objetivando mitigar as ameaças no projeto.
• Monitoração e controle dos riscos: monitorar os riscos residuais,
identificar novos riscos, executar os planos de mitigação de riscos e avaliar sua
efetividade durante todo o ciclo de vida do projeto.
5
4.1.2 Escopo
De acordo com o PMBOK o gerenciamento de escopo é composto
dos processos para garantir que o projeto inclua todo o trabalho exigido, para assim
completar o projeto com eficiência e atender os requisitos.
A finalidade do escopo é servir como um guia do projeto, um passo a
passo, fazendo com que o projeto atenda o que foi solicitado e mostrando o que é
necessário e desnecessário ao mesmo. O escopo deve ser criado para dar suporte a
finalidade e necessidade do projeto. O escopo deverá ser projetado e para tal
gerente e equipe de projeto precisam ter uma visão única sobre quais são os
componentes do projeto e dos requisitos e as expectativas dos estakeholders.
4.1.3 Fornecedores
De posse de propostas de fornecedores para o que é necessário
para a realização do projeto, o gerente deve analisar as mesmas para adequar
expectativas, qualidade, custos necessários e valores agregados.
Isso pode levar ao resultado total de quanto o projeto custaria para
ser realizado. Este ainda pode ser a soma de valores de entregas individuais do
projeto, quando subprodutos do projeto devem ser desenvolvidos de forma
independente
4.1.4 Partes interessadas
Segundo o Guia PMBOK®, identificar as partes interessadas é o
processo de identificação de todas as pessoas ou organizações que podem ser
afetadas pelo projeto e documentação das informações relevantes relacionadas aos
seus interesses, envolvimento e impacto no sucesso do projeto.
Esse talvez seja o processo mais crítico do gerenciamento do
projeto, pois, descobrir as partes interessadas e escutá-las de forma efetiva no
início, trará um maior comprometimento, maior clareza de requisitos e objetivos e
consequentemente, menos mudanças no decorrer do projeto.
O gerenciamento de projeto deve conectar as partes interessadas maximizando as
influências positivas e minimizando as resistências, o que implicará em uma maior
probabilidade de aceitação das entregas.
Um erro não tão raro é descobrir partes interessadas importantes do projeto após o
planejamento, ocasionando em várias mudanças solicitadas e grande resistência em
6
relação ao projeto.
5. Resenha Capítulo 11 Engenharia de Software Ian Sommerville
O projeto de arquitetura envolve descrição de elementos
arquiteturais dos quais os sistemas serão construídos, interações entre esses
elementos, padrões que guiam suas composições e restrições sobre estes padrões.
Define os componentes de software, suas propriedades externas... baseando na
teoria de Hofmeister et al (Hofmeister, et al.,2000) Arquitetura de sistema pode afeta
o desempenho, mas também facilita a distribuição, manutenção de um sistema
(Bosch,2000). Existe o Diagrama de blocos de um sistema de controle robotizado de
empacotamento muito utilizado e recomendado, mas baseando-se em outras teorias
os diagramas padrões de caixas e linhas não são representações úteis de
arquitetura.
11.1 Decisões de projeto de arquitetura
A decisões de projeto de arquitetura apresenta um conjunto de
informações que podem subsidiar decisões de um projeto arquitetural de sistemas. É
de suma importância em um projeto de arquitetura, pois um projetista desenvolve
um projeto considerando um conjunto de decisões de projeto. Para tomar decisões,
ele leva em conta os requisitos arquiteturais que motivam e justificam suas decisões.
Os modelos de arquitetura são baseados em modelos de acordo com estilo ou com
estilos arquiteturais genéricos, contudo o processo de projeto de arquitetura incluir
representação que abordar módulos com estruturas gráficas.
11.2 Organização de sistema
A organização de um sistema existe um conjunto de técnicas que tem
como objetivo principal aperfeiçoar o funcionamento das organizações. Existem
7
estilos organizacionais que ajudam a ter uma visão mais ampla podendo ser usados
separadamente, ou juntos.
11.2.1 O modelo de repositório
Os sistema devem trocar informações de modo que possam trabalhar
juntos, e existem duas formas na qual isso pode ser feito.
Mantendo os dados compartilhados em um bando de dados, ou cada sistema
mantém seu próprio banco de dados.
11.2.2 O modelo cliente-servidor
O modelo de cliente-servidor é baseado em uma aplicação distribuída,
esse modelo é responsável por distribuir tarefas e cargas de trabalho entre os
fornecedores de um recurso ou serviço. Eles se comunicam geralmente através
de servidores, por meio de chamadas remotas usando protocolo como o
famoso http que é usado no sistema Web. Este modelo é atualmente o
predominante nas redes informáticas.
11.2.3 O modelo em camadas
Esse modelo é responsável por organizar um sistema em formato de
camadas, conhecido também como maquina abstrata referência de um modelo
de camada é o de 3 camadas, camada de apresentação, camada de dados e a
camada de negócio, tendo isso as alterações (atualizações e correções de
defeitos) de interface podem ser realizadas sem o comprometimento das
informações contidas em um banco de dados.
11.3 Estilos de decomposição modular
A decomposição modular define outro nível de estruturação da
arquitetura, em que os subsistemas são decompostos em módulos ou unidades que
comporão o projeto. Lembrando que um módulo oferece um ou mais serviços a
outros módulos, usa serviços de outros módulos e podem conter componentes mais
simples (ex.: rotinas, funções, métodos e objetos) um subsistema é também um
sistema e é independente dos serviços prestados por outros subsistemas. Um
módulo é um componente do sistema que provê serviços para outros componentes,
8
mas não é considerado um sistema separado.
11.3.1 Decomposição orientada a objetos
O sistema é decomposto de acordo com conceitos abstratos
encontrados no problema e é visto como uma série de agentes autônomos (os
objetos) que colaboram entre si para atingir um objetivo. O sistema é decomposto
em objetos que interagem por meio de troca de mensagens.
11.3.2 Pipelining orientado a funções
Decompõe o sistema em módulos funcionais que aceitam os dados
de entrada e transforma-os em dados de saída.
Vantagens:
- Apoia o reuso de transformações;
- Intuitiva (entrada/saída);
- Evolução do sistema pela adição de novas transformações,
geralmente é direta;
- Simples de ser implementada tanto quanto um sistema concorrente
ou sequencial.
Desvantagens:
- Necessita de um formato comum para as transferências de dados
para que possa ser reconhecido por todas as transformações;
- Não é adequado para sistemas interativos.
11.4 Modelos de Controle
Diferente do modelo de decomposição de sistema, os modelos de
controle estão relacionados ao fluxo de controle entre subsistemas.
11.4.1 Controle centralizado
Um subsistema tem responsabilidade global pelo controle, e inicia e
para outros sistemas. Um subsistema de controle é responsável pelo
gerenciamento da execução de outros subsistemas.
11.4.2 Sistemas orientados a eventos
Dirigidos por eventos gerados externamente onde o timing dos
eventos está fora do controle dos subsistemas que processam o evento. Dois
modelos dirigidos a eventos principais: Modelos de broadcast - Um evento é
transmitido a todos os subsistemas, qualquer subsistema programado para
9
manipular esse evento pode responder a ele.
Modelos orientados a interrupções: - Usado em sistemas de tempo
real onde as interrupções são detectadas por um tratador de interrupções e
passadas por algum outro componente para processamento. Outros modelos
dirigidos a eventos incluem sistemas de planilhas e de produção.
11.5 Arquiteturas de referência
Os modelos de arquitetura podem ser específicos para algum
domínio de aplicação. Existem dois tipos de modelos de domínio específico:
Modelos genéricos, que são abstrações de uma série de sistemas reais que
englobam as características principais desses sistemas.
Modelos de referência são mais abstratos, é um modelo
idealizado, fornece um meio de informação sobre essa classe de sistema e
sobre comparação de arquiteturas diferentes. Os modelos genéricos são
geralmente modelos bottom-up, os modelos de referência são modelos top-
down.
6. Resenha Cap. 12 engenharia de software Ian sommerville
12.1 Arquitetura de multiprocessadores
É um dos modelos de sistemas distribuídos mais simples, que
consiste em uma série de processos que podem ou não ser processados
por processadores diferentes, é bastante comum em sistemas de grande
porte que são executados em tempo real.
12.2 Arquiteturas cliente-servidor
Consiste em conjuntos de serviços que são oferecidos ao
cliente. No caso, cliente e o servidor (sistema que oferece os serviços) são
tratados de maneira diferente.
A arquitetura cliente-servidor é um modelo que separa os
clientes e os servidores. Neste modelo, as partes são interligadas entre si,
geralmente utilizando-se uma rede de computadores.
Cada objeto de um cliente pode enviar requisições de dado para
algum dos servidores conectados e esperar pela resposta. Por sua vez, os
servidores disponíveis podem aceitar tais requisições, processá-las e
retornar o resultado para o cliente. Apesar do conceito ser aplicado em
10
diversos usos e aplicações, a arquitetura é praticamente a mesma.
Muitas vezes os clientes e servidores se comunicam através de
uma rede de computador com hardwares separados, como no caso de um
sistema web, mas também o cliente e servidor podem residir no mesmo
local. Um cliente não compartilha de seus recursos, mas solicita o conteúdo
de um servidor ou função de serviço. Os clientes, portanto, iniciam sessões
de comunicação com os servidores que esperam as solicitações de
entrada.
A característica de cliente-servidor, descreve a relação de
programas em um aplicativo. O componente de servidor fornece uma
função ou serviço a um ou muitos clientes, que iniciam os pedidos de
serviços.
Por exemplo, um navegador da web é um programa cliente em
execução no computador de um usuário que pode acessar informações
armazenadas em um servidor web na Internet. Um outro exemplo seria
algum usuário de serviços bancários de algum banco, como o Itaú ou Caixa
Econômica Federal, acessando de seu computador via um navegador da
Web (aplicativo-cliente), como o Firefox ou Google Chrome para enviar uma
solicitação para um servidor web do banco (servidor).
Cada instância de software do cliente pode enviar requisições de
dados a um ou mais servidores ligados. Por sua vez, os servidores podem
aceitar esses pedidos, processá-los e retornar as informações solicitadas
para o cliente. Embora este conceito possa ser aplicado para uma
variedade de razões para diversos tipos de aplicações, a arquitetura
permanece fundamentalmente a mesma.
12.3 Arquiteturas de objetos distribuídos
É um conjunto de objetos distribuídos que interagem entre si e
não há distinção entre um provedor de serviços de um usuário desses
serviços. No modelo cliente-servidor de um sistema distribuído os clientes
recebem serviços dos servidores e não de outros clientes. Os objetos
podem ser distribuídos por uma série de computadores e se comunicam
através de middleware e este mesmo é chamado de requisitor de objetos.
11
12.3.1 Corba
CORBA (abreviado de Common Object Request Broker
Architecture) é a arquitetura padrão criada pelo Object Management Group
para estabelecer e simplificar a troca de dados entre sistemas distribuídos
heterogêneos. Em face da diversidade de hardware e software que
encontramos atualmente, a CORBA atua de modo que os objetos
(componentes dos softwares) possam se comunicar de forma transparente
ao usuário, mesmo que para isso seja necessário interoperar com outro
software, em outro sistema operacional e em outra ferramenta de
desenvolvimento. CORBA é um dos modelos mais populares de objetos
distribuídos, juntamente com o DCOM, formato proprietário da Microsoft. O
padrão CORBA foi desenvolvido para facilitar a comunicação entre
diferentes plataformas.
12.4 Computação interorganizacional distribuída
Por motivos de proteção e interoperabilidade, a computação foi
implementada inicialmente em nível organizacional. Uma organização tem
uma serie de servidores e distribui a sua carga computacional entre eles.
Devido ao fato de eles estarem todos localizados dentro da mesma
organização, podem ser aplicados padrões e processos operacionais
locais. Embora, para sistemas baseados na Web, os computadores clientes
estejam muitas vezes fora dos limites da organização, sua funcionalidade é
limitada a executar um software de interface com o usuário.
12.4.1 Arquiteturas ponto a ponto
Peer-to-peer (do inglês par-a-par ou simplesmente ponto-a-ponto,
com sigla P2P) é uma arquitetura onde cada um dos pontos ou nós da rede
funciona tanto como cliente quanto como servidor, permitindo
compartilhamentos de serviços e dados sem a necessidade de um servidor
central. As redes P2P podem ser configuradas em casa, em Empresas e
ainda na Internet. Todos os pontos da rede devem usar programas
compatíveis para ligar-se um ao outro. Uma rede peer-to-peer pode ser
usada para compartilhar músicas, vídeos, imagens, dados, enfim qualquer
coisa com formato digital.
Os Peers são os participantes da rede igualmente privilegiados na
aplicação. Essa aplicação tem suas tarefas ou cargas dividas em pares.
12
Cada computador da rede é um nó (ponto de interconexão da rede) e fica
responsável por uma parcela dos recursos da rede, tais como
armazenamento, poder de processamento e largura de banda. Os recursos
são divididos diretamente entre cada participante da rede sem a
necessidade de uma coordenação central de um servidor ou hosts. Nesse
modelo de rede, cada par de computadores são fornecedores e
consumidores de recurso, diferentemente do modelo cliente-servidor, onde
o servidor alimenta toda a rede e os clientes somente consomem. Os novos
sistemas P2P estão indo além do compartilhamento entre pares, estão
buscando pares diferentes que podem trazer recursos, capacitando os
pares individuais para realizarem tarefas maiores, mas que são de
benefícios de todos os pares. Esse tipo de arquitetura de rede é muito
conhecido pelo compartilhamento de ficheiros. No entanto as redes P2P
são utilizadas para outras áreas, tais como, armazenamento distribuídos
em meios acadêmico e científico e telecomunicações, por exemplo.
12.4.2 Arquitetura de sistema orientada a serviços
É um estilo de arquitetura de software cujo princípio fundamental
prega que as funcionalidades implementadas pelas aplicações devem ser
disponibilizadas na forma de serviços. Frequentemente estes serviços são
conectados através de um "barramento de serviços" (enterprise service bus,
em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de
web services ou outra forma de comunicação entre aplicações. A
arquitetura é baseada nos princípios da computação distribuída e utiliza o
paradigma request/reply para estabelecer a comunicação entre os sistemas
clientes e os sistemas que implementam os serviços.
Além da perspectiva estritamente técnica, a arquitetura orientada a
serviços também se relaciona com determinadas políticas e conjuntos de
"boas práticas" que pretendem criar um processo para facilitar a tarefa de
encontrar, definir e gerenciar os serviços disponibilizados.
A arquitetura orientada a serviços também se insere em um
processo de reorganização dos departamentos de tecnologia da informação
das organizações, permitindo um melhor relacionamento entre as áreas que
dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio
propriamente dito, graças a maior agilidade na implementação de novos
13
serviços e reutilização dos ativos existentes.
7 – Resenha Cap 13, engenharia de software Ian Sommerville
13. Arquiteturas de aplicações
13.1 Sistema de processamento de dados
São Aplicações voltados a dados, onde as mesmas processam
dados em lotes sem intervenções explicitas do usuário durante o
processamento. As Ações explicitas tomadas pela aplicação dependem dos
dados que são processados. Os sistemas de processamento em lotes são
normalmente usados em aplicações de negócios nas quais as operações
similares são realizadas sobre uma grande quantidade de dados. Eles
tratam de uma grande variedade de funções administrativas, como folha de
pagamento, cobrança, contabilidade e publicidade. Essas aplicações
enfocam os dados. Os bancos de dados são geralmente maiores que os
sistemas de informações (SI).
Os sistemas de processamento de dados selecionam os dados de
registros de entrada e, dependendo do valor dos campos nos registros,
tomam algumas ações especificadas no programa. Eles podem, então,
enviar o resultado novamente do processamento ao banco de dados e
formatar a entrada e a saída processada para impressão.
Os sistemas de processamento de dados possuem 3 componentes
principais:
1 Entrada: A entrada coleta as entradas de uma ou mais fontes.
2 Processamento: O processamento realiza a computação usando
essas entradas.
3 Saída: A saída gera Saídas a serem escritas novamente no banco
de dados e ou impressas.
Os componentes de entrada, processamento e de saída podem ser
decompostos ainda em uma estrutura entrada-processamento-saída.
Exemplo:
Um componente de entrada pode ler algum dado de um arquivo ou
banco de dados (entrada) e corrigir alguns erros (processo) e depois
enfileirar os dados validos para processamento (saída)
São sistemas orientados a funções, pois os registros e as
14
transações são processados em série, sem necessidade de manter o
estado entre as transações.
13.2 sistemas de processamento de transações
Os sistemas de transações são projetados para processar
solicitações de informações por usuários de um banco de dados.
Tecnicamente uma sequência de operações é tratada como uma unidade
simples (uma unidade atômica). Todas as operações têm que ser
realizadas antes que as mudanças se tornem permanentes no banco de
dados.
Os sistemas de processamento de transações são geralmente
sistemas interativos nos quais os usuários enviam solicitações assíncronas
de serviço. Primeiro um usuário faz uma solicitação para o sistema através
de um componente de processamento de entrada/saída. A solicitação é
processada por alguma lógica especifica da aplicação. Uma transação é
criada e passada para um gerenciador de transações, que é em geral
incorporado ao sistema de gerenciamento de banco de dados. Depois que
o gerenciador de transações assegurar que a transação foi concluída
adequadamente, ele sinalizara para a aplicação que o processamento foi
finalizado.
A estrutura entrada-processo-saída se aplica aos muitos sistemas de
processamento de transações. Alguns desses sistemas são versões
interativas de sistemas de processamento de lotes.
Um exemplo de sistema de processamento de transações é um
sistema bancário que permite aos clientes consultarem suas contas e
retirarem dinheiro de um caixa eletrônico. O sistema é composto de dois
subsistemas de software que cooperam entre si – o software de caixa
eletrônico e o software de processamento de contas localizadas no servidor
de banco de dados. Os subsistemas de entrada e de saída são
implementados como softwares no caixa eletrônico, uma vez que o
subsistema de processamento está no servidor de banco de dados.
Em sistemas como os de contabilidade de clientes de um banco,
pode haver diferentes maneiras de interagir com o sistema. Muitos clientes
interagirão por meio de caixas eletrônicos, mas uma equipe do banco usara
terminais de mesa para acessar o sistema. Pode haver vários tipos de
15
caixas eletrônicos e terminais de mesa, e alguns clientes e a equipe do
banco podem acessar os dados de contas por meio de navegadores WEB.
Para simplificar o gerenciamento de diferentes protocolos de
comunicação entre terminais, sistemas de processamento de transações de
larga escala podem incluir middleware para comunicação com todos os
tipos de terminal, organização e ordenação em serie dos dados dos
terminais e envio dos dados para processamento.
13.2.1 Sistemas de gerenciamento de informações e recursos
Um sistema de informações permite acesso controlado de uma
grande base de informações, tais como catalogo de bibliotecas, tabela de
horários de voos ou registros de pacientes em um hospital. O
desenvolvimento da WEB fez com que um grande número de sistemas de
informações migrasse de sistemas organizacionais especializados para
sistemas de propósito geral acessíveis universalmente.
O sistema de informação é modelado com o uso de uma abordagem
de camadas ou de máquina abstrata na qual a camada superior apoia a
interface com o usuário e a camada inferior, o banco de dados de sistema.
A camada de comunicações inclui uma lógica especifica de aplicação para
acesso e atualização do banco de dados.
Sistemas de alocação de recursos são uma classe de aplicação
amplamente usada, sua arquitetura está alinhada com o modelo de sistema
de informações. Os componentes de um sistema de alocação de recursos
incluem:
1- Um banco de dados de recursos que mantém detalhes de
recursos que são alocados. Os recursos podem ser adicionados ou
removidos do banco de dados.
2- Um conjunto de regras que descreve as regras de alocação de
recursos.
3- Um componente de gerenciamento de recursos que permite que o
provedor de recursos adicione, edite ou elimine recursos do sistema.
4- Um componente de alocação de recursos que atualiza o banco de
dados de recursos quando eles são designados e que associam esses
recursos a detalhes do solicitante do recurso.
5- Um modulo de autenticação de usuários que permite ao sistema
16
verificar se os recursos estão sendo alocados para um usuário reconhecido.
6- Um modulo de gerenciamento de consultas que permite ao
usuário descobrir quais recursos estão disponíveis.
7- Um componente de entrega de recursos que prepara os recursos
a serem entregues ao solicitante. Em um sistema de emissão de ingressos,
isso pode envolver a preparação de uma confirmação por e-mail, o envio de
uma solicitação para uma impressora que imprime os ingressos e os
detalhes de para onde os ingressos devem ser enviados.
8- Um componente de interface com o usuário que está fora do
sistema e permite ao solicitante do recurso enviar consultas e solicitações
para o recurso a ser alocado.
13.3 Sistemas de processamento de eventos
Os sistemas de processamento de eventos respondem aos eventos
do ambiente ou da interface com o usuário do sistema. A principal
característica dos sistemas de processamento de eventos é que a
sequência de eventos é imprevisível e o sistema deve ser capaz de
trabalhar com esses eventos quando eles ocorrerem.
Sistemas de tempo real, são também sistemas de processamento
baseados em eventos, porem ao invés de ter eventos de interface com o
usuário, tem eventos associados a sensores e atuadores do sistema.
13.4 Sistemas de processamento de linguagens
Os sistemas de processamento de linguagens aceitam uma
linguagem natural ou artificial como entrada e geram alguma outra
representação dessa linguagem como saída. Em engenharia de software,
os sistemas de processamento de linguagens mais amplamente usados
são os compiladores que traduzem uma linguagem artificial de
programação de alto nível em código de máquina. Mais outros sistemas de
processamento de linguagens traduzem uma descrição de dados XML em
comandos para consultar um banco de dados e sistemas de
processamento de linguagem natural que tentam traduzir uma linguagem
em outra.
Os tradutores em um sistema de processamento de linguagens têm
uma arquitetura genérica que inclui os seguintes componentes:
1. Um analisador léxico, que obtém elementos da linguagem de
17
entrada e os converte em um formato interno.
2. Uma tabela de símbolos que mantém informações sobre os
nomes de entidades (variáveis, nomes de classes) usadas no texto que
está sendo traduzido.
3. Um analisador sintático, que verifica a sintaxe da linguagem que
está sendo traduzida. Ele usa uma gramática definida de linguagem e
constrói uma arvore de sintaxe.
4. Uma árvore de sintaxe, que é uma estrutura interna que
representa o programa que está sendo compilado.
5. Um analisador semântico, que usa informações da árvore de
sintaxe e da tabela de símbolos para verificar a correção sintática do texto
da linguagem de entrada.
6. Um gerador de código que ‘caminha’ pela árvore de sintaxe e gera
o código de máquina abstrata.
8- Capítulo 29, Gerenciamento de configurações engenharia de software Ian
Sommerville
29.1 Planejamento de gerenciamento de configurações
Gerência de Configuração ou ainda Gestão de Configuração de
Software é uma área da engenharia de software responsável por fornecer o
apoio para o desenvolvimento de software. Suas principais atribuições são
o controle de versão, o controle de mudança e a auditoria das
configurações.
Em outras palavras, a Gerência de Configuração de Software tem
como objetivo responder as seguintes perguntas:
O que mudou e quando?
Por que mudou?
Quem fez a mudança?
Podemos reproduzir esta mudança?
Cada uma dessas perguntas corresponde a uma das atividades
realizadas pela Gerência de Configuração de Software. O controle de
versão é capaz de dizer o que mudou e quando mudou. O controle de
mudanças é capaz de atribuir os motivos a cada uma das mudanças. A
Auditoria por sua vez responde as duas últimas perguntas: Quem fez a
18
mudança e podemos reproduzir a mudança?
29.1.1 IDENTIFICAÇÃO DE ITEM DE CONFIGURAÇÃO
O termo item de configuração ou IC é a qualquer componente que
necessita ser configurado com o objetivo de se entregar um serviço de TI
Refere-se à unidade estrutural fundamental de um sistema de
gerenciamento de configuração.
Os ICs normalmente incluem serviços de TI, hardware, software,
pessoas e documentações formais, como documentação de processos e
ANSs.
Exemplos de itens de configuração incluem documentos de
requisitos individuais, software, modelos e planos. O sistema de
gerenciamento de configuração supervisiona a vida dos ICs, através de
uma combinação de processos e ferramentas, implementando e habilitando
os elementos fundamentais de identificação, gerenciamento de mudanças,
contabilidade, status e auditorias. O objetivo deste sistema é o de evitar a
introdução de erros relacionados com a falta de testes, bem como
incompatibilidades com outros ICs.
Durante o desenvolvimento de software, uma grande quantidade de
informações é produzida e cada um desses documentos produzidos que
precisam sofrer controle de versões e de mudanças é chamado de item de
configuração de software O Item de configuração é um elemento unitário
que será gerenciado: um arquivo de código fonte, um documento de texto,
um projeto de uma placa eletrônica, uma planta feita em papel, um CD-
ROM de instalação de um sistema operacional, etc. A configuração de um
sistema é basicamente a lista de todos os itens de configuração
necessários para reproduzir um determinado estado de um sistema. Em
geral números de versão são associados aos itens de configuração de
forma a podermos identificar também a evolução destes itens.
29.1.2 BANCO DE DADOS DE CONFIGURAÇÃO
Um banco de dados de configuração (BDC) é um repositório de
informações relacionadas a todos os componentes de um sistema de
informação. Ele contém os detalhes dos itens de configuração (IC) na
infraestrutura de TI. Apesar de repositórios similares aos BDCs terem sido
utilizados por departamentos de TI durante muitos anos, o termo BDC
19
resulta da ITIL. No contexto da ITIL, um BDC representa a configuração
autorizada dos componentes significativos do ambiente de TI. Um BDC
ajuda uma organização a entender os relacionamentos entre estes
componentes e acompanhar suas configurações. O BDC é um componente
fundamental do processo de gerenciamento de configuração do framework
ITIL. As implementações de BDCs geralmente envolvem associação, a
inclusão de dados no BDGC de outras fontes, como gerenciamento de
ativos, de tal forma que a fonte dos dados retenha o controle dos dados.
Associação normalmente é distinta de soluções de extração, transformação
e carga, nas quais os dados são copiados no BDC.
O BDC registra os ICs e os detalhes sobre os atributos importantes e
os relacionamentos entre ICs. Gerentes de configuração normalmente
descrevem ICs usando três atributos configuráveis:
Técnico
Propriedade
Relacionamento
Um fator chave de sucesso na implementação do BDC é a
habilidade de descobrir automaticamente informações sobre os ICs
(autodescoberta) e acompanhar as mudanças quando elas ocorrerem.
BDCs contém metadados e, desta forma, o conceito coincide com o
de repositório de metadados os quais são ambos utilizados nas
organizações de TI de ampla administração. O gerenciamento de
configuração trata de como os dados permanecerão atualizados, o que
historicamente tem sido uma fraqueza dos repositórios de metadados. Um
banco de dados de configuração armazena informações sobre itens de
configuração e referencia seus nomes num sistema de gerenciamento de
versão ou depósito de arquivos.
29.2 Gerenciamento de mudanças
Gerência de mudanças, é uma parte importante da Gerência de
configuração, pois é a atividade que permite se saber o motivo de uma
configuração ter sido mudada para outra configuração. Esta atividade
também pode ser parcialmente automatizada, e diversos Sistemas de
controle de versão já são integrados com sistemas de gerência de
mudanças. A gerência de mudanças tem por objetivo mapear, para cada
20
mudança efetuada no sistema, qual foi o motivo que gerou esta mudança. É
comum vermos em sistemas de software arquivos que listam as melhorias
e mudanças entre duas versões. Estes arquivos são resultado da gerência
de mudanças, identificando o que mudou entre uma versão e outra.
29.3 Gerenciamento de versões e releases
Controle de Versão resolve diversos problemas básicos de
desenvolvimento tais como uso de diferentes versões de código,
sincronização do trabalho paralelo de desenvolvedores no mesmo projeto,
recuperação de versões anteriores e registro do histórico de alterações.
A finalidade do Controle de versão é dar um controle maior sobre
tudo que você altera no seu projeto de software. Ele permite que você
tenha um histórico de tudo o que você mudar no seu projeto. Se você
modificou aquela rotina para otimizar uma consulta, se você inseriu uma
nova função e retirou outra, se você modificou a imagem que era exibida
em determinada página html, tudo fica guardado neste histórico. Para que
isso? Para o caso de sua alteração causar algum problema! Se deu você
nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez
tudo correto, basta um simples comando e você recupera o estado anterior.
Um release do sistema é uma versão distribuída aos clientes. Cada
release deve incorporar novas funcionalidades ou ser planejado para uma
plataforma diferente de hardware.
29.3.1 Identificação de versões
Alguns projetos precisam de variações específicas, conforme as
necessidades específicas de cada cliente, ou criação de um ramo para
experimentações no projeto, sem comprometer a linha principal de
desenvolvimento. O sistema de controle de versão oferece funcionalidades
que facilitam a coordenação de ramos diferentes de desenvolvimento em
um mesmo projeto. As alterações feitas em um ramo muitas vezes
precisam ser mescladas em outro ramo. Essa operação é bastante delicada
e é facilitada em muito com o sistema de controle de versão, que permite
bastante controle e automação no processo. Mesmo em caso de uma fusão
malsucedida, o sistema de controle de versão permite voltar ao estado
anterior, o que traz bastante segurança aos desenvolvedores.
Tipos de identificação:
21
1. Numeração de versões: O componente recebe um número
explicito e único.
2. identificação baseada em atributos: Cada componente tem um
nome e um grupo de atributos associados para cada versão.
3. identificação orientada a mudanças: Cada componente é
denominado como na identificação baseada em atributos, mas é também
associado com uma ou mais solicitações de mudanças.
29.3.2 Gerenciamento de releases
Um release de sistema é uma versão do sistema distribuído para os
clientes. A criação de um release é um processo de criação de arquivos e
documentos que inclui todos os componentes do release do sistema, o
código executável de programas e todos os arquivos de dados associados
devem ser coletados e identificados. Se os manuais a serem lidos em
computadores são distribuídos, copias eletrônicas devem ser armazenadas
com o software. Finalmente, quando todas as informações estiverem
disponíveis, o diretório do release é manipulado para a distribuição.
Quando um release de sistema é produzido, ele deve ser
documentado para assegurar que possa ser recriado no futuro. Isso é
importante para sistemas embutidos de ciclo de vida longo e feitos para os
clientes, como aqueles que controlam maquinas complexas.
Para documentar um release você deve registrar as versões
especificas dos componentes de código fonte usados para criar o código
executável. Você deve manter cópias dos códigos fonte e código
executável e de todos os arquivos de dados e de configuração, você deve
também registrar as versões do sistema operacional, as bibliotecas, os
compiladores e outras ferramentas usadas para construir o software, elas
podem ser necessárias para construir exatamente o mesmo sistema em
alguma data posterior.
29.5 Construção de sistemas
A construção de sistemas é um processo de compilação e ligação de
componentes de software num programa que executa determinada
configuração definida.
29.5 Ferramentas case para gerenciamento de configurações
Uma ferramenta CASE é sistema que suporta uma ou mais
22
atividades do processo de desenvolvimento de um software e a utilização
destas ferramentas auxilia na melhoria da construção e no aumento de
produtividade. O processo de seleção de ferramentas CASE que serão
utilizadas por uma determinada organização estão se tornando a cada dia
mais comuns. Demonstram aos desenvolvedores como será a sua estrutura
até as entidades e relacionamentos utilizados no sistema. Para que esta
escolha seja adequada é que existem estes métodos de seleção destas
ferramentas os quais orientam com maior clareza quais são os critérios a
serem avaliados trazendo consigo os inúmeros benefícios que vão desde
agilizar o processo de desenvolvimento de um software até a
documentação que pode ser gerada pela própria ferramenta. Através
processo de avaliação e seleção das ferramentas candidatas é possível se
destacar todas as funcionalidades das ferramentas que estão sendo
analisadas. Neste processo, mesmo que uma determinada ferramenta não
seja escolhida, ela poderá ser reaproveitada para processos futuros, pois
quando se realiza este processo são gerados relatórios com todas as
informações sobre as ferramentas. Durante o estudo destes métodos é
possível perceber que esta seleção de ferramentas ainda não é bem
conhecida por alguns desenvolvedores, mas a cada dia mais está se
tornando necessária a adoção destas ferramentas para que se possa
agilizar o desenvolvimento.
29.5.1 Apoio para gerenciamento de mudanças
Trata-se de ferramentas de gerenciamento de mudanças para dar
apoio, suporte aos profissionais, essas ferramentas fornecem alguns ou
todos os recursos para dar suporte ao processo.
29.5.2 Apoio para gerenciamento de versões
São ferramentas de gerenciamento de versões que controlam um
repositório de itens de configuração, no qual os conteúdos não mudam, são
imutáveis.
29.5.3 Suporte para construção de sistemas
A construção de um sistema é um processo computacional e pode
levar muito tempo, se ligados e compilados manualmente a incidência de
erros poderá ser muito grande, para isso existem ferramentas para auxiliar
neste processo.
23
9 – Comparação de frameworks para desenvolvimento web (java)
No desenvolvimento do software, um Framework (ou arcabouço) é
uma estrutura de suporte definida em que um outro projeto de software
pode ser organizado e desenvolvido. Um Framework pode incluir
programas de suporte, bibliotecas de código, linguagens de script e outros
softwares para ajudar a desenvolver e juntar diferentes componentes de um
projeto de software [Magela 2006].
Frameworks são projetados com a intenção de facilitar o
desenvolvimento de software, habilitando designers e programadores a
gastarem mais tempo determinando nas exigências do software do que
com detalhes tediosos de baixo nível do sistema.
Especificamente em orientação a objeto (que é o paradigma da
Java), Framework é um conjunto de classes com objetivo de reutilização de
um design, provendo um guia para uma solução de arquitetura em um
domínio específico de software.
9.1- Comparação dos principais frameworks
Os frameworks JSF, Grails e Spring Web MVC possuem vários
atributos em comum, como a arquitetura em MVC, utilização do padrão
Front Controller, suporte a validação e conversão de dados,
internacionalização e manipulação de erros. Neste capítulo serão
comparados algumas de suas principais características.
9.1.2 - IMPLEMENTAÇÃO DO PADRÃO MVC
No JSF a camada de controle é composta por:
· FacesServlet – recebe as requisições da WEB, redireciona-as para
o modelo e remete uma resposta.
· Arquivos de configuração - realizam associações e mapeamentos
de ações e definem as regras de navegação.
· Manipuladores de eventos – recebem os dados vindos da camada
de visualização, acessam o modelo e devolvem o resultado ao
FacesServlet.
A camada modelo é representada por objetos de negócio (Java
Beans), que executam uma lógica de negócio ao receber os dados oriundos
da camada de visualização.
24
A camada de visualização é representada por uma hierarquia de
componentes (component tree), que possibilita a união de componentes
para construir interfaces mais ricas e complexas.
Na versão 2.0 o padrão para montagem de templates é o Facelets
(extensão xhtml), mas também podem ser utilizadas outras tecnologias
como JSP e Clay.
Arquitetura JSF baseada no modelo MVC
Fonte: Pitanga
9.1.3 - Spring Web MVC
No Spring Web MVC, a camada de controle é composta por:
· DispatcherServlet – processa todas as requisições do usuário e
invoca elementos Controller apropriados.
· HandlerMapping – baseado na URL da requisição indica ao
DispatcherServlet qual é o controlador a ser invocado.
25
· HandlerAdapter – responsável por delegar a requisição para mais
processamentos.
· ViewResolver – interface que devolve ao DispatcherServlet qual
visão deve ser buscada e instanciada, baseada em seu nome e localização.
· Controlador – processa os dados e executa alguma regra de
negócio da aplicação.
Para criar um controlador em Spring 3.0 basta usar a anotação
@Controller na classe.
Muitos dos métodos das subclasses do Controller retornam um
objeto org.springframework.web.servlet.ModelandView. Esse objeto
encapsula o modelo (como um objeto java.util.Map que mantém JavaBeans
que a interface View irá compor) e o nome da visão, possibilitando retornar
ambos em um valor de retorno de um método para o Dispatcher.
A camada de visão do Spring é representada por várias tecnologias:
JSP, JSTL, Velocity, FreeMarker, JasperReport, XSLT, Tiles, PDF e Excel.
Fluxo de informações no Spring Web MVC
Fonte: Saab (2011)
9.1.4 - Grails
De acordo com Seifeddine (2009), o modelo do Grails é
representado com classes de domínio assim como os outros frameworks
apresentados, porém essas são automaticamente persistidas e podem até
mesmo gerar o esquema de dados. Grails trata as classes de domínio
26
como o componente central e mais importante da aplicação.
Grails utiliza o framework de persistência Hibernate, que provê uma
solução de mapeamento objeto-relacional (ORM – Object Relational
Mapping) para aplicações. Ao invés de construir sua própria solução ORM a
partir do zero, Grails envolveu o Hibernate em uma API Groovy, chamada
Grails Object Relation Mapping (GORM), que provê a linguagem Domain
Specific Language (DSL) que usa convenção das próprias classes para
construir o mapeamento, tornando desnecessária a utilização de arquivos
externos, como XML, no Hibernate.
Os controladores basicamente manipulam as solicitações e
preparam a resposta. Para criar um controlador em Grails basta criar uma
classe cujo nome termine com Controller e salvá-la no diretório
grails-app/controllers/.
Visões em Grails são tipicamente Groovy Server Pages (GSP) que
são uma extensão de JSP, porém mais flexíveis e convenientes para se
trabalhar, mas Grails suporta ambos os tipos. Cada visão GSP tem acesso
a um modelo que é mapeado basicamente com chaves e valores que
podem ser passados pelo controlador e usados na visão.
9.1.5 – Hibernate
O Hibernate é um framework de mapeamento objeto relacional para
aplicações Java, ou seja, é uma ferramenta para mapear classes Java em
tabelas do banco de dados e vice-versa. É bastante poderoso e dá suporte
ao mapeamento de associações entre objetos, herança, polimorfismo,
composição e coleções. O Hibernate não apresenta apenas a função de
realizar o mapeamento objeto relacional. Também disponibiliza um
poderoso mecanismo de consulta de dados, permitindo uma redução
considerável no tempo de desenvolvimento da aplicação.
10 – Relação custo/benefício no uso de frameworks
A seguir serão mostradas algumas vantagens e desvantagens no
uso de frameworks para desenvolvimento web, as vantagens do uso de
frameworks nos projetos, de acordo com Assis e Sauvê são:
• baixo tempo de codificação: devido à estrutura semi-pronta, muitas
funcionalidades necessárias já estão disponíveis;
• uso de soluções bem testadas por outras pessoas: conforme o uso
27
de framework aumenta, estes passam a adquirir maturidade ao se
descobrirem erros e adicionar novas funcionalidades;
• desenvolvedores se preocupam em implementar o que é
necessário, não é preciso que se codifique todo o software, pois se utiliza
os componentes que já estão prontos;
• menor probabilidade de erros nos códigos, com uso de
frameworks, menos linhas de código são escritas pelos programadores,
diminuindo, assim, a possibilidade de erros comuns.
Por outro lado, existem desvantagens provindas do uso de
frameworks.
De acordo com Assis e Sauvê essas desvantagens são:
• frameworks requerem pessoas especializadas: para a utilização de
um framework, deve-se possuir uma equipe com conhecimentos e para
isso, é necessário que se façam treinamentos, demandando tempo e
aumentando o prazo final para o produto;
• depuração dos programas mais difícil, se o fabricante do framework
não disponibilizar os códigos-fonte, ficará difícil de se encontrar possíveis
erros, visto que estes podem estar contidos nos objetos do framework;
• mudança do foco de desenvolvimento, os desenvolvedores têm
que assimilar ideias que, na maioria das vezes, foram propostas por
pessoas que não fazem parte da sua equipe de trabalho;
• implementação em linguagem específica, como os frameworks são
desenvolvidos em linguagens de programação específicas, perde-se
portabilidade em relação às linguagens que podem ser usadas em conjunto
com o framework, tal restrição obriga os desenvolvedores a utilizar a
mesma linguagem empregada pela solução adotada.
Feito esta análise o desenvolvedor precisará “pesar” a relação
custo/benefício e verificar se existem mais vantagens que desvantagens na
elaboração do projeto.
11 – Programação java web (plataforma de desenvolvimento)
Plataforma Java é o nome dado ao ambiente computacional, ou
plataforma, criada pela empresa estadunidense Sun Microsystems e
vendida para a Oracle depois de alguns anos. A plataforma permite
desenvolver aplicativos utilizando qualquer uma das linguagens criadas
28
para a plataforma Java, sendo a linguagem padrão a que leva seu próprio
nome: Linguagem Java. Uma grande vantagem da plataforma é a de não
estar presa a um único sistema operacional ou hardware, pois seus
programas rodam através de uma máquina virtual que pode ser emulada
em qualquer sistema que suporte à linguagem C++.
Um programa escrito para a plataforma Java necessita de dois
componentes para ser executado: a máquina virtual Java, e um conjunto de
bibliotecas de classe que disponibilizam uma série de serviços para esse
programa. O pacote de software que contém a máquina virtual e esta
biblioteca de classes é conhecido como JRE (Java Runtime Environment).
12 – Arquitetura a ser usada no projeto China Telecom
Como já foi dito na descrição do problema da China Telecon, a
melhor solução para essa empresa seria realmente adotar um software de
uma empresa especializada e com um bom suporte, mas baseado na
hipótese de a empresa querer desenvolver seu próprio software para
reduzir os custos seria necessário também reduzir o tempo de
desenvolvimento do mesmo e manter a qualidade e produtividade no
desenvolvimento, além de contar com uma equipe de profissionais
capacitados, também seria necessário adotar padrões e técnicas que irão
ajudar a desenvolver um bom sistema para a empresa. Analisando entre
os padrões existentes, é fácil chegar à conclusão que o melhor padrão para
ser adotado no desenvolvimento do software em questão seria a arquitetura
MVC.
A arquitetura MVC foi desenvolvida para ser usado em projetos de
interface visual em Smalltalk, linguagem de programação que juntamente
com o C++ ganhou grande reconhecimento na época, o MVC foi criado na
década de 70, e após esses anos de sua criação ainda é um pattern
aplicável nas mais variadas aplicações, principalmente em aplicações web.
Quando um software começa a ficar grande e complexo, muitos
dados são apresentados para os usuários, sentimos a necessidade de
aplicar uma arquitetura que facilite nosso trabalho, desde a organização do
projeto, as divisões das responsabilidades até as possíveis modificações
que poderão ser efetuadas ao longo do desenvolvimento do software para
isso precisaram dividir o projeto em três objetos para aplicar o MVC.
29
Hibernate
O Hibernate é um framework open source de mapeamento
objeto/relacional desenvolvido em Java, ou seja, ele transforma objetos
definidos pelo desenvolvedor em dados tabulares de uma base de dados,
portanto com ele o programador se livra de escrever uma grande
quantidade de código de acesso ao banco de dados e de SQL. Se
comparado com a codificação manual e SQL, o Hibernate é capaz de
diminuir 95% das tarefas relacionadas a persistência.
Vantagens do Hibernate
A utilização de código SQL dentro de uma aplicação agrava o
problema da independência de plataforma de banco de dados e complica,
em muito, o trabalho de mapeamento entre classes e banco de dados
relacional.
O Hibernate abstrai o código SQL da nossa aplicação e permite
escolher o tipo de banco de dados enquanto o programa está rodando,
permitindo mudar sua base sem alterar nada no seu código Java.
Além disso, ele permite criar suas tabelas do banco de dados de um
jeito bem simples, não se fazendo necessário todo um design de tabelas
antes de desenvolver seu projeto que pode ser muito bem utilizado em
projetos pequenos.
O Hibernate não apresenta apenas a função de realizar o
mapeamento objeto relacional. Também disponibiliza um poderoso
mecanismo de consulta de dados, permitindo uma redução considerável no
tempo de desenvolvimento da aplicação.
Ferramenta Utilizada
No caso do desenvolvimento do sistema China Telecon poderia ser
utilizada qualquer ferramenta de base Java, como Eclipse ou NetBeans. O
que vai definir a escolha de uma ferramenta seria a afinidade da equipe
com determinada ferramenta. No meu caso utilizaria o netbeans por ter
uma interface gráfica mais atraente e por suportar os diversos Frameworks
para Java.
O Netbeans é uma poderosa ferramenta de desenvolvimento Java.
30
Entre muitas melhorias, esta versão dará suporte às plataformas PHP,
JavaScript e Ajax, Ruby e Ruby em Rails, Groovy e C/C++.
O Netbeans 7 apresenta algumas melhorias comparativamente a
versões anteriores e das quais destacamos:
Suporte para o Java 7, melhorias a nível do editor, suporte para
HTML5, suporte para quebras de linha, suporte para Git 1.7.х, melhor
integração com bases de dados Oracle.
O NetBeans tem uma interface bem organizado e disponibiliza um
conjunto de funções que permitem aos programadores desenvolver
aplicações de alto nível. Considerando que a linguagem de programação
Java é uma das mais usadas actualmente, o Netbeans torna-se um
excelente IDE para desenvolvimento.
MVC é composto por três tipos de objetos. O modelo é o objeto de
aplicação, a vista é a apresentação na tela e o controlador define a maneira
como a interface do usuário reage às entradas do mesmo. Antes do MVC,
os projetos de interface para o usuário tendiam em agrupar esses objetos.
MVC para aumentar a flexibilidade e a reutilização. (GAMMA et al. 2000, p.
20).
O MVC tem como principal objetivo: separar dados ou lógicos de
negócios (Model) da interface do usuário (View) e o fluxo da aplicação
(Controller), a idéia é permitir que uma mensagem da lógica de negócios
possa ser acessada e visualizada através de várias interfaces. Na
arquitetura MVC, a lógica de negócios, ou seja, nosso Model não sabe
quantas nem quais as interfaces com o usuário estão exibindo seu estado,
a view não se importa de onde está recebendo os dados, mas ela tem que
garantir que sua aparência reflita o estado do modelo, ou seja, sempre que
os estados do modelo mudam, o modelo notifica as view para que as
mesmas se atualizem.
MVC é um conceito (paradigma) de desenvolvimento e design que
tenta separar uma aplicação em três partes distintas. Uma parte, a Model,
está relacionada ao trabalho atual que a aplicação administra outra parte a
View está relacionada a exibir os dados ou informações dessa uma
aplicação e a terceira parte, Controller, em coordenar os dois anteriores
exibindo a interface correta ou executando algum trabalho que a aplicação
31
precisa completar. (GONÇALVES, 2007, p. 141).
Model: ou modelo é a camada que contém a lógica da
aplicação, é responsável pelas regras de negócio, para sistemas
persistentes, o modelo representa a informação (dados) dos formulários e
as regras SQL para manipular dados do banco, o modelo mantém o estado
persistente do negócio e fornece ao controlador a capacidade de acessar
as funcionalidades da aplicação, o modelo é o principal responsável toda
aplicação deve representar o modelo atua isoladamente não tem
conhecimento de quais serão a ou as interfaces que terá de atualizar, o
modelo somente acessa a base de dados e deixa os dados prontos para o
controlador este por sua vez encaminha para a visão correta.
View: ou visão é a camada de apresentação com usuário, é a
interface que proporcionará a entrada de dados e a visualização de
respostas geradas, nas aplicações web é representado pelo HTML que é
mostrado pelo browser, geralmente a visão contém formulários, tabelas,
menus e botões para entrada e saída de dados. A visão deve garantir que
sua apresentação reflita o estado do modelo, quando os dados do modelo
mudam, o modelo notifica as vistas que dependem dele, cada vista tem a
chance de atualizar-se. Desta maneira permite ligar muitas vistas a um
modelo podendo fornecer diferentes apresentações, essa camada não
contém códigos relacionados a lógica de negócios, ou seja, todo o
processamento é feito pelo Modelo e este repassa para a visão,
evidenciaremos abaixo um exemplo de duas vistas atuando sobre o mesmo
modelo.
Controller: já descrevemos da view e do modelo, mas, temos de
concordar que tudo isso se tornaria uma bagunça se tivesse alguém para
organizar esta arquitetura, um controlador funciona de intermediário entre a
camada de apresentação e a camada de negócios, sua função como já diz
é controlar coordenar o envio de requisições feitas entre a visão e o
modelo. O controller define o comportamento da aplicação, o controle é
quem interpreta as solicitações (cliques, seleções de menus) feitas por
usuários com bases nestes requerimentos o controlador comunica-se com
o modelo que seleciona a view e atualiza-a para o usuário, ou seja, o
controlador controla e mapeia as ações.
32
Embora o MVC só contenha três camadas há outra camada
fundamental para o bom andamento da arquitetura, esta é um mecanismo
de eventos necessário a comunicação entre outros três elementos, este
elemento permite uma comunicação assíncrona que é invocada quando
algum evento interessante acontece, esta quarta camada contém os beans
de entidade onde se localizam os métodos get e set das classes.
Design Patterns aplicados na arquitetura MVC
A arquitetura MVC utiliza padrões de projetos em suas camadas
analisamos a arquitetura agora com os patterns.
O MVC usa outros padrões de projeto, tais como Factory Method,
para especificar por falta (by default) a classe controladora para uma vista e
Decarator, para acrescentar capacidade de rolagem (scrolling) a uma vista.
Mais os principais relacionamentos do MVC são fornecidos pelos padrões
Observer, Composite, Strategy. (GAMMA et al. , 2000, p. 22)
Os designs patterns nos ajuda a explicar a arquitetura MVC, e com
eles podemos perceber que por traz do MVC pode conter um conjunto de
padrões trabalhando juntos em uma mesma estrutura. Abordamos agora os
patterns Observer e Strategy que são padrões comportamentais e o
Composite padrão estrutural, o objetivo de abordar os patterns é para
facilitar a compreensão de como a arquitetura MVC trabalha, sabendo que
é um padrão de arquitetural que confundem projetistas e desenvolvedores.
Nas palavras de Gamma et al. os principais padrões que o
MVC utiliza são os Observer, Composite e o Strategy. Analisemos a Figura
3 do livro de Padrões de Projetos dos autores Freeman & Freeman que nos
ajudará a explicar como os padrões contribuem na arquitetura MVC:
A visualização ou a View juntamente com o padrão
Composite está à disposição do usuário esperando por qualquer evento,
quando este evento é ativado o controlador é avisado sobre o evento, este
avisa para a visão se atualizar, e ao mesmo tempo manda o modelo para
que ele atue para contemplar o evento provocado pelo usuário, depois de
atuado o modelo fica pronto para ser acessada pela visualização, esta por
sua vez, acessa e atualiza-se para o usuário assim funciona a arquitetura
MVC em conjunto com os padrões de projetos.
Utilizando essa arquitetura, o tempo de desenvolvimento do
33
software diminuirá sem perde a qualidade e sem aumento de custos.
Framework
Uma das melhores opções seria o Hibernate como framework de
persistência de dados.
O Hibernate é um framework para mapeamento objeto/relacional
em Java, que abstrai o código SQL da aplicação, permitindo, entre outras
coisas, modificar a base de dados para outro SGBD (Sistema Gerenciador
de Banco de Dados) sem modificar uma linha de código.
34
7. CONCLUSÃO
Após muita pesquisa foi possível mostrar mais sobre a linguagem java
de programação, também um estudo sobre arquitetura de software e padrões de
software e um pouco mais de experiência na resolução de um problema, neste caso
o da empresa china telecom.
35
8. REFERÊNCIAS BIBLIOGRÁFICAS
SOMMERVILLE, Ian. Engenharia de Software. 8ª. ed. Pearson Education do Brasil. São Paulo,2003.
Academia.edu, - comparativo entre frameworks. Disponível em: (http://www.academia.edu/3706845/COMPARATIVO_ENTRE_FRAMEWORKS_DE_JAVA_SERVER_FACES_APACHE_TOBAGO_PRIMEFACES_E_RICHFACES) Acesso em: 17 de abril de 2015.
Hibernate. In: hibernate. Disponível em : (http://hibernate.com.org) acesso em 11 de Maio de 2015.
blog.glaucocustodio, porque usar um framework. Disponível em: (http://blog.glaucocustodio.com/2012/07/31/porque-usar-um-framework/) Acesso em: 05 de Maio de 2015.
WIKIPEDIA, Plataforma java. Disponível em: (http://pt.wikipedia.org/wiki/Plataforma_Java) Acesso em: 10 de Maio de 2015.
Info Q, comparando o desempenho de frameworks. Disponível em: (http://www.infoq.com/br/news/2014/06/benchmark-web-framework) Acesso em: 19 de Abril de 2015.
36