SISTEMA DE ENSINO PRESENCIAL CONECTADO

TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS

FERNANDA SILVA MOTA

PORTIFLIO INDIVIDUAL

Rio Branco- Acre

2015
1

FERNANDA SILVA MOTA

PORTIFLIO INDIVIDUAL

Atividade interdisciplinar individual para obteno de nota

semestral do curso superior de tecnologia em anlise e
desenvolvimento de sistemas, curso oferecido pena
Universidade Norte do Paran

Rio Branco- Acre

2015
2

Sumrio
1 Introduo ..........................................................................................................................................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 distribudos. ....................................................................................11
4.3. Arquitetura de aplicaes. .....................................................................................................13
4.4.Gerenciamento de configuraes............................................................................................14
5 Frameworks para plataforma Web ..................................................................................................16
6 Projeto China Telecon. ....................................................................................................................28
Concluso. ..........................................................................................................................................32
5 Referncias ......................................................................................................................................33

Introduo
Esta produo interdisciplinar do 5 semestre do curso de analises e
desenvolvimento de sistemas, tem como objetivo exercitar os contedos assimilados no
perodo elencando os diversos conceitos, tcnicas e prticas.
O trabalho a seguir - China Telecom - prope 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
Edio, teve como intuito realizar uma resenha dos seguintes captulo 11 Projeto de
arquitetura, captulo 12 arquiteturas de sistemas distribudos, captulo 13 arquiteturas de
aplicaes e captulo 29 gerenciamento de configurao.
Os captulos 11 13 tratam da estrutura abstratas de software, estruturao de
software para execuo distribudas, estruturas genricas para tipos de aplicaes e o
captulo 29 apresenta o processo de gerenciamento de cdigo e documentao no
desenvolvimento do sistema de software.
Assim poderemos entender porque a empresa decidiu contratar do que ela
mesmo desenvolver o software necessrio.
Atualmente, existem frameworks para todo o tipo de aplicao, desde
programao de dispositivos mveis at programao para Web. Ao longo desse
trabalho, so tratados os frameworks que se referem ao desenvolvimento Web.

Objetivo
O objetivo deste trabalho aprendizagem o aluno quanto ao assunto respectivo s
disciplinas do curso de analise e desenvolvimento de sistemas do 5 perodo,
trabalhando o contedo do eixo temtico e auxiliar nas aplicaes dos conceitos
temticos, Projeto Orientado a Objetos, Engenharia e Projeto de Software E
Programao para Web II.

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 esto devidamente separados
em cada uma das suas respectivas reas de conhecimento.
3.1 rea de conhecimento Riscos.
Esta rea descreve os processos relativos realizao 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
sero identificados, analisados e como as respostas sero planejadas e como risco ser
planejado, criam uma lista de riscos identificados no projeto com diversas tcnicas que
ajudam a gerar essa lista de riscos, buscam priorizar os riscos com base no grau de
criticidade, permitem atribuir probabilidade numrica aos riscos, definem estratgias e
aes para lidar com os riscos negativos e positivos, monitoram os risco com novos
risco sendo identificados, reviso das anlises de riscos, definio de outras prioridades
de riscos, etc.
Os processos dessa rea so:

Planejar o Gerenciamento dos Riscos.

Identificar os Riscos.

Realizar a Anlise Qualitativa de Riscos.

Realizar a Anlise 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 verificao de que o projeto inclui
todo o trabalho necessrio e apenas o trabalho necessrio, para que seja concludo com
sucesso.

