ABNT - UNOPAR - Completo

PAGE

SUMRIO31INTRODUO

42DESENVOLVIMENTO

42.1DESAFIO I RESENHA DAS AREAS DE CONHECIMENTO RISCO, ESCOPO, FORNECEDORES E PARTES INTERESSADAS DO PMBOK.

42.1.1Riscos

52.1.2Escopo

62.1.3Fornecedores

72.1.4Partes Interessadas

92.2DESAFIO II ENGENHARIA DE SOFTWARE, RESENHAS DOS CAPTULOS 11,12,13 E 29.

92.2.1PROJETO DE ARQUITETURA (CAP. 11)

92.2.1.1Decises de projeto de arquitetura (Cap. 11.1)

102.2.1.2Organizao de sistema (Cap. 11.2)

102.2.1.2.1O modelo Repositrio (Cap. 11.2.1)

112.2.1.2.2Modelo cliente-servidor (Cap. 11.2.2)

112.2.1.2.3O modelo em camadas (Cap. 11.2.3)

122.2.1.3Estilos de decomposio modular (Cap. 11.3)

122.2.1.3.1Decomposio orientada a objetos (Cap. 11.3.1)

132.2.1.3.2Pipeline orientado a funes (Cap. 11.3.2)

132.2.1.4Modelos de controle (Cap. 11.4)

132.2.1.4.1Controle centralizado (Cap. 11.4.1)

142.2.1.4.2Sistemas orientados a eventos (Cap. 14.4.2)

152.2.1.5Arquiteturas de referncia (Cap. 11.5)

162.2.2ARQUITETURA DE SISTEMAS DISTRIBUIDOS (Cap. 12)

162.2.2.1Arquitetura de multiprocessadores (Cap. 12.1)

172.2.2.2Arquiteturas cliente servidor (Cap. 12.2)

192.2.2.3Arquiteturas de objetos distribudos (Cap. 12.3)

202.2.2.3.1CORBA (Cap. 12.3.1)

212.2.2.4Computao Interorganizacional distribuda (Cap. 12.4)

212.2.2.4.1Arquiteturas Ponto a ponto (Cap. 12.4.1)

212.2.2.4.2Arquitetura de sistema orientada a servios (Cap. 12.4.2)

232.2.3ARQUITETURA DE APLICAES (Cap.13)

232.2.3.1Sistemas de processamento de dados (Cap. 13.1)

242.2.3.2Sistemas de processamento de transaes (Cap. 13.2)

242.2.3.2.1Sistemas de gerenciamento de informaes e recursos (Cap. 13.2.1)

252.2.3.3Sistema de processamento de eventos (Cap. 13.3)

262.2.3.4Sistemas de processamento de linguagem (Cap. 13.4)

262.2.4GERENCIAMENTO DE CONFIGURAO (Cap 29)

262.2.4.1Planejamento de gerenciamento de configurao (Cap. 29.1)

262.2.4.1.1Identificao de item de configurao (Cap. 29.1.1)

262.2.4.1.2Banco de dados (Cap. 29.1.2)

272.2.4.2Gerenciamento de mudanas (Cap. 29.2)

272.2.4.3Gerenciamento de verses e releases (Cap. 29.3)

272.2.4.3.1Identificao de verso (Cap.29.3.1)

282.2.4.3.2Gerenciamento de releases (Cap. 29.3.2)

282.2.4.4Construo de sistemas (Cap. 29.4)

282.2.4.5Ferramentas CASE para gerenciamento de configurao (Cap. 29.5)

282.2.4.5.1Apoio para gerenciamento de mudanas (Cap. 29.5.2)

292.2.4.5.2Apoio para gerenciamento de sistemas (Cap. 29.5.3)

292.3DESAFIO III FRAMEWORKS DE DESENVOLVIMENTO JAVA

292.3.1Pesquisa bibliogrfica sobre frameworks

292.3.1.1Interface

312.3.1.2Persistncia de dados

312.3.2Benefcios de uso de frameworks

312.3.3Plataforma de desenvolvimento JAVA Web

322.4DESAFIO IV ANLISE CHINA TELECOM

333CONCLUSO

34REFERNCIAS

1 INTRODUO

Em um ambiente de crescente demanda para o desenvolvimento de software cresce tambm a responsabilidade por quem os fabrica, pensando nisso aumentou a preocupao das empresas em estabelecer e seguir padres de projetos e de desenvolvimentos, durante o transcorrer deste trabalho apresentaremos alguns aspectos do gerenciamento de projetos baseados no guia PMBOK, apresentaremos tambm o livro Engenharia de Software de Ian Sommerville alm de fazermos um comparativo de utilizao de frameworks de desenvolvimento java, por ltimo, apresentaremos uma soluo com base no estudo de caso da empresa China telecom.2 DESENVOLVIMENTO2.1 DESAFIO I RESENHA DAS AREAS DE CONHECIMENTO RISCO, ESCOPO, FORNECEDORES E PARTES INTERESSADAS DO PMBOK.2.1.1 RiscosA gerncia de riscos do projeto inclui os processos referentes ao planejamento da gerncia de riscos, identificao, anlise, ao planejamento das respostas e ao controle e monitorao dos riscos em um projeto. Esses processos interagem entre si e com os processos das outras reas do conhecimento. Os objetivos da gerncia de risco so aumentar a probabilidade de ocorrncia e os impactos de eventos positivos e diminuir a probabilidade e os impactos dos eventos adversos aos objetivos do projeto. Os processos da gerncia de risco so [PMBOK, 2000]:

