Portifolio Ind 5 periodo unopar
-
Upload
fernanda-mota -
Category
Documents
-
view
40 -
download
4
description
Transcript of Portifolio Ind 5 periodo unopar
1
SISTEMA DE ENSINO PRESENCIAL CONECTADO
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
FERNANDA SILVA MOTA
PORTIFÓLIO INDIVIDUAL
Rio Branco- Acre
2015
2
FERNANDA SILVA MOTA
PORTIFÓLIO INDIVIDUAL
Atividade interdisciplinar individual para obtenção de nota
semestral do curso superior de tecnologia em análise e
desenvolvimento de sistemas, curso oferecido pena
Universidade Norte do Paraná
Rio Branco- Acre
2015
3
Sumário
1 Introdução ..........................................................................................................................................4
2 Objetivo .............................................................................................................................................5
3 Áreas de conhecimento segundo PMBoK .........................................................................................6
3.1.1 Área de conhecimento de riscos. ...........................................................................................6
3.1.2 Área de conhecimento de escopo ..........................................................................................6
3.1.3 Área de conhecimento de fornecedores .................................................................................7
3.1.4 Área de conhecimento partes interessadas ............................................................................7
4 Engenharia de Software ...................................................................................................................8
4.1. Projeto de Arquitetura. ............................................................................................................8
4.2. Arquitetura de sistemas distribuídos. ....................................................................................11
4.3. Arquitetura de aplicações. .....................................................................................................13
4.4.Gerenciamento de configurações............................................................................................14
5 Frameworks para plataforma Web ..................................................................................................16
6 Projeto China Telecon. ....................................................................................................................28
Conclusão. ..........................................................................................................................................32
5 Referências ......................................................................................................................................33
4
Introdução
Esta produção interdisciplinar do 5º semestre do curso de analises e
desenvolvimento de sistemas, tem como objetivo exercitar os conteúdos assimilados no
período elencando os diversos conceitos, técnicas e práticas.
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).
O PMBoK é um guia de conhecimento em gerenciamento de projetos que foi
criado e está constantemente sendo atualizado pelos profissionais que fazem parte da
área de gerenciamento de projetos
Realizando um estudo do livro Engenharia de software – Ian Sommerville 8ª
Edição, teve como intuito realizar uma resenha dos seguintes capítulo 11 Projeto de
arquitetura, capítulo 12 arquiteturas de sistemas distribuídos, capítulo 13 arquiteturas de
aplicações e capítulo 29 gerenciamento de configuração.
Os capítulos 11 á 13 tratam da estrutura abstratas de software, estruturação de
software para execução distribuídas, estruturas genéricas para tipos de aplicações e o
capítulo 29 apresenta o processo de gerenciamento de código e documentação no
desenvolvimento do sistema de software.
Assim poderemos entender porque a empresa decidiu contratar do que ela
mesmo desenvolver o software necessário.
Atualmente, existem frameworks para todo o tipo de aplicação, desde
programação de dispositivos móveis até programação para Web. Ao longo desse
trabalho, são tratados os frameworks que se referem ao desenvolvimento Web.
5
Objetivo
O objetivo deste trabalho aprendizagem o aluno quanto ao assunto respectivo às
disciplinas do curso de analise e desenvolvimento de sistemas do 5º período,
trabalhando o conteúdo do eixo temático e auxiliar nas aplicações dos conceitos
temáticos, Projeto Orientado a Objetos, Engenharia e Projeto de Software E
Programação para Web II.
6
3. Áreas de conhecimento segundo PMBoK.
O PMBoK é um guia de conhecimento em gerenciamento de projetos que foi
criado e está constantemente sendo atualizado pelos profissionais que fazem parte da
área de gerenciamento de projetos. O guia PMBoK define áreas de conhecimento na
qual cada área possui alguns dos 42 processos do guia que estão devidamente separados
em cada uma das suas respectivas áreas de conhecimento.
3.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 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, 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.
3.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.
7
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 confirma 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.
3.3 Área de conhecimento –Fornecedores.
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 a 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.4 Área de conhecimento – Partes Interessadas.
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.
8
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, determinam 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.
Reportar Desempenho.
4.0 Resenha Livro Engenharia de Softwre de Lan Sommerville.
Capítulo 11 explica perspectivas estruturais consideradas úteis no projeto de
software, o capítulo 12 trata da estruturação de software para execução distribuida , o
capítulo 13 trata das estruturas genéricas para vários tipos de aplicações que podem ser
usadas como um ponto de partida para a indentificação de subsistemas, o capítulo 29
comprenderá porque o gerenciamento de software e necessário para sistesmas
complexos.
4.1 Projeto de Arquitetura.
O processo inicial de projetos, que consiste em indentificar subsistemas e
estabelecer um framework para o controle e a comunicação de subsistemas é chamado
de projeto de arquitetura, o projeto de arquiterura e o primento estagio do processo de
projeto.
Bass et al. (Bass, et al.,2003) Explicam três vatagens de projetar e documentar
explicitamente uma arquiterura de software:
9
1. Comunicação de stakeholders.
2. Analises de sistemas.
3. Reuso em larga escala.
A arquiterura de sistema afeta o seu desempenho podendo falicitar ou não a
distribuição e manutenção do sistema.
Decisões de projeto de arquitetura.
O projeto de arquitetura é um processo criativo em que se tenta estabelcer uma
organização de sistema que satifaça os requisitos funcionais do sistemas.Ao projetar
uma arquiterura de sistemas, voce precisa decidir o que o sistema e classes tem em
comum, e decidir quanto conhecimento dessas arquiteturas você pode usar.
A arquitetura de um sitemade software pode ser baseada em um modelo ou estilo
de arquitetura específica ou varios estilos de arquiteturas , tem que escolher qual a
estrutrua mais apropriada, como a estrutura cliente-servidor ou em camadas, no
processo de modelagem de controle, você deve tomar decisões sobre como a execução
de susbsitencias é controlada, avaliação e para ver quão bem ela atende os requisitos
funcionais e não funcionais depois de implantada.
Organização de sistema.
A organização de um sistema reflete a estratégia que vai ser usada para
estruturá-lo, sua organização via refletir diretamente na estrutrua do subsistema.
O modelo repositório.
Os subsistemas que constituem um sistema devem trocar informações de modo
que possam trabalhar juntos eficientemente.
A maioria dos sistemas que usam grandes quantidades de dados é organizada
com base em banco de dados ou repositório compartilhado. Esse modelo é, portanto,
adequado para aplicações em que os dados são gerados por um sistema e usados por um
outro.
O modelo cliente-servidor.
10
O modelo cliente- servidor é um modelo em que o sistema é organizado como
um conjunto de serviços e servidores e clientes associados que acesssm e usam os
serviços.
As vantagens mais importantes de um modelo cliente- servidoré que ele é uma
arquitetura distribuida. O Uso efetivo de sitemas em rede pode ser feito com muitos
processadores distribuídos.
O modelo em camadas.
O modelo em camadas de arquiteturas organiza um sistema em camadas, cada
uma das quais fornecendo um conjunto de serviços,uma desvantagem da abordagem é
que a estruturação de sistemas dessa maneira pode ser difícil, as camadas mais internas
podem fornecer recursos básicos, como gerenciamento de arquivosm necessários em
todos os níveis.
Estilos de decomposição modular.
A abodagem na descomposição de subsistemas em módulos, os componentes em
módulos são geralmente menores que os subsitemas, que permitem a ultilização de
estilos alternativos de descomposição.
As vantagens de evitar um projeto de sistema concorrente é que programas
equenciais são mais fáceis de projetar , implementar e testar do que sistemas paralelos.
Decomposição orientada a objetos.
A arquittura orientada a objetos estrutura o sistema em um conjunto de objetos
não firmemente aclopados com interfaces bem definidas.Uma decomposição orientada a
objetos está relacionada a classes de objetos, seus atributos e sua operações.
As vantagens da abordagem orientada a objetos , devido não serem firmente
aclopados, a implementação de objetos pode ser modificada sem afetar outros objetos.
As desvantagens para usar serviços, os objetos devem fazer referência explícita
ao nome e á interface de outros objetos.
11
Pipeling orientado a funções.
Em um pipeling orientado a funçoes as trasnformações funcionais processam
suas entradas e produzem saídas, ou seja um sistema de processamento de faturas, as
vantagens e a evolução do sistema pela adição de novas transformações e geralmente
direta.
O principal problema com esse estilo é que ele necesita ser um formato comum
para transferencia de dados que possa ser reconhecido por todas as transformações.
Modelos de Controle.
Modelos de controle são usados em conjunto com estilos de etrutruras. Todos os
estilos de estrutrura podem ser implementados por meio de controle centralizado ou
baseado em eventos
Controle centralizado.
Um sistema de controle centralizado é designado como controlador de sistema e
tem a responsabilidade pelo gerenciamento da execução de outros subsistemas.
Sistemas orientados a eventos.
Os modelos orientados a eventos são regidos pelos eventos gerados
externamente. Existem muitos tipos de sistemas orientados a eventos ,estes incluem
editores em que os eventos de interface com o usuario significam comandos de edição,
sistema de produção baseados em regras como as usadas em inteligencia artificial.
Arquiteturas de refência.
As arquiteruras de referência não são geralmente consideradas um roteiro de
implementação. Em vez disso, sai princiapal função é ser um meio de discurção de
arquiteturas de domínio específico e de comparação de sistemas diferentes em um
domínio. Um modelo de renferência fornece um vocabulário para comparação, ele atua
como uma base em relaçao á qual os sitemas podem ser avaliados.
4.2. Arquiteturas de sistemas distribuídos.
12
Praticamente todos os sistemas baseados em grande computadores atualmente
são sistemas distribuídos .Um sistemas distriuído é aquele em que as infromações em
fase de processamento são distribuídos para vários computadores, em vez de ficarem
confinados em uma única máquina.
Arquiteturas cliente-servidor.
Arquiterura cliente – servidor é chamada de arquiterura cliente – servido de duas
camadas, naqual uma aplicação é organizda como um servidor ou vários servidores
idênticos , modelo cliente magro e modelo cliente –gordo.
Arquitetura de objetos distribuídos.
Uma arquitetura de objetos distribuídos pode ser usada como um modelo lógico
que perminte estruturar e organizar o sistema.
CORBA
O modelo de objeto CORBA considera um objeto como se fosse um
encapsulamento de atributos e serviços,como é normal em objetos.Contudo, os objetos
CORBA devem ter uma definicção de interface separada que define os atributos e
opreações públicas do objeto. As interface de objetos CORBA são definidas por meio
de uma linguagem de definição de interface padronizada independente de linguagem.
Computação interorganizacional distriuída.
Por motivo de proteção e interorganizacional, a computação distribuída foi
implementada inicialmente em nível organizacional.
Arquiteturas ponto a ponto.
Sistemas ponto a ponto são sistemas descentralizaos em que as computações
podem ser realizadas por qualque nó da rede e, em prncípio pelo menos, nenhuma
distinção é feita entre clientes e servidores.
Sistemas ponto a ponto é uma abordagem muito mais eficiente para computação
interorganizacional que a abordagem baseada enm serviços, os sistemas ponto a ponto
13
sõ mais adequados a sistemas de informações não críticos ou nos quais já existam
relacionamentos de trabalho entre as organizações.
Arquitetura de sitema orientada a serviços.
Corresponde a uma metodologia para desenvolvimento de software, serviços,
representa todos ativos de softwares da empresa. Também podemos descrever neste
caso serviços. Como sendo um componente, uma parte de desenvolvimento de um
software onde ao fazer a junção de todos os ”módulos”, teremos um software completo
para aquela determinada função para que foi desenhado, produto final do escopo do
projeto onde foi determinado a criação de um serviço.
4.3 Arquiteturas de aplicações.
Sistemas de aplicações são criados para atender necessidades de negócio ou
organizacionais.
Sistemas de processamento de dados.
Os sistemas de processamento de dados são sistemas de procesamento em lotes
nos quais os dados são entradas e saídas em lotes de um arquivo ou banco de dados em
vez de entradas e saídas par um terminal de usuário.
Sistemas de processamento de transações.
Os sistemas de processamento de transações são projetados para processar
solicitações de informações por usuários de um banco de dados pou solicitações para
atualizar o banco de dado.
Sistemas de gerenciamento de informações e recursos.
Sistemas de informação e a interação com um banco de dado compartilhado, ele
permite acesso controlado de uma grande base de informações, tais como bibliotecas e
registros de pacientes.
Sistemas de processamento de eventos.
Os sistemas de processamento de eventos respondem aos eventos do ambiente ou da
14
interface com o usuário do sistema. Sua principal característica é que a sequência de
eventos é imprevisível e o sistema deve ser capaz de trabalhar com esses eventos
quando eles ocorrerem.
Sistemas de processamento de linguagens.
Esses sistemas aceitam uma linguagem natural ou artificial como entrada e
geram alguma outra representação dessa linguagem como saída. Em engenharia de
software, os mais usados são os compiladores que traduzem uma linguagem artificial
de programação de alto nível em código de máquina.
4.4 Gerenciamento de configurações.
Compreende o quando o gerenciamento de software e importante para sistemas
complexos, e como as ferramentas CASE são utilizadas para apoiar os processos de
gerenciamento.
Planejamento de gerenciamento de configurações.
O Gerenciamento de configurações descreve os padrões e procedimentos que
devem ser usados para o gerenciamento. O ponto de partida para o desenvolvimento
deve ser adaptado para se atender aos requisitos e as restrições de cada projeto
específico.
Identificação de item de configuração.
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 uteis 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.
Os nomes de itens de configuração associam componentes com um projeto
especifico e, dessa maneira, reduzem as oportunidades para o reuso, podendo ser muito
15
difícil encontrar componentes relacionados.
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. Usa-se o banco de dados CM para auxiliar a
avaliação do impacto das mudanças de sistema e para gerar relatórios para a gerência
sobre o processo de CM. 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.
Gerenciamento de mudanças.
Procedimentos de gerenciamento de mudança dizem respeito a análise de custo e
benefício das mudanças propostas, a aprovação das mudanças viáveis e a rastreabilidade
de quais componentes do sistema foram alterados.
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.
Gerenciamento de versões e releases.
Os processos envolvidos no gerenciamento de versões e releases preocupam-se
com a identificação e a manutenção da rastreabilidade das versões de um sistema. 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.
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.
As três técnicas básicas para identificação da versão de componentes são:
Numeração de versões.
Identificação baseada em atributos.
16
Identificação orientada a mudanças.
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.
Construção de sistemas.
A construção de sistemas é um processo de compilação e ligação de
componentes de software num programa que executa determinada configuração
definida. Durante sua construção, pode-se questionar o seguinte; você deve pensar nas
seguintes questões: Todos os componentes que compõem um sistema foram incluídos
nas instruções de construção? Todos os arquivos de dados necessários estão
disponíveis? A versão apropriada do compilador e de outras ferramentas requeridas está
disponível?
.
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.
5.0 Frameworks para plataforma Web.
Comparativo entre os frameworks para desenvolvimento Web.
17
O quadro 1 apresenta um breve comparativo sobre as tecnologias apresentadas
anteriormente. As informações contidas nesse quadro foram retiradas das apresentações
dos frameworks contidas nesse capítulo, e todas as referências são as mesmas usadas no
item 2.2. Através das características abordadas nesse quadro pode-se usar como base na
escolha de um framework em detrimento a outro, por exemplo, caso o projeto necessite
de apoio para a camada de controle (MVC) recomenda-se o uso de Struts, porém se o
foco for ajudar no desenvolvimento de interfaces gráficas é mais interessante o uso da
recente Java FX ou até tags JSP 4que também oferecem suporte à criação de
componentes de interface. No quadro são expostas todas as principais características,
objetivos e versão atual do framework.
Quadro 1 Quadro comparativos de framework.
Objetivos Vantagens Características
Struts Tornar
independentes
as camadas de
lógica de
negócio
interface, dados;
Reusabilidade
Os componentes do
Strutus são
reutilizáveis pela
aplicação.
Sua utilização
proporciona uma
melhora no
desempenho de
aplicativo Web.
Usa a arquitetura MVC.
Compatível com os padrões
de desenvolvimento.
Spring Retirar as
informações do
objeto sobre
suas
dependências e
as colocá-las em
arquivos de
configurações.
Desacoplamento
entre objetos,
tomando as
aplicações menos
amarradas entre si.
Baseado em injeções de
dependências.
JSF Reduzir o esforço
necessário para
criar páginas JSP
Possui uma poderosa
linguagem de
expressão para acessar
Incorpora características de
um framework MVC - Permite
uma divisão clara entre as
18
com
processamento
feito por servlets;
Facilitar e
padronizar a
criação de
componentes de
interfaces
gráficas na
internet;
propriedades de
beans5 e coleções;
JSF torna fácil
associar código Java
que irá responder a
determinados eventos
em páginas HTML
(HyperText Markup
Language,);
camadas.
Modelos de interfaces gráficas
baseadas em eventos;
JPA Através do
mapeamento das
entidades Java,
proporciona a
persistência dos
objetos Java;
Forma simples de
mapear objetos no
banco de dados;
Padroniza o
mapeamento
Objeto/Relacional
(O/R);
Solução completa para
mapeamento e persistência de
objetos: modo declarativo de
descrever mapeamento O/R,
linguagem de consulta,
ferramentas para manipular
entidades;
Jasper
Reports
Gerar relatórios
de forma
confiável e
eficiente em
sistemas Web e
Desktop;
Facilidade na criação
de relatórios em Java
graças a ferramenta
visual iReport,
possibilitando criar
visualmente um
relatório para um
sistema desenvolvido
em Java;
Geração de relatórios em
diversos formatos; -
Ferramenta visual
especialmente para o
framework; última versão
contém: suporte ao gráfico de
área empilhado; pequenas
correções de bugs e melhorias;
DWR Permitir que
trechos de código
JavaScript na
camada cliente
invoquem
métodos em
objetos Java no
servidor;
Intregração com
Servlets, Spring,
Annotations e outras
tecnologias; Facilita o
desenvolvimento, em
código Java;
Orientado a objetos;
Código aberto;
Esta uma camada acima
XMLHttpRequest;
Java FX Tornar simples a
criação de GUI e
Tem um estilo
declarativo, nas quais
Linguagem de Script, similar
ao
19
interfaces; a estrutura visual se
reflete diretamente na
linguagem de
programação;
A simplicidade no
vínculo entre dados e
elementos visuais;
CSS (Cascading Style Sheets)
do
HTML (HyperText Markup
Language);
Relativamente nova, recém
lançada em maio de 2007;
Os frameworks que foram apresentados nse capítulo estão entre os mais
utilizados e conhecidos e destaca-se que a maior vantagem entre eles é a facilidade de
muitos desses frameworks integrarem-se, ou seja, serem utilizados em um mesmo
projeto em conjunto, o que, em muitos casos, melhora muito o processo de
desenvolvimento, a produtividade e a qualidade do produto final.
Frameworks De Persistência.
Quando falamos de frameworks voltados para persistência e bancos de dados,
felizmente, não há tanta dúvida quanto no mundo dos frameworks Web. O Hibernate é
praticamente unanimidade no mercado Java, principalmente se usado como
implementação da JPA. Há outras possibilidades, como o Toplink, o EclipseLink, o
OpenJPA, o DataNucleus, o JDO, o iBatis etc. Mas o Hibernate é o mais importante.
Custo/ Benefícios de usar frameworks no desenvolvimento Web.
Sabe-se que o preço do produto final é proporcional ao custo despendido com ele,
por isso uma análise mal feita sobre quais recursos serão empregados no projeto poderá
acarretar um alto preço de venda. O uso de um framework em projetos de software traz
benefícios e custos que devem ser analisados no momento de se escolher quais
ferramentas serão utilizadas na aplicação a ser construída.
As vantagens do uso de frameworks nos projetos, de acordo com Assis e Sauvê são:
Baixo tempo de codificação: devido à estrutura semi-pronta, muitas
funcionalidades necessárias já estão disponíveis;
Uso de soluções bem testadas por outras pessoas: conforme o uso de framework
aumenta, estes passam a adquirir maturidade ao se descobrirem erros e adicionar
novas funcionalidades;
20
Desenvolvedores se preocupam em implementar o que é necessário: não é
preciso que se codi_que todo o software, pois se utiliza os componentes que já
estão prontos;
Menor probabilidade de erros nos códigos: com uso de frameworks, menos
linhas de código são escritas pelos programadores, diminuindo, assim, a
possibilidade de erros comuns.
Por outro lado, existem desvantagens provindas do uso de frameworks. De acordo
com Assis e Sauvê essas desvantagens são:
Frameworks requerem pessoas especializadas: para a utilização de um
framework, deve-se possuir uma equipe com conhecimentos e para isso, é
necessário que se façam treinamentos, demandando tempo e aumentando o
prazo final para o produto;
Depuração dos programas mais difícil: se o fabricante do framework não
disponibilizar os códigos-fonte, _cará difícil de se encontrar possíveis erros,
visto que estes podem estar contidos nos objetos do framework;
21
Mudança do foco de desenvolvimento: os desenvolvedores têm que assimilar
ideias que, na maioria das vezes, foram propostas por pessoas que não fazem
parte da sua equipe de trabalho;
Implementação em linguagem específica: como os frameworks são
desenvolvidos em linguagens de programação específicas, perde-se
portabilidade em relação às linguagens que podem ser usadas em conjunto com
o framework. Tal restrição obriga os desenvolvedores a utilizar a mesma
linguagem empregada pela solução adotada.
Requistos necessário para implentar e disponibilizar uma aplicação Web.
O objetivo é aprender, então será criado um serviço bem simples. O serviço é a
soma de duas variáveis inteiras retornando o resultado. Este exemplo poderá servir para
qualquer outra implementação. Abaixo está a classe implementada. O nome do arquivo
é Servico.java:
public class Servico {
public int soma(int valor1, int valor2) {
return valor1 + valor2;
}
}
Agora só falta disponibilizá-lo no nosso servidor para o mundo acessar. E, para
fazer isso, deve-se alterar o nome do arquivo de Servico.java para Servico.jws, colocá-
lo no diretório: CATALINA_HOME / webapps / axis / e iniciar o servidor, se ele já não
estiver iniciado. Se já estiver iniciado, o seu Web Service está publicado.
Os arquivos. jws são lidos pelo Axise representam Java Web Services. O Axis se
baseará nesses arquivos (. jws) para criar os arquivos de definição WSDL. Todos os
métodos públicos existentes nessas classes serão automaticamente disponibilizados para
terceiros.
Criar documentos XML é demorado e, muitas vezes, chato. Gerar o WSDL é uma
característica muito relevante na escolha de uma implementação de SOAP e oAxisé um
dos poucos frameworks que conseguem fazer essa façanha de maneira transparente para
22
o desenvolvedor. É por esse motivo que ele é altamente recomendado na construção de
Web Services.
1. <?xml version="1.0" encoding="UTF-8"?>
2. <wsdl:definitions targetNamespace="http://localhost:8080/axis/Servico.jws"
3. xmlns="http://schemas.xmlsoap.org/wsdl/"
4. xmlns:apachesoap="http://xml.apache.org/xml-soap"
5. xmlns:impl="http://localhost:8080/axis/Servico.jws"
6. xmlns:intf="http://localhost:8080/axis/Servico.jws"
7. xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
8. xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
9. xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
10. xmlns:xsd="http://www.w3.org/2001/XMLSchema">
11. <wsdl:message name="somaRequest">
12. <wsdl:part name="valor1" type="xsd:int"/>
13. <wsdl:part name="valor2" type="xsd:int"/>
14. </wsdl:message>
15. <wsdl:message name="somaResponse">
16. <wsdl:part name="somaReturn" type="xsd:int"/>
17. </wsdl:message>
18. <wsdl:portType name="Servico">
19. <wsdl:operation name="soma" parameterOrder="valor1 valor2">
20. <wsdl:input message="impl:somaRequest" name="somaRequest"/>
21. <wsdl:output message="impl:somaResponse" name="somaResponse"/>
22. </wsdl:operation>
23. </wsdl:portType>
24. <wsdl:binding name="ServicoSoapBinding" type="impl:Servico">
25. <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/h
ttp"/>
26. <wsdl:operation name="soma">
27. <wsdlsoap:operation soapAction=""/>
28. <wsdl:input name="somaRequest">
29. <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodin
g/"
23
30. namespace="http://DefaultNamespace" use="encoded"/>
31. </wsdl:input>
32. <wsdl:output name="somaResponse">
33. <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodin
g/"
34. namespace="http://localhost:8080/axis/Servico.jws" use="encoded"/>
35. </wsdl:output>
36. </wsdl:operation>
37. </wsdl:binding>
38. <wsdl:service name="ServicoService">
39. <wsdl:port binding="impl:ServicoSoapBinding" name="Servico">
40. <wsdlsoap:address location="http://localhost:8080/axis/Servico.jws"/>
41. </wsdl:port>
42. </wsdl:service>
43. </wsdl:definitions>
Analisar este arquivo é essencial para entender a profundidade da implementação.
Uma das linhas mais importantes para este arquivo é a linha 19, onde define-se o nome
do método e o nome de seus parâmetros. Eles deverão ser de conhecimento público para
que as interfaces cliente consigam se comunicar com o Web Service.
Realizando um teste básico.
O Axis aceita que um Web Service seja chamado via uma requisição HTTP-
GET. Portanto, ao digitar um endereço é possível testar o web service.
No exemplo deste artigo o endereço é
este:http://localhost:8080/axis/Servico.jws?method=soma&valor1=2&valor2=4. Como
pode-se notar, o endereço é a junção de um namespace, que é o endereço do
WebService representado porhttp://localhost:8080/axis/Servico.jws, a variável
methodque, como seu nome diz, contém o nome do método que se deseja executar, e
uma sequência dos parâmetros deste método. Lembrando que o nome dos parâmetros
deve ser o mesmo definido na função da classe.
24
O resultado da execução é um documento XML com a resposta6. Novamente,
dependendo do browser não será visível as tags XML. O XML que retornou na
execução está abaixo:
01 <?xml version="1.0" encoding="UTF-8"?>
02 <soapenv:Envelope
03 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
04 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
05 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
06 <soapenv:Body>
07 <somaResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encodin
g/">
08 <somaReturn xsi:type="xsd:int">6</somaReturn>
09
10 </somaResponse>
11 </soapenv:Body>
12 </soapenv:Envelope>
Criando um cliente em Java para acessar o Servidor.
O cliente também é uma classe simples, mas exige conhecimento em algumas
classes não tão comuns no dia-a-dia. As classes Service e Call são classes doAxis,
portanto, para compilar e executar esta classe é necessário que todo o diretório lib,
encontrado dentro do zip doAxisesteja no CLASSPATH da aplicação.
Visto este detalhe, abaixo encontra-se o arquivo fonte do cliente de Web
Service. Esta classe fará a conexão ao Web Service para somar 2 com 4 e irá apresentar
o resultado 6 na saída padrão.
01 import org.apache.axis.client.Service;
02 import org.apache.axis.client.Call;
03
04 public class Cliente {
05 public static void main(String[] args) throws Exception {
06 // Endereço, local onde encontra-se o Web Service
07 String local = "http://localhost:8080/axis/Servico.jws";
08
25
09 // Criando e configurando o serviço
10 Call call = (Call) new Service().createCall();
11 // Configurando o endereço.
12 call.setTargetEndpointAddress(local);
13 // Marcando o método a ser chamado.
14 call.setOperationName("soma");
15
16 // Parâmetros da função soma.
17 Object[] param = new Object[]{new Integer(2),new Integer(4)};
18 // Retorno da Função
19 Integer ret = (Integer)call.invoke(param);
20
21 // Imprime o resultado: ret = 2 + 4.
22 System.out.println("Resultado da soma : " + ret);
23 }
24 }
Este código está dentro de um arquivo chamado Cliente.java, após compilar e
executar esta classe exibirá o resultado " Resultado da soma: 6 " como desejado.
O framework do Axis trata a primitivainte a classe wrapper Integer como sendo
iguais. Portanto, tanto faz usar uma ou outra. Neste exemplo, foi criado o Web Service
com dois parâmetros Integer.
Como pode-se notar, o framework do Axis abstrai qualquer trabalho com XML,
evitando que o desenvolvedor necessite conhecer a sintaxe do XML do SOAP.
Acessando o Web Service via J2ME.
Para este passo, é necessário que o Java Wireless Toolkit esteja instalado e
funcionando no ambiente.
A comunicação com Web Services se dá através de XML e do protocolo SOAP.
Como o J2ME não possui classes para tratar estas implementações, é necessário utilizar
outros dois projetos para atender as transparências. Os projetos são oKSOAPe
oKXMLdaObjectWeb. Ambos estão sob licença pública.
26
Como pretende-se criar uma simples aplicação para celular (MIDP2), será
utilizado a fonte dos dois projetos junto um outro arquivo fonte que será criado. É o
jeito mais fácil de executar uma aplicação J2ME com duas bibliotecas
O fonte doKSOAPpode ser encontrado
aqui:http://ksoap.objectweb.org/software/downloads/current/ksoap-source.zip
E o fonte doKXMLpode ser encontrado
aqui:http://kxml.objectweb.org/software/downloads/current/kxml-source.zip
1. # SeuProjetoJ2ME
2.
3. * org
4. o kxml
5. o - -
Todas as suas pastas e arquivos internos a esta pasta que estão no zip. kobjects
6. o - -
Todas as suas pastas e arquivos internos a esta pasta que estão no zip. ksoap
7. + transport
8. - - Necessário excluir o pacote marshal.
Não serão utilizados as pastas referentes a servlets e a j2se do ksoap. Somente
referente a J2ME e ao fonte básico.
No diretório SeuProjetoJ2ME, deve ser criado a classe ClienteJ2ME.java
conforme abaixo:
1. import javax.microedition.lcdui.Display;
2. import javax.microedition.lcdui.TextBox;
3.
4. import org.ksoap.SoapObject;
5. import org.ksoap.transport.HttpTransport;
6.
7. public class ClienteJ2ME extends javax.microedition.midlet.MIDlet {
8. private Display display;
9. private String url = "http://localhost:8080/axis/Servico.jws";
10. TextBox textbox = null;
27
11.
12. public void startApp() {
13. display = Display.getDisplay(this);
14. try {
15. testWebService();
16. } catch (Exception ex) {
17. System.out.println(ex);
18. }
19. }
20.
21. public void pauseApp() {}
22. public void destroyApp(boolean unconditional) {}
23.
24. public void testWebService() throws Exception {
25. StringBuffer stringBuffer = new StringBuffer();
26.
27. TextBox textBox = null;
28.
29. // Chama o WebService
30. SoapObject client = new SoapObject(url,"soma");
31. client.addProperty("valor1",new Integer(2));
32. client.addProperty("valor2",new Integer(4));
33. HttpTransport ht = new HttpTransport(url,"soma");
34. stringBuffer.append("
35. Resultado: " + ht.call(client));
36.
37. // mostra o valor do resultado na tela.
38. textBox = new TextBox("Teste WebService", stringBuffer.toString(), 1024, 0
);
39. display.setCurrent(textBox);
40. }
41. }
28
6.0 Projeto China Telecon ,Funcionalidades, aplicações dos padrões de criação.
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 a 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 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,
29
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 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.
30
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 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 á 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.
31
Utilizando essa arquitetura, o tempo de desenvolvimento do software diminuirá
sem perde a qualidade e sem aumento de custos. Frameork 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
32
Conclusão
O presente trabalho foi realizado uma pesquisa bibliográfica, baseada nos
assuntos tratados nas disciplinas de Engenharia e Projeto de Software, Projeto
Orientado a Objetos e Programação para Web II para melhor compreensão.
Conhecendo a melhor arquitetura MVC que seria a melhor opção para o projeto
China telecon, que teria que desenvolver seu próprio software para reduzir os custos,
sendo necessário também reduzir o tempo de desenvolvimento do mesmo e mantendo a
qualidade e produtividade no seu desenvolvimento.
.
33
Referências.
AVANSINI, Régis da Silva. Investigação da efetividade de um Framework Corporativo
de persistência de dados com base no Framework NHibernate em um ambiente
empresarial. Universidade Estadual de Maringá Centro de Tecnologia – Departamento
de Informática, Maringá, 2012,
APACHE, Struts. Disponível em: . Acesso em 11 de maio de 2009.
BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web.
Jaguariúna, 2007.
RAMOS, José Yoshiriro Ajisaka. Comparação entre os principais Frameworks Java
para o desenvolvimento de aplicações WEB 2.0. Instituto de Estudos Superiores da
Amazônia, Belém – PA, 2007.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edição. São Paulo:
Pearson Addison Wesley, 2007."
UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS
(Guia PMBoK), 4º edição. Pensylvania, PMI, 2008.
GOETTEN, V. JUNIOR. Desmistificando o framework Jakarta Struts. Java
Free.Disponível em: <http://www.javafree.org/content/view.jf?idContent=22>.
Acessado em: 11 Abril de 2015.
SAUVÊ, J. P. Frameworks. Notas de Aula. Paraíba : Universidade Federal da Paraíba,
2004. Disponível em: <http://www.dsc.ufcg.edu.br/ jacques/
cursos/map/html/map1.htm>. Acesso em: 11 de abril de 2015
SIELO - Frameworks. Disponível em:
<http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0034-76122011000500014>.
Acesso em: 11 maio de 2015.