Existem trs processos de planejamento (trs 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
verificao confirma com o cliente que est tudo correto.
Os processos dessa rea so:

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, servios ou
resultados, alm dos processos de gerenciamento de contratos. Os processos desta rea
de conhecimento tm 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 esto de acordo com o que foi
estabelecido, pagar o fornecedor, e por ltimo formalizar a finalizao do contrato.
Os processos dessa rea so:

Planejar as Aquisies.

Realizar as Aquisies.

Administrar as Aquisies.

Encerrar as Aquisies.

3.4 rea de conhecimento Partes Interessadas.

Esta rea descreve os processos relativos gerao, coleta, disseminao,
armazenamento e destinao final das informaes do projeto de forma oportuna e
adequada.
7

Os processos desta rea de conhecimento determinam quem est envolvido no

projeto, definem como as comunicaes vo ocorrer quando o projeto iniciar e
determina o tipo de informaes gerada, quem o responsvel, qual o meio, quem
receber as informaes geradas, qual a periodicidade, determinam como sero
distribudas as informaes, como podemos gerenciar as expectativas dos interessados
medindo o grau de satisfao ou insatisfao das pessoas interessadas, e geram
relatrios que permitam o acompanhamento e controle do que est acontecendo com o
tempo, custo, escopo, etc.
Os processos dessa rea so:

Identificar as Partes Interessadas.

Planejar as Comunicaes.

Distribuio das Informaes.

Gerenciar as Expectativas das Partes Interessadas.

Reportar Desempenho.

4.0 Resenha Livro Engenharia de Softwre de Lan Sommerville.

Captulo 11 explica perspectivas estruturais consideradas teis no projeto de
software, o captulo 12 trata da estruturao de software para execuo distribuida , o
captulo 13 trata das estruturas genricas para vrios tipos de aplicaes que podem ser
usadas como um ponto de partida para a indentificao de subsistemas, o captulo 29
comprender porque o gerenciamento de software e necessrio 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 comunicao 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 trs vatagens de projetar e documentar
explicitamente uma arquiterura de software:

1. Comunicao de stakeholders.
2. Analises de sistemas.
3. Reuso em larga escala.
A arquiterura de sistema afeta o seu desempenho podendo falicitar ou no a
distribuio e manuteno do sistema.
Decises de projeto de arquitetura.
O projeto de arquitetura um processo criativo em que se tenta estabelcer uma
organizao de sistema que satifaa 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 especfica 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 decises sobre como a execuo
de susbsitencias controlada, avaliao e para ver quo bem ela atende os requisitos
funcionais e no funcionais depois de implantada.
Organizao de sistema.
A organizao de um sistema reflete a estratgia que vai ser usada para
estrutur-lo, sua organizao via refletir diretamente na estrutrua do subsistema.
O modelo repositrio.
Os subsistemas que constituem um sistema devem trocar informaes 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 repositrio compartilhado. Esse modelo , portanto,
adequado para aplicaes em que os dados so gerados por um sistema e usados por um
outro.
O modelo cliente-servidor.
9

O modelo cliente- servidor um modelo em que o sistema organizado como

um conjunto de servios e servidores e clientes associados que acesssm e usam os
servios.
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 distribudos.
O modelo em camadas.
O modelo em camadas de arquiteturas organiza um sistema em camadas, cada
uma das quais fornecendo um conjunto de servios,uma desvantagem da abordagem
que a estruturao de sistemas dessa maneira pode ser difcil, as camadas mais internas
podem fornecer recursos bsicos, como gerenciamento de arquivosm necessrios em
todos os nveis.
Estilos de decomposio modular.
A abodagem na descomposio de subsistemas em mdulos, os componentes em
mdulos so geralmente menores que os subsitemas, que permitem a ultilizao de
estilos alternativos de descomposio.
As vantagens de evitar um projeto de sistema concorrente que programas
equenciais so mais fceis de projetar , implementar e testar do que sistemas paralelos.
Decomposio orientada a objetos.
A arquittura orientada a objetos estrutura o sistema em um conjunto de objetos
no firmemente aclopados com interfaces bem definidas.Uma decomposio orientada a
objetos est relacionada a classes de objetos, seus atributos e sua operaes.
As vantagens da abordagem orientada a objetos , devido no serem firmente
aclopados, a implementao de objetos pode ser modificada sem afetar outros objetos.
As desvantagens para usar servios, os objetos devem fazer referncia explcita
ao nome e interface de outros objetos.

10

Pipeling orientado a funes.

Em um pipeling orientado a funoes as trasnformaes funcionais processam
suas entradas e produzem sadas, ou seja um sistema de processamento de faturas, as
vantagens e a evoluo do sistema pela adio de novas transformaes 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 transformaes.
Modelos de Controle.
Modelos de controle so 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 execuo de outros subsistemas.
Sistemas orientados a eventos.
Os modelos orientados a eventos so 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 edio,
sistema de produo baseados em regras como as usadas em inteligencia artificial.
Arquiteturas de refncia.
As arquiteruras de referncia no so geralmente consideradas um roteiro de
implementao. Em vez disso, sai princiapal funo ser um meio de discuro de
arquiteturas de domnio especfico e de comparao de sistemas diferentes em um
domnio. Um modelo de renferncia fornece um vocabulrio para comparao, ele atua
como uma base em relaao qual os sitemas podem ser avaliados.
4.2. Arquiteturas de sistemas distribudos.
11

Praticamente todos os sistemas baseados em grande computadores atualmente

so sistemas distribudos .Um sistemas distriudo aquele em que as infromaes em
fase de processamento so distribudos para vrios computadores, em vez de ficarem
confinados em uma nica mquina.
Arquiteturas cliente-servidor.
Arquiterura cliente servidor chamada de arquiterura cliente servido de duas
camadas, naqual uma aplicao organizda como um servidor ou vrios servidores
idnticos , modelo cliente magro e modelo cliente gordo.
Arquitetura de objetos distribudos.
Uma arquitetura de objetos distribudos pode ser usada como um modelo lgico
que perminte estruturar e organizar o sistema.
CORBA
O modelo de objeto CORBA considera um objeto como se fosse um
encapsulamento de atributos e servios,como normal em objetos.Contudo, os objetos
CORBA devem ter uma definico de interface separada que define os atributos e
opreaes pblicas do objeto. As interface de objetos CORBA so definidas por meio
de uma linguagem de definio de interface padronizada independente de linguagem.
Computao interorganizacional distriuda.
Por motivo de proteo e interorganizacional, a computao distribuda foi
implementada inicialmente em nvel organizacional.
Arquiteturas ponto a ponto.
Sistemas ponto a ponto so sistemas descentralizaos em que as computaes
podem ser realizadas por qualque n da rede e, em prncpio pelo menos, nenhuma
distino feita entre clientes e servidores.
Sistemas ponto a ponto uma abordagem muito mais eficiente para computao
interorganizacional que a abordagem baseada enm servios, os sistemas ponto a ponto
12

s mais adequados a sistemas de informaes no crticos ou nos quais j existam

relacionamentos de trabalho entre as organizaes.
Arquitetura de sitema orientada a servios.
Corresponde a uma metodologia para desenvolvimento de software, servios,
representa todos ativos de softwares da empresa. Tambm podemos descrever neste
caso servios. Como sendo um componente, uma parte de desenvolvimento de um
software onde ao fazer a juno de todos os mdulos, teremos um software completo
para aquela determinada funo para que foi desenhado, produto final do escopo do
projeto onde foi determinado a criao de um servio.
4.3 Arquiteturas de aplicaes.
Sistemas de aplicaes so criados para atender necessidades de negcio ou
organizacionais.
Sistemas de processamento de dados.
Os sistemas de processamento de dados so sistemas de procesamento em lotes
nos quais os dados so entradas e sadas em lotes de um arquivo ou banco de dados em
vez de entradas e sadas par um terminal de usurio.
Sistemas de processamento de transaes.
Os sistemas de processamento de transaes so projetados para processar
solicitaes de informaes por usurios de um banco de dados pou solicitaes para
atualizar o banco de dado.
Sistemas de gerenciamento de informaes e recursos.
Sistemas de informao e a interao com um banco de dado compartilhado, ele
permite acesso controlado de uma grande base de informaes, 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
13

interface com o usurio do sistema. Sua principal caracterstica que a sequncia de

eventos imprevisvel 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 representao dessa linguagem como sada. Em engenharia de
software, os mais usados so os compiladores que traduzem uma linguagem artificial
de programao de alto nvel em cdigo de mquina.

4.4 Gerenciamento de configuraes.

Compreende o quando o gerenciamento de software e importante para sistemas
complexos, e como as ferramentas CASE so utilizadas para apoiar os processos de
gerenciamento.

Planejamento de gerenciamento de configuraes.

O Gerenciamento de configuraes descreve os padres 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 restries de cada projeto
especfico.

Identificao de item de configurao.

Durante o processo de planejamento de gerenciamento de configurao, voc

decide exatamente quais itens sero controlados. Planos de projetos, especificaes,
projetos, programas, e massa de dados de teste so normalmente mantidos como itens
de configurao. Todos os documentos que podem ser uteis para a evoluo futura do
sistema devem ser controlados pelo sistema de gerenciamento de configurao. O
esquema de identificao de itens de configurao deve atribuir um nico nome para
todos os documentos sob controle de configurao.
Os nomes de itens de configurao associam componentes com um projeto
especifico e, dessa maneira, reduzem as oportunidades para o reuso, podendo ser muito
14

difcil encontrar componentes relacionados.

Banco de dados de configurao.

utilizado para registrar todas as informaes relevantes sobre as configuraes

de sistema e os itens de configurao. Usa-se o banco de dados CM para auxiliar a
avaliao do impacto das mudanas de sistema e para gerar relatrios para a gerncia
sobre o processo de CM. Um banco de dados de configurao armazena informaes
sobre itens de configurao e referencia seus nomes num sistema de gerenciamento de
verso ou depsito de arquivos.

Gerenciamento de mudanas.

Procedimentos de gerenciamento de mudana dizem respeito a anlise de custo e

benefcio das mudanas propostas, a aprovao das mudanas viveis 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 mudanas correspondentes no
sistema de software. Para garantir que essas mudanas sero aplicadas ao sistema de
maneira controlada, voc precisa de um conjunto de procedimentos de gerenciamento
de mudanas apoiado por ferramentas.

Gerenciamento de verses e releases.

Os processos envolvidos no gerenciamento de verses e releases preocupam-se
com a identificao e a manuteno da rastreabilidade das verses de um sistema. Um
release do sistema uma verso distribuda aos clientes. Cada release deve incorporar
novas funcionalidades ou ser planejado para uma plataforma diferente de hardware.

Identificao de verses.
Para criar uma verso especifica de um sistema, voc precisa especificar as
verses dos componentes de sistema que devem ser includas nele.
As trs tcnicas bsicas para identificao da verso de componentes so:

Numerao de verses.

Identificao baseada em atributos.

15

Identificao orientada a mudanas.

Gerenciamento de releases.

Um release de sistema uma verso do sistema distribudo para os clientes. Os

gerentes de release de sistemas so responsveis por decidir quando um sistema pode
ser liberado para os clientes, gerenciar o processo de criao do release e de meios de
distribuio e documentar o release para assegurar que ele pode ser recriado exatamente
como foi distribudo, se for necessrio.

Construo de sistemas.

A construo de sistemas um processo de compilao e ligao de

componentes de software num programa que executa determinada configurao
definida. Durante sua construo, pode-se questionar o seguinte; voc deve pensar nas
seguintes questes: Todos os componentes que compem um sistema foram includos
nas instrues de construo? Todos os arquivos de dados necessrios esto
disponveis? A verso apropriada do compilador e de outras ferramentas requeridas est
disponvel?
.
Ferramentas CASE para gerenciamento de configuraes.

Processos de gerenciamento de configuraes so normalmente padronizados e

envolvem aplicaes de procedimentos predefinidos. Eles requerem o gerenciamento
cuidadoso de grande quantidade de dados e essencial a ateno aos detalhes. Quando
um sistema est sendo construdo com base em verses de componentes, um nico erro
de gerenciamento de configurao pode significar que o software no ir operar
adequadamente.
5.0 Frameworks para plataforma Web.
Comparativo entre os frameworks para desenvolvimento Web.

16

O quadro 1 apresenta um breve comparativo sobre as tecnologias apresentadas

anteriormente. As informaes contidas nesse quadro foram retiradas das apresentaes
dos frameworks contidas nesse captulo, e todas as referncias so as mesmas usadas no
item 2.2. Atravs das caractersticas 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, porm se o
foco for ajudar no desenvolvimento de interfaces grficas mais interessante o uso da
recente Java FX ou at tags JSP 4que tambm oferecem suporte criao de
componentes de interface. No quadro so expostas todas as principais caractersticas,
objetivos e verso atual do framework.
Quadro 1 Quadro comparativos de framework.

Struts

Objetivos

Vantagens

Caractersticas

Tornar

Os componentes do

Usa a arquitetura MVC.

independentes

Strutus

as camadas de

reutilizveis

lgica

aplicao.

de

Sua

negcio
interface, dados;
Reusabilidade

so
pela

Compatvel com os padres

de desenvolvimento.

utilizao

proporciona

uma

melhora

no

desempenho

de

aplicativo Web.
Spring

Retirar

as Desacoplamento

informaes do

entre

objeto

tomando

sobre

Baseado em injees de

objetos,

dependncias.

as

suas

aplicaes

menos

dependncias e

amarradas entre si.

as coloc-las em
arquivos

de

configuraes.
JSF

Reduzir o esforo Possui uma poderosa

necessrio

para

criar pginas JSP

17

linguagem

Incorpora caractersticas de

de

um framework MVC - Permite

expresso para acessar

uma diviso clara entre as

com

propriedades

processamento

beans5 e colees;

feito por servlets;

Facilitar

JSF

de

torna

Modelos de interfaces grficas

fcil

associar cdigo Java

que ir responder a

criao

de

determinados eventos

componentes

de

em pginas HTML

padronizar

interfaces

(HyperText

grficas

camadas.

baseadas em eventos;

Markup

na Language,);

internet;
JPA

Atravs

do Forma

simples

de

objetos

no

mapeamento das

mapear

entidades

banco de dados;

Java,

proporciona

persistncia

dos

Padroniza

Gerar

Reports

descrever mapeamento O/R,

de

consulta,

ferramentas para manipular

entidades;

relatrios Facilidade na criao

de

para

mapeamento e persistncia de

linguagem

mapeamento

(O/R);
Jasper

completa

objetos: modo declarativo de

Objeto/Relacional

objetos Java;

Soluo

Gerao

de

forma

de relatrios em Java

diversos

confivel

graas a ferramenta

Ferramenta

eficiente

em

visual

especialmente

iReport,
criar

formatos;

em
-

visual
para

possibilitando

Desktop;

visualmente

um

contm: suporte ao grfico de

relatrio

um

rea

sistema desenvolvido

ltima

sistemas Web e

para

framework;

relatrios

empilhado;

verso

pequenas

correes de bugs e melhorias;

em Java;
DWR

Permitir

que

Intregrao

com

trechos de cdigo

Servlets,

JavaScript

na

Annotations e outras

cliente

tecnologias; Facilita o

camada
invoquem
mtodos

Spring,

Orientado a objetos;
Cdigo aberto;
Esta

uma

camada

acima

XMLHttpRequest;

desenvolvimento, em
em

cdigo Java;

objetos Java no
servidor;
Java FX

Tornar simples a
criao de GUI e

18

Tem

um

estilo

declarativo, nas quais

Linguagem de Script, similar

ao

interfaces;

a estrutura visual se CSS (Cascading Style Sheets)

reflete diretamente na do
linguagem

de

programao;
A

HTML

(HyperText

Markup

Language);

simplicidade

no

vnculo entre dados e

Relativamente nova, recm

lanada em maio de 2007;

elementos visuais;

Os frameworks que foram apresentados nse captulo esto 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 Persistncia.
Quando falamos de frameworks voltados para persistncia e bancos de dados,
felizmente, no h tanta dvida quanto no mundo dos frameworks Web. O Hibernate
praticamente unanimidade no mercado Java, principalmente se usado como
implementao 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/ Benefcios de usar frameworks no desenvolvimento Web.

Sabe-se que o preo do produto final proporcional ao custo despendido com ele,
por isso uma anlise mal feita sobre quais recursos sero empregados no projeto poder
acarretar um alto preo de venda. O uso de um framework em projetos de software traz
benefcios e custos que devem ser analisados no

momento de se escolher quais

ferramentas sero utilizadas na aplicao a ser construda.

As vantagens do uso de frameworks nos projetos, de acordo com Assis e Sauv so:
Baixo tempo de codificao: devido estrutura semi-pronta, muitas
funcionalidades necessrias j esto disponveis;
Uso de solues bem testadas por outras pessoas: conforme o uso de framework
aumenta, estes passam a adquirir maturidade ao se descobrirem erros e adicionar
novas funcionalidades;
19

 Desenvolvedores se preocupam em implementar o que necessrio: no

preciso que se codi_que todo o software, pois se utiliza os componentes que j
esto prontos;
Menor probabilidade de erros nos cdigos: com uso de frameworks, menos
linhas de cdigo so 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 so:
Frameworks requerem pessoas especializadas: para a utilizao de um
framework, deve-se possuir uma equipe com conhecimentos e para isso,
necessrio que se faam treinamentos, demandando tempo e aumentando o
prazo final para o produto;
Depurao dos programas mais difcil: se o fabricante do framework no
disponibilizar os cdigos-fonte, _car difcil de se encontrar possveis erros,
visto que estes podem estar contidos nos objetos do framework;

20

 Mudana do foco de desenvolvimento: os desenvolvedores tm que assimilar

ideias que, na maioria das vezes, foram propostas por pessoas que no fazem
parte da sua equipe de trabalho;
Implementao
desenvolvidos

em

linguagem

especfica:

em

linguagens

de

como

programao

os

frameworks

especficas,

so

perde-se

portabilidade em relao s linguagens que podem ser usadas em conjunto com

o framework. Tal restrio obriga os desenvolvedores a utilizar a mesma
linguagem empregada pela soluo adotada.
Requistos necessrio para implentar e disponibilizar uma aplicao Web.
O objetivo aprender, ento ser criado um servio bem simples. O servio a
soma de duas variveis inteiras retornando o resultado. Este exemplo poder servir para
qualquer outra implementao. 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, coloclo no diretrio: CATALINA_HOME / webapps / axis / e iniciar o servidor, se ele j no
estiver iniciado. Se j estiver iniciado, o seu Web Service est publicado.
Os arquivos. jws so lidos pelo Axise representam Java Web Services. O Axis se
basear nesses arquivos (. jws) para criar os arquivos de definio WSDL. Todos os
mtodos pblicos existentes nessas classes sero automaticamente disponibilizados para
terceiros.
Criar documentos XML demorado e, muitas vezes, chato. Gerar o WSDL uma
caracterstica muito relevante na escolha de uma implementao de SOAP e oAxis um
dos poucos frameworks que conseguem fazer essa faanha de maneira transparente para

21

o desenvolvedor. por esse motivo que ele altamente recomendado na construo 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/"

22

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 implementao.
Uma das linhas mais importantes para este arquivo a linha 19, onde define-se o nome
do mtodo e o nome de seus parmetros. Eles devero ser de conhecimento pblico para
que as interfaces cliente consigam se comunicar com o Web Service.

Realizando um teste bsico.

O Axis aceita que um Web Service seja chamado via uma requisio HTTPGET. Portanto, ao digitar um endereo possvel testar o web service.
No

exemplo

deste

artigo

endereo

este:http://localhost:8080/axis/Servico.jws?method=soma&valor1=2&valor2=4. Como
pode-se notar, o endereo a juno de um namespace, que o endereo do
WebService

representado

porhttp://localhost:8080/axis/Servico.jws,

varivel

methodque, como seu nome diz, contm o nome do mtodo que se deseja executar, e
uma sequncia dos parmetros deste mtodo. Lembrando que o nome dos parmetros
deve ser o mesmo definido na funo da classe.

23

O resultado da execuo um documento XML com a resposta6. Novamente,

dependendo do browser no ser visvel as tags XML. O XML que retornou na
execuo 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 tambm uma classe simples, mas exige conhecimento em algumas

classes no to comuns no dia-a-dia. As classes Service e Call so classes doAxis,
portanto, para compilar e executar esta classe necessrio que todo o diretrio lib,
encontrado dentro do zip doAxisesteja no CLASSPATH da aplicao.
Visto este detalhe, abaixo encontra-se o arquivo fonte do cliente de Web
Service. Esta classe far a conexo ao Web Service para somar 2 com 4 e ir apresentar
o resultado 6 na sada padro.
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

// Endereo, local onde encontra-se o Web Service

07

String local = "http://localhost:8080/axis/Servico.jws";

08
24

09

// Criando e configurando o servio

10

Call call = (Call) new Service().createCall();

11

// Configurando o endereo.

12

call.setTargetEndpointAddress(local);

13

// Marcando o mtodo a ser chamado.

14

call.setOperationName("soma");

15
16

// Parmetros da funo soma.

17

Object[] param = new Object[]{new Integer(2),new Integer(4)};

18

// Retorno da Funo

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 cdigo est dentro de um arquivo chamado Cliente.java, aps 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 parmetros 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, necessrio que o Java Wireless Toolkit esteja instalado e
funcionando no ambiente.
A comunicao com Web Services se d atravs de XML e do protocolo SOAP.
Como o J2ME no possui classes para tratar estas implementaes, necessrio utilizar
outros dois projetos para atender as transparncias. Os projetos so oKSOAPe
oKXMLdaObjectWeb. Ambos esto sob licena pblica.

25

Como pretende-se criar uma simples aplicao para celular (MIDP2), ser
utilizado a fonte dos dois projetos junto um outro arquivo fonte que ser criado. o
jeito mais fcil de executar uma aplicao J2ME com duas bibliotecas
O

fonte

doKSOAPpode

ser

encontrado

aqui:http://ksoap.objectweb.org/software/downloads/current/ksoap-source.zip
E

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 esto no zip. kobjects

6.

o-Todas as suas pastas e arquivos internos a esta pasta que esto no zip. ksoap

7.
8.

+ transport
- - Necessrio excluir o pacote marshal.
No sero utilizados as pastas referentes a servlets e a j2se do ksoap. Somente

referente a J2ME e ao fonte bsico.

No diretrio 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;

26

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.
40. }
41. }

