Embed Size (px)
DESCRIPTION
Trabalho para a turma de ADS
Citation preview
xxxxxxxxx2015
XXXXXXXXXXXXXXXX
SISTEMA DE ENSINO PRESENCIAL CONECTADOTECNLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
PRODUÇÃO TEXTUAL INDIVIDUAL
xxxxxxx2015
PRODUÇÃO TEXTUAL INDIVIDUAL
Trabalho apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, para a disciplina de Programação para Web II.
Prof. Veronice de Freitas.
XXXXXXXXXXXXXXX
SUMÁRIO
1 INTRODUÇÃO......................................................................................................3
2 Objetivo................................................................................................................4
3 DESENVOLVIMENTO..........................................................................................5
3.1 Engenharia e Projeto de Software.................................................................5
3.2 Projeto de Arquitetura....................................................................................7
3.2.1 Capitulo 11 – Projeto de Arquitetura.............................................................7
3.2.2 Capitulo 12 – Arquitetura de Sistemas Distribuídos....................................11
3.2.3 Capitulo 13 – Arquitetura de Aplicações......................................................15
3.2.4 Capitulo 29 – Gerenciamento de Configuração...........................................17
3.3 Programação para Web II.............................................................................20
3.3.1 Comparação de Frameworks para Desenvolvimento Web (Java)..............20
3.3.2 Custo Benefício de Frameworks no Desenvolvimento Web........................21
3.3.3 Programação Java Web (Plataforma de Desenvolvimento)........................22
3.4 Projeto Orientado a Objetos........................................................................23
4 CONCLUSÃO.....................................................................................................27
REFERÊNCIA............................................................................................................28
1 INTRODUÇÃO
O trabalho a seguir “China Telecom” propõe que o aluno entenda a demanda de recursos (pessoas especialistas, hardwares e softwares, fornecedores, viagens, entre outros).
3
2 OBJETIVO
Desenvolvimento de sistema de informação, analisando,
incrementando o conhecimento em engenharia de software, gestão de projetos, e
programação para web. Com eixo temático sobre a “China Telecom”, para
compreender o motivo da contratação de uma empresa de renome do que ela
mesma o fazer.
4
3 DESENVOLVIMENTO
3.1 ENGENHARIA E PROJETO DE SOFTWARE
Desafio 01
Analisamos, dentre as dificuldades e facilidades mapeadas na literatura, quais
e por que as mesmas estão presentes no processo de gerenciamento de projetos
com base no guia PMBOK. Verificamos quais os possíveis argumentos que os
gestores vivenciam no gerenciamento de projetos no que diz respeito aos sucessos
e fracassos apresentados. O estudo se concentrou em profissionais com certificação
PMP por apresentarem o conhecimento em Gerenciamento de Projetos com base
no guia PMBOK e, por ser uma área de crescimento onde as empresas buscam
profissionais com melhores práticas e vantagem competitiva. Valendo-se do
questionário estruturado como instrumento de coleta de dados e analisando os
resultados, os principais pontos encontrados dizem respeito ao tempo em que os
gerentes lidam com gerenciamento de projetos, as dificuldades encontradas pelos
gerentes em sua prática profissional, a área do PMBOK com maior dificuldade de
ser gerenciada, os itens que geram sucessos e fracassos nos projetos. A entrevista
semiestruturada evidenciou que o gerenciamento de projetos apresenta algumas
dificuldades presentes na prática profissional dos gerentes. Sugerimos investigar
melhor o impacto que a certificação PMP proporciona aos gerentes de projetos e se
a relação maturidade organizacional e experiência em gerenciamento de projetos é
fator de sucesso para o projeto.
Algumas áreas da competência, segundo PMBOK estão relacionadas abaixo:
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 tem como objetivo determinar como os
riscos serão identificados, analisados e como as respostas serão planejadas 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,
5
monitoram os risco com novos risco sendo identificados, 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.
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.
Os processos dessa área são: Coletar requisitos, definir o escopo, cria a EAP,
verificar o Escopo e Controlar o Escopo.
.
Fornecedores: Os processos de gerenciamento das aquisições do projeto
envolvem acordos, incluindo contratos, que são documentos legais entre um
comprador e um fornecedor. Um contrato representa um acordo mútuo que obriga o
fornecedor a oferecer algo de valor (por exemplo, produtos, serviços ou resultados
especificados) e obriga o comprador a fornecer uma compensação monetária ou de
outro tipo. O acordo pode ser simples ou complexo, e pode refletir a simplicidade ou
complexidade dos resultados e do esforço necessário.
6
3.2 PROJETO DE ARQUITETURA
Desafio 02
3.2.1 Capitulo 11 – Projeto de Arquitetura
O projeto de arquitetura é primeiro estágio no processo de projetos.
No livro diz que ele idêntica subsistemas e estabelece um framework para controlar
a comunicação dos subsistemas, 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, Analise de sistemas, Reuso em larga
escala:
A arquitetura de software serve para negociar requisitos de sistema e estruturar
discussões com os clientes, desenvolvedores e gerentes. É uma ferramenta
essencial parra gerenciamento de complexidade, ocultando detalhes e focando as
abstrações principais do sistema.
Se o desempenho for um requisito crítico a aplicação deve localizar operações
críticas 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 auto contidos que
possam ser prontamente mudados.
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.
Durante o processo de projeto de arquitetura os arquitetos de sistemas devem ser
feita 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?
7
Qual será a abordagem fundamental usada para estruturar o 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?
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 está 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 do subsistema.
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.
O modelo em camadas organiza um sistema em camadas, cada uma das quais
fornecendo um conjunto de serviços.
A abordagem em camadas apoia o desenvolvimento incremental de sistemas. A
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.
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.
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
8
subsistema em módulos.
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 está relacionada a classes de objetos, seus
atributos e suas operações. 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 referência explicita
ao nome e a interface de outros objetos.
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 sequencialmente. Cada etapa é
implementada como uma transformação.
Os dados de entrada fluem através dessas transações até serem convertidos em
dados se saída.
Vantagens: Apoiar o reuso de transformações.
Os modelos 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.
Em modelo de controle centralizado, um subsistema é designado como controlado
de sistema e tem a responsabilidade pelo gerenciamento da execução de outros
subsistemas. Tendo duas classes, dependendo se forem executados
sequencialmente ou paralelamente.
O modelo retorno 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 sequenciais.
Os modelos gerenciados, aplicados em modelos concorrentes. Sistema concorrente
projetado como um gerenciador de sistema e controla o início, a parada e a
9
coordenação de outros processos do sistema.
As arquiteturas de referência 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.
Uma proposta de modelo de referência é 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.
10
3.2.2 Capitulo 12 – Arquitetura de Sistemas Distribuídos
Um sistema bem 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:
Compartilhamento de recursos, Abertura, Concorrência, Escalabilidade, Tolerância a
defeitos.
Esses sistemas de distribuição comparados aos sistemas que operam com um
processador ou com um cluster de processadores podem ter algumas desvantagens
como: Complexidade, Proteção, Gerenciamento, Imprevisibilidade e Defeitos que em
uma máquina podem se propagar a outra maquinas com consequências
inesperadas.
Tipos diferentes de arquiteturas de sistemas distribuídos:
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.
Arquiteturas de objetos distribuídos. Podemos pensar no sistema como um conjunto
de objetos que interagem e cuja a 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, intraorganizacional.
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
11
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:
Permite que o projetista do sistema postergue decisões sobre onde e como os
serviços devem ser fornecidos.
Uma arquitetura de objetos distribuídos em lugar de uma arquitetura cliente-servidor
é adequada para esse tipo de aplicação por três razões:
O modelo lógico do sistema não é um dos fornecimentos de serviços em que
existem serviços distintos de gerenciamento de dados.
Pode adicionar bancos de dados ao sistema sem grande interrupções.
A maior Desvantagem é que elas são mais complexas do que sistemas cliente-
servidor.
CORBA
Existem quatro elementos principais desse padrão:
• Um modelo de objeto para objetos de aplicações.
• Um requisitor de objetos.
• Um conjunto de serviços de objetos.
• Um conjunto de componentes comum.
O Corba considera um objeto como se fosse um encapsula mento de atributos e
serviços, como é normal em objetos.
Os objetos Corba tem um único identificador chamado de referência de objeto
interoperável. Esse IOR é usado quando um objeto solicita serviços de um outro
objeto.
O requisitor de objetos conhece os objetos que estão solicitando serviços e suas
12
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.
Os componentes verticais são componentes específicos de um domínio de
aplicação. Os componentes horizontais são componentes de propósito geral, como
componentes de interface com o usuário.
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, podem ser aplicados
padrões e processos operacionais locais.
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.
A 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 prático.
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.
13
Todos estes padrões baseados em XML.
14
3.2.3 Capitulo 13 – Arquitetura de Aplicações
Aplicações de processamento de dados.
São Aplicações voltados a dados. Elas 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.
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 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.
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.
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.
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 acessar os dados de contas por
15
meio de navegadores WEB.
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:
Um analisador léxico, uma tabela de símbolos, um analisador sintático, uma árvore
de sintaxe, um analisador semântico e um gerador de código.
16
3.2.4 Capitulo 29 – Gerenciamento de Configuração
Gerenciamento de configurações é o desenvolvimento e o uso de
padrões e procedimentos para o gerenciamento de sistemas de software em
desenvolvimento. Ha muitas razões por que os sistemas existem em diferentes
configurações.
Configurações podem ser produzidas para diferentes computadores, diferentes
sistemas operacionais, incorporando funções especificas para 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.
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.
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.
Todos os documentos podem ser úteis para a evolução do sistema. O esquema de
identificação de itens de configuração deve atribuir um único nome para todos os
documentos sob controle de configuração. No esquema de atribuição de nomes,
você pode desejar evidenciar a relação entre os itens para garantir que os
documentos relacionados possuam uma mesma raiz em seus nomes.
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. Como
parte do processo de CM, deve-se definir o esquema do banco de dados de CM, os
17
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.
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 aplicadas ao sistema de maneira
controlada, você precisa de um conjunto de procedimentos de gerenciamento de
mudanças apoiado por ferramentas.
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 estágio seguinte é a avaliação da mudança e o custo. 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.
Uma das três técnicas básicas para identificação da versão de componentes é
Numeração de versões. O componente recebe um número explicito e único de
versão. Isso é o mais comumente usado no esquema de identificação.
"A versão de componente é identificada pelo conjunto de solicitações de mudanças
que se aplicam ao componente."
18
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 um 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.
19
3.3 PROGRAMAÇÃO PARA WEB II
Desafio 03
3.3.1 Comparação de Frameworks para Desenvolvimento Web (Java).
Classifica-se um framework de acordo com duas dimensões: como ele é utilizado e
onde é utilizado. No tratamento de como um framework pode ser utilizado, será
analisado o ponto de como introduzir as particularidades de uma aplicação. Neste
sentido Willemann e Ibarra (2007) os classificam em:
Caixa branca: são baseados na especialização por herança e sobrescrita de
métodos, modificando assim as funcionalidades básicas do framework.
Caixa preta: são os frameworks focados na composição, devendo utilizar as
funcionalidades já presentes no framework, ou seja, neste tipo de framework as
funcionalidades internas não podem ser vistas nem modificadas e devem-se
utilizar as interfaces fornecidas pelo framework. Neste framework as
instanciações e composições feitas é o que determinam as particularidades da
aplicação.
Caixa cinza: são frameworks híbridos, misturam os dois focos, herança e
composição, ou seja, são frameworks baseados em herança (caixa branca) com
algumas funcionalidades prontas.
A seguir são apresentadas as formas de utilização de um framework.
Frameworks de suporte ou de integração middleware: oferecem serviços de
sistema de baixo nível, tais como dispositivos de interface para periféricos
(drivers) e de acesso a arquivos, sendo normalmente usados para integrar
aplicações e componentes distribuídos, como frameworks BORBA ORB, DCOM,
implementações do padrão ODMG, entre outros (MATOS, 2008).
Frameworks de aplicação ou de infraestrutura: são frameworks que cobrem
funcionalidades que podem ser aplicadas a diferentes domínios. Ou seja, são
independentes do domínio ao qual será endereçado, como por exemplo, os
frameworks para sistemas operacionais, comunicação, redes e para construção
de interfaces (MATOS, 2008).
Frameworks de domínio: capturam conhecimento e especialidade em um
domínio de problema particular. Representam um projeto geral de aplicações
para domínios específicos, como telecomunicações, manufatura, jogos, controle
de produção, multimídia e engenharia financeira (MATOS, 2008).
20
3.3.2 Custo Benefício de Frameworks no Desenvolvimento Web
Melhora a modularização – encapsulamento dos detalhes
volá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.
De acordo com Willemann e Ibarra (2007), a principal vantagem na utilizando de
frameworks é a redução de custos, sendo que já existe uma estrutura definida e
que o desenvolvimento pode concentrar-se em desenvolver as regras específicas
do negócio em que o sistema deve atuar. Um framework ainda proporciona uma
maior reutilização de códigos e a fatoração de problemas em aspectos comuns a
várias aplicações, permite também obter sistemas com códigos menos frágeis e
com menos defeitos.
Entretanto, caso se decida construir um framework deve ter em mente que é uma
tarefa complexa, pois o reuso não acontece por acaso, devendo ser
adequadamente planejado. Iniciar a construção de um framework sem um bom
planejamento pode trazer mais prejuízos do que vantagens.
Com certeza, construir uma aplicação e construir um framework paralelamente,
demora muito mais do que construir uma aplicação isolada. Isso tudo pelo fato de
que quando se constrói um framework, deve-se planejá-lo de forma que atenda a
mais do que uma aplicação, ou seja, atenda a um domínio específico de aplicações
e não somente uma. As vantagens de um framework só aparecem em longo prazo,
na medida em que a estrutura se torna consistente e de domínio das equipes de
desenvolvimento.
21
3.3.3 Programação Java Web (Plataforma de Desenvolvimento).
Os critérios que mais contribuíram para selecionar as ferramentas que
utilizaremos ao longo do livro são simples: popularidade e experiência. Além das
ferramentas selecionadas estarem entre as mais populares, elas fazem parte do dia-
a-dia dos autores. Isso com certeza possibilita criar um texto ao mesmo tempo
técnico e composto de dicas, que são baseadas na experiência adquirida pelo uso
de tais ferramentas.
Além disso, se você desenvolver seu projeto usando o Apache Tomcat e o
MySQL, encontrará com mais facilidade algum serviço de hospedagem que tenha
exatamente essa configuração. Não basta ter uma excelente ideia de um novo
produto para a internet e executá-lo somente em seu computador doméstico. É
preciso pensar no futuro: seu produto pode ser o próximo a ser comprado por alguns
milhões de dólares por alguma megaempresa da internet.
3.4 PROJETO ORIENTADO A OBJETOS
Desafio 04
22
A melhor solução para China Telecom 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 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.
Para a Gamma et al. 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 ideia é
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,
23
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 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 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,
24
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 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.
5. 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. 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 está por sua vez acessa e atualiza-se
25
para o usuário assim funciona a arquitetura MVC em conjunto com os padrões de
projetos.
Ferramenta Utilizada
No caso do desenvolvimento do sistema China Telecom 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. Entre muitas
melhorias, esta versão dará suporte às plataformas PHP, JavaScript e Ajax, Ruby e
Ruby on 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
atualmente, o Netbeans torna-se um excelente IDE para desenvolvimento.
26
4 CONCLUSÃO
A China Telecom se concentrará em usar o sistema para uma 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ário.
27
REFERÊNCIA
Silva, Flávio de Almeida e. Desenvolvimento Orientado a Objetos I. São Paulo: Pearson Prentice Hall, 2009.
Perine, Luis Cláudio. Engenharia de Software / Luis Cláudio Perine, Marco Ikuno Hisatomi, Wagner Luiz Berto. São Paulo: Pearson Prentice Hall, 2009.
Sommerville, Ian. Engenharia de Software,8ª edição. São Paulo: Pearson Addison-Wesley, 2007.
28
