Embed Size (px)
DESCRIPTION
trabalho Unopar Portfolio 5 Semestre 2015 China Telecom.
Citation preview
xx-xx2015
XXX
SISTEMA DE ENSINO PRESENCIAL CONECTADOCURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E
DESENVOLVIMENTO DE SISTEMAS
TRABALHO INDIVIDUAL 5º SEMESTRE
xx-xx2015
TRABALHO INDIVIDUAL 5º SEMESTRE
Trabalho de Análise e Desenvolvimento de Sistemas apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina De Projeto Orientado a Objetos, Engenharia e Projeto de Software, Programação para Web II.
Orientador: Márcio Roberto Chiaveli,Luis Claudio Perini,Marco Ikuro Hisatomi,Veronice de Freitas.
XXXXXXXXXX
SUMÁRIO
Conteúdo1 INTRODUÇÃO 3
2 objetivos4
3 desenvolvimento 5
3.1 ENGENHARIA E PROJETO DE SOFTWARE 5
3.1.1 Área de Conhecimento – Riscos............................................................53.1.2 Área de Conhecimento – Escopo...........................................................63.1.3 Área de Conhecimento – Aquisições.....................................................73.1.4 Área de Conhecimento – Comunicações...............................................73.1.5 Resenha do livro Engenharia de Software.............................................8
3.2 frameworks para desenvolvimento web......................................................323.2.1 Comparação de frameworks para desenvolvimento web (Java)..........323.2.2 Custo Benefício de frameworks no desenvolvimento Web..................333.2.3 Programação Java Web (plataforma de desenvolvimento)..................34
3.3 Projeto Orientado a Objetos........................................................................354 conclusão 41
5 referências 42
1 INTRODUÇÃO
A empresa China Telecom - A maior empresa de telefonia fixa do
mundo emprega 350 mil funcionários divididos em áreas como operações de rede,
serviços de informação ao cliente, voz e dados por telefone fixo, atendimento ao
usuário e serviços de faturamento/cobrança de clientes. Apesar da forte
concorrência da telefonia móvel, a empresa vem mantendo um crescimento
vertiginoso.
No entanto, ainda em transição de uma empresa estatal para uma
nova e moderna empresa e com objetivo de se firmar como uma concorrente de
peso no mercado mundial, a China Telecom teve que resolver vários problemas –
demanda recursos de várias pessoas e especialistas, além de inúmeros recursos,
entre hardware, software, fornecedores, viagens, entre outros. Neste contexto
veremos que a sobre como ajudar a empresa a resolver estes problemas.
3
2 OBJETIVOS
Aplicar todos os conhecimentos necessários com o objetivo de
possibilitar a empresa China Telecom numa integração mais profunda com outros
sistemas, de maneira que a empresa tenha uma visão completa de todos os seus
processos com clientes, fornecedores e funcionários.
4
3 DESENVOLVIMENTO
Como a empresa China Telecom – demanda recursos de várias
pessoas e especialistas, além de inúmeros recursos, entre hardware, software,
fornecedores, viagens, entre outros, farei uma resenha sobre o Guia PMBOK, dentro
da Engenharia e Projeto de Software.
3.1 ENGENHARIA E PROJETO DE SOFTWARE
O PMBOK® Guide não é uma metodologia, pois não distingue os
diferentes tipos de projeto (certamente gerenciar projetos administrativos é
totalmente diferente de gerenciar projetos de construção pesada).
Não utiliza peculiaridades de linguagem que respeitem a cultura de diferentes tipos
de empresas e não apresenta modelos específicos de documentos a serem
preenchidos.
Resumidamente podemos chamar de manual que descreve o
universo de conhecimentos para o Gerenciamento de Projetos. Transformou-se em
um padrão á fonte de inspiração para quase todas as metodologias existentes.
O PMBOK torna um projeto melhor estruturado e atendendo as suas
demandas de forma mais eficiente, tendo também em vista um melhor planejamento
para assim bater as suas metas como o custo, benefício, e prazo estabelecido.
Ele é um conjunto de boas práticas para ajudar na construção de um projeto,
promove um melhor vocabulário para se discutir entre profissionais na área.
O guia PMBOK possui em sua 5ªedição 10 áreas de conhecimento dentre elas...
3.1.1 Área de Conhecimento – Riscos
Esta área descreve os processos relativos à realização do
gerenciamento de riscos em um projeto. Temos cinco processos de planejamento e
um de controle. Os processos desta área de conhecimento têm como objetivo
determinar como os riscos serão identificados, analisados e como as respostas será
5
planejado e como risco será planejado, criam uma lista de riscos identificados no
projeto com diversas técnicas que ajudam a gerar essa lista de riscos, buscam
priorizar os riscos com base no grau de criticidade, permitem atribuir probabilidade
numérica aos riscos, definem estratégias e ações para lidar com os riscos negativos
e positivos, monitoram os riscos com novo risco sendo identificada, revisão das
análises de riscos, definição de outras prioridades de riscos, etc.
Os processos dessa área são:
Planejar o Gerenciamento dos Riscos.
Identificar os Riscos.
Realizar a Análise Qualitativa de Riscos.
Realizar a Análise Quantitativa dos Riscos.
Planejar as Respostas aos Riscos.
Monitorar e Controlar os Riscos.
3.1.2 Área de Conhecimento – Escopo
Esta área descreve os processos envolvidos na verificação de que o
projeto inclui todo o trabalho necessário e apenas o trabalho necessário, para que
seja concluído com sucesso.
Existem três processos de planejamento (três primeiros) e dois
processos de controle e monitoramento (dois últimos). Os processos de
planejamento criam um plano para o gerenciamento de escopo. Os processos de
controle e monitoramento controlam se que o escopo está sendo cumprido conforme
foi definido nos processos de planejamento e a verificação confirmam com o cliente
que está tudo correto.
Os processos dessa área são:
Coletar Requisitos.
Definir o Escopo.
Cria a EAP.
Verificar o Escopo.
Controlar o Escopo.
6
3.1.3 Área de Conhecimento – Aquisições
Esta área descreve os processos que compram ou adquirem
produtos, serviços ou resultados, além dos processos de gerenciamento de
contratos. Os processos desta área de conhecimento têm como objetivo determinar
o que se quer adquirir, de quem se quer adquirir, receber as resposta dos
fornecedores e selecionar o fornecedor, como se dará o gerenciamento dos
contratos, pagamentos, se as entregas estão de acordo com o que foi estabelecido,
pagar o fornecedor, e por último formalizar a finalização do contrato.
Os processos dessa área são:
Planejar as Aquisições.
Realizar as Aquisições.
Administrar as Aquisições.
Encerrar as Aquisições.
3.1.4 Área de Conhecimento – Comunicações
Esta área descreve os processos relativos à geração, coleta,
disseminação, armazenamento e destinação final das informações do projeto de
forma oportuna e adequada.
Os processos desta área de conhecimento determinam quem está
envolvido no projeto, definem como as comunicações vão ocorrer quando o projeto
iniciar e determina o tipo de informações gerada, quem é o responsável, qual o
meio, quem receberá as informações geradas, qual a periodicidade determina como
serão distribuídas as informações, como podemos gerenciar as expectativas dos
interessados medindo o grau de satisfação ou insatisfação das pessoas
interessadas, e geram relatórios que permitam o acompanhamento e controle do
que está acontecendo com o tempo, custo, escopo, etc.
Os processos dessa área são:
Identificar as Partes Interessadas.
Planejar as Comunicações.
Distribuição das Informações.
Gerenciar as Expectativas das Partes Interessadas.
7
Reportar Desempenho
3.1.5 Resenha do livro Engenharia de Software
A empresa China Telecom decidiu investir em um software de ERP
fornecido por uma empresa de renome do que investir no desenvolvimento interno
de um que levaria muito tempo e sairia muito caro. Neste caso, “levaria muito tempo
e sairia muito caro”. Vamos supor que a empresa optasse pelo desenvolvimento
próprio, para isso farei uma resenha dos seguintes capítulos do livro Engenharia de
Software, de Ian Sommerville:
3.1.5.1 CAPITULO 11 – Projeto de Arquitetura
O projeto de arquitetura é primeiro estagio no processo de projetos.
Diz o livro que ele idêntica subsistemas e estabelece um framework para controlar a
comunicação dos subsistemas, subsistemas são sistemas grandes decompostos em
subsistemas e que fornece algum conjunto de serviços relacionados. Ele também
representa uma ligação critica entre processos de engenharia de projeto e
requisitos. Três vantagens de projetar e documentar explicitamente uma arquitetura
de software:
Comunicação de stakeholders: é uma apresentação em alto
nível do sistema que enfoca a discussão entre diferentes
stakeholders.
Analise de sistemas: Tem profundo efeito sobre o sistema,
mostra se o sistema pode atender aos requisitos críticos
como, confiabilidade, desempenho e facilidade de
manutenção.
Reuso em larga escala: Apóia o reuso em larga escala de
sistemas que possuem arquiteturas de sistemas familiares.
A arquitetura de software serve para negociar requisitos de sistema
e estruturar discussões com os clientes, desenvolvedores e gerentes. É uma
8
ferramenta essencial parra gerenciamento de complexidade, ocultando detalhes e
focando as abstrações principais do sistema. O estilo e estrutura da aplicação
dependem dos requisitos não funcionais do sistema, por exemplo:
Se o desempenho for um requisito crítico a aplicação deve localizar
operações criticas dentro de subsistemas e usar componentes de alta granularidade
em detrimento dos de baixa granularidade para reduzir a comunicação entre eles.
Se a facilidade de manutenção for um requisito crítico, a arquitetura de sistemas
deve ser projetada usando componentes de baixa granularidade e autocontidos que
possam ser prontamente mudados.
Há conflitos potenciais entre algumas dessas arquiteturas, por
exemplo, se o desempenho que necessita de alta granularidade e a facilidade de
manutenção que necessita de baixa granularidade forem ambos o requisito crítico
terá que ser encontrada alguma solução eficaz.
Um projeto de subsistemas é decomposição abstrata de um sistema
de componentes em alta granularidade. Os diagramas de blocos são usados para
representar um projeto de subsistemas.
Esses diagramas de blocos são bons para comunicação entre
stakeholders e para o planejamento do projeto, pois, não estão abarrotados de
detalhes, já para a arquitetura não são tão bons, pois não mostram relacionamento
entre os componentes do sistema.
O projeto de arquitetura tenta estabelecer uma organização de
sistemas que satisfação os requisitos funcionais e os não funcionais do sistema.
Durante o processo de projeto de arquitetura os arquitetos de sistemas devem
responder a algumas perguntas:
Existe uma arquitetura genérica de aplicação que possa
funcionar como um modelo para o sistema que está sendo
projetado?
Como o sistema será distribuído ao longo de vários
processadores?
Qual ou quais estilos de arquitetura são apropriados para o
sistema?
Qual será a abordagem fundamental usada para estruturar o
9
sistema?
Como as unidades estruturais de um sistema serão
decompostas em módulos?
Qual estratégia será utilizada para controlar a operação das
unidades do sistema?
Como o projeto de arquitetura será avaliado?
Como a arquitetura do sistema deve ser documentada?
Ao Projetar uma arquitetura de sistemas, você precisa decidir o que
seu sistema e classes mais amplas de aplicação têm em comum, e decidir quanto
conhecimento dessas arquiteturas de aplicação você pode reusar. A arquitetura de
um sistema de software pode ser baseada em um modelo ou estilo de arquitetura
especifico. Em alguns casos a arquitetura geral de um sistema pode ser uma
arquitetura composta.
Os modelos de arquitetura que podem ser desenvolvidos podem
incluir:
Um modelo estático de estrutura que mostra os subsistemas
ou componentes desenvolvidos como unidades separadas.
Um modelo dinâmico de processo que mostra como o sistema
esta organizado em processos em tempo de execução.
A organização de um sistema reflete a estratégia básica usada para
estruturá-lo. Você precisa tomar decisões sobre o modelo geral organizacional de
um sistema com antecedência no processo de projeto de arquitetura. A organização
pode refletir diretamente na estrutura subsistema. Possuem três estilos de
organizacionais amplamente usados:
3.1.5.1.1 Modelo de repositório
Os subsistemas que constituem um sistema devem trocar
informações de mofo que possam trabalhar juntos eficientemente.
Esse modelo é, portanto, adequado para aplicações em que os dados são gerados
por um subsistema e usados por outro. O repositório é passivo e o controle é de
10
responsabilidade dos subsistemas que o usam.
3.1.5.1.2 Modelo Cliente – Servidor
O modelo de arquitetura cliente – servidor é um modelo em que o
sistema é organizado como um conjunto de serviços e servidores e clientes
associados que acessam e usam os serviços. Os clientes talvez precisem saber os
nomes dos servidores disponíveis e os serviços que eles fornecem. No entanto os
servidores não precisam saber a identidade do cliente ou quantos são. São
acessados os serviços por meio de chamadas remotas de procedimento usando um
protocolo request–eply, o cliente faz um pedido a um servidor e espera ate receber
uma resposta. A vantagem de um modelo cliente servidor é que ele é uma
arquitetura distribuída. O uso efetivo de sistemas em rede pode ser feito com muitos
processadores distribuídos. É fácil adicionar um novo servidor e integrá-lo ao
restante do sistema.
3.1.5.1.3 Modelo em Camadas
O modelo em camadas organiza um sistema em camadas, cada
uma das quais fornecendo um conjunto de serviços. A abordagem em camadas
apóia o desenvolvimento incremental de sistemas. À medida que uma camada é
desenvolvida alguns serviços fornecidos por essa camada podem ser
disponibilizados para os usuários. Essa arquitetura também é modificável e portável.
Desde que sua interface permaneça inalterada, uma camada poderá ser substituída
por outra equivalente. Uma desvantagem da abordagem em camadas é que a
estruturação de sistemas dessa maneira pode ser difícil. As camadas mais internas
podem fornecer recursos básicos, como gerenciamento de arquivos, necessários em
todos os níveis. O desempenho também pode ser um problema devido aos vários
níveis de interpretação de comandos algumas vezes exigidos.
11
3.1.5.1.4 Estilos de decomposição modular
Depois que a organização geral do sistema foi escolhida, precisa-se
tomar uma decisão sobre a abordagem a ser usada na decomposição de
subsistemas em módulos. Um modulo é normalmente um componente de sistema
que fornece um ou mais serviços para outros módulos. Ele faz uso de serviços
fornecidos por outros módulos. Existem duas estratégias principais que você pode
usar ao decompor um subsistema em módulos. Decomposição orientada a objetos e
pipelining orientado a funções. Você deve evitar tomar decisões prematuras sobre a
simultaneidade de um sistema.
3.1.5.1.5 DECOMPOSIÇÃO ORIENTADA A OBJETOS.
Um modelo de arquitetura orientado a objetos estrutura o sistema
em um conjunto de objetos não firmemente acoplados com interfaces bem definidas.
Os objetos chamam serviços oferecidos por outros objetos. Uma decomposição
orientada a objetos esta relacionada a classes de objetos, seus atributos e suas
operações. Quando implementados os objetos são criados a partir dessas classes e
algum modelo de controle é usado para coordenar as operações de objetos. A
vantagem é que implementação de objetos pode ser modificada sem afetar outros
objetos. A desvantagem é que para usar serviços os objetos devem fazer referencia
explicita ao nome e a interface de outros objetos.
3.1.5.1.6 Pipelining orientado a funções
No pipelining orientado a funções ou modelo de fluxo de dados, as
transformações processam suas entradas e produzem saídas. Os dados fluem de
uma para outra função e são transformados ao moverem – se seqüencialmente.
Cada etapa é implementada como uma transformação. Os dados de entrada fluem
através dessas transações ate serem convertidos em dados se saída. As vantagens
dessa arquitetura são: Apoiar o reusa de transformações. Ele é intuitiva, muitas
pessoas pensam em seu trabalho em termos de processamento de entrada e saída.
A evolução do sistema pela adição de novas transformações é geralmente direta.
12
Ela é simples de ser implementada tanto quanto um sistema concorrente ou
seqüencial. O principal problema é que ele necessita ser um formato comum para
transferir dados que possa ser reconhecido por todas as transformações.
Sistemas interativos são difíceis de escrever usando esse modelo por causa da
necessidade de uma seqüência de dados ser processada.
3.1.5.1.7 Modelos de controle
O modelo de controle tem como objetivo controlar subsistemas de
maneira que seus serviços sejam entregues no lugar certo e no tempo certo.
Modelos de controle são usados em conjunto com estilos de estrutura. Todos os
estilos de estrutura que foi explicado podem ser implementados por meio de controle
centralizado ou baseado em eventos.
3.1.5.1.8 Controle Centralizado
Em modelo de controle centralizado, um subsistema é designado
como controlado de sistema e tem a responsabilidade pelo gerenciamento da
execução de outros subsistemas. Modelos de controle centralizados Dividem – se
em duas classes, dependendo se forem executados seqüencialmente ou
paralelamente.
O modelo chamado – retorno: O controle começa no topo da
hierarquia de sub – rotina e através de chamadas de sub-rotinas, passa para os
níveis mais baixos na arvore, são aplicados em modelos seqüenciais.
O modelo gerenciado: Aplicados em modelos concorrentes. Um
sistema concorrente é projetado como um gerenciador de sistema e controla o inicio,
a parada e a coordenação de outros processos do sistema.
3.1.5.1.9 Sistemas orientados a eventos
As decisões dos modelos orientados a eventos são regidos pelos
eventos gerados externamente. O termo evento pode ser um sinal que pode assumir
uma gama de valores ou uma entrada de comando baseados em um menu.
13
Possuem dois modelos de controle orientados a eventos.
Modelos de broadcast: Nesse modelo, um evento é transmitido a
todos os subsistemas. Qualquer subsistema programado para manipular o evento
pode responder a ele. A vantagem dessa abordagem é que a evolução é
relativamente simples, um novo subsistema para tratar classes especifica de
eventos pode ser integrado por meio do registro de seus eventos no tratador de
eventos. A desvantagem é que os subsistemas não sabem se ou quando os eventos
serão manipulados.
Modelos orientados a interrupções: São usados em sistemas de
tempo real como requisitos rigorosos de tempo, nos quais as interrupções externas
são detectadas por um trator de interrupções. A vantagem dessa abordagem é que
ela permite respostas muito rápidas aos eventos a serem implementados. Sua
desvantagem é a complexidade da programação e a dificuldade de validação.
3.1.5.1.10 Arquitetura de referencia
As arquiteturas de referencia não são geralmente consideradas um
roteiro de implementações. Em vez disso, sua principal função é ser um meio de
discussão de arquiteturas de domínio especifico e de comparação de sistemas
diferentes em um domínio. Um modelo de referencia fornece um vocabulário para
comparação. Ele atua como uma base, em relação a qual os sistemas podem ser
avaliados.
Uma proposta de modelo de referencia é um modelo para ambientes
CASE que identifica cinco conjuntos de serviços que um ambiente CASE deve
fornecer. Ele deve também fornecer recursos de plug in para ferramentas CASE
individuais que usam esses serviços. Os cincos níveis de referencias são:
Serviços de repositório de dados: Estes serviços fornecem recursos
para o armazenamento e o gerenciamento de itens de dados e seus
relacionamentos.
Serviços de integração de dados: Estes serviços fornecem recursos
para o gerenciamento de grupos ou para definição de relacionamentos entre eles.
Serviços de gerenciamento de tarefas, estes serviços fornecem recursos para a
14
definição e aprovação de modelos de processo.
Serviços de mensagem: Comunica ferramenta – Ferramenta,
ambiente-ferramenta e ambiente – ambiente.
Serviços de interface com o usuário: Estes serviços fornecem
recursos para o desenvolvimento de interface com o usuário.
A finalidade dessa arquitetura de referencia é ser um meio de
classificação e comparação de ferramentas e ambientes CASE integrados.
3.1.5.2 CAPITULO 12 – Arquitetura de sistemas distribuídos
Um sistema distribuído é aquele em que as informações em fase de
processamento são distribuídas a vários computadores. Vantagens de usar uma
abordagem distribuída para desenvolvimento de sistemas.
1. Compartilhamento de recursos – Um sistema
distribuído permite o compartilhamento de
recursos de hardware e software, como discos,
impressoras, arquivos e computadores que estão
associados aos diferentes computadores de uma
rede.
2. Abertura - permitem a equipamentos e software
de diferentes fabricantes serem combinados, pois
são projetados com base em protocolos padrões.
3. Concorrência – vários processos podem operar ao
mesmo tempo em diferentes computadores, e
podem (mais não precisam) conversar uns com os
outros.
4. Escalabilidade – são escalonáveis a maneira que
a capacidade de um sistema pode ser ampliada
pela adição de novos recursos para atender as
demandas dos sistemas.
5. Tolerância a defeitos – pela disponibilidade de
vários computadores e o potencial de duplicação
15
de informação significa que os sistemas
distribuídos possam ser tolerantes a algumas
falhas de hardware e software.
Esses sistemas de distribuição comparados aos sistemas que
operam com um processador ou com um cluster de processadores podem ter
algumas desvantagens como:
1. Complexidade - os sistemas distribuídos são mais
complexos que os sistemas centralizados.
2. Proteção – o sistema pode ser acessado de vários
computadores diferentes, e o trafego na rede
pode estar sujeita a interceptações.
3. Gerenciamento – os computadores do sistema
podem ser de tipos diferentes e podem operar em
versões diferentes de sistemas operacionais.
Defeitos em uma máquina podem se propagar a
outra maquinas com conseqüências inesperadas.
4. Imprevisibilidade – Como todos os usuários da
web sabem, os sistemas distribuídos são
imprevisíveis em suas respostas. A resposta
depende da carga total do sistema, sua
organização e a carga da rede.
Como tudo isso pode mudar em um curto período de tempo, o tempo
de resposta para uma solicitação do usuário pode variar drasticamente de uma
solicitação para outra.
Possuem dois tipos diferentes de arquiteturas de sistemas
distribuídos:
1. Arquitetura cliente-servidor: É o sistema como um
conjunto de serviços fornecidos aos
clientes que fazem uso desses serviços. Os
servidores e clientes são tratados de maneiras
diferentes nesses sistemas.
2. Arquiteturas de objetos distribuídos. Podemos
16
pensar no sistema como um conjunto de objetos
que interagem e cuja localização é irrelevante.
Não há distinção entre cliente e servidor.
Tanto a arquitetura cliente-servidor e a arquitetura
de objetos distribuídos são amplamente usadas
no setor, mais a aplicação ocorre geralmente
dentro de uma única organização. A organização
é, portanto, intra-organizacional.
3.1.5.2.1 Arquitetura de multiprocessadores
O multiprocessador São processos que podem ser executados
separados. Esses modelos tomam decisões usando essas informações e enviam
sinais aos atuadores, que modificam o ambiente do sistema. O uso de vários
processadores aprimora o desempenho e a capacidade de recuperação do sistema.
3.1.5.2.2 Arquitetura Cliente-servidor
Em uma arquitetura cliente-servidor, uma aplicação é modelada
como um conjunto de clientes que usam esses serviços. Os clientes precisam estar
informados sobre os serviços disponíveis, mas geralmente não sabem da existência
de outros clientes. Vários processos de serviços podem ser executados em um
único processador de serviço, portanto não há mapeamento entre processos e
processadores de um sistema.
O projeto de sistemas cliente-servidor deve refletir a estrutura lógica
da aplicação que esta sendo desenvolvida. Um exemplo é uma aplicação que esta
dividida em três camadas:
A camada de apresentação: que se encarrega da
17
apresentação de informações para o usuário e toda a
interação com o usuário.
A camada de processos de aplicações se encarrega da
implementação da lógica da aplicação.
A camada de gerenciamento de dados se encarrega de todas
as operações de banco de dados.
A arquitetura cliente-servidor mais simples denomina-se arquitetura
cliente-servidor de duas camadas, podem ter duas formas:
Modelo cliente-magro: O processamento e o gerenciamento
de dados são realizados no servidor. O cliente apenas
executa o software de apresentação.
Modelo cliente-gordo: O servidor é responsável somente pelo
gerenciamento de dados. O software do cliente implementa a
lógica da aplicação e as interações com o usuário do sistema.
Uma desvantagem do modelo cliente-magro é que ele impõe uma
grande carga de processamento sobre o servidor e a rede. O modelo cliente-gordo
faz uso dessa capacidade de processamento disponível e distribui o processamento
lógico de aplicação e a apresentação do cliente. O servidor é essencialmente um
servidor de transações que gerencia todas as transações do banco de dados.
Enquanto o modelo cliente-gordo distribui o processamento mais eficientemente do
que um modelo cliente-magro, o gerenciamento do sistema é mais complexo. A
funcionalidade da aplicação é dividida entre vários computadores. Quando o
software precisa ser alterado, isso envolve reinstalação em cada computador cliente,
o que pode resultar em um custo significativo se houver centenas de clientes no
sistema. O Problema com a abordagem cliente-servidor de duas camadas é que as
três camadas lógicas devem ser mapeadas sobre dois sistemas de computador – o
cliente e o servidor. Pode haver problemas de escalabilidade e desempenho, se o
modelo cliente-magro for escolhido, ou problemas de gerenciamento de sistemas, se
o modelo cliente-gordo for usado. Para evitar esses problemas uma alternativa é
usar o modelo cliente-servidor de três camadas. Em alguns casos é melhor estender
o modelo cliente-servidor de três camadas para uma variante com varias camadas,
na qual servidores adicionais são incorporados ao sistema.
18
3.1.5.2.3 Arquiteturas de objetos distribuídos
Nesse modelo os objetos podem ser distribuídos entre uma serie de
computadores na rede e se comunicam através de um middleware, que é chamado
de requisitor de objetos. O Middleware fornece uma interface transparente continua
entre os objetos. Ele fornece um conjunto de serviços que permitem que os objetos
se comuniquem e sejam adicionados e removidos do sistema. As vantagens são que
permite que o projetista do sistema postergue decisões sobre onde e como os
serviços devem ser fornecidos. È uma arquitetura de sistema aberto que permite que
novos recursos sejam adicionados.
Uma arquitetura de objetos distribuídos pode ser usada como um
modelo lógico, que permite estruturar e organizar o sistema. Uma arquitetura de
objetos distribuídos em lugar de uma arquitetura cliente-servidor é adequada para
esse tipo de aplicação porque o modelo lógico do sistema não é um dos
fornecimentos de serviços em que existem serviços distintos de gerenciamento de
dados e pode adicionar bancos de dados ao sistema sem grandes interrupções.
A maior Desvantagem é que elas são mais complexas do que sistemas cliente-
servidor.
3.1.5.2.4 CORBA
Existem quatro elementos principais desse padrão:
1. Um modelo de objeto para objetos de aplicações
em que um objeto corba é um encapsulamento
de estado com uma interface bem definida em
linguagem neutra descrita em uma linguagem de
definição de interface.
2. Um requisitor de objetos que gerencia
solicitações para serviços de objetos.
3. Um conjunto de serviços de objetos que são
serviços gerais com probabilidade de serem
solicitados por muitas aplicações distribuídas.
4. Um conjunto de componentes comuns
19
construídos sobre esses serviços básicos que
podem ser solicitados pelas aplicações.
O Corba considera um objeto como se fosse um encapsulamento de
atributos e serviços, como é normal em objetos.
Ele deve ter uma definição de interface separada que define
atributos e operações publicas do objeto. As interfaces são definidas por uma
linguagem de definição de interface padronizada independe de linguagem.
O objeto corba tem um único identificador chamado de referencia de
objeto interoperavel. Esse IOR é usado quando um objeto solicita serviços de outro
objeto. O requisitor de objetos conhece os objetos que estão solicitando serviços e
suas interfaces. O ORB cuida da comunicação entre os objetos, os objetos que se
comunicam não precisam conhecer a localização de outros objetos nem sobre sua
implementação. O objeto que fornece o serviço tem um esqueleto de IDL associado
que liga a interface a implementação dos serviços.
O corba foi desenvolvido desde 1980 e as versões recentes de
corba foram simplesmente dedicadas ao apoio aos objetos distribuídos.
Os padrões Corba incluem definições de interface
para uma grande variedade de componentes horizontais e verticais. Os
componentes verticais são componentes específicos de um domínio de aplicação.
Os componentes horizontais são componente de propósito geral,
como componentes de interface com o usuário.
3.1.5.2.5 COMPUTAÇÃO INTERORGANIZACIONAL DISTRIBUIDA
Por motivo de segurança e interoperabilidade, a computação
distribuída foi implementada inicialmente em nível organizacional. Uma organização
tem uma serie de servidores e distribui sua carga computacional entre eles. Devido
ao fato de eles estarem todos localizados dentro da mesma organização, pode ser
aplicado padrões e processos operacionais locais.
3.1.5.2.6 ARQUITETURAS PONTO A PONTO
São sistemas descentralizados em que as computações podem ser
20
realizadas por qualquer nó da rede, nenhuma distinção é feita entre clientes e
servidores. O sistema global é projetado para beneficiar-se da capacidade
computacional e armazenamento disponível em uma rede de computadores
potencialmente grande. Em principio, em sistemas ponto a ponto, todo nó de rede
pode estar ciente a respeito de qualquer outro nó, pode fazer conexões com ele e
pode trocar dados com ele. Em uma arquitetura descentralizada, os nos de rede não
são simplesmente elementos funcionais, mais também chaves de comunicação que
podem guiar os sinais de dados e de controle de um nó para o outro.
No entanto quando se recupera um documento, o nó que esta recuperando se torna
visível para outros.
3.1.5.2.7 ARQUITETURA DE SITEMA ORIENTADO A SERVIÇOS
A essência de um serviço, é que o fornecimento dos serviços é
independente da aplicação que usa o serviço. Os
provedores de serviços podem desenvolver serviços especializados e oferecê-los a
uma gama de usuários de serviços de organizações diferentes. O proposto WEB
Service foi lançada, pois o acesso de servidores web era somente por meio de
navegar web, e o acesso direto aos repositórios de informações por outros
programas não era pratico. Os três padrões fundamentais que possibilitam
comunicação entre WEB SERVICES são:
SOP: Define uma organização para troca estruturada de
dados entre WEB SERVICES.
WSDL. Define como as interfaces dos WEB services podem
ser representadas.
UDDI. Este é um padrão de descobrimento que define como
as informações de descrição do serviço usadas pelos
solicitantes do serviços para descobrir serviços, pode ser
organizada.
Todos esses padrões são baseados em XML.
21
3.1.5.3 CAPITULO 13 – Arquitetura de Aplicações
3.1.5.3.1 SISTEMAS DE PROCESSAMENTO DE DADOS
Aplicações de processamento de dados são aplicações voltadas aos
dados. Elas Processam dados em lotes sem intervenções explicitas do usuário
durante o processamento. As ações explicitam 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 três componentes principais:
Entrada: A entrada coleta as entradas de uma ou mais fontes.
Processamento: O processamento realiza a computação
usando essas entradas.
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
transações são processados em serie, sem necessidade de manter o estado entre
as transações.
22
3.1.5.3.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
seqüê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
tornem-se 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
assegurarem 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 caixas
eletrônicos e terminais de mesa, e alguns clientes e a equipe do banco podem
23
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.
3.1.5.3.3 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 vôos ou registros de pacientes em um hospital. O desenvolvimento da WEB fez
com que um grande numera 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 maquina abstrata na qual a camada superior apóia 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 é uma classe de aplicação
amplamente usada. Sua arquitetura esta alinhada com o modelo de sistema de
informações.
O componente de um sistema de alocação de recursos inclui:
1) Um banco de dados de recursos que mantém detalhe 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 associa esse recursos a
24
detalhes do solicitante do recurso.
5) Um modulo de autenticação de usuários que permite ao sistema
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 esta fora do
sistema e permite ao solicitante do recurso enviar consultas e solicitações para o
recurso a ser alocado.
3.1.5.3.4 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 seqüê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.
3.1.5.3.5 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
maquina. Mais outros sistemas de processamento de linguagens traduzem uma
25
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 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 esta 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 esta
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 maquina abstrata.
3.1.5.4 CAPITULO 29 – Gerenciamento de Configurações
Gerenciamento de configurações são o desenvolvimento e o uso de
padrões e procedimentos para o gerenciamento de sistemas de software em
desenvolvimento. Há muitas razões Por que os sistemas existem em diferentes
configurações. Configurações podem ser produzidas para diferentes computadores,
26
para diferentes sistemas operacionais, incorporando funções especificas de clientes.
Os gerentes de configurações são responsáveis por manter a rastreabilidade das
diferenças entre versões de software, para assegurar que as novas versões sejam
derivadas de maneira controlada e liberar novas versões para clientes certos no
momento certo.
3.1.5.4.1 PLANEJAMENTO DE GERENCIAMENTO DE CONFIGURAÇÕES
O plano de gerenciamento de configurações descreve os padrões e
procedimentos que devem ser usados para o gerenciamento. O ponto de partida
para o desenvolvimento do plano deve ser um conjunto de padrões de configuração,
que devem ser adaptados para se atender aos requisitos e as restrições de cada
projeto específico.
3.1.5.4.1.1 IDENTIFICAÇÃO DE ITEM DE CONFIGURAÇÃO
Em um grande sistema de software, pode haver módulos de
milhares de códigos fonte, scripts de testes, documentos de projeto etc. Eles são
produzidos por pessoas diferentes e, quando criados, podem ser denominados com
nomes similares ou idênticos. Para manter a rastreabilidade de todas essas
informações de maneira que o arquivo certo possa ser encontrado quando for
necessário você necessita de um esquema de identificação consistente para todos
os itens no sistema de gerenciamento de configurações.
Durante o processo de planejamento de gerenciamento de configuração, você
decide exatamente quais itens serão controlados. Planos de projetos,
especificações, projetos, programas, e massa de dados de teste são normalmente
mantidos como itens de configuração. Todos os documentos que podem ser úteis
para a evolução futura do sistema devem ser controlados pelo sistema de
gerenciamento de configuração. O esquema de identificação de itens de
configuração deve atribuir um único nome para todos os documentos sob controle
de configuração. Esse nome pode refletir o tipo do item, uma parte do sistema ao
qual ele se aplica, o criador do item. No esquema de atribuição de nomes, você
pode desejar evidenciar a relação entre os itens para garantir que os documentos
27
relacionados possuam uma mesma raiz em seus nomes. Portanto, você pode definir
um esquema de hierarquia com nome. Esquemas de nomes hierarquizados são
simples e de fácil compreensão: algumas vezes, podem mapear uma estrutura de
diretórios usada para armazenar arquivos de projeto. No entanto, refletem a
estrutura de projeto na qual o software foi desenvolvido. Os nomes de itens de
configuração associam componentes com um projeto especifico e, dessa maneira,
reduzem as oportunidades para o reuso. Pode ser muito difícil encontrar
componentes relacionados.
3.1.5.4.1.2 BANCO DE DADOS DE CONFIGURAÇÃO
O banco de dados de configuração é utilizado para registrar todas as
informações relevantes sobre as configurações de sistema e os itens de
configuração. Você usa o banco de dados CM para auxiliar a avaliação do impacto
das mudanças de sistema e para gerar relatórios para a gerencia sobre o processo
de CM. Como parte do processo de CM, deve-se definir o esquema do banco de
dados de CM, os formulários para coletar informações para serem registradas no
banco de dados e procedimentos para registro e recuperação de informações de
projeto.
Um banco de dados de configuração pode registrar informações
sobre usuários de componentes, clientes de sistemas, plataformas de execução,
mudanças propostas e etc. De preferência, um banco de dados de configuração
deve ser integrado com a versão do sistema de gerenciamento usada para
armazenar e gerenciar os documentos formais do projeto.
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.
3.1.5.4.2 GERENCIAMENTO DE MUDANÇAS
As necessidades e requisitos organizacionais alteram-se durante a
vida útil de um sistema. Isso significa que você precisa fazer as mudanças
correspondentes no sistema de software. Para garantir que essas mudanças serão
28
aplicadas ao sistema de maneira controlada, você precisa de um conjunto de
procedimentos de gerenciamento de mudanças apoiado por ferramentas.
Procedimentos de gerenciamento de mudança dizem respeito a analise de custo e
beneficio das mudanças propostas, a aprovação das mudanças viáveis e a
rastreabilidade de quais componentes do sistema foram alterados. O processo de
gerenciamento de mudança deve surtir efeito quando o software ou a documentação
associada são colocados em baseline pela equipe de gerenciamento de
configurações.
O primeiro estágio no processo de gerenciamento de configurações
é completar um formulário de solicitação de mudança (CRF – change request form)
que descreve a mudança necessária para o sistema. Uma vez que o formulário de
solicitação de mudança é enviado, ele deve ser registrado no banco de dados de
configuração. A solicitação de mudança é então analisada para verificar se a
mudança solicitada é necessária.
Para mudanças validas, o estagio seguinte é a avaliação da
mudança e o custo. O impacto da mudança no restante do sistema deve ser
verificado. Isso envolve todos os componentes afetados pela mudança. Se realizar a
mudança significa que mudanças adicionais em alguma parte do sistema são
necessárias, isso aumenta claramente o custo de sua implementação. Em seguida
as mudanças necessárias para os módulos do sistema são avaliadas. Finalmente, o
custo para realizar a mudança é estimado, considerando os custos de mudança nos
componentes relacionados.
3.1.5.4.3 GERENCIAMENTO DE VERSÕES E RELEASES
Os processos envolvidos no gerenciamento de versões e relases
preocupam-se com a identificação e a manutenção da rastreabilidade das versões
de um sistema. Gerentes de versões idealizam procedimentos para assegurar que
as versões de um sistema possam ser recuperadas quando solicitadas e não sejam
alteradas acidentalmente pela equipe de desenvolvimento. Para produtos, os
gerentes trabalham com a equipe de marketing, e , para sistemas feitos sob
encomenda, com os clientes, para planejar quando novos releases de um sistema
devem ser criados e distribuídos para implantação.
29
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.
3.1.5.4.3.1 IDENTIFICAÇÃO DE VERSÕES
Para criar uma versão especifica de um sistema, você precisa
especificar as versões dos componentes de sistema que devem ser incluídas nele.
Você não pode usar o nome do item de configuração para identificar a versão,
porque ele pode ter muitas versões para cada item
de configuração identificado.
A três técnicas básicas para identificação da versão de componentes
são:
1. Numeração de versões: O componente recebe
um numero explicito e único de versão. Isso é o
mais comumente usado no esquema de
identificação.
2. Identificação baseada em atributos: Cada
componente tem um nome (como o nome do item
de configuração, que não é único para diferentes
versões) e um grupo de atributos associados
para cada versão, componentes são portanto,
identificados pela especificação de seus nomes e
valores de atributos.
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. Ou
seja, considera –se que cada versão de
componente foi criada em resposta a uma ou
mais solicitações de mudanças. A versão de
componente é identificada pelo conjunto de
solicitações de mudanças que se aplicam ao
30
componente.
3.1.5.4.3.2 GERENCIAMENTO DE RELEASES
Um release de sistema é uma versão do sistema distribuído para os
clientes. Os gerentes de release de sistemas são responsáveis por decidir quando
um sistema pode ser liberado para os clientes, gerenciar o processo de criação do
release e de meios de distribuição e documentar o release para assegurar que ele
pode ser recriado exatamente como foi distribuído, se for necessário.
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 disponiveis, 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 ipsis literis 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 compias 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.
3.1.5.4.4 CONTRUÇÃ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. Quando você esta construindo um sistema com base em seus
31
componentes, você deve pensar nas seguintes questões:
1. Todos os componentes que compõem um sistema
foram incluídos nas instruções de construção?
2. A versão apropriada de cada componente
necessário foi incluída nas instruções de
construção ?
3. Todos os arquivos de dados necessários estão
disponíveis?
4. Se os arquivos de dados estão referenciados
dentro de um componente, o nome usado é o
mesmo que o do arquivo de dados na maquina –
alvo?
5. A versão apropriada do compilador e de outras
ferramentas requeridas esta disponível?
As versões atuais das ferramentas de software podem ser
incompatíveis com as versões antigas usadas para desenvolver o sistema.
3.1.5.4.5 FERRAMENTAS CASE PARA GERENCIAMENTO DE CONFIGURAÇÕES
Processos de gerenciamento de configurações são normalmente
padronizados e envolvem aplicações de procedimentos predefinidos. Eles requerem
o gerenciamento cuidadoso de grande quantidade de dados e é essencial a atenção
aos detalhes. Quando um sistema está sendo construído com base em versões de
componentes, um único erro de gerenciamento de configuração pode significar que
o software não irá operar adequadamente. Consequentemente, o apoio de uma
ferramenta CASE é essencial para o gerenciamento de configuração. Essas
ferramentas podem ser combinadas para criar uma área de trabalho para apoiar
todas as atividades de CM.
32
3.2 FRAMEWORKS PARA DESENVOLVIMENTO WEB
3.2.1 Comparação de frameworks para desenvolvimento web (Java).
Devido ao crescimento acelerado da Internet e, conseqüentemente,
as facilidades que a mesma oferece, a empresa China Telecom decidiu migrar de
seus sistemas Desktop para sistemas Web. Esta migração em grande escala fez
com que o desenvolvimento Web também crescesse para atender essa demanda e,
com isto, esta empresa assim como as empresas que decidiram investir nessa
migração tiveram vantagens como: Disponibilizar serviços a um maior número de
pessoas; Expandir o horizonte da empresa graças ao maior alcance da Internet.
Porém, era necessário que as formas de desenvolvimento Web
também evoluíssem, pois ainda eram usadas técnicas que não proporcionavam a
produtividade esperada, e um sistema Web era considerado muito complexo de
desenvolver, afinal, as ferramentas de programação para essa plataforma não eram
muito eficazes em relação às seguintes características: confiabilidade, produtividade,
facilidade de desenvolvimento e o principal, reusabilidade. Em paralelo a essa
necessidade, um padrão usado em smalltalk nos anos 80 voltou a ser utilizado, o
MVC (Modelo-View-Controller ou Modelo-Visão-Controle), onde os programadores
criam interfaces e 15 telas, acesso a dados e lógica de negócios de forma
independente, o que se notou uma forma eficiente de se desenvolver aplicativos
Web.
A importância de usar frameworks também é notada ao seguir o
modelo MVC, porque, sem frameworks fica praticamente impossível utilizar
corretamente esse modelo, usando Java EE (Enterprise Edition) como exemplo, é
possível seguir esse modelo usando Java Server Pages para a criação do layout de
páginas na camada de visão; usar um banco de dados conectado ao JDBC para a
camada de modelo. No entanto, a camada de controle não é possível criá-la
independentemente das outras camadas, ou seja, para desenvolver a camada de
controle puramente em Java EE seria necessário usar código correspondente a
lógica de negócios em todas as páginas JSP (Java Server Pages) o que não torna a
aplicação independente entre camadas, pois assim a camada de visão estaria sobre
a camada de controle o que em manutenções futuras seria um agravante, pois para
33
uma simples alteração no layout da página poderia afetar o código referente à
camada de controle justamente por eles encontrarem-se no mesmo arquivo.
3.2.2 Custo Benefício de frameworks no desenvolvimento Web
Parvoláteis de implementação através de interfaces estáveis.
Aumenta a reutilização – definição de componentes genéricos
que podem ser replicados para criar novos sistemas.
Extensibilidade – favorecida pelo uso de métodos hooks que
permitem que as aplicações estendam interfaces estáveis.
Inversão de controle – IoC – o código do desenvolvedor é
chamado pelo código do framework. Dessa forma, o
framework controla a estrutura e o fluxo de execução dos
programas.
3.2.3 Programação Java Web (plataforma de desenvolvimento).
Aplicação web designa, de forma geral, sistemas de informática
projetados para utilização através de um navegador, através da internet ou
aplicativos desenvolvidos utilizando tecnologias web HTML, JavaScript e CSS.1
Pode ser executado a partir de um servidor HTTP (Web Host) ou localmente, no
dispositivo do usuário.
Uma aplicação web também é definida em tudo que se é processado
em algum servidor, exemplo: quando você entra em um e-commerce a página que
você acessa antes de vir até seu navegador é processada em um computador ligado
a internet que retorna o processamento das regras de negócio nele contido. Por isso
se chama aplicação e não simplesmente site web.
A função do servidor web é receber uma solicitação (requisição) e
devolver (resposta) algo para o cliente.O browser permite ao usuário solicitar um
recurso e quando o servidor responde a uma solicitação são encontrados recursos
como: páginas HTML, figuras e documento PDF que são exibidas depois para o
usuário. Geralmente os servidores enviam instruções para o browser escritas em
HTML. O HTML diz ao browser como apresentar conteúdo ao usuário web.
34
O servidor em si tem alguns recursos, mas por algumas deficiências
não consegue processar tudo sozinho como: criações de páginas dinâmicas e o
armazenamento de dados em um banco de dados.
Páginas dinâmicas – Quando a aplicação roda no servidor, este
disponibiliza somente páginas estáticas. Porém, para efetuar essa comunicação é
necessário o auxílio de uma outra aplicação de ajuda que é passada através de
Servlet.
Armazenar dados no servidor – Para efetuar essa ação o servidor
precisa de uma aplicação de apoio (Servlet), fazendo com que o servidor envie
esses parâmetros para o Servlet.
As falhas de segurança podem surgir em diferentes etapas, tais
como: análise de requisito; especificação; Implementação. Os riscos de aplicação na
vulnerabilidade de uma empresa pode causar impactos.
O HTTP usa um modelo de solicitações e respostas. Uma solicitação
ocorre quando o usuário faz uma solicitação HTTP e o servidor web devolve uma
resposta HTTP, sendo que o browser verifica como tratar esse conteúdo. Se a
resposta que vem do servidor for uma página HTML, então é inserido na resposta
HTTP.
As diferenças entre as solicitações GET e POST são que enquanto o
GET anexa dados do formulário no final da URL o POST inclui dados do formulário
no corpo da solicitação.
3.3 PROJETO ORIENTADO A OBJETOS
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 nos baseando 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
35
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.
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, á lógica de negócios,
ou seja, nosso Model não sabe quantas nem quais as interfaces com o usuário esta
exibindo seu estado, a view não se importa de onde esta 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
atualizem-se.
MVC é um conceito (paradigma) de desenvolvimento e design que
tenta separar uma aplicação em três partes distintas. Uma parte, a Model, esta
relacionada ao trabalho atual que a aplicação administra outra parte a View esta
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
36
executando algum trabalho que a aplicação 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 á 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 á 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á á 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 á 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.
Embora o MVC só contenha três camadas há outra camada
37
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.
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 á 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 software
diminuirá sem perde a qualidade e sem aumento de custos.
38
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 outra coisas,
modificar a base de dados para outro SGBD (Sistema Gerenciador de Banco de
Dados) sem modificar uma linha de código Java.
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 à persistência.
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.
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.
39
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 tem um 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 atualmente, o Netbeans torna-se um excelente IDE para desenvolvimento
40
4 CONCLUSÃO
Vemos que na atual situação em que se encontra a empresa China
Telecom, e pelas mudanças que quer realizar, a importância da Engenharia de
Software para planejar todos os requisitos e ações de inovações que quer implantar.
Também da importância que são os frameworks e a plataforma Java para a
aplicação Web e da arquitetura MVC no projeto orientado a objetos para um melhor
resultado de seu software.
41
5 REFERÊNCIAS
Wikipédia. Aplicação Web. Wikipédia, a enciclopédia livre. Disponível em: <
http://pt.wikipedia.org/wiki/Aplica%C3%A7%C3%A3o_web>. Acesso em: 10 de mai
2015.
Wikipédia. Framework. Wikipédia, a enciclopédia livre. Disponível em:
<http://pt.wikipedia.org/wiki/Framework>. Acesso em: 10 de mai 2015.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edição. São Paulo: Pearson
Addison Wesley, 2007.
Lima, Maria, Gerenciamento de escopo em projetos, acessado em 10 de maio de
2015, disponível em: <http://www.devmedia.com.br/pmbok-gerenciamento-de-
escopo-em-projetos/29787>
Project Management Institute, Um Guia do Conhecimento Em Gerenciamento de
Projetos - Guia Pmbok® - 5ª Ed. 2014 -
42