27

display.setCurrent(textBox);

6.0 Projeto China Telecon ,Funcionalidades, aplicaes dos padres de criao.

A melhor soluo para essa empresa seria realmente adotar um software de uma
empresa especializada e com um bom suporte. Mas nos baseando na hiptese de a
empresa querer desenvolver seu prprio software, para reduzir os custos seria necessrio
tambm reduzir o tempo de desenvolvimento do mesmo e manter a qualidade e
produtividade no desenvolvimento. Alm de contar com uma equipe de profissionais
capacitados, tambm seria necessrio adotar padres e tcnicas que iro ajudar a
desenvolver um bom sistema para a empresa. Analisando entre os padres existentes,
fcil chegar a concluso que o melhor padro para ser adotado no desenvolvimento do
software em questo seria a arquitetura MVC.
A arquitetura MVC foi desenvolvida para ser usado em projetos de interface
visual em Smalltalk, linguagem de programao que juntamente com o C++ ganhou
grande reconhecimento na poca, o MVC foi criado na dcada de 70, e aps esses anos
de sua criao ainda um pattern aplicvel nas mais variadas aplicaes, principalmente
em aplicaes web. Quando um software comea a ficar grande e complexo, muitos
dados so apresentados para os usurios, sentimos a necessidade de aplicar uma
arquitetura que facilite nosso trabalho, desde a organizao do projeto, as divises das
responsabilidades at as possveis modificaes que podero ser efetuadas ao longo do
desenvolvimento do software para isso precisaram dividir o projeto em trs objetos para
aplicar o MVC.
Para a Gamma et al. o MVC : MVC composto por trs tipos de objetos. O
modelo o objeto de aplicao, a vista a apresentao na tela e o controlador define a
maneira como a interface do usurio reage s entradas do mesmo. Antes do MVC, os
projetos de interface para o usurio tendiam em agrupar esses objetos. MVC para
aumentar a flexibilidade e a reutilizao. (GAMMA et al. 2000, p. 20).
O MVC tem como principal objetivo: separar dados ou lgicos de negcios
(Model) da interface do usurio (View) e o fluxo da aplicao (Controller), a idia
permitir que uma mensagem da lgica de negcios possa ser acessada e visualizada
atravs de vrias interfaces. Na arquitetura MVC, lgica de negcios, ou seja, nosso
Model no sabe quantas nem quais as interfaces com o usurio esta exibindo seu estado,
28