Planejamento da gerncia de riscos: planejar as atividades de gerncia de risco a serem realizadas para o projeto.

Identificao dos riscos: identificar os riscos que podem afetar o projeto, documentando suas caractersticas.

Anlise qualitativa dos riscos: analisar qualitativamente os riscos, priorizando seus efeitos no projeto.

Anlise quantitativa dos riscos: mensurar a probabilidade de ocorrncia dos riscos e suas consequncias e estimar as implicaes no projeto.

Planejamento da resposta aos riscos: gerar procedimentos e tcnicas para avaliar oportunidades, objetivando mitigar as ameaas no projeto.

Monitorao e controle dos riscos: monitorar os riscos residuais, identificar novos riscos, executar os planos de mitigao de riscos e avaliar sua efetividade durante todo o ciclo de vida do projeto.2.1.2 Escopo

O gerenciamento do escopo o processo de definir qual trabalho necessrio e garantir que todo este trabalho, e apenas este trabalho, seja executado. O escopo do projeto o trabalho que ser feito para entregar o produto do projeto, e engloba o escopo do produto.Segundo o PMI, o gerenciamento de escopo esta subdivididos nos seguintes processos:

Iniciao: o reconhecimento formal da necessidade de um novo projeto ou continuidade de um projeto j existente, para atender uma determinada necessidade da organizao (novo produto, exigncia legal, atualizao tecnolgica, necessidade social, etc.). Sero utilizadas neste processo as descries do produto, o plano estratgico da organizao, critrios de seleo de projeto e informaes histricas pertinentes ao trabalho a ser realizado. Desta forma, mtodos de seleo de projeto e avaliao especializada podero gerar o Project Charter (Carta do Projeto), documento que autoriza formalmente o projeto, alm de identificar o gerente de projeto, premissas e restries; Planejamento do escopo: Utilizando-se as descries do produto, Project Charter, premissas e restries, possvel elaborar e documentar o trabalho do projeto, de forma a produzir o produto do projeto. Ser feita uma anlise do produto, bem como do custo/benefcio, identificao de alternativas, podendo exigir avaliao especializada, produzindo a declarao de escopo e plano de gerenciamento de escopo; Detalhamento do escopo: A partir dos subprodutos do projeto, definidos anteriormente, possvel subdividi-los em componentes menores e mais gerenciveis, melhorando a preciso das estimativas de custo, tempo e recursos, controlar o desempenho e atribuir responsabilidades. Nesta fase ser criado o WBS (Work Breakdown Structure) ou EAP (Estrutura Analtica de Projeto), um documento reutilizvel entre projetos similares que decompe os principais subprodutos do projeto em componentes menores, chegando ao nvel de atividades; Verificao do escopo: Formalizao do aceite do escopo do projeto pelos Stakeholders, de forma a garantir que o trabalho est sendo contemplado correta e satisfatoriamente. Nesta fase importante tanto a exatido como a aceitao do escopo. A documentao gerada anteriormente ser utilizada para inspeo e aceitao formal; Controle de mudanas do escopo: As mudanas devero ser identificadas, discutidas e combinadas, devendo ser gerenciadas de forma efetiva e com aprovao dos Stakeholders. Devem ser utilizados sistemas de controle de mudanas de escopo, medies de desempenho e planejamento adicional, de forma a documentar as mudanas, tomar aes corretivas e registras as lies aprendidas em uma base histrica.O escopo o corao do projeto, onde colocamos o objetivo do servio ou produto proposto pelo projeto. Quanto maior os detalhes do escopo menor o risco de o projeto ter um desvio. O Gerente do Projeto deve fazer um monitoramento minucioso do escopo durante a execuo verificando assim se nada est saindo do que foi planejado e gerenciando as mudanas do escopo aprovando ou reprovando conforme a necessidade do projeto, para que se obtenha um resultado positivo ao final do projeto.2.1.3 Fornecedores

A gesto de fornecedores feita na rea de conhecimento referente a gerenciamento de aquisies do projeto, captulo que trata dos processos necessrios para comprar ou adquirir produtos, servios ou resultados externos equipe do projeto. O gerenciamento de aquisies uma das reas de conhecimento do Guia PMBOK frequentemente empregada no gerenciamento de projetos, seja o projeto de pequeno, mdio ou grande porte. A prtica da terceirizao, verificada de modo especial nas ltimas duas dcadas, tem, de uma forma geral, tornado cada vez mais presente a figura do fornecedor como um personagem importante para a realizao do projeto, seja este fornecedor de recursos ou servios. Em muitos casos o fracasso de fornecedores de materiais, equipamentos ou servios durante o andamento do projeto poder trazer impactos significativos ao cumprimento do projeto, ou mesmo comprometer a sua realizao. Para poder alcanar os objetivos do projeto, o gerente de projeto deve conhecer e estar alinhado s boas prticas da gesto de aquisies.O objetivo bsico do gerenciamento de aquisies em projetos propiciar a construo e a manuteno de relaes comerciais slidas e equilibradas entre cliente e fornecedor, de forma que o projeto possa ser finalizado a contento. Segundo o Guia PMBOK, existem um total de 6 (seis) processos includos na rea de conhecimentos do gerenciamento de aquisies em projetos, so eles:

