You are on page 1of 33

SISTEMA DE ENSINO PRESENCIAL CONECTADO

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
FERNANDA SILVA MOTA

PORTIFÓLIO INDIVIDUAL

Rio Branco- Acre
2015
1

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
2

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

3

O trabalho a seguir . Os capítulos 11 á 13 tratam da estrutura abstratas de software. 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. existem frameworks para todo o tipo de aplicação. desde programação de dispositivos móveis até programação para Web.Introdução Esta produção interdisciplinar do 5º semestre do curso de analises e desenvolvimento de sistemas. viagens. Atualmente. hardwares e softwares. 4 . Assim poderemos entender porque a empresa decidiu contratar do que ela mesmo desenvolver o software necessário. técnicas e práticas. 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. fornecedores. Ao longo desse trabalho. capítulo 13 arquiteturas de aplicações e capítulo 29 gerenciamento de configuração. são tratados os frameworks que se referem ao desenvolvimento Web. entre outros). teve como intuito realizar uma resenha dos seguintes capítulo 11 Projeto de arquitetura. estruturação de software para execução distribuídas. capítulo 12 arquiteturas de sistemas distribuídos.propõe que o aluno entenda a demanda de recursos (pessoas especialistas. tem como objetivo exercitar os conteúdos assimilados no período elencando os diversos conceitos.China Telecom .

Projeto Orientado a Objetos. 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. Engenharia e Projeto de Software E Programação para Web II.

definem estratégias e ações para lidar com os riscos negativos e positivos.  Identificar os Riscos. Esta área descreve os processos relativos à realização do gerenciamento de riscos em um projeto.  Realizar a Análise Quantitativa dos Riscos. permitem atribuir probabilidade numérica aos riscos. 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. para que seja concluído com sucesso. monitoram os risco com novos risco sendo identificados.2 Área de conhecimento – Escopo.  Realizar a Análise Qualitativa de Riscos. definição de outras prioridades de riscos. etc. Os processos dessa área são:  Planejar o Gerenciamento dos Riscos.  Monitorar e Controlar os Riscos. Os processos desta área de conhecimento tem como objetivo determinar como os riscos serão identificados.  Planejar as Respostas aos Riscos. buscam priorizar os riscos com base no grau de criticidade. 6 . criam uma lista de riscos identificados no projeto com diversas técnicas que ajudam a gerar essa lista de riscos. analisados e como as respostas serão planejadas e como risco será planejado. 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. 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. revisão das análises de riscos. 3. Áreas de conhecimento segundo PMBoK.1 Área de conhecimento – Riscos. Temos cinco processos de planejamento e um de controle. 3.3.

coleta. serviços ou resultados. 3.Existem três processos de planejamento (três primeiros) e dois processos de controle e monitoramento (dois últimos). 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. 7 .  Realizar as Aquisições. Esta área descreve os processos relativos à geração. como se dará o gerenciamento dos contratos. receber a resposta dos fornecedores e selecionar o fornecedor. de quem se quer adquirir.  Encerrar as Aquisições. pagar o fornecedor. Os processos dessa área são:  Coletar Requisitos.  Cria a EAP.  Definir o Escopo. Os processos dessa área são:  Planejar as Aquisições. Esta área descreve os processos que compram ou adquirem produtos. disseminação. 3. pagamentos.3 Área de conhecimento –Fornecedores.  Verificar o Escopo. além dos processos de gerenciamento de contratos. Os processos de planejamento criam um plano para o gerenciamento de escopo. Os processos desta área de conhecimento têm como objetivo determinar o que se quer adquirir. se as entregas estão de acordo com o que foi estabelecido.4 Área de conhecimento – Partes Interessadas. armazenamento e destinação final das informações do projeto de forma oportuna e adequada.  Controlar o Escopo.  Administrar as Aquisições. e por último formalizar a finalização do contrato.

(Bass.1 Projeto de Arquitetura.  Reportar Desempenho. o capítulo 29 comprenderá porque o gerenciamento de software e necessário para sistesmas complexos. que consiste em indentificar subsistemas e estabelecer um framework para o controle e a comunicação de subsistemas é chamado de projeto de arquitetura. etc. definem como as comunicações vão ocorrer quando o projeto iniciar e determina o tipo de informações gerada. qual a periodicidade.  Distribuição das Informações. 4. o capítulo 12 trata da estruturação de software para execução distribuida .2003) Explicam três vatagens de projetar e documentar explicitamente uma arquiterura de software: 8 . como podemos gerenciar as expectativas dos interessados medindo o grau de satisfação ou insatisfação das pessoas interessadas.Os processos desta área de conhecimento determinam quem está envolvido no projeto. e geram relatórios que permitam o acompanhamento e controle do que está acontecendo com o tempo. o projeto de arquiterura e o primento estagio do processo de projeto. determinam como serão distribuídas as informações. 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. qual o meio. 4. et al. Bass et al. quem é o responsável.0 Resenha Livro Engenharia de Softwre de Lan Sommerville. O processo inicial de projetos. custo.  Gerenciar as Expectativas das Partes Interessadas. Os processos dessa área são:  Identificar as Partes Interessadas. escopo..  Planejar as Comunicações. quem receberá as informações geradas. Capítulo 11 explica perspectivas estruturais consideradas úteis no projeto de software.

como a estrutura cliente-servidor ou em camadas. O modelo cliente-servidor.1. A arquiterura de sistema afeta o seu desempenho podendo falicitar ou não a distribuição e manutenção do sistema. sua organização via refletir diretamente na estrutrua do subsistema. Os subsistemas que constituem um sistema devem trocar informações de modo que possam trabalhar juntos eficientemente. Comunicação de stakeholders. Reuso em larga escala. Organização de sistema. Decisões de projeto de arquitetura. avaliação e para ver quão bem ela atende os requisitos funcionais e não funcionais depois de implantada. 3. no processo de modelagem de controle. A arquitetura de um sitemade software pode ser baseada em um modelo ou estilo de arquitetura específica ou varios estilos de arquiteturas .Ao projetar uma arquiterura de sistemas. você deve tomar decisões sobre como a execução de susbsitencias é controlada. adequado para aplicações em que os dados são gerados por um sistema e usados por um outro. tem que escolher qual a estrutrua mais apropriada. A organização de um sistema reflete a estratégia que vai ser usada para estruturá-lo. 2. Analises de sistemas. 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. Esse modelo é. 9 . O modelo repositório. portanto. voce precisa decidir o que o sistema e classes tem em comum. e decidir quanto conhecimento dessas arquiteturas você pode usar. A maioria dos sistemas que usam grandes quantidades de dados é organizada com base em banco de dados ou repositório compartilhado.

devido não serem firmente aclopados. as camadas mais internas podem fornecer recursos básicos. como gerenciamento de arquivosm necessários em todos os níveis.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 de evitar um projeto de sistema concorrente é que programas equenciais são mais fáceis de projetar . As desvantagens para usar serviços. O modelo em camadas. As vantagens mais importantes de um modelo cliente. seus atributos e sua operações. Estilos de decomposição modular. Decomposição orientada a objetos.servidoré que ele é uma arquitetura distribuida. que permitem a ultilização de estilos alternativos de descomposição.Uma decomposição orientada a objetos está relacionada a classes de objetos. 10 . os objetos devem fazer referência explícita ao nome e á interface de outros objetos. As vantagens da abordagem orientada a objetos . cada uma das quais fornecendo um conjunto de serviços. a implementação de objetos pode ser modificada sem afetar outros objetos. O Uso efetivo de sitemas em rede pode ser feito com muitos processadores distribuídos.uma desvantagem da abordagem é que a estruturação de sistemas dessa maneira pode ser difícil. os componentes em módulos são geralmente menores que os subsitemas. O modelo em camadas de arquiteturas organiza um sistema em camadas. A abodagem na descomposição de subsistemas em módulos. A arquittura orientada a objetos estrutura o sistema em um conjunto de objetos não firmemente aclopados com interfaces bem definidas. implementar e testar do que sistemas paralelos.O modelo cliente.

As arquiteruras de referência não são geralmente consideradas um roteiro de implementação. sistema de produção baseados em regras como as usadas em inteligencia artificial. Um sistema de controle centralizado é designado como controlador de sistema e tem a responsabilidade pelo gerenciamento da execução de outros subsistemas. Em um pipeling orientado a funçoes as trasnformações funcionais processam suas entradas e produzem saídas. Modelos de controle são usados em conjunto com estilos de etrutruras. ou seja um sistema de processamento de faturas. Sistemas orientados a eventos. 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. ele atua como uma base em relaçao á qual os sitemas podem ser avaliados. Os modelos orientados a eventos são regidos pelos eventos gerados externamente.2. Um modelo de renferência fornece um vocabulário para comparação. 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. 4. Modelos de Controle. Existem muitos tipos de sistemas orientados a eventos . Arquiteturas de refência.Pipeling orientado a funções. 11 .estes incluem editores em que os eventos de interface com o usuario significam comandos de edição. as vantagens e a evolução do sistema pela adição de novas transformações e geralmente direta. Arquiteturas de sistemas distribuídos. Todos os estilos de estrutrura podem ser implementados por meio de controle centralizado ou baseado em eventos Controle centralizado. Em vez disso.

Arquiteturas cliente-servidor. Arquiterura cliente – servidor é chamada de arquiterura cliente – servido de duas camadas.como é normal em objetos. em prncípio pelo menos. nenhuma distinção é feita entre clientes e servidores. As interface de objetos CORBA são definidas por meio de uma linguagem de definição de interface padronizada independente de linguagem. Uma arquitetura de objetos distribuídos pode ser usada como um modelo lógico que perminte estruturar e organizar o sistema.Contudo. a computação distribuída foi implementada inicialmente em nível organizacional. os objetos CORBA devem ter uma definicção de interface separada que define os atributos e opreações públicas do objeto. Sistemas ponto a ponto é uma abordagem muito mais eficiente para computação interorganizacional que a abordagem baseada enm serviços. Sistemas ponto a ponto são sistemas descentralizaos em que as computações podem ser realizadas por qualque nó da rede e. Arquitetura de objetos distribuídos. modelo cliente magro e modelo cliente –gordo. Arquiteturas ponto a ponto. os sistemas ponto a ponto 12 . em vez de ficarem confinados em uma única máquina. naqual uma aplicação é organizda como um servidor ou vários servidores idênticos . Computação interorganizacional distriuída.Um sistemas distriuído é aquele em que as infromações em fase de processamento são distribuídos para vários computadores. CORBA O modelo de objeto CORBA considera um objeto como se fosse um encapsulamento de atributos e serviços.Praticamente todos os sistemas baseados em grande computadores atualmente são sistemas distribuídos . Por motivo de proteção e interorganizacional.

3 Arquiteturas de aplicações. serviços. Sistemas de aplicações são criados para atender necessidades de negócio ou organizacionais. Arquitetura de sitema orientada a serviços. Sistemas de gerenciamento de informações e recursos. Os sistemas de processamento de eventos respondem aos eventos do ambiente ou da 13 . Sistemas de informação e a interação com um banco de dado compartilhado. Sistemas de processamento de eventos. Como sendo um componente. produto final do escopo do projeto onde foi determinado a criação de um serviço. Também podemos descrever neste caso serviços. representa todos ativos de softwares da empresa. 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. 4.sõ mais adequados a sistemas de informações não críticos ou nos quais já existam relacionamentos de trabalho entre as organizações. tais como bibliotecas e registros de pacientes. 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 dados. teremos um software completo para aquela determinada função para que foi desenhado. ele permite acesso controlado de uma grande base de informações. Sistemas de processamento de transações. Corresponde a uma metodologia para desenvolvimento de software. uma parte de desenvolvimento de um software onde ao fazer a junção de todos os ”módulos”.

e massa de dados de teste são normalmente mantidos como itens de configuração. programas. você decide exatamente quais itens serão controlados. Compreende o quando o gerenciamento de software e importante para sistemas complexos. 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. Identificação de item de configuração. O ponto de partida para o desenvolvimento deve ser adaptado para se atender aos requisitos e as restrições de cada projeto específico. 4. Esses sistemas aceitam uma linguagem natural ou artificial como entrada e geram alguma outra representação dessa linguagem como saída.interface com o usuário do sistema. O esquema de identificação de itens de configuração deve atribuir um único nome para todos os documentos sob controle de configuração. Os nomes de itens de configuração associam componentes com um projeto especifico e. reduzem as oportunidades para o reuso. projetos. Sistemas de processamento de linguagens. podendo ser muito 14 . dessa maneira. Planejamento de gerenciamento de configurações. Durante o processo de planejamento de gerenciamento de configuração. O Gerenciamento de configurações descreve os padrões e procedimentos que devem ser usados para o gerenciamento.4 Gerenciamento de configurações. e como as ferramentas CASE são utilizadas para apoiar os processos de gerenciamento. 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. especificações. Todos os documentos que podem ser uteis para a evolução futura do sistema devem ser controlados pelo sistema de gerenciamento de configuração. Planos de projetos.

As necessidades e requisitos organizacionais alteram-se durante a vida útil de um sistema. Banco de dados de configuração. você precisa de um conjunto de procedimentos de gerenciamento de mudanças apoiado por ferramentas. Cada release deve incorporar novas funcionalidades ou ser planejado para uma plataforma diferente de hardware. Um release do sistema é uma versão distribuída aos clientes. 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. É utilizado para registrar todas as informações relevantes sobre as configurações de sistema e os itens de configuração. 15 . Gerenciamento de versões e releases.  Identificação baseada em atributos. 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. a aprovação das mudanças viáveis e a rastreabilidade de quais componentes do sistema foram alterados. 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. Para garantir que essas mudanças serão aplicadas ao sistema de maneira controlada. Procedimentos de gerenciamento de mudança dizem respeito a análise de custo e benefício das mudanças propostas.difícil encontrar componentes relacionados. Isso significa que você precisa fazer as mudanças correspondentes no sistema de software. 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. Gerenciamento de mudanças. Identificação de versões. As três técnicas básicas para identificação da versão de componentes são:  Numeração de versões.

Durante sua construção. Identificação orientada a mudanças. se for necessário. Quando um sistema está sendo construído com base em versões de componentes. Eles requerem o gerenciamento cuidadoso de grande quantidade de dados e é essencial a atenção aos detalhes.0 Frameworks para plataforma Web. 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. Processos de gerenciamento de configurações são normalmente padronizados e envolvem aplicações de procedimentos predefinidos. 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. Gerenciamento de releases. 16 . Os gerentes de release de sistemas são responsáveis por decidir quando um sistema pode ser liberado para os clientes. 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? . um único erro de gerenciamento de configuração pode significar que o software não irá operar adequadamente. pode-se questionar o seguinte. Construção de sistemas. Comparativo entre os frameworks para desenvolvimento Web. 5. Ferramentas CASE para gerenciamento de configurações. Um release de sistema é uma versão do sistema distribuído para os clientes.

JSF  Reduzir o esforço  Possui uma poderosa necessário para criar páginas JSP 17 linguagem  Incorpora características de de um framework MVC . No quadro são expostas todas as principais características. independentes Strutus as camadas de reutilizáveis lógica aplicação. as suas aplicações menos dependências e amarradas entre si. objetivos e versão atual do framework. Spring Retirar as  Desacoplamento informações do entre objeto tomando sobre  Baseado em injeções de objetos. utilização proporciona uma melhora no desempenho de aplicativo Web. dependências. Quadro 1 Quadro comparativos de framework. Struts Objetivos Vantagens Características  Tornar  Os componentes do  Usa a arquitetura MVC. dados. por exemplo. caso o projeto necessite de apoio para a camada de controle (MVC) recomenda-se o uso de Struts. Através das características abordadas nesse quadro pode-se usar como base na escolha de um framework em detrimento a outro. 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.  Reusabilidade são pela  Compatível com os padrões de desenvolvimento. as colocá-las em arquivos de configurações. de  Sua negócio interface.Permite expressão para acessar uma divisão clara entre as . 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.O quadro 1 apresenta um breve comparativo sobre as tecnologias apresentadas anteriormente.2.

 Solução  Geração de forma de relatórios em Java diversos confiável e graças a ferramenta Ferramenta eficiente em visual especialmente iReport. relatórios empilhado. proporciona a persistência dos  Padroniza o  Gerar Reports descrever mapeamento O/R. Java FX  Tornar simples a criação de GUI e 18  Tem um estilo declarativo. JavaScript na Annotations e outras cliente tecnologias. Java. JPA  Através do  Forma simples de objetos no mapeamento das mapear entidades banco de dados. internet.com propriedades processamento beans5 e coleções. Jasper completa objetos: modo declarativo de  Objeto/Relacional objetos Java. feito por servlets. similar ao . versão pequenas correções de bugs e melhorias. desenvolvimento. em em código Java.  Esta uma camada acima XMLHttpRequest.  Código aberto. objetos Java no servidor. em - visual para possibilitando Desktop. nas quais  Linguagem de Script. relatórios  Facilidade na criação de para mapeamento e persistência de linguagem mapeamento (O/R).  Facilitar  JSF de torna  Modelos de interfaces gráficas fácil e associar código Java a que irá responder a criação de determinados eventos componentes de em páginas HTML padronizar interfaces (HyperText gráficas camadas. ferramentas para manipular entidades. visualmente um contém: suporte ao gráfico de relatório um área sistema desenvolvido última o sistemas Web e para framework.). Markup na Language. de consulta. Facilita o camada invoquem métodos Spring. em Java. baseadas em eventos. criar formatos. DWR  Permitir que  Intregração com trechos de código Servlets.  Orientado a objetos.

em muitos casos. A HTML (HyperText Markup Language). elementos visuais. Frameworks De Persistência. Mas o Hibernate é o mais importante. felizmente. o DataNucleus. Há outras possibilidades. ou seja. simplicidade no vínculo entre dados e  Relativamente nova. estes passam a adquirir maturidade ao se descobrirem erros e adicionar novas funcionalidades. de acordo com Assis e Sauvê são:  Baixo tempo de codificação: devido à estrutura semi-pronta. não há tanta dúvida quanto no mundo dos frameworks Web. principalmente se usado como implementação da JPA. como o Toplink. Custo/ Benefícios de usar frameworks no desenvolvimento Web.interfaces. Quando falamos de frameworks voltados para persistência e bancos de dados. a estrutura visual se CSS (Cascading Style Sheets) reflete diretamente na do linguagem de programação. melhora muito o processo de desenvolvimento. o OpenJPA. o JDO. muitas funcionalidades necessárias já estão disponíveis. 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. Sabe-se que o preço do produto final é proporcional ao custo despendido com ele. O Hibernate é praticamente unanimidade no mercado Java. 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. serem utilizados em um mesmo projeto em conjunto. o EclipseLink. o que. 19 . o iBatis etc.  Uso de soluções bem testadas por outras pessoas: conforme o uso de framework aumenta. a produtividade e a qualidade do produto final. recém lançada em maio de 2007. As vantagens do uso de frameworks nos projetos.

existem desvantagens provindas do uso de frameworks. visto que estes podem estar contidos nos objetos do framework. demandando tempo e aumentando o prazo final para o produto. diminuindo. _cará difícil de se encontrar possíveis erros. deve-se possuir uma equipe com conhecimentos e para isso. Por outro lado. a possibilidade de erros comuns.  Depuração dos programas mais difícil: se o fabricante do framework não disponibilizar os códigos-fonte.  Menor probabilidade de erros nos códigos: com uso de frameworks. De acordo com Assis e Sauvê essas desvantagens são:  Frameworks requerem pessoas especializadas: para a utilização de um framework. é necessário que se façam treinamentos. 20 . menos linhas de código são escritas pelos programadores. 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. assim.

jws. para fazer isso.java para Servico. muitas vezes. foram propostas por pessoas que não fazem parte da sua equipe de trabalho. } } Agora só falta disponibilizá-lo no nosso servidor para o mundo acessar. Abaixo está a classe implementada. 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 21 . então será criado um serviço bem simples. O serviço é a soma de duas variáveis inteiras retornando o resultado. Os arquivos. Todos os métodos públicos existentes nessas classes serão automaticamente disponibilizados para terceiros. Tal restrição obriga os desenvolvedores a utilizar a mesma linguagem empregada pela solução adotada. Se já estiver iniciado. deve-se alterar o nome do arquivo de Servico. O Axis se baseará nesses arquivos (.  Implementação desenvolvidos em linguagem específica: em linguagens de como programação os frameworks específicas. int valor2) { return valor1 + valor2. colocálo no diretório: CATALINA_HOME / webapps / axis / e iniciar o servidor. jws são lidos pelo Axise representam Java Web Services. chato. O objetivo é aprender. jws) para criar os arquivos de definição WSDL. Criar documentos XML é demorado e. o seu Web Service está publicado. Mudança do foco de desenvolvimento: os desenvolvedores têm que assimilar ideias que. se ele já não estiver iniciado. Este exemplo poderá servir para qualquer outra implementação.java: public class Servico { public int soma(int valor1. E. Requistos necessário para implentar e disponibilizar uma aplicação Web. O nome do arquivo é Servico. são perde-se portabilidade em relação às linguagens que podem ser usadas em conjunto com o framework. na maioria das vezes.

<wsdl:output message="impl:somaResponse" name="somaResponse"/> 22. <wsdl:binding name="ServicoSoapBinding" type="impl:Servico"> 25.org/wsdl/soap/" 10. xmlns:intf="http://localhost:8080/axis/Servico. <wsdl:part name="somaReturn" type="xsd:int"/> 17. <wsdl:portType name="Servico"> 19.xmlsoap. 1. <wsdl:input message="impl:somaRequest" name="somaRequest"/> 21. <wsdl:message name="somaRequest"> 12. <wsdlsoap:operation soapAction=""/> 28.jws" 7. xmlns:wsdlsoap="http://schemas. <?xml version="1.org/wsdl/" 9. </wsdl:message> 15. <wsdl:part name="valor1" type="xsd:int"/> 13.xmlsoap.org/xml-soap" 5.org/2001/XMLSchema"> 11. <wsdlsoap:body encodingStyle="http://schemas. </wsdl:portType> 24. <wsdl:message name="somaResponse"> 16.xmlsoap.org/soap/h ttp"/> 26. xmlns:xsd="http://www. <wsdl:definitions targetNamespace="http://localhost:8080/axis/Servico.xmlsoap.xmlsoap.0" encoding="UTF-8"?> 2. É por esse motivo que ele é altamente recomendado na construção de Web Services. <wsdl:operation name="soma" parameterOrder="valor1 valor2"> 20.o desenvolvedor. <wsdl:input name="somaRequest"> 29.xmlsoap. <wsdl:part name="valor2" type="xsd:int"/> 14. <wsdlsoap:binding style="rpc" transport="http://schemas.jws" 3. xmlns:soapenc="http://schemas. </wsdl:message> 18.org/soap/encoding/" 8. xmlns="http://schemas.org/wsdl/" 4.jws" 6. xmlns:apachesoap="http://xml. xmlns:impl="http://localhost:8080/axis/Servico. <wsdl:operation name="soma"> 27. </wsdl:operation> 23.apache.w3. xmlns:wsdl="http://schemas.org/soap/encodin g/" 22 .

Lembrando que o nome dos parâmetros deve ser o mesmo definido na função da classe. a variável methodque. como seu nome diz. </wsdl:output> 36. Realizando um teste básico. </wsdl:port> 42. namespace="http://localhost:8080/axis/Servico. onde define-se o nome do método e o nome de seus parâmetros. </wsdl:binding> 38. <wsdlsoap:address location="http://localhost:8080/axis/Servico. 23 . <wsdl:output name="somaResponse"> 33.jws?method=soma&valor1=2&valor2=4. Como pode-se notar. que é o endereço do WebService representado porhttp://localhost:8080/axis/Servico.jws" use="encoded"/> 35.jws. ao digitar um endereço é possível testar o web service. <wsdlsoap:body encodingStyle="http://schemas. namespace="http://DefaultNamespace" use="encoded"/> 31.30. Eles deverão ser de conhecimento público para que as interfaces cliente consigam se comunicar com o Web Service. Uma das linhas mais importantes para este arquivo é a linha 19. </wsdl:service> 43. contém o nome do método que se deseja executar. e uma sequência dos parâmetros deste método.jws"/> 41. O Axis aceita que um Web Service seja chamado via uma requisição HTTPGET. </wsdl:input> 32. No exemplo deste artigo o endereço é este:http://localhost:8080/axis/Servico. </wsdl:definitions> Analisar este arquivo é essencial para entender a profundidade da implementação. <wsdl:port binding="impl:ServicoSoapBinding" name="Servico"> 40.org/soap/encodin g/" 34. o endereço é a junção de um namespace. </wsdl:operation> 37.xmlsoap. Portanto. <wsdl:service name="ServicoService"> 39.

w3.axis.jws".w3.axis.apache.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.xmlsoap. 08 24 .client. 02 import org.0" encoding="UTF-8"?> 02 <soapenv:Envelope 03 xmlns:soapenv="http://schemas. mas exige conhecimento em algumas classes não tão comuns no dia-a-dia. 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.O resultado da execução é um documento XML com a resposta6. 03 04 public class Cliente { 05 public static void main(String[] args) throws Exception { 06 // Endereço.org/soap/envelope/" 04 xmlns:xsd="http://www. As classes Service e Call são classes doAxis.apache. abaixo encontra-se o arquivo fonte do cliente de Web Service.Call. O cliente também é uma classe simples. encontrado dentro do zip doAxisesteja no CLASSPATH da aplicação. Visto este detalhe.Service.org/2001/XMLSchema" 05 xmlns:xsi="http://www. 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. para compilar e executar esta classe é necessário que todo o diretório lib. local onde encontra-se o Web Service 07 String local = "http://localhost:8080/axis/Servico. portanto.org/2001/XMLSchema-instance"> 06 <soapenv:Body> 07 <somaResponse soapenv:encodingStyle="http://schemas. 01 import org.client.xmlsoap.

createCall(). Para este passo. Como pode-se notar. A comunicação com Web Services se dá através de XML e do protocolo SOAP. 15 16 // Parâmetros da função soma. Como o J2ME não possui classes para tratar estas implementações. Ambos estão sob licença pública. 23 } 24 } Este código está dentro de um arquivo chamado Cliente. o framework do Axis abstrai qualquer trabalho com XML.new Integer(4)}. Acessando o Web Service via J2ME. evitando que o desenvolvedor necessite conhecer a sintaxe do XML do SOAP. 20 21 // Imprime o resultado: ret = 2 + 4.println("Resultado da soma : " + ret). é necessário utilizar outros dois projetos para atender as transparências. Neste exemplo. Portanto. foi criado o Web Service com dois parâmetros Integer. 25 . tanto faz usar uma ou outra.09 // Criando e configurando o serviço 10 Call call = (Call) new Service(). 12 call.java. 13 // Marcando o método a ser chamado.invoke(param).setOperationName("soma"). é necessário que o Java Wireless Toolkit esteja instalado e funcionando no ambiente. 18 // Retorno da Função 19 Integer ret = (Integer)call. O framework do Axis trata a primitivainte a classe wrapper Integer como sendo iguais.setTargetEndpointAddress(local). 14 call. 22 System. Os projetos são oKSOAPe oKXMLdaObjectWeb.out. 11 // Configurando o endereço. 17 Object[] param = new Object[]{new Integer(2). após compilar e executar esta classe exibirá o resultado " Resultado da soma: 6 " como desejado.

será utilizado a fonte dos dois projetos junto um outro arquivo fonte que será criado.Necessário excluir o pacote marshal.. ksoap 7. public class ClienteJ2ME extends javax.TextBox. 3. 4. o kxml 5. import org. # SeuProjetoJ2ME 2. 3. Somente referente a J2ME e ao fonte básico.lcdui.microedition. private Display display. 7.jws".SoapObject. 9.zip E o fonte doKXMLpode ser encontrado aqui:http://kxml. É o jeito mais fácil de executar uma aplicação J2ME com duas bibliotecas O fonte doKSOAPpode ser encontrado aqui:http://ksoap.MIDlet { 8. o-Todas as suas pastas e arquivos internos a esta pasta que estão no zip.org/software/downloads/current/ksoap-source. deve ser criado a classe ClienteJ2ME.objectweb. private String url = "http://localhost:8080/axis/Servico.ksoap. o-Todas as suas pastas e arquivos internos a esta pasta que estão no zip. + transport . kobjects 6. 8.java conforme abaixo: 1. import javax. No diretório SeuProjetoJ2ME.objectweb.microedition. 5.lcdui.Display. import javax.ksoap.Como pretende-se criar uma simples aplicação para celular (MIDP2).midlet. 10.org/software/downloads/current/kxml-source. Não serão utilizados as pastas referentes a servlets e a j2se do ksoap. * org 4.HttpTransport.microedition.transport. TextBox textbox = null. import org. 26 .zip 1. 2. 6.

40. // Chama o WebService 30. 18. 32. 36.addProperty("valor1". 28. 31. StringBuffer stringBuffer = new StringBuffer(). public void startApp() { 13. 0 ). 16. client."soma"). } 41. 38. 27. 33. Resultado: " + ht.setCurrent(textBox). 24. 12. public void testWebService() throws Exception { 25.toString().new Integer(4)). textBox = new TextBox("Teste WebService". display = Display. } catch (Exception ex) { 17. } 27 display. .println(ex). try { 15. TextBox textBox = null.out. public void destroyApp(boolean unconditional) {} 23.append(" 35. 26. stringBuffer.addProperty("valor2". testWebService(). // mostra o valor do resultado na tela. client. SoapObject client = new SoapObject(url. } 19.new Integer(2)). 39. 1024. HttpTransport ht = new HttpTransport(url. } 20.11. 29. 21.call(client)). 14. 37. public void pauseApp() {} 22.getDisplay(this)."soma"). System. stringBuffer. 34.

aplicações dos padrões de criação. sentimos a necessidade de aplicar uma arquitetura que facilite nosso trabalho. é 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. muitos dados são apresentados para os usuários. Além de contar com uma equipe de profissionais capacitados. Analisando entre os padrões existentes.Funcionalidades. 2000. os projetos de interface para o usuário tendiam em agrupar esses objetos. também seria necessário adotar padrões e técnicas que irão ajudar a desenvolver um bom sistema para a empresa. Na arquitetura MVC. 20). o MVC foi criado na década de 70. linguagem de programação que juntamente com o C++ ganhou grande reconhecimento na época. ou seja. Mas nos baseando na hipótese de a empresa querer desenvolver seu próprio software. 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). á lógica de negócios. A arquitetura MVC foi desenvolvida para ser usado em projetos de interface visual em Smalltalk. para reduzir os custos seria necessário também reduzir o tempo de desenvolvimento do mesmo e manter a qualidade e produtividade no desenvolvimento. o MVC é: MVC é composto por três tipos de objetos. MVC para aumentar a flexibilidade e a reutilização. 28 . a vista é a apresentação na tela e o controlador define a maneira como a interface do usuário reage às entradas do mesmo. O modelo é o objeto de aplicação. Para a Gamma et al. principalmente em aplicações web.6. e após esses anos de sua criação ainda é um pattern aplicável nas mais variadas aplicações. a idéia é permitir que uma mensagem da lógica de negócios possa ser acessada e visualizada através de várias interfaces.0 Projeto China Telecon . p. desde a organização do projeto. Antes do MVC. (GAMMA et al. 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. Quando um software começa a ficar grande e complexo. nosso Model não sabe quantas nem quais as interfaces com o usuário esta exibindo seu estado. A melhor solução para essa empresa seria realmente adotar um software de uma empresa especializada e com um bom suporte.

sempre que os estados do modelo mudam. (GONÇALVES. MVC é um conceito (paradigma) de desenvolvimento e design que tenta separar uma aplicação em três partes distintas. para sistemas persistentes. cada vista tem a chance de atualizar-se. é responsável pelas regras de negócio. tabelas. o modelo notifica as vistas que dependem dele. Controller. mas ela tem que garantir que sua aparência reflita o estado do modelo. Desta maneira permite ligar muitas vistas a um modelo podendo fornecer diferentes apresentações. Controller: já descrevemos da view e do modelo. 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 representa a informação (dados) dos formulários e as regras SQL para manipular dados do banco. ou seja. 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. todo o processamento é feito pelo Modelo e este repassa para a visão. menus e botões para entrada e saída de dados. 141). sua função como já diz é controlar coordenar o envio de requisições feitas entre a visão e o modelo. 29 . View: ou visão é a camada de apresentação com usuário. evidenciaremos abaixo um exemplo de duas vistas atuando sobre o mesmo modelo. Model: ou modelo é a camada que contém a lógica da aplicação. em coordenar os dois anteriores exibindo a interface correta ou executando algum trabalho que a aplicação precisa completar. mas. geralmente a visão contém formulários. nas aplicações web é representado pelo HTML que é mostrado pelo browser. A visão deve garantir que sua apresentação reflita o estado do modelo. um controlador funciona de intermediário entre a camada de apresentação e a camada de negócios. ou seja. Uma parte. o modelo notifica as view para que as mesmas atualizem-se. 2007. o modelo mantém o estado persistente do negócio e fornece ao controlador á capacidade de acessar as funcionalidades da aplicação. 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. quando os dados do modelo mudam. é a interface que proporcionará á entrada de dados e a visualização de respostas geradas. essa camada não contém códigos relacionados á lógica de negócios. a Model. p. temos de concordar que tudo isso se tornaria uma bagunça se tivesse alguém para organizar esta arquitetura.a view não se importa de onde esta recebendo os dados.

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. Composite. esta é um mecanismo de eventos necessário a comunicação entre outros três elementos. este avisa para a visão se atualizar. o controle é quem interpreta as solicitações (cliques. Embora o MVC só contenha três camadas há outra camada fundamental para o bom andamento da arquitetura. sabendo que é um padrão de arquitetural que confundem projetistas e desenvolvedores.O controller define o comportamento da aplicação. 2000. Design Patterns aplicados na arquitetura MVC A arquitetura MVC utiliza padrões de projetos em suas camadas analisamos a arquitetura agora com os patterns. Mais os principais relacionamentos do MVC são fornecidos pelos padrões Observer. para especificar por falta (by default) a classe controladora para uma vista e Decarator. ou seja. Abordamos agora os patterns Observer e Strategy que são padrões comportamentais e o Composite padrão estrutural. tais como Factory Method. 5. o controlador controla e mapeia as ações. este elemento permite uma comunicação assíncrona que é invocada quando algum evento interessante acontece. 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. . 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. Nas palavras de Gamma et al. quando este evento é ativado o controlador é avisado sobre o evento. para acrescentar capacidade de rolagem (scrolling) a uma vista. os principais padrões que o MVC utiliza são os Observer. O MVC usa outros padrões de projeto. e com eles podemos perceber que por traz do MVC pode conter um conjunto de padrões trabalhando juntos em uma mesma estrutura. Composite e o Strategy. o objetivo de abordar os patterns é para facilitar a compreensão de como a arquitetura MVC trabalha. esta quarta camada contém os beans de entidade onde se localizam os métodos get e set das classes. e ao mesmo tempo manda o modelo para que ele atue para contemplar o evento provocado pelo usuário. (GAMMA et al. 30 . 22) Os designs patterns nos ajuda á explicar a arquitetura MVC. Strategy. p.

entre outra coisas. que abstrai o código SQL da aplicação. 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. permitindo.Utilizando essa arquitetura. modificar a base de dados para outro SGBD (Sistema Gerenciador de Banco de Dados) sem modificar uma linha de código 31 . O Hibernate é um framework para mapeamento objeto/relacional em Java.

que teria que desenvolver seu próprio software para reduzir os custos. . baseada nos assuntos tratados nas disciplinas de Engenharia e Projeto de Software. sendo necessário também reduzir o tempo de desenvolvimento do mesmo e mantendo a qualidade e produtividade no seu desenvolvimento. Conhecendo a melhor arquitetura MVC que seria a melhor opção para o projeto China telecon.Conclusão O presente trabalho foi realizado uma pesquisa bibliográfica. Projeto Orientado a Objetos e Programação para Web II para melhor compreensão. 32 .

GOETTEN. J. JUNIOR. V.0. Struts. APACHE.Disponível em: <http://www." UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (Guia PMBoK).ufcg. Belém – PA. AVANSINI. Disponível em: <http://www. Acessado em: 11 Abril de 2015. Paraíba : Universidade Federal da Paraíba. 2007.scielo. Disponível em: <http://www. SAUVÊ.edu. Maringá.dsc. Guilherme Augusto Peron. 2008. José Yoshiriro Ajisaka.Referências. Universidade Estadual de Maringá Centro de Tecnologia – Departamento de Informática. Régis da Silva. Acesso em: 11 de abril de 2015 SIELO Frameworks.br/ jacques/ cursos/map/html/map1. ENGENHARIA DE SOFTWARE. SOMMERVILE. Frameworks. Acesso em 11 de maio de 2009. 2007. Acesso em: 11 maio de 2015. P. Frameworks para o desenvolvimento web. Notas de Aula. RAMOS. 33 . 2007. Ian.br/scielo.javafree. Instituto de Estudos Superiores da Amazônia. BORGES. 4º edição. Desmistificando o framework Jakarta Struts. São Paulo: Pearson Addison Wesley. 8 Edição. Pensylvania. Disponível em: . Jaguariúna. Investigação da efetividade de um Framework Corporativo de persistência de dados com base no Framework NHibernate em um ambiente empresarial. 2012.htm>. 2004. PMI. Comparação entre os principais Frameworks Java para o desenvolvimento de aplicações WEB 2.jf?idContent=22>.org/content/view. Java Free.php?script=sci_arttext&pid=S0034-76122011000500014>.