a view no se importa de onde esta recebendo os dados, mas ela tem que garantir que
sua aparncia 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 aplicao em trs partes distintas. Uma parte, a Model, esta relacionada ao trabalho
atual que a aplicao administra outra parte a View esta relacionada a exibir os dados ou
informaes dessa uma aplicao e a terceira parte, Controller, em coordenar os dois
anteriores exibindo a interface correta ou executando algum trabalho que a aplicao
precisa completar. (GONALVES, 2007, p. 141). Model: ou modelo a camada que
contm a lgica da aplicao, responsvel pelas regras de negcio, para sistemas
persistentes, o modelo representa a informao (dados) dos formulrios e as regras SQL
para manipular dados do banco, o modelo mantm o estado persistente do negcio e
fornece ao controlador capacidade de acessar as funcionalidades da aplicao, o
modelo o principal responsvel toda aplicao deve representar o modelo atua
isoladamente no tem conhecimento de quais sero 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 viso correta.

View: ou viso a

camada de apresentao com usurio, a interface que proporcionar entrada de dados

e a visualizao de respostas geradas, nas aplicaes web representado pelo HTML
que mostrado pelo browser, geralmente a viso contm formulrios, tabelas, menus e
botes para entrada e sada de dados.
A viso deve garantir que sua apresentao 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 apresentaes, essa camada no contm cdigos
relacionados lgica de negcios, ou seja, todo o processamento feito pelo Modelo e
este repassa para a viso, 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 baguna se tivesse algum para organizar esta
arquitetura, um controlador funciona de intermedirio entre a camada de apresentao e
a camada de negcios, sua funo como j diz controlar coordenar o envio de
requisies feitas entre a viso e o modelo.
29