Planejar compras e aquisies;

Planejar contrataes;

Solicitar respostas de fornecedores;

Selecionar fornecedores;

Administrao do contrato;

Encerramento do contrato.

Dentre os elementos presentes nestas prticas, merece destaque a elaborao da documentao que detalhar o escopo do fornecimento (SOW) dos produtos e servios a serem contratados. o momento em que todo o know-how da equipe de projetos deve ser explorado, j que os eventuais erros ou omisses que possam estar presentes no SOW certamente se tornaro riscos de ameaa para o projeto e riscos de oportunidade para o fornecedor.2.1.4 Partes Interessadas

As partes interessadas so compostas por todas as entidades que possuem algum interesse, sejam estas internas ou externas, bem como toda a equipe de gerenciamento de projetos. Cabe ao gerente de projetos garantir que, na iniciao do projeto, o maior nmero possvel de partes interessadas seja identificado, com o objetivo de garantir que os requisitos do projeto e as expectativas das partes interessadas sejam devidamente identificados e registrados. Alm disto, cabe ao gerente de projetos assegurar o correto gerenciamento da influncia das partes interessadas, visando assegurar o sucesso do projeto.As partes interessadas podem influenciar os objetivos do projeto de maneira negativa ou positiva, bem como podem entender que os objetivos do projeto afetam, de maneira negativa ou positiva, os seus interesses.Basicamente, pode-se definir que as partes interessadas de um projeto so compostas por:

Patrocinador: pessoa ou Grupo que fornece suporte e recursos, financeiros ou no, para o projeto. O patrocinador responsvel pelo sucesso do projeto. O patrocinador promove o projeto desde a concepo inicial at seu encerramento, serve como porta-voz para o Board da organizao. responsabilidade do patrocinador conduzir o projeto atravs dos processos iniciais at a autorizao formal para execuo do projeto. O patrocinador desempenha um papel fundamental na definio do escopo inicial e do termo de abertura do projeto.

Clientes e Usurios: os clientes so pessoas ou organizaes que iro aprovar e gerenciar o resultado, produto ou servio criado pelo projeto. Os usurios so definidos como organizaes ou pessoas que usaro o produto, resultado ou servio criado pelo projeto.

Fornecedores: Empresas externas, terceiros, que prestam o fornecimento de servios ou insumos necessrios para a execuo do projeto.

Parceiros de Negcio: empresas externas que possuem uma relao que vai alm da relao de um fornecedor. Possuem uma importncia maior, para a execuo do projeto, do que os simples fornecedores.

Grupos Organizacionais: so definidos como partes interessadas internas organizao, que podem ser afetadas pelas atividades do projeto. Resumidamente, so os departamentos internos da organizao.

Gerentes Funcionais: so profissionais que desempenham a funo gerencial dentro da organizao. Este profissional pode fornecer consultoria sobre o assunto de especialidade atribuda a ele.

Outras Partes Interessadas: so outras partes interessadas que podem ter um interesse no projeto, por exemplo: instituies financeiras, sindicatos, rgos reguladores entre outros.

2.2 DESAFIO II ENGENHARIA DE SOFTWARE, RESENHAS DOS CAPTULOS 11,12,13 E 29.

2.2.1 PROJETO DE ARQUITETURA (CAP. 11)

Objetivo de apresentao dos conceitos de arquitetura de software e projeto de arquitetura.2.2.1.1 Decises de projeto de arquitetura (Cap. 11.1)

Capitulo que trata da dificuldade enfrentada pelo arquiteto de softwares na definio de uma arquitetura, apresenta de uma forma geral os estilos de arquitetura conhecidos como as estruturas cliente-servidor e camadas e destaca que o verdadeiro teste da arquitetura recai sob o quo bem ela atende os requisitos funcionais e no funcionais. Ao concluir as decises do projeto de arquitetura, gerado um documento de projeto de arquitetura que pode incluir vrias representaes grficas do sistema juntamente com texto descritivo aonde dever conter informaes de como os subsistemas esto estruturados, a abordagem adotada e como cada subsistema est estruturado em mdulos. Os modelos de arquitetura que podem ser desenvolvidos podem incluir: Um modelo esttico de estrutura de mostra os subsistemas ou componentes desenvolvidos como unidades separadas. Um modelo dinmico de processo de mostra como o sistema est organizado em processos em tempo de execuo.

Um modelo de interface de define os servios oferecidos por cada subsistema por meio de suas interfaces pblicas.

Modelos de relacionamentos que mostram os relacionamentos, tal como fluxo de dados, entre os subsistemas.

Um modelo de distribuio que mostra como os subsistemas podem ser distribudos pelos computadores.

