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