O controller define o comportamento da aplicao, o controle quem interpreta

as solicitaes (cliques, selees de menus) feitas por usurios com bases nestes
requerimentos o controlador comunica-se com o modelo que seleciona a view e
atualiza-a para o usurio, ou seja, o controlador controla e mapeia as aes.
Embora o MVC s contenha trs camadas h outra camada fundamental para o
bom andamento da arquitetura, esta um mecanismo de eventos necessrio a
comunicao entre outros trs elementos, este elemento permite uma comunicao
assncrona que invocada quando algum evento interessante acontece, esta quarta
camada contm os beans de entidade onde se localizam os mtodos get e set das classes.
5. Design Patterns aplicados na arquitetura MVC A arquitetura MVC utiliza padres de
projetos em suas camadas analisamos a arquitetura agora com os patterns. O MVC usa
outros padres 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 so
fornecidos pelos padres 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 padres trabalhando juntos
em uma mesma estrutura. Abordamos agora os patterns Observer e Strategy que so
padres comportamentais e o Composite padro estrutural, o objetivo de abordar os
patterns para facilitar a compreenso de como a arquitetura MVC trabalha, sabendo
que um padro de arquitetural que confundem projetistas e desenvolvedores.
Nas palavras de Gamma et al. os principais padres que o MVC utiliza so
os Observer, Composite e o Strategy. Analisemos a Figura 3 do livro de Padres de
Projetos dos autores Freeman & Freeman que nos ajudar a explicar como os padres
contribuem na arquitetura MVC: A visualizao ou a View juntamente com o
padro Composite est disposio do usurio esperando por qualquer evento, quando
este evento ativado o controlador avisado sobre o evento, este avisa para a viso se
atualizar, e ao mesmo tempo manda o modelo para que ele atue para contemplar o
evento provocado pelo usurio, depois de atuado o modelo fica pronto para ser acessada
pela visualizao esta por sua vez acessa e atualiza-se para o usurio assim funciona a
arquitetura MVC em conjunto com os padres de projetos.