2.2.1.2 Organizao de sistema (Cap. 11.2)Captulo que trata dos modelos de organizao dos sistemas e apresenta trs estilos organizacionais amplamente usados, estes estilos podem ser usados separadamente ou juntos. 2.2.1.2.1 O modelo Repositrio (Cap. 11.2.1)Sistemas cujas partes precisam trocar dados com frequncia aonde dados compartilhados podem ser mantidos em um banco de dados central e acessados por todos os subsistemas, cada subsistema mantm seu prprio banco de dados e passa dados para outros subsistemas, podem usar uma abstrao de repositrio centralizado possui Implementao distribuda.

2.2.1.2.2 Modelo cliente-servidor (Cap. 11.2.2)Modelo subdividido em trs principais componentes, um conjunto de servidores onde os servios so disponibilizados, conjunto de clientes que solicita os servios aos servidores e uma estrutura de rede que permite a comunicao entre os servidores e os clientes. A figura abaixo demostra um sistema multiusurio que oferece um acervo de filmes e fotografias. A principal vantagem deste modelo a caracterstica de ser uma arquitetura distribuda, que permite a separao do processamento em muitos processadores, alm disso, quando houver necessidade de se adicionar um novo servidor e integr-lo ao restante isso pode ser feito facilmente e de maneira transparente s outras partes do sistema.

2.2.1.2.3 O modelo em camadas (Cap. 11.2.3)Modelo arquitetural que organiza o sistema em camadas onde cada camada fornece um conjunto de servios, essa abordagem apoia o desenvolvimento incremental de sistemas, aonde a medida que a camada desenvolvida alguns servios fornecidos por essa camada j podem ser disponibilizados, podemos dizer tambm que esta arquitetura modificvel e portvel

2.2.1.3 Estilos de decomposio modular (Cap. 11.3)Captulo que aborda os modelos de decomposio dos subsistemas em mdulos, como no h uma distino rgida entre organizao do sistema e decomposio modular os estilos apresentados no capitulo anterior podem ser utilizados neste nvel tambm, apesar de no haver distino interessante pensar que os mdulos normalmente so compostos de outros sistemas mais simples do sistema.Existem duas estratgias principais que podem ser usadas para decompor um subsistema em mdulos:

Decomposio orientada a objetos Compem conjuntos de objetos que se comunicam. Pipelining orientado a funo Decomposio orientado a funo aonde os mdulos aceitam dados de entrada e transforma-os em dados de sada.

2.2.1.3.1 Decomposio orientada a objetos (Cap. 11.3.1)Esta forma decomposio baseada na premissa que os dados e no as funes so a parte mais importante do sistema. Este tipo de decomposio interpreta um software como sendo uma quantidade de estruturas de dados isoladas que formam no seu todo a estrutura base do sistema. No nvel arquitetural, frequentemente empregado na construo de sistemas distribudos onde uma implementao orientada a objetos no implica em uma arquitetura orientada a objetos.

2.2.1.3.2 Pipeline orientado a funes (Cap. 11.3.2)Modelo de decomposio onde as transformaes funcionais processam suas entradas para produzir sadas. O estilo tambm pode ser chamado de duto e filtro, suas principais vantagens so o apoio ao reuso de transformaes, uma arquitetura intuitiva, de fcil evoluo e simples e ser implementada.Um problema comum no estilo de arquitetura a necessidade de utilizao de um formato comum para transferncia de dados que possa res reconhecido por todas as transformaes.

No indicado para uso em sistemas interativos pela necessidade de haver uma sequencia de dados a ser processada aonde as entradas baseadas em eventos como cliques ou seleo de menus so difceis de serem traduzidas de forma compatvel com o modelo pipelining.2.2.1.4 Modelos de controle (Cap. 11.4)

Capitulo trata da forma que os subsistemas so controlados para funcionar como um sistema de maneira que seus servios sejam entregues no lugar certo e no tempo certo. Existem dois estilos genricos de controle que so usados: Centralizado Um subsistema controla todo o sistema.

Baseado em eventos Cada subsistema autnomo para responder a eventos esternos.

Modelos de controle so usados em conjunto com estilos de estrutura.

2.2.1.4.1 Controle centralizado (Cap. 11.4.1)

Modelo de controle centralizado onde um subsistema designado para controlar os demais, est incorporado em linguagens como C, Ada e Pascal e dividem-se em duas formas de controle de acordo com a forma que os subsistemas so executados. Sequencial, aonde o modelo executado conhecido como chamada-retorno aonde o modelo inicia a execuo pelo topo e passa para os nveis mais baixos da rvore (top-down) e paralelos, aplicado em sistemas concorrentes, conhecido como modelo gerenciado, os processos so executados (ou podem ser executados) paralelamente.O processo controlador decide quando os processos devem ser iniciados ou interrompidos, geralmente est em loop contnuo sempre verificando mudanas de estado dos sensores por isso conhecido tambm por modelo evento-loop.

2.2.1.4.2 Sistemas orientados a eventos (Cap. 14.4.2)Enquanto nos sistemas com controle centralizado as decises so tomadas a partir de dados de variveis, nos sistemas orientados a eventos o que determina as decises so os eventos gerados externamente aonde evento neste contexto significa sinal binrio. Dois modelos so abordados pelo autor:

Modelos de broadcast Onde o evento transmitido a todos os subsistemas, eficazes na integrao de sistemas distribudos na rede.

