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.