30

Utilizando essa arquitetura, o tempo de desenvolvimento do software diminuir

sem perde a qualidade e sem aumento de custos. Frameork Uma das melhores opes
seria o Hibernate como framework de persistncia de dados. O Hibernate um
framework para mapeamento objeto/relacional em Java, que abstrai o cdigo SQL da
aplicao, permitindo, entre outra coisas, modificar a base de dados para outro SGBD
(Sistema Gerenciador de Banco de Dados) sem modificar uma linha de cdigo

31

Concluso
O presente trabalho foi realizado uma pesquisa bibliogrfica, baseada nos
assuntos tratados nas disciplinas de Engenharia e Projeto de Software, Projeto
Orientado a Objetos e Programao para Web II para melhor compreenso.
Conhecendo a melhor arquitetura MVC que seria a melhor opo para o projeto
China telecon, que teria que desenvolver seu prprio software para reduzir os custos,
sendo necessrio tambm reduzir o tempo de desenvolvimento do mesmo e mantendo a
qualidade e produtividade no seu desenvolvimento.
.

32

Referncias.
AVANSINI, Rgis da Silva. Investigao da efetividade de um Framework Corporativo
de persistncia de dados com base no Framework NHibernate em um ambiente
empresarial. Universidade Estadual de Maring Centro de Tecnologia Departamento
de Informtica, Maring, 2012,

APACHE, Struts. Disponvel em: . Acesso em 11 de maio de 2009.

BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web.

Jaguarina, 2007.
RAMOS, Jos Yoshiriro Ajisaka. Comparao entre os principais Frameworks Java
para o desenvolvimento de aplicaes WEB 2.0. Instituto de Estudos Superiores da
Amaznia, Belm PA, 2007.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo:
Pearson Addison Wesley, 2007."
UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS
(Guia PMBoK), 4 edio. Pensylvania, PMI, 2008.
GOETTEN, V. JUNIOR. Desmistificando o framework Jakarta Struts. Java
Free.Disponvel

em:

<http://www.javafree.org/content/view.jf?idContent=22>.

Acessado em: 11 Abril de 2015.

SAUV, J. P. Frameworks. Notas de Aula. Paraba : Universidade Federal da Paraba,

2004.

Disponvel

em:

<http://www.dsc.ufcg.edu.br/

jacques/

cursos/map/html/map1.htm>. Acesso em: 11 de abril de 2015

SIELO
Frameworks.
Disponvel
em:
<http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0034-76122011000500014>.
Acesso em: 11 maio de 2015.

33