Modelo orientado a interrupo Usado em sistemas que trabalham em tempo real aonde um tratador de interrupes trata os eventos.

2.2.1.5 Arquiteturas de referncia (Cap. 11.5)

Este captulo aborda os modelos arquiteturais de referncia, os modelos que foram citados anteriormente so modelos gerais, os tratados neste captulo se referem a um domnio especfico, geralmente os modelos genricos so bottom-up e os de referncia so top-down.Dentre os modelos de referncia temos o modelo OSI, um modelo de sete camadas onde as camadas inferiores esto relacionadas a interconexo fsica; as camadas intermediarias, transferncia de dados e as superiores a transferncia de informaes, a figura 11.11 a seguir demonstra o modelo.

Outro modelo de referncia o modelo para ambientes CASE, onde identificado cinco nveis de servio que ambientes CASE devem fornecer. Repositrio de dados - onde os dados so armazenados, Integrao de dados - que fornece recursos para gerenciamento, Gerenciamento de tarefas fornecem recurso para definio e aprovao de modelos de processos, Mensagem fornece comunicao entre as ferramentas e Interface de Usurio recursos para desenvolvimento de interfaces de usurio. A figura 11.12 a seguir demonstra o modelo.

2.2.2 ARQUITETURA DE SISTEMAS DISTRIBUIDOS (Cap. 12)

Sistema distribudo todo o sistema onde o processamento de informaes distribudo em vrios computadores ao invs de confinado em uma nica mquina, existem duas formas de compartilhamento/distribuio de processamento em arquitetura de software so elas as arquiteturas cliente-servidor onde as maquinas clientes fazem uso dos servios disponibilizados pelos servidores e as arquiteturas de objetos distribudos onde no h distino de o que cliente e o que servidos, os objetos so distribudos e interagem entre si onde a localizao irrelevante. So desenvolvidos com uma abordagem orientada a objetos que refletem suas caractersticas, portanto so abstraes naturais para os componentes do sistema distribudo.2.2.2.1 Arquitetura de multiprocessadores (Cap. 12.1)Sistema composto de mltiplos processos que podem (mas no precisam) executar em processadores diferentes, a distribuio de processo para o processador pode ser predeterminada ou pode estar sob o controle de um escalonador.

2.2.2.2 Arquiteturas cliente servidor (Cap. 12.2)A aplicao modelada como um conjunto de servios que so fornecidos pelos servidores e um conjunto de clientes que usam estes servios, os clientes sabem da existncia dos servidores, mas os servidores no sabem dos clientes.

Dentro da mesma ideia de cliente-servidor tambm temos os cliente-servidor em camadas onde temos:

Camada de apresentao Est relacionada apresentao dos resultados de um processamento para os usurios do sistema, e coleta de entradas do usurio.

Camada de processamento de aplicao Est relacionada ao fornecimento de funcionalidade especfica da aplicao, por exemplo, em um sistema de banco, funes bancrias, tais como abrir conta, fechar conta, etc.

Camada de gerenciamento de dados Est relacionada ao gerenciamento do banco de dados do sistema.

Modelo de cliente-magro Em um modelo cliente-magro, todo o processamento de aplicao e o gerenciamento de dados realizado no servidor. O cliente responsvel, simplesmente por executar o software de apresentao.

Modelo de cliente-gordo Nesse modelo, o servidor responsvel somente pelo gerenciamento de dados. O software do cliente implementa a lgica da aplicao e as interaes com o usurio do sistema.

Arquiteturas em trs camadas, podem ser executadas em maquinas separadas proporcionando escalabilidade e interoperabilidade.

2.2.2.3 Arquiteturas de objetos distribudos (Cap. 12.3)Nestes modelos de arquitetura, no existem distines entre clientes e servidores, cada entidade distribuvel um objeto que fornece servios para outros objetos e recebe servios de outros objetos, se comunicam atravs de um sistema de middleware chamado requisitor de objetos que tem o papel de fornecer uma interface transparente e contnua entre os objetos, as principais vantagens deste modelo so a possibilidade do projetista decidir posteriormente como e onde os servios devem ser fornecidos, uma arquitetura aberta que permite adio de novos recursos, novos recursos podem ser adicionados quando a carga do sistema aumentas sem interromper outros objetos do sistema e a possibilidade de reconfigurar o sistema dinamicamente com objetos que migram atravs da rede conforme necessrio.

2.2.2.3.1 CORBA (Cap. 12.3.1)

Da sigla Common Object Request Broker Architecture, tem por objetivo a interoperabilidade entre diferentes sistemas computacionais e linguagens de programao atravs de ORBs, que so estruturas que permitem que os programadores faam chamadas de um computador a outro atravs de uma rede. O CORBA definido e padronizado pela OMG.

ORBs so um conjunto de objetos em uma biblioteca que so ligadas a uma aplicao quando ela desenvolvida ele manipula comunicaes e conhece todos os objetos no sistema e suas interfaces. Usando um ORB, o objeto chamador liga um stub IDL que define a interface do objeto chamado, O chamado desse stub resulta em chamadas para o ORB, que ento chama um objeto requisitado por meio de um esqueleto IDL publicado que liga a interface implementao de servios.

2.2.2.4 Computao Interorganizacional distribuda (Cap. 12.4)

2.2.2.4.1 Arquiteturas Ponto a ponto (Cap. 12.4.1)Sistemas descentralizados onde a computao pode ser realizada em qualquer n da rede, o sistema global desenvolvido para se beneficiar da capacidade computacional. As principais vantagens so redundncia, tolerncia a defeitos, maior eficincia. As desvantagens so overhead de comunicao, mensagens replicadas, proteo dos dados e confiana.

2.2.2.4.2 Arquitetura de sistema orientada a servios (Cap. 12.4.2)O desenvolvimento da web promoveu o acesso distribudo a informaes, porm a princpio o acesso era somente atravs de navegadores, pensando em aumentar a disponibilidade de informaes clientes remotos surgiu o webservice que garante a publicao da informao para ser acessada por um software cliente, esta arquitetura conhecida com semiscentralizada.

O fornecimento dos servios , portanto, independente da aplicao que usa o servio, um web service uma abordagem padronizada para tornar-se um componente reusvel disponvel e acessvel atravs da rede.

Um sistema de informaes de um automvel fornece aos motoristas informaes sobre o clima, condies de trfego, Informaes locais, etc. O sistema ligado ao aparelho de rdio do automvel que apresenta as informaes como um sinal de emissora de rdio especfica. O automvel equipado com um receptor GPS para informar sua posio e, baseado nessa posio, o sistema acessa uma gama de servios de informaes. A informao pode ser fornecida no idioma especificado pelo motorista.

2.2.3 ARQUITETURA DE APLICAES (Cap.13)2.2.3.1 Sistemas de processamento de dados (Cap. 13.1)As empresas possuem um sistema de concentrao de dados, estes sistemas so muitas vezes maiores que as aplicaes em si, estes sistemas de processamento de dados so sistemas de processamento em lotes nos quais os dados so entradas e sadas em lote de um arquivo ou banco de dados em vez de entradas ou sadas para um terminal de usurio. A arquitetura de sistemas de processamento em lotes tem trs componentes principais entrada, processo e sada conforme figura.2.2.3.2 Sistemas de processamento de transaes (Cap. 13.2)Os sistemas de processamento de transao so projetados para executar atualizaes informaes em banco de dados.

2.2.3.2.1 Sistemas de gerenciamento de informaes e recursos (Cap. 13.2.1)

Todo o sistema que possui interao com banco de dados pode ser considerado um sistema baseado em transaes, para entendermos melhor o sistema de gerenciamento de informaes e recursos observe as figuras a seguir.

O componente LIBSYS autentica os usurios

O componente gerenciador de formulrios gerencia os formulrios que podem ser apresentados aos usurios

O componente gerenciador de impressoras controla o gerenciamento de impresses que pode ter restries conforme requisitos.

A camada de recuperao e modificao do LIBSYS possui os seguintes componentes especficos Busca distribuda que procura os documentos em resposta s consultas.

Recuperao de documentos que recupera os documentos solicitados pelo usurio.

Gerenciador de direitos que gerencia as alteraes e direitos autorais, mantm registro de quem requisitou o documento e assegura que no sejam feitas vrias requisies para o mesmo documento pela mesma pessoa.

Contabilidade que registra as solicitaes e cuida de quaisquer encargos criados pelas bibliotecas.2.2.3.3 Sistema de processamento de eventos (Cap. 13.3)Os sistemas de processamento de eventos respondem aos eventos do ambiente ou da interface com o usurio do sistema, sistemas com funcionamento em tempo real so sistemas de processamento de eventos, porm os eventos so associados a sensores e atuadores do sistema. Podemos utilizar como exemplo os sistemas de processamento de texto e jogos.

2.2.3.4 Sistemas de processamento de linguagem (Cap. 13.4)

Os sistemas de processamento de linguagens aceitam uma linguagem natural ou artificial como entrada e geram alguma outra representao dessa linguagem como sada. Ex. Compiladores e descrio de dados XML em comandos.

2.2.4 GERENCIAMENTO DE CONFIGURAO (Cap 29)

Envolve o desenvolvimento e a aplicao de procedimentos e padres para gerenciar um produto de software em evoluo, o GC pode ser visto como parte de um processo mais geral de gerenciamento do projeto, os artefatos que esto sob gerenciamento de configurao so chamados de itens de configurao.

2.2.4.1 Planejamento de gerenciamento de configurao (Cap. 29.1)

Processo que define o que ser gerenciado, quem o responsvel pelo gerenciamento, as polticas de gerenciamento, especifica as ferramentas que sero usadas e descreve a estrutura do banco de dados de configurao.2.2.4.1.1 Identificao de item de configurao (Cap. 29.1.1)

Processo onde feito a deciso de quais itens (ou classe de itens) sero controlados.

2.2.4.1.2 Banco de dados (Cap. 29.1.2)

Utilizado para registrar todas as informaes referente as configuraes do sistema e os itens de configurao e alm disso, informaes tpicas como quais clientes pegaram a verso, configurao de HW necessria, quantas verses do sistema foram criadas, quais verses podem ser impactadas por uma alterao, quantas solicitaes de mudana surgiram e quantos defeitos foram reportados.

2.2.4.2 Gerenciamento de mudanas (Cap. 29.2)

Sistemas de software so sujeitos a solicitaes contnuas de mudana, mudanas essas que podem partir de usurios, desenvolvedores ou foras do mercado. O gerenciamento de mudanas est relacionado manuteno da rastreabilidade dessas mudanas de modo que reparos realmente corrijam falhas, novas falhas produzidas por reparos possam ser identificadas rapidamente e seja fcil descobrir quais mudanas foram implementadas e quando.

O maior problema no gerenciamento de mudanas o acompanhamento de seu status por isso ferramentas de gesto de mudanas fornecem meios para se acompanhar a situao de cada solicitao, as mudanas devem ser analisadas por um grupo que analise se elas so adequadas ou no em termos de custo, tempo, risco e tambm de um ponto de vista estratgico ou organizacional ao invs de somente o ponto de vista tcnico.

2.2.4.3 Gerenciamento de verses e releases (Cap. 29.3)

Usado para elaborar um esquema de identificao para verses do sistema, planejar quando uma nova verso do sistema ser produzida, asseguras de procedimentos e ferramentas de gerenciamento das verses sejam adequadamente aplicas alm de planejar a distribuio de novas releases ou verses do sistema.

2.2.4.3.1 Identificao de verso (Cap.29.3.1)

uma instncia de um sistema que funcionalmente distinta, de alguma maneira, de outras instncias de um sistema, existem 3 tcnicas bsicas para identificao de verso:

Numerao de veres Nmero explcito e nico da verso Identificao baseada em atributos Identificao pelo nome ou valores de atributos Identificao orientada a mudanas Identificada pelo conjunto de solicitaes que se aplicaram ao componente.2.2.4.3.2 Gerenciamento de releases (Cap. 29.3.2)

uma instncia de um sistema distribuda para os usurios fora da equipe de desenvolvimento, somente liberada aps a anlise de fatores estratgicos.

2.2.4.4 Construo de sistemas (Cap. 29.4)

A construo de sistema a compilao e ligao e ligao de componentes de software que executa determinada configurao questes como. Todos os componentes foram includos? As verses so as necessrias para construo? Todos os arquivos esto disponveis? A verso do compilador requerido est disponvel?

Hoje em dia, os gerenciadores de configurao auxiliam no processo de construo do sistema onde todas as dependncias so especificadas no script de configurao.

2.2.4.5 Ferramentas CASE para gerenciamento de configurao (Cap. 29.5)

A responsabilidade no gerenciamento de configuraes exige rigor ao gerar uma nova verso, por isso foi necessrio o desenvolvimento do uso de ferramentas CASE para facilitar e melhorar este controle. Muitos sistemas de grande porte so produzidos em lugares diferentes e por isso necessitam de um sistema de SCM que apoie esta forma de trabalho como a CVS que conta com este recurso.2.2.4.5.1 Apoio para gerenciamento de mudanas (Cap. 29.5.2)

Existem ferramentas CASE para auxlio no gerenciamento de mudanas, desde as mais simples e OpenSource como o BugZila at as mais abrangentes e integradas com a ClearQuest da Rational, estas ferramentas fornecem uma srie de funcionalidades que facilitam o controle de mudanas como editor de formulrios, sistemas de workflow, compilao distribuda e gerenciamento de objetos derivados.

2.2.4.5.2 Apoio para gerenciamento de sistemas (Cap. 29.5.3)

O processo de construo do sistema dependendo do tamanho do projeto pode envolver diversos arquivos, a gesto destes arquivos para compilao se depender de mo humana pode ser crtica para o sistema por isso, aconselhado o uso de fermentas case que fazem o gerenciamento dos arquivos e ligaes de forma automtica evitando possveis erros humanos. Caractersticas como uma linguagem de especificao de dependncia e um interpretador associado, seleo de ferramenta de apoio a instalao, compilao distribuda e gerenciamento de objetos derivados normalmente esto presentes nestas ferramentas.2.3 DESAFIO III FRAMEWORKS DE DESENVOLVIMENTO JAVA

Framework uma abstrao que une cdigos comuns entre vrios projetos de software provendo uma funcionalidade genrica. Um framework pode atingir uma funcionalidade especfica, por configurao, durante a programao de uma aplicao. Ao contrrio das bibliotecas, o framework quem dita o fluxo de controle da aplicao, chamado de Inverso de Controle.No desenvolvimento, utilizar um framework til quando se utiliza aquela funcionalidade com frequncia. Atualmente podemos encontrar diversos frameworks disponveis para uso, faremos um comparativo dos principais.

2.3.1 Pesquisa bibliogrfica sobre frameworks

2.3.1.1 Interface Struts Framework desenvolvido por Craig McClanahan e doado a apache foundation, O objetivo do Struts separar o model (modelo - lgica de aplicativo que interage com um banco de dados) do view (visualizao - pginas HTML apresentadas para o cliente) e do controller (controlador - instncia que transmite informaes entre a exibio e o modelo). Struts fornece o controlador/controller (um servlet conhecido como ActionServlet) e facilita a escrita de moldes padronizados para a camada de visualizao/view (normalmente em JSP, mas XML/XSLT e Velocity tambm so suportados). O programador de aplicativo da web responsvel por escrever o cdigo do modelo/model, e por criar um arquivo de configurao centralizador (struts-config.XML) que une modelo, visualizao e controlador. As principais funes so a facilitao de populao de beans (Action Forms), a simplificao do uso de servlets, necessitando apenas a criao de classes Action e possibilita a dispensa do uso de scriptlets em 98% dos casos.

JSF - um framework para a construo de interfaces de usurio baseadas em componentes para aplicaes web. Possui um modelo de programao dirigido a eventos, abstraindo os detalhes da manipulao dos eventos e organizao dos componentes, permitindo que o programador se concentre na lgica da aplicao. Suas principais caractersticas so: Permite que o desenvolvedor crie UIs atravs de um conjunto de componentes UIs pr-definidos;

Fornece um conjunto de tags JSP para acessar os componentes;

Reutiliza componentes da pgina;

Associa os eventos do lado cliente com os manipuladores dos eventos do lado do servidor (os componentes de entrada possuem um valor local representando o estado no lado servidor);

Fornece separao de funes que envolvem a construo de aplicaes Web.

Utiliza Ajax em alguns de seus componentes tornando alguns processos mais rpidos e eficientes.2.3.1.2 Persistncia de dados

Hibernate - Framework para o mapeamento objeto-relacional escrito na linguagem Java, Este framework facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicao, o objetivo do Hibernate diminuir a complexidade entre os programas Java sendo sua principal caracterstica a transformao das classes em tabelas de dados alm dos tipos de dados do JAVA para SQL. JDO - Plataforma para persistncia de objetos, uma das suas funcionalidades o servio de persistncia para o modelo de domnio. Ela disponibiliza uma interface bem definida que prov uma camada de abstrao entre as aplicaes e armazenadores de dados de vrios tipos. Os objetos persistentes na especificao JDO so objetos de classes simples escritas em Java (POJOs); no existe necessidade de implementar certas interfaces ou estender classes especiais.2.3.2 Benefcios de uso de frameworks

As principais vantagens do uso de frameworks para desenvolvimento java a reduo de custos e a reduo do tempo de entrega pela maximizao do reuso, menor manuteno.2.3.3 Plataforma de desenvolvimento JAVA WebPara execuo e implementao de um sistema web desenvolvido em java necessrio a instalao de alguns componentes que so pr-requisitos:

Instalao da ltima verso do Java

Instalao do JDK que possui todo o ambiente necessrio para desenvolver e executar aplicativos em Java

Se o objetivo for desenvolvimento deve instalar um ambiente RAD para facilitar na implementao.

2.4 DESAFIO IV ANLISE CHINA TELECOMPara suprir necessidade da China Telecom for escolhido o modelo cliente servidor por proporcionar uma centralizao do processamento e permitir que as informaes sejam acessadas nas unidades descentralizadas da empresa, os aplicativos devero utilizar a arquitetura SOA onde devero acessar os servios e dados disponveis nos servidores de Hewlett-Packard adquiridos para este mesmo projeto. Dever ser adotado um framework MVC para desenvolvimento e deve-se prezar pelo reaproveitamento de cdigo.Para persistncia dos dados ser utilizado banco de dados Oracle, por sua confiabilidade e robustez tendo em vista o crescimento rpido que aempresa tem tido nos ltimos anos.3 CONCLUSOAps a ampla pesquisa feita para cumprimentos dos desafios apresentados conclui-se a implementao de padres para projetos e construo de softwares so muito importantes devido aos compromissos que so assumidos pelos desenvolvedores serem cada vez maiores, com requisitos de qualidade mais aprimorados e tambm com prazo cada vez mais curto. Vimos tambm alguns frameworks JAVA e podemos conhecer melhor suas vantagens e caractersticas assim como o ambiente necessrio para utilizao destas ferramentas. Com a anlise do caso da China Telecom foi possvel o exerccio dos ensinamentos adquiridos na pesquisa e durante as aulas ministradas no semestre.REFERNCIAS

PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fifth Edition. Pennsylvania: PMI, 2013.

HISATOMI, Marco Ikuro. Projeto de sistemas. So Paulo: Pearson Education do

Brasil, 2010.

SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Education do

Brasil, 2009.

THE APACHE SOFTWARE FOUNDATION. Apache Struts. Disponvel em: Acesso em: 13 de maio de 2015REDHAT. Hibernate ORM. Disponvel em: Acesso em: 13 de maio de 2015.

SOUV, Jacques Philippe. Vantagens e desvantagens no uso de Frameworks. Disponvel em: Acesso em: 13 de maio de 2015.Sistema de Ensino Presencial Conectado

Anlise e desenvolvimento de sistemas

gabriel martins ribeiro

eNGENHARIA E PROJETO DE SOFTWARE:

Apresentao dos desafios propostos.

Santa Maria RS

2015

GABRIEL MARTINS RIBEIRO

eNGENHARIA E PROJETO DE SOFTWARE:

Apresentao dos desafios propostos.

Trabalho apresentado ao Curso de Anlise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paran, para a disciplina de produo textual individual.

Prof.

Mrcio Rodberto Chiaveli

Luis Claudio Perini

Marco Ikuro Hisatomi

Veronice de freitas

Santa Maria RS

2015

Sistema

Sada

Processo

Entrada

Banco de dados