73
24 2 INTRODUÇÃO Este trabalho trará breve informação quanto ao conteúdo desenvolvido durante o quarto semestre do curso de Análise e Desenvolvimento de Sistema na modalidade EAD, pela UNOPAR (Universidade Norte do Paraná), abordando os assuntos de Programação Orientada a Objeto, Engenharia de Software e Programação para Web II usando como eixo temático Gestão do Processo de Desenvolvimento I, visando melhorias e agilidade em desenvolvimento de softwares WEB de uma forma segura e organizada, consequentemente ampliando a confiabilidade do sistema desenvolvido tanto pelos desenvolvedores quanto pelos usuários finais, dando mais segurança no momento da construção de um programa e assim tentar diminuir o máximo possível as falhas ou erros durante este processo.

Produção Textual Individual 01_2015

Embed Size (px)

DESCRIPTION

Produção textual individual quinto semestre.

Citation preview

Page 1: Produção Textual Individual 01_2015

2 INTRODUÇÃO

Este trabalho trará breve informação quanto ao conteúdo desenvolvido durante o

quarto semestre do curso de Análise e Desenvolvimento de Sistema na modalidade EAD, pela

UNOPAR (Universidade Norte do Paraná), abordando os assuntos de Programação Orientada

a Objeto, Engenharia de Software e Programação para Web II usando como eixo temático

Gestão do Processo de Desenvolvimento I, visando melhorias e agilidade em

desenvolvimento de softwares WEB de uma forma segura e organizada, consequentemente

ampliando a confiabilidade do sistema desenvolvido tanto pelos desenvolvedores quanto

pelos usuários finais, dando mais segurança no momento da construção de um programa e

assim tentar diminuir o máximo possível as falhas ou erros durante este processo.

4

Page 2: Produção Textual Individual 01_2015

3 OBJETIVO

Este trabalho prima pelo desenvolvimento do conhecimento adquirido durante os 6

(seis) meses do quarto semestre de curso de Análise e Desenvolvimento de Sistema,

trazendo informações de uma forma coerente e concisa quanto a Gestão do Processo de

Desenvolvimento de Sistemas tanto web ou desktop, utilizando frameworks de modelagem

de sistema web e seus benefícios quanto a organização no processo de desenvolvimento sites

e softwares, trazendo assim uma forma de trabalho mais homogenia no momento do

desenvolver o trabalho em equipe e/ou mesmo no desenvolvimento individual, dando assim

mais comodidade, agilidade confiança e conforto para os clientes que procuram este tipo de

serviço. Contudo o viso aprimorar meus conhecimentos quanto aos assuntos abordados neste

semestre e assim ampliar e fixar meus conhecimentos nas disciplinas de Programação

Orientada a Objeto, Engenharia de Software e Programação para Web II.

5

Page 3: Produção Textual Individual 01_2015

4 – DESENVOLVIMENTO

4.1 - Desafio 1

Uma mudança dentro de uma empresa é uma grande processo onde se deve levar em

consideração diversos fatores, como: custos, riscos, manutenção etc. Mas também deve ser

levado em consideração as melhorias que serão realizadas como: agilidade nos processos

realizados, economia de tempo, valores e pessoal etc.

Abaixo será descrito alguns fatores importantes seguindo o modelo de gerenciamento

de software segundo o PMBOK

RISCOS:

A Gerência de Riscos está presente em várias metodologias de Gestão de

Projetos.

O gerenciamento de riscos é parte fundamental da gestão de projetos, porque

aumenta consideravelmente a chance de um projeto ser concluído com sucesso. O

desenvolvimento de software é uma atividade complexa envolvendo inúmeros fatores que

são imprevisíveis e de difícil controle, como inovações tecnológicas e mudanças

constantes nos requisitos do cliente, dentre muitos outros. Esta complexidade faz com que

grande parte dos projetos de desenvolvimento de software exceda o prazo e o orçamento

previstos, além de não atender às expectativas do cliente em termos de funcionalidades

e qualidade. Diante deste cenário, um

gerenciamento eficaz tem-se

evidenciado como de fundamental

importância para o sucesso de projetos

de software. Uma vez que a incerteza

é inerente a este tipo de projeto, o

gerenciamento de riscos vem se

tornando cada vez mais relevante neste

contexto.

Podemos citar de forma resumida que os riscos se dividem nas seguintes categorias:

6

Tipos de riscos EAR - PMBOK

Page 4: Produção Textual Individual 01_2015

Riscos organizacionais;

Riscos de gerência de Projetos;

Riscos técnicos, de qualidade ou desempenho;

Riscos externos.

ESCOPO:

O objetivo principal dessa gerência é definir e manter o desenvolvimento do projeto

dentro do escopo desenhado, controlando o que deve e o que não deve estar incluído

no projeto, tendo a segurança, que é realmente a necessidade do cliente, e qualquer

mudança que venha a se realizar no escopo deverá ter o consentimento do cliente.

Declaração do escopo do projeto: descreve os principais objetivos do projeto, permitindo que

a equipe do projeto realize um planejamento mais detalhado, servindo de orientação

para a equipe do projeto durante a execução, auxiliando a avaliar as solicitações de

mudança e verificar se estas estão dentro ou fora dos limites estabelecidos no projeto.

Quanto maior for o grau e o nível de

detalhamento da declaração de escopo do

projeto, melhor será definido o trabalho que

será realizado pela equipe ajudando a

planejar, gerenciar e controlar sua execução.

A declaração do escopo detalhada do projeto

poderá incluir as seguintes informações:

a. Objetivos do projeto: os critérios mensuráveis do sucesso do projeto estão incluídos na

declaração do escopo. Os objetivos podem ser de ordem técnica, de negócios, custo,

cronograma e qualidade. Os objetivos do projeto também podem incluir metas de

custo, cronograma e qualidade, e estas definidas em uma determinada moeda como

parâmetros.

b. Descrição do escopo do produto: descreve as características do produto, serviço

ou resultado do por que da realização do projeto. À medida que o projeto

avança as características serão mais detalhadas, elas podem variar com o tempo,

contanto que forneçam detalhes suficientes para dar suporte ao planejamento posterior

do escopo do projeto.

7

Detalhamento do escopo de um projeto - PMBOK

Page 5: Produção Textual Individual 01_2015

c. Requisitos do projeto: são as normas, especificações ou outros documentos

formalmente impostos, com descrição das condições a serem seguidas projeto

para atender a um determinado contrato. As expectativas e necessidades das

partes interessadas deverão ser transformadas em requisitos prioritários.

d. Limites do projeto: identifica o que está incluído dentro do projeto e descreve

explicitamente o que está fora do projeto, para prevenir que a parte interessada cobre

que um determinado produto, serviço ou resultado específico seja componente do

projeto.

e. Entregas do projeto: as entregas possuem os relatórios de gerenciamento de

projetos e sua documentação e dependendo da declaração do escopo do projeto,

as entregas podem ser descritas de forma sumarizada ou detalhada.

f. Critérios de aceitação de produtos: define o processo e os critérios para aceitar

os produtos terminados.

g. Restrições do projeto: lista e descreve as restrições específicas do projeto

associadas ao escopo do projeto que limitam as opções da equipe. As restrições

listadas na declaração do escopo do projeto são normalmente mais numerosas e mais

detalhadas do que as listadas no termo de abertura do projeto.

h. Premissas do projeto: lista e descreve as premissas específicas do projeto

associadas ao escopo do projeto e o impacto potencial dessas premissas, se não

forem confirmadas. Frequentemente, as equipes de projetos identificam, documentam

e validam as premissas como parte do seu processo de planejamento. As

premissas listadas na declaração do escopo detalhada do projeto são

normalmente mais numerosas e mais detalhadas do que as listadas no termo de

abertura do projeto.

i. Organização inicial do projeto: os membros da equipe do projeto e as partes

interessadas são identificados e também é documentada.

j. Riscos iniciais definidos: Identifica os riscos conhecidos.

k. Marcos do cronograma: Os marcos são identificados e datados. Essas datas podem ser

consideradas como restrições do cronograma.

l. Limitação de fundos: Descreve qualquer limitação dos recursos financeiros do projeto

uma limitação do valor total ou uma limitação imposta em prazos especificados.

8

Page 6: Produção Textual Individual 01_2015

m. Estimativa de custos: A estimativa de custos do projeto indica o custo total esperado

do projeto e é normalmente precedida de um modificador que fornece alguma

indicação de exatidão como, por exemplo, conceitual ou definitiva.

n. Requisitos do gerenciamento de configuração do projeto: Descreve o nível de

gerenciamento de configuração e controle de mudanças que será implementado

no projeto.

o. Especificações do projeto: Identifica os documentos de especificação com os quais o

projeto deve estar de acordo.

p. Requisitos de aprovação: Identifica os requisitos de aprovação que podem ser

aplicados a itens como objetivos, entregas, documentos e trabalho do projeto.

FORNECEDORES:

Dentro dos processos descritos no PMBOK quanto ao gerenciamento de projetos,

está o gerenciamento de aquisição de projeto que é a parte que cuida dos compras, aquisições,

contatos com fornecedores e demais tarefas que condizem com o fornecimento de material e

estruturas tecnológicas ou físicas durante o processo de fabricação do software.

Os processos de gerenciamento de aquisições do projeto incluem:

• Planejar compras e aquisições – determinação do que comprar ou adquirir e de

quando e como fazer isso.

• Planejar contratações – documentação dos requisitos de produtos, serviços e

resultados e identificação de possíveis fornecedores.

• Solicitar respostas de fornecedores – obtenção de informações, cotações, preços,

ofertas ou propostas, conforme adequado.

• Selecionar fornecedores – análise de ofertas, escolha entre possíveis fornecedores e

negociação de um contrato por escrito com cada fornecedor. 

• Administração de contrato – gerenciamento do contrato e da relação entre o

comprador documentação do desempenho atual ou passado de um fornecedor a fim de

estabelecer ações corretivas necessárias e fornecer uma base para futuras relações com o

9

Page 7: Produção Textual Individual 01_2015

fornecedor, gerenciamento de mudanças relacionadas ao contrato e, quando adequado,

gerenciamento da relação contratual com o comprador externo do projeto.

• Encerramento do contrato – terminar e liquidar cada contrato, inclusive a resolução

de quaisquer itens em aberto, e encerrar cada contrato aplicável ao projeto ou a uma fase do

projeto.

Análise de proposta de fornecedor: de posse de propostas de fornecedores para o que

é necessário para a realização do projeto, o gerente deve analisar as mesmas para adequar:

expectativas, custos necessários e valores agregados.

PARTES INTERESSADAS

Quem são as Partes interessadas? (Stakeholders)

As partes interessadas (também chamados pelo termo inglês, stakeholders) são os

indivíduos e as organizações ativamente envolvidos no projeto, ou seja, quem interessa no seu

projeto.

O projeto irá atender necessidades das partes interessadas e elas são responsáveis por

atender o objetivo do projeto.

Podem ser positivamente ou negativamente afetados com a execução do projeto e

irão influenciar o projeto e/ou seu resultado.

Vale ressaltar algumas partes interessadas muito importantes para o projeto:

Cliente: o projeto irá atender sua(s) necessidade(s);

Patrocinador: quem está financiando o projeto;

Gerente de projeto: quem faz a gestão do projeto e orquestra todas as partes

interessadas de modo a alcançar os objetivos do projeto;

Equipe do Projeto: todos responsáveis por atividades no projeto, precisam estar

motivados e alinhados com os objetivos do projeto;

Entre outras, como o PMO, gerente responsável pelo Escritório de Projetos, a

organização, os fornecedores, população afetada, ...

Quais são os interesses das partes interessadas?

Clientes: produto mais barato com maior qualidade;

Parceiros /Fornecedores: maior lucro;

Executivos

10

Page 8: Produção Textual Individual 01_2015

- Visibilidade;

- Redução de custos;

- Desempenho

Time do Projeto

- Parte dos resultados;

- Excelência técnica;

- Autonomia

- Interesses individuais.

Gerentes

- Cumprir suas metas;

- Não compartilhar seus recursos;

- Menos stress e pressão.

Quem são as partes interessadas mais críticas?

Poder de alocação sobre recursos críticos dos projetos

Escopo (Poder de veto)

$$$

Pessoas

Patrocinador

Designado para especificar o produto

Chefe hierárquico pela equipe do projeto

Segundo o Guia PMBOK, Identificar as partes interessadas é o processo de

identificação de todas as pessoas ou organizações que podem ser afetadas pelo projeto e

documentação das informações relevantes relacionadas aos seus interesses, envolvimento e

impacto no sucesso do projeto.

Esse talvez seja o processo mais crítico do gerenciamento do projeto, pois, descobrir

as partes interessadas e escutá-las de forma efetiva no início, trará um maior

comprometimento, maior clareza de requisitos e objetivos e consequentemente, menos

mudanças no decorrer do projeto.

O Guia PMBOK deve conectar as partes interessadas maximizando as influências

positivas e minimizando as resistências, o que implicará em uma maior probabilidade de

aceitação das entregas.

11

Page 9: Produção Textual Individual 01_2015

Um erro não tão raro é descobrir partes interessadas importantes do projeto após o

planejamento, ocasionando em várias mudanças solicitadas e grande resistência em relação ao

projeto.

4.1.2 – Desafio 2

Pontos importantes que devem ser considerados:

Aprimora a habilidade de mudar através da gestão de reações; além disso, desenvolve

uma compreensão sobre a mudança através da identificação dos impactos gerados por

iniciativas e do aprendizado sobre como lidar com as mesmas.

Descobre como as pessoas reagem à mudança e utiliza esse conhecimento para guiá-

las através da transformação dos negócios.

Aprende sobre as teorias de mudança e sobre como aplicar a teoria adequada às

necessidades específicas de uma organização. Deste modo, a mudança é aceita, de

modo satisfatório, por colegas e organizações. Além disso, processos de gestão de

mudança pessoal baseados nos aprendizados são estabelecidos.

Sabe como conduzir as pessoas através das várias fases de transição, além de saber

como conduzir mudanças de modo efetivo, ou seja, com menos resistência e maior

suporte.

O Change Management ajuda você a entender como reagir a uma mudança. Desta

maneira, você estará equipado para liderar com eficácia.

Apoia o processo decisório no Gerenciamento de Mudanças ao permitir que

definições de prioridades e a melhor ordem possível de implantação de mudanças sejam

obtidas, levando em consideração recursos disponíveis, impactos e riscos desconhecidos para

a organização. Baseado na análise de critérios pré-estabelecidos e utilizados pelos tomadores

de decisão da empresa de forma qualitativa, os mesmos ponderam o grau de importância ou

atratividade entre os critérios, chegando a resulta dos quantitativos que consolidam o

julgamento da ordem e prioridade de um conjunto de mudanças a serem implantadas.

Conforme [19], os resultados obtidos pela análise multicritério dependem do conjunto de

ações consideradas, da qualidade dos dados, da escolha e estruturação dos critérios, dos

12

Page 10: Produção Textual Individual 01_2015

valores de ponderação atribuídos aos critérios, do método de agregação utilizado e da

participação dos diferentes tomadores de decisão.

CAPITULO 11 – Projeto de Arquitetura

O projeto de arquitetura é primeiro estágio no processo de projetos. Diz o livro que

ele idêntica subsistemas e estabelece um framework para controlar a comunicação dos

subsistemas, subsistemas são sistemas grandes decompostos em subsistemas e que fornece

algum conjunto de serviços relacionados. Ele também representa uma ligação critica entre

processos de engenharia de projeto e requisitos.

três vantagens de projetar e documentar explicitamente uma arquitetura de software:

Comunicação de stakeholders: é uma apresentação em alto nível do sistema que enfoca a

discussão entre diferentes stakeholders.

Analise de sistemas: Tem profundo efeito sobre o sistema, mostra se o sistema pode

atender aos requisitos críticos como, confiabilidade, desempenho e facilidade de manutenção.

Reuso em larga escala:

Apoia o reuso em larga escala de sistemas que possuem arquiteturas de sistemas

familiares.

A arquitetura de software serve para negociar requisitos de sistema e estruturar discussões

com os clientes, desenvolvedores e gerentes. É uma ferramenta essencial parra gerenciamento

de complexidade, ocultando detalhes e focando as abstrações principais do sistema. O estilo e

estrutura da aplicação dependem dos requisitos não funcionais do sistema, por exemplo:

Se o desempenho for um requisito crítico a aplicação deve localizar operações

criticas dentro de subsistemas e usar componentes de alta granularidade em detrimento dos de

baixa granularidade para reduzir a comunicação entre eles.

Se a facilidade de manutenção for um requisto crítico, a arquitetura de sistemas deve

ser projetada usando componentes de baixa granularidade e autocontidos que possam ser

prontamente mudados.

Há conflitos potenciais entre algumas dessas arquiteturas, por exemplo se o

desempenho que necessita de alta granularidade e a facilidade de manutenção que necessita de

baixa granularidade forem ambos requisitos críticos terá que ser encontrada alguma solução

eficaz.

13

Page 11: Produção Textual Individual 01_2015

Um projeto de subsistemas é decomposição abstrata de um sistema de componentes

em alta granularidade. Os diagramas de blocos são usados para representar um projeto de

subsistemas.

Esses diagramas de blocos são bons para comunição entre stakeholders e para o

planejamento do projeto pois não estão abarrotados de detalhes, já para a arquitetura não são

tão bons, pois não mostram relacionamento entre os componentes do sistema.

O projeto de arquitetura tenta estabelecer uma organização de sistemas que satisfação

os requisitos funcionais e os não funcionais do sistema. Durante o processo de projeto de

arquitetura os arquitetos de sistemas devem responder a algumas perguntas:

Existe uma arquitetura genérica de aplicação que possa funcionar como um modelo

para o sistema que está sendo projetado?

Como o sistema será distribuído ao longo de vários processadores?

Qual ou quais estilos de arquitetura são apropriados para o sistema?

Qual será a abordagem fundamental usada para estruturar o sistema?

Como as unidades estruturais de um sistema serão decompostas em módulos?

Qual estratégia será utilizada para controlar a operação das unidades do sistema?

Como o projeto de arquitetura será avaliado?

Como a arquitetura do sistema deve ser documentada?

Ao Projetar uma arquitetura de sistemas, você precisa decidir o que seu sistema e

classes mais amplas de aplicação tem em comum, e decidir quanto conhecimento dessas

arquiteturas de aplicação você pode reusar. A arquitetura de um sistema de software pode ser

baseada em um modelo ou estilo de arquitetura especifico, Em alguns casos a arquitetura

geral de um sistema pode ser uma arquitetura composta.

Os modelos de arquitetura que podem ser desenvolvidos podem incluir:

Um modelo estático de estrutura que mostra os subsistemas ou componentes desenvolvidos

como unidades separadas.

Um modelo dinâmico de processo que mostra como o sistema esta organizado em

processos em tempo de execução.

A organização de um sistema reflete a estratégia básica usada para estrutura-lo. Você

precisa tomar decisões sobre o modelo geral organizacional de um sistema com antecedência

no processo de projeto de arquitetura. A organização pode refletir diretamente na estrutura

subsistema.

Possuem três estilos de organizacionais amplamente usados:

14

Page 12: Produção Textual Individual 01_2015

Modelo de repositório

Os subsistemas que constituem um sistema devem trocar informações de mofo que possam

trabalhar juntos eficientemente.

Esse modelo é, portanto, adequado para aplicações em que os dados são gerados por

um subsistema e usados por outro.

O repositório é passivo e o controle é de responsabilidade dos subsistemas que o

usam.

Os modelos de arquitetura que podem ser desenvolvidos podem incluir:

Um modelo estático de estrutura que mostra os subsistemas ou componentes

desenvolvidos como unidades separadas.

Um modelo dinâmico de processo que mostra como o sistema esta organizado em

processos em tempo de execução.

A organização de um sistema reflete a estratégia básica usada para estrutura-lo. Você

precisa tomar decisões sobre o modelo geral organizacional de um sistema com antecedência

no processo de projeto de arquitetura. A organização pode refletir diretamente na estrutura

subsistema.

O repositório é passivo e o controle é de responsabilidade dos subsistemas que o

usam.

3 - Modelo Cliente – Servidor

O modelo de arquitetura cliente – servidor é um modelo em que o sistema é

organizado como um conjunto de serviços e servidores e clientes associados que acessam e

usam os serviços. Os clientes talvez precisem saber os nomes dos servidores disponíveis e os

serviços que eles fornecem. No entanto os servidores não precisam saber a identidade do

cliente ou quantos são. São acessados os serviços por meio de chamadas remotas de

procedimento usando um protocolo request–eply, o cliente faz um pedido a um servidor e

espera ate receber uma resposta.

A vantagem de um modelo cliente servidor é que ele é uma arquitetura distribuída. O uso

efetivo de sistemas em rede pode ser feito com muitos processadores distribuídos. É fácil

adicionar um novo servidor e integra-lo ao restante do sistema

15

Page 13: Produção Textual Individual 01_2015

4 - O Modelo em Camadas

O modelo em camadas organiza um sistema em camadas, cada uma das quais

fornecendo um conjunto de serviços.

A abordagem em camadas apoia o desenvolvimento incremental de sistemas. A medida que

uma camada é desenvolvida alguns serviços fornecidos por essa camada podem ser

disponibilizados para os usuários. Essa arquitetura também é modificável e portável. Desde

que sua interface permaneça inalterada, uma camada poderá ser substituída por outra

equivalente. Uma desvantagem da abordagem em camadas é que a estruturação de sistemas

dessa maneira pode ser difícil. As camadas mais internas podem fornecer recursos básicos,

como gerenciamento de arquivos, necessários em todos os níveis.

O desempenho também pode ser um problema devido aos vários níveis de interpretação de

comandos algumas vezes exigidos.

5 Estilos de decomposição modular

Depois que a organização geral do sistema foi escolhida, precisa-se tomar uma

decisão sobre a abordagem a ser usada na decomposição de subsistemas em módulos.

Um modulo é normalmente um componente de sistema que fornece um ou mais serviços para

outros módulos. Ele faz uso de serviços fornecidos por outros módulos.existem duas

estratégias principais que você pode usar ao decompor um subsistema em módulos.

Decomposição orientada a objetos e pipelining orientado a funções.

Você deve evitar tomar decisões prematuras sobre a simultaneidade de um sistema.

6 - Decomposição Orientada a Objetos.

Um modelo de arquitetura orientado a objetos estrutura o sistema em um conjunto de

objetos não firmemente acoplados com interfaces bem definidas. Os objetos chamam serviços

oferecidos por outros objetos.

Uma decomposição orientada a objetos está relacionada a classes de objetos, seus atributos e

suas operações. Quando implementados, os objetos são criados a partir dessas classes e algum

modelo de controle é usado para coordenar as operações de objetos. A vantagem é que

implementação de objetos pode ser modificada sem afetar outros objetos.

A desvantagem é que para usar serviços os objetos devem fazer referência explicita ao nome e

16

Page 14: Produção Textual Individual 01_2015

a interface de outros objetos.

7 - Pipelining Orientado a Funções

No pipelining orientado a funções ou modelo de fluxo de dados, as transformações

processam suas entradas e produzem saídas. Os dados fluem de uma para outra função e são

transformados ao moverem – se sequencialmente. Cada etapa é implementada como uma

transformação. Os dados de entrada fluem através dessas transações até serem convertidos em

dados se saída.

As vantagens dessa arquitetura são:

Apoiar o reuso de transformações. Ele é intuitiva, muitas pessoas pensam em seu trabalho em

termos de processamento de entrada e saída.

A evolução do sistema pela adição de novas transformações é geralmente direta.

Ela é simples de ser implementada tanto quanto um sistema concorrente ou sequencial.

O principal problema é que ele necessita ser um formato comum para transferir dados que

possa ser reconhecido por todas as transformações.

Sistemas interativos são difíceis de escrever usando esse modelo por causa da necessidade de

uma sequência de dados ser processada.

8 - Modelos de controle

Os modelos de controle têm como objetivo controlar subsistemas de

maneira que seus serviços sejam entregues no lugar certo e no tempo certo.

Modelos de controle são usados em conjunto com estilos de estrutura. Todos os estilos de

estrutura que foi explicado podem ser implementados por meio de controle centralizado ou

baseado em eventos.

9 - Controle centralizado.

Em modelo de controle centralizado, um subsistema é designado como controlado

de sistema e tem a responsabilidade pelo gerenciamento da execução de outros subsistemas.

Modelos de controle centralizados Dividem – se em duas classes, dependendo se forem

executados sequencialmente ou paralelamente.

17

Page 15: Produção Textual Individual 01_2015

O modelo chamado – retorno. O controle começa no topo da hierarquia de sub – rotina e ,

através de chamadas de sub-rotinas, passa para os níveis mais baixos na arvore, são aplicados

em modelos sequenciais.

O modelo gerenciados. Aplicados em modelos concorrentes. Um sistema concorrente é

projetado como um gerenciador de sistema e controla o início, a parada e a coordenação de

outros processos do sistema.

Sistemas orientados a eventos.

As decisões dos modelos orientados a eventos são regidas pelos eventos gerados

externamente. O termo evento pode ser um sinal que pode assumir uma gama de valores ou

uma entrada de comando baseados em um menu.

Possuem dois modelos de controle orientados a eventos.

Modelos de broadcast. Nesse modelo, um evento é transmitido a todos os subsistemas.

Qualquer subsistema programado para manipular o evento pode responder a ele. A vantagem

dessa abordagem é que a evolução é relativamente simples, um novo subsistema para tratar

classes especificas de eventos pode ser integrado por meio do registro de seus eventos no

tratador de eventos. A desvantagem é que os subsistemas não sabem se ou quando os eventos

serão manipulados.

Modelos orientados a interrupções. São usados em sistemas de tempo real como requisitos

rigorosos de tempo, nos quais as interrupções externas são detectadas por um trator de

interrupções. A vantagem dessa abordagem é que ela permite respostas muito rápidas aos

eventos a serem implementados. Sua desvantagem é a complexidade da programação e a

dificuldade de validação.

10 - Arquitetura de referência

As arquiteturas de referência não são geralmente consideradas um roteiro de

implementações. Em vez disso, sua principal função é ser um meio de discussão de

arquiteturas de domínio especifico e de comparação de sistemas diferentes em um domínio.

Um modelo de referência fornece um vocabulário para comparação. Ele atua como uma base,

em relação a qual os sistemas podem ser avaliados.

Uma proposta de modelo de referência é um modelo para ambientes CASE que

identifica cinco conjuntos de serviços que um ambiente CASE deve fornecer. Ele deve

18

Page 16: Produção Textual Individual 01_2015

também fornecer recursos de plug in para ferramentas CASE individuais que usam esses

serviços. Os cincos níveis de referências são:

Serviços de repositório de dados. Estes serviços fornecem recursos para o

armazenamento e o gerenciamento de itens de dados e seus relacionamentos.

Serviços de integração de dados. Estes serviços fornecem recursos para o

gerenciamento de grupos ou para definição de relacionamentos entre eles.

Serviços de gerenciamento de tarefas, estes serviços fornecem recursos para a

definição e aprovação de modelos de processo.

Serviços de mensagem. Comunica ferramenta – Ferramenta, ambiente-ferramenta e

ambiente – ambiente.

Serviços de interface com o usuário. Este serviço fornecem recursos para o

desenvolvimento de interface com o usuário.

A finalidade dessa arquitetura de referência é ser um meio de classificação e

comparação de ferramentas e ambientes CASE integrados.

CAPITULO 12 – Arquitetura de sistemas distribuídos

Um sistema distribuído é aquele em que as informações em fase de processamento

são distribuídas a vários computadores.

Vantagens de usar uma abordagem distribuída para desenvolvimento de sistemas.

1. Compartilhamento de recursos – Um sistema distribuído permite o compartilhamento de

recursos de hardware e software, como discos, impressoras, arquivos e computadores que

estão associados aos diferentes computadores de uma rede.

2. Abertura - permitem a equipamentos e software de diferentes fabricantes serem

combinados, pois são projetados com base em protocolos padrões.

3. Concorrência – vários processos podem operar ao mesmo tempo em diferentes

computadores, e podem (mais não precisam) conversar uns com os outros.

19

Page 17: Produção Textual Individual 01_2015

4. Escalabilidade – são escalonáveis a maneira que a capacidade de um sistema pode ser

ampliada pela adição de novos recursos para atender as demandas dos sistemas.

5. Tolerância a defeitos – pela disponibilidade de vários computadores e o potencial de

duplicação de informação significa que os sistemas distribuídos possam ser tolerantes a

algumas falhas de hardware e software.

Esses sistemas de distribuição comparados aos sistemas que operam com um processador ou

com um cluster de processadores podem ter algumas desvantagens como:

1. Complexidade - os sistemas distribuídos são mais complexos que os sistemas

centralizados.

2. Proteção – o sistema pode ser acessado de vários computadores diferentes, e o

trafego na rede pode estar sujeita a interceptações.

3. Gerenciamento – os computadores do sistema podem ser de tipos diferentes e

podem operar em versões diferentes de sistemas operacionais. Defeitos em uma maquina

podem se propagar a outra maquinas com consequências inesperadas.

4. Imprevisibilidade – Como todos os usuários da web sabem, os sistemas

distribuídos são imprevisíveis em suas respostas. A resposta depende da carga total do

sistema, sua organização e a carga da rede. Como tudo isso pode mudar em um curto período

de tempo, o tempo de resposta para uma solicitação do usuário pode variar drasticamente de

uma solicitação para outra.

Possuem dois tipos diferentes de arquiteturas de sistemas distribuídos:

1. Arquitetura cliente-servidor. É o sistema como um conjunto de serviços

fornecidos aos

clientes que fazem uso desses serviços. Os servidores e clientes são tratados de maneiras

diferentes nesses sistemas.

2. Arquiteturas de objetos distribuídos. Podemos pensar no sistema como um

conjunto de objetos que interagem e cuja a localização é irrelevante. Não há distinção entre

cliente e servidor.

20

Page 18: Produção Textual Individual 01_2015

Tanto a arquitetura cliente-servidor e a arquitetura de objetos distribuídos são

amplamente usadas no setor, mais a aplicação ocorre geralmente dentro de uma única

organização. A organização é, portanto, intra-organizacional.

1 ARQUITETURA DE MULTIPROCESSADORES

O multiprocessador São processos que podem ser executados separados. Esse modelo

toma decisões usando essas informações e enviam sinais aos atuadores, que modificam o

ambiente do sistema. O uso de vários processadores aprimora o desempenho e a capacidade

de recuperação do sistema

2 ARQUITETURA CLIENTE-SERVIDOR

Em uma arquitetura cliente-servidor, uma aplicação é modelada como um conjunto

de clientes que usam esses serviços. Os clientes precisam estar informados sobre os serviços

disponíveis, mas geralmente não sabem da existência de outros clientes. Vários processos de

serviços podem ser executados em um único processador de serviço, portanto não há

mapeamento entre processos e processadores de um sistema. O projeto de sistemas cliente-

servidor deve refletir a estrutura lógica da aplicação que está sendo desenvolvida. Um

exemplo é uma aplicação q esta dividida em 3 camadas: a camada de apresentação, que se

encarrega da apresentação de informações para o usuário e toda a interação com o usuário. A

camada de processos de aplicações se encarrega daimplementação da lógica da aplicação e a

camada de gerenciamento de dados se encarrega de todas as operações de banco de dados.

A arquitetura cliente-servidor mais simples denomina-se arquitetura cliente-servidor de duas

camadas, podem ter duas formas:

Modelo cliente-magro. O processamento e o gerenciamento de dados são realizados

no servidor. O cliente apenas executa o software de apresentação.

Modelo cliente-gordo. O servidor é responsável somente pelo gerenciamento de

dados. O software do cliente implementa a lógica da aplicação e as interações com o usuário

do sistema.

Uma desvantagem do modelo cliente-magro é que ele impõe uma grande carga de

processamento sobre o servidor e a rede. O modelo cliente-gordo faz uso dessa capacidade de

processamento disponível e distribui o processamento lógico de aplicação e a apresentação do

cliente. O servidor é essencialmente um servidor de transações que gerencia todas as

21

Page 19: Produção Textual Individual 01_2015

transações do banco de dados. Enquanto o modelo cliente-gordo distribui o processamento

mais eficientemente do que um modelo cliente-magro, o gerenciamento do sistema é mais

complexo. A funcionalidade da aplicação é dividida entre vários computadores. Quando o

software precisa ser alterado, isso envolve reinstalação em cada computador cliente, o que

pode resultar em um custo significativo se houver centenas de clientes no sistema. O

Problema com a abordagem cliente-servidor de duas camadas é que as três camadas lógicas,

devem ser mapeadas sobre dois sistemas de computador – o cliente e o servidor. Pode haver

problemas de escalabilidade e desempenho, se o modelo cliente-magro for escolhido, ou

problemas de gerenciamento de sistemas, se o modelo cliente-gordo for usado. Para evitar

esses problemas uma alternativa é usar o modelo cliente-servidor de três camadas.

Em alguns casos é melhor estender o modelo cliente-servidor de três camadas para

uma variante com várias camadas, na qual servidores adicionais são incorporados ao sistema.

3 ARQUITETURAS DE OBJETOS DISTRIBUÍDOS

Nesse modelo os objetos podem ser distribuídos entre uma serie de computadores na

rede e se comunicam através de um middleware, que é chamado de requisitos de objetos. O

Middleware fornece uma interface transparente continua entre os objetos. Ele fornece um

conjunto de serviços que permitem que os objetos se comuniquem e sejam adicionados e

removidos do sistema. As vantagens são:

Permite que o projetista do sistema postergue decisões sobre onde e como os serviços

devem ser fornecidos.

É uma arquitetura de sistema aberto que permite que novos recursos sejam

adicionados.

Uma arquitetura de objetos distribuídos pode ser usada como um modelo lógico, que permite

estruturar e organizar o sistema.

Uma arquitetura de objetos distribuídos em lugar de uma arquitetura cliente-servidor é

adequada para esse tipo de aplicação por três razões:

O modelo lógico do sistema não é um dos fornecimentos de serviços em que existem serviços

distintos de gerenciamento de dados.

Pode adicionar bancos de dados ao sistema sem grande interrupções.

A maior Desvantagem é que elas são mais complexas do que sistemas cliente-servidor.

22

Page 20: Produção Textual Individual 01_2015

4 CORBA

Existem quatro elementos principais desse padrão:

1. um modelo de objeto para objetos de aplicações em que um objeto corba é um

encapsulamento de estado com uma interface bem definida em linguagem neutra descrita em

um linguagem de definição de interface.

2. Um requisitor de objetos que gerencia solicitações para serviços de objetos.

3. Um conjunto de serviços de objetos que são serviços gerais com probabilidade de

serem solicitados por muitas aplicações distribuídas.

4. Um conjunto de componentes comuns construídos sobre esses serviços básicos

que podem ser solicitados pelas aplicações.

O Corba considera um objeto como se fosse um encapsulamento de atributos e

serviços, como é normal em objetos.o Corba deve ter uma definição de interface separada que

define atributos e operações publicas do objeto. as interfaces são definidas por uma linguagem

de definição de interface padronizada independe de linguagem.

Os objetos corba tem um único identificador chamado de referencia de objeto interoperavel.

Esse IOR é usado quando um objeto solicita serviços de um outro objeto.

O requisitor de objetos conhece os objetos que estão solicitando serviços e suas

interfaces. O ORB cuida da comunicação entre os objetos.os objetos que se comunicam não

precisam conhecer a localização de outros objetos nem sobre sua implementação.

O objeto que fornece o serviço tem um esqueleto de IDL associado que liga a interface a

implementação dos serviços.

O corba foi desenvolvido desde 1980 e as versões recentes de corba foram

simplesmente dedicadas ao apoio aos objetos distribuídos.

Os padrões Corba incluem definições de interfacepara uma grande variedade de

componentes horizontais e verticais. Os componentes verticais são componentes específicos

de um domínio de aplicação. Os componentes horizontais são componentes de propósito

geral, como componentes de interface com o usuário.

5 COMPUTAÇÃO INTERORGANIZACIONL DISTRIBUIDA

23

Page 21: Produção Textual Individual 01_2015

Por motivo de segurança e interoperabilidade, a computação distribuída foi

implementada inicialmente em nível organizacional. Uma organização tem uma serie de

servidores e distribui sua carga computacional entre eles. Devido ao fato de eles estarem todos

localizados dentro da mesma organização, podem ser aplicados padrões e processos

operacionais locais.

6 ARQUITETURAS PONTO A PONTO

São sistemas descentralizados em que as computações podem ser realizadas por

qualquer nó da rede, nenhuma distinção é feita entre clientes e servidores. O sistema global é

projetado para beneficiar-se da capacidade computacional e armazenamento disponíveis em

uma rede de computadores potencialmente grande.

Em princípio, em sistemas ponto a ponto, todo nó de rede pode estar ciente a respeito

de qualquer outro nó, pode fazer conexões com ele e pode trocar dados com ele. Em uma

arquitetura descentralizada, os nós de rede não são simplesmente elementos funcionais, mais

também chaves de comunicação que podem guiar os sinais de dados e de controle de um nó

para o outro. No entanto quando se recupera um documento, o nó que está recuperando se

torna visível para outros.

7 ARQUITETURA DE SISTEMA ORIENTADO A SERVIÇOS

A essência de um serviço, é que o fornecimento dos serviços é independente da

aplicação que usa o serviço. Os provedores de serviços podem desenvolver serviços

especializados e oferecê-los a uma gama de usuários de serviços de organizações diferentes.

A proposto WEB Service foi lançada pois o acesso de servidores web, era somente por meio

de navegar web, e o acesso direto aos repositórios de informações por outros programas não

era prático.

Os três padrões fundamentais que possibilitam comunicação entre WEB SERVICES

são:

SOP. Define uma organização para troca estruturada de dados entre WEB SERVICES.

WSDL. Define como as interfaces dos WEB services podem ser representadas.

24

Page 22: Produção Textual Individual 01_2015

UDDI. Este é um padrão de descobrimento que define como as informações de descrição

do serviço usadas pelos solicitantes do serviços para descobrir serviços, pode ser

organizada.

Todos esses padrões são baseados em XML

CAPITULO 13 – Arquitetura de aplicações

1 SISTEMAS DE PROCESSAMENTO DE DADOS

Aplicações de processamento de dados.

São Aplicações voltados a dados. Elas processam dados em lotes sem intervenções

explicitas do usuário durante o processamento. As Ações explicitas tomadas pela aplicação

dependem dos dados que são processados. Os sistemas de processamento em lotes são

normalmente usados em aplicações de negócios nas quais as operações similares são

realizadas sobre uma grande quantidade de dados. Eles tratam de uma grande variedade de

funções administrativas, como folha de pagamento, cobrança, contabilidade e publicidade.

Essas aplicações enfocam os dados. Os bancos de dados são geralmente maiores que os

sistemas de informações (SI). Os sistemas de processamento de dados selecionam os dados de

registros de entrada e, dependendo do valor dos campos nos registros, tomam algumas ações

especificadas no programa. Eles podem, então, enviar o resultado novamente do

processamento ao banco de dados e formatar a entrada e a saída processada para impressão.

Os sistemas de processamento de dados possuem 3 componentes principais:

1 - Entrada. A entrada coleta as entradas de uma ou mais fontes.

2 - processamentos. O processamento realiza a computação usando essas entradas.

3 - saídas. A saída gera Saídas a serem escritas novamente no banco de dados e ou

impressas.

Os componentes de entrada, processamento e de saída podem ser decompostos ainda

em uma estrutura entrada-processamento-saída. Exemplo:

Um componente de entrada pode ler algum dado de um arquivo ou banco de

dados(entrada) e corrigir alguns erros (processo) e, depois enfileirar os dados validos para

25

Page 23: Produção Textual Individual 01_2015

processamento (saída). São sistemas orientados a funções, pois os registros e as transações são

processados em série, sem necessidade de manter o estado entre as transações.

2 SISTEMAS DE PROCESSAMENTE DE TRANSAÇÕES

Os sistemas de transações são projetados para processar solicitações de informações

por usuários de um banco de dados. Tecnicamente uma sequencia de operações é tratada

como uma unidade simples (uma unidade atômica). Todas as operações tem que ser realizadas

antes que as mudanças tornem-se permanentes no banco de dados. Os sistemas de

processamento de transações são geralmente sistemas interativos nos quais os usuários

enviam solicitações assíncronas de serviço. Primeiro um usuário faz uma solicitação para o

sistema através de um componente de processamento de entrada/saída. A solicitação é

processada por alguma lógica especifica da aplicação. Uma transação é criada e passada para

um gerenciador de transações, que é em geral incorporado ao sistema de gerenciamento de

banco de dados. Depois que o gerenciador de transações assegurar que a transação foi

concluída adequadamente, ele sinalizara para a aplicação que o processamento foi finalizado.

A estrutura entrada-processo-saída se aplica aos muitos sistemas de processamento de

transações. Alguns desses sistemas são versões interativas de sistemas de processamento de

lotes.

Um exemplo de sistema de processamento de transações é um sistema bancário que

permite aos clientes consultarem suas contas e retirarem dinheiro de um caixa eletrônico. O

sistema é composto de dois subsistemas de software que cooperam entre si – o software de

caixa eletrônico e o software de processamento de contas localizadas no servidor de banco de

dados. Os subsistemas de entrada e de saída são implementados como softwares no caixa

eletrônico, uma vez que o subsistema de processamento está no servidor de banco de dadso.

Em sistemas como os de contabilidade de clientes de um banco, pode haver diferentes

maneiras de interagir com o sistema. Muitos clientes interagirão por meio de caixas

eletrônicos, mas uma equipe do banco usara terminais de mesa para acessar o sistema. Pode

haver vários tipos de caixas eletrônicos e terminais de mesa, e alguns clientes e a equipe do

banco podem acessar os dados de contas por meio de navegadores WEB. Para simplificar o

gerenciamento de diferentes protocolos de comunicação entre terminais, sistemas de

processamento de transações de larga escala podem incluir middleware para comunicação

26

Page 24: Produção Textual Individual 01_2015

com todos os tipos de terminal, organização e ordenação em serie dos dados dos terminais e

envio dos dados para processamento.

3 Sistemas de gerenciamento de informações e recursos

Um sistema de informações permite acesso controlado de uma grande base de

informações, tais como catalogo de bibliotecas, tabela de horários de voos ou registros de

pacientes em um hospital. O desenvolvimento da WEB fez com que um grande número de

sistemas de informações migrasse de sistemas organizacionais especializados para sistemas de

propósito geral acessíveis universalmente. O sistema de informação é modelado com o uso de

uma abordagem de camadas ou de máquina abstrata na qual a camada superior apoia a

interface com o usuário e a camada inferior, o banco de dados de sistema. A camada de

comunicações inclui uma lógica especifica de aplicação para acesso e atualização do banco de

dados.

Sistemas de alocação de recursos são uma classe de aplicação amplamente usada. Sua

arquitetura está alinhada com o modelo de sistema de informações. Os componentes de um

sistema de alocação de recursos inclui:

1- Um banco de dados de recursos que mantém detalhes de recursos que são alocados. Os

recursos podem ser adicionados ou removidos do banco de dados.

2- Um conjunto de regras que descreve as regras de alocação de recursos.

3- Um componente de gerenciamento de recursos que permite que o provedor de

recursos adicione, edite ou elimine recursos do sistema.

4- Um componente de alocação de recursos que atualiza o banco de dados de recursos

quando eles são designados e que associa esses recursos a detalhes do solicitante do recurso.

5- Um modulo de autenticação de usuários que permite ao sistema verificar se os

recursos estão sendo alocados para um usuário reconhecido.

6- Um modulo de gerenciamento de consultas que permite ao usuário descobrir quais

recursos estão disponíveis.

7- Um componente de entrega de recursos que prepara os recursos a serem entregues ao

solicitante. Em um sistema de emissão de ingressos, isso pode envolver a preparação de uma

confirmação por e-mail, o envio de uma solicitação para uma impressora que imprime os

ingressos e os detalhes de para onde os ingressos devem ser enviados.

27

Page 25: Produção Textual Individual 01_2015

8- Um componente de interface com o usuário que esta fora do sistema e permite ao

solicitante do recurso enviar consultas e solicitações para o recurso a ser alocado.

4 Sistemas de processamento de eventos

Os sistemas de processamento de eventos respondem aos eventos do ambiente ou da

interface com o usuário do sistema. A principal característica dos sistemas de processamento

de eventos é que a sequência de eventos é imprevisível e o sistema deve ser capaz de trabalhar

com esses eventos quando eles ocorrerem.

Sistemas de tempo real, são também sistemas de processamento baseados em

eventos, porem ao invés de ter eventos de interface com o usuário, tem eventos associados a

sensores e atuadores do sistema.

5 Sistemas de processamento de linguagens

Os sistemas de processamento de linguagens aceitam uma linguagem natural ou

artificial como entrada e geram alguma outra representação dessa linguagem como saída. Em

engenharia de software, os sistemas de processamento de linguagens mais amplamente usados

são os compiladores que traduzem uma linguagem artificial de programação de alto nível em

código de máquina. Mais outros sistemas de processamento de linguagens traduzem uma

descrição de dados XML em comandos para consultar um banco de dados e sistemas de

processamento de linguagem natural que tentam traduzir uma linguagem em outra.

Os tradutores em um sistema de processamento de linguagens tem uma arquitetura genérica

que inclui os seguintes componentes:

1. Um analisador léxico, que obtém elementos da linguagem de entrada e os converte em

um formato interno.

2. Uma tabela de símbolos que mantém informações sobre os nomes de entidades

(variáveis, nomes de classes.) usadas no texto que está sendo traduzido.

3. Um analisador sintático, que verifica a sintaxe da linguagem que está sendo traduzida.

Ele usa uma gramática definida de linguagem e constrói uma arvore de sintaxe.

4. Uma árvore de sintaxe, que é uma estrutura interna que representa o programa que está

sendo compilado.

5. Um analisador semântico, que usa informações da árvore de sintaxe e da tabela de

símbolos para verificar a correção sintática do texto da linguagem de entrada.

28

Page 26: Produção Textual Individual 01_2015

6. Um gerador de código que ‘caminha’ pela árvore de sintaxe e gera o código de máquina

abstrata.

Capitulo 29 – gerenciamento de configurações

Gerenciamento de configurações é o desenvolvimento e o uso de padrões e

procedimentos para o gerenciamento de sistemas de software em desenvolvimento. Há muitas

razões Por que os sistemas existem em diferentes configurações. Configurações podem ser

produzidas para diferentes computadores, para diferentes sistemas operacionais, incorporando

funções especificas de clientes. Os gerentes de configurações são responsáveis por manter a

rastreabilidade das diferenças entre versões de software, para assegurar que as novas versões

sejam derivadas de maneira controlada e liberar novas versões para clientes certos no

momento certo.

1 Planejamento de gerenciamento de configurações

O plano de gerenciamento de configurações descreve os padrões e procedimentos

que devem ser usados para o gerenciamento. O ponto de partida para o desenvolvimento do

plano deve ser um conjunto de padrões de configuração, que devem ser adaptados para se

atender aos requisitos e as restrições de cada projeto específico.

1 IDENTIFICAÇÃO DE ITEM DE CONFIGURAÇÃO

Em um grande sistema de software, pode haver módulos de milhares de códigos

fonte, scripts de testes, documentos de projeto etc. Eles são produzidos por pessoas diferentes

e, quando criados, podem ser denominados com nomes similares ou idênticos. Para manter a

rastreabilidade de todas essas informações de maneira que o arquivo certo possa ser

encontrado quando for necessário você necessita de um esquema de identificação consistente

para todos os itens no sistema de gerenciamento de configurações. 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

29

Page 27: Produção Textual Individual 01_2015

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. Esse nome

pode refletir o tipo do item, uma parte do sistema ao qual ele se aplica, o criador do item. No

esquema de atribuição de nomes, você pode desejar evidenciar a relação entre os itens para

garantir que os documentos relacionados possuam uma mesma raiz em seus nomes. Portanto,

você pode definir um esquema de hierarquia com nome.

Esquemas de nomes hierarquizados são simples e de fácil compreensão: algumas

vezes, podem mapear uma estrutura de diretórios usada para armazenar arquivos de projeto.

No entanto, refletem a estrutura de projeto na qual o software foi desenvolvido. Os nomes de

itens de configuração associam componentes com um projeto especifico e, dessa maneira,

reduzem as oportunidades para o reuso. Pode ser muito difícil encontrar componentes

relacionados.

2 BANCO DE DADOS DE CONFIGURAÇÃO

O 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. Você usa o banco de

dados CM para auxiliar a avaliação do impacto das mudanças de sistema e para gerar

relatórios para a gerencia sobre o processo de CM. Como parte do processo de CM, deve-se

definir o esquema do banco de dados de CM, os formulários para coletar informações para

serem registradas no banco de dados e procedimentos para registro e recuperação de

informações de projeto. Um banco de dados de configuração pode registrar informações sobre

usuários de componentes, clientes de sistemas, plataformas de execução, mudanças propostas

e etc.

De preferência, um banco de dados de configuração deve ser integrado com a versão

do sistema de gerenciamento usada para armazenar e gerenciar os documentos formais do

projeto. 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.

2 Gerenciamento de mudanças

30

Page 28: Produção Textual Individual 01_2015

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.

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. O processo de gerenciamento de mudança

deve surtir efeito quando o software ou a documentação associada são colocados em baseline

pela equipe de gerenciamento de configurações.

O primeiro estágio no processo de gerenciamento de configurações é completar um

formulário de solicitação de mudança (CRF – change request form) que descreve a mudança

necessária para o sistema. Uma vez que o formulário de solicitação de mudança é enviado, ele

deve ser registrado no banco de dados de configuração. A solicitação de mudança é então

analisada para verificar se a mudança solicitada é necessária. Para mudanças validas, o estagio

seguinte é a avaliação da mudança e o custo. O impacto da mudança no restante do sistema

deve ser verificado. Isso envolve todos os componentes afetados pela mudança. Se realizar a

mudança significa que mudanças adicionais em alguma parte do sistema são necessárias, isso

aumenta claramente o custo de sua implementação. Em seguida as mudanças necessárias para

os módulos do sistema são avaliadas. Finalmente, o custo para realizar a mudança é estimado,

considerando os custos de mudança nos componentes relacionados.

3 Gerenciamento de versões e releases

Os processos envolvidos no gerenciamento de versões e relases preocupam-se com

a identificação e a manutenção da rastreabilidade das versões de um sistema. Gerentes de

versões idealizam procedimentos para assegurar que as versões de um sistema possam ser

recuperadas quando solicitadas e não sejam alteradas acidentalmente pela equipe de

desenvolvimento. Para produtos, os gerentes trabalham com a equipe de marketing, e , para

sistemas feitos sob encomenda, com os clientes, para planejar quando novos releases de um

sistema devem ser criados e distribuídos para implantação.

31

Page 29: Produção Textual Individual 01_2015

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.

1 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. Você não pode usar o nome do

item de configuração para identificar a versão, porque ele pode ter muitas versões para cada

item de configuração identificado.

A três técnicas básicas para identificação da versão de componentes.

1. Numeração de versões. O componente recebe um número explicito e único de

versão. Isso é o mais comumente usados no esquema de identificação.

2. Identificação baseada em atributos. Cada componente tem um nome (como o

nome do item de configuração, que não é único para diferentes versões) e um grupo de

atributos associados para cada versão, componentes são portanto, identificados pela

especificação de seus nomes e valores de atributos.

3. Identificação orientada a mudanças. Cada componente é denominado como na

identificação baseada em atributos, mas é também associado com uma ou mais solicitações de

mudanças. Ou seja, considera –se que cada versão de componente foi criada em resposta a

uma ou mais solicitações de mudanças. A versão de componente é identificada pelo conjunto

de solicitações de mudanças que se aplicam ao componente.

2 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.

32

Page 30: Produção Textual Individual 01_2015

A criação de um release é um processo de criação de arquivos e documentos que

inclui todos os componentes do release do sistema. O código executável de programas e todos

os arquivos de dados associados devem ser coletados e identificados. Se os manuais a serem

lidos em

computadores são distribuídos, copias eletrônicas devem ser armazenadas com o software.

Finalmente, quando todas as informações estiverem disponíveis, o diretório do release é

manipulado para a distribuição.

Quando um release de sistema é produzido, ele deve ser documentado para assegurar

que possa ser recriado ipsis literais no futuro. Isso é importante para sistemas embutidos de

ciclo de vida longo e feitos para os clientes, como aqueles que controlam maquinas

complexas.

Para documentar um release você deve registrar as versões especificas dos

componentes de código fonte usados para criar o código executável. Você deve manter cópias

dos códigos fonte e código executável, e de todos os arquivos de dados e de configuração.

Você deve também registrar as versões do sistema operacional, as bibliotecas, os

compiladores e outras ferramentas usadas para construir o software. Elas podem ser

necessárias para construir exatamente o mesmo sistema em alguma data posterior.

4 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. Quando você está

construindo um sistema com base em seus componentes, você deve pensar nas seguintes

questões:

1. Todos os componentes que compõem um sistema foram incluídos nas instruções de

construção?

2. A versão apropriada de cada componente necessário foi incluída nas instruções de

construção ?

3. Todos os arquivos de dados necessários estão disponíveis?

4. Se os arquivos de dados estão referenciados dentro de um componente, o nome usado

é o mesmo que o do arquivo de dados na máquina – alvo?

33

Page 31: Produção Textual Individual 01_2015

5. A versão apropriada do compilador e de outras ferramentas requeridas está disponível?

As versões atuais das ferramentas de software podem ser incompatíveis com as versões

antigas usadas para desenvolver o sistema.

5 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.

Consequentemente, o apoio de uma ferramenta CASE é essencial para o gerenciamento de

configuração. Essas ferramentas podem ser combinadas para criar uma área de trabalho para

apoiar todas as atividades de CM.

4.2 – PROGRAMAÇÃO PARAWEB II (Desafio 3)

No desenvolvimento do software, um Framework (ou arcabouço) é uma

estrutura de suporte definida em que um outro projeto de software pode ser organizado

e desenvolvido. Um Framework pode incluir programas de suporte, bibliotecas de

código, linguagens de script e outros softwares para ajudar a desenvolver e juntar

diferentes componentes de um projeto de software [Magela 2006].

Frameworks são projetados com a intenção de facilitar o desenvolvimento de

software, habilitando designers e programadores a gastarem mais tempo determinando nas

exigências do software do que com detalhes tediosos de baixo nível do sistema.

Especificamente em orientação a objeto (que é o paradigma da Java), Framework é um

conjunto de classes com objetivo de reutilização de um design, provendo um guia para uma

solução de arquitetura em um domínio específico de software.

PRINCIPAIS FRAMEWORKS

Alguns dos principais Frameworks Java para desenvolvimento WEB são: JSF (Java

Server Faces) [Jacobi 2007], Spring MVC [Walls 2006], Struts 2 [Apache 2006] e Tapestry

34

Page 32: Produção Textual Individual 01_2015

[Sam-Bodden 2006]. Antes de partir para a comparação entre eles para o desenvolvimento

WEB 2.0 segue uma breve descrição de cada:

JSF (Java Server Faces)

Desenvolvido pela Sun e lançado em 2005, tem por finalidade fazer com que o

desenvolvedor não crie as páginas JSP como se fossem páginas HTML e sim como se fossem

“telas” de um programa. O Framework é que transforma a “tela” em uma página HTML. O

grande poder deste Framework está nos aplicativos que dão suporte ao seu uso, pois tornam a

criação das telas (JSPs) bem rápida e de maneira visual com o uso do “drag and drop”, ou

seja, “clica e arrasta” e do WYSIWYD - “What You See is What You Do”, ou seja, “O que

Você Vê é O que Você Faz” -. A Figura abaixo apresenta o funcionamento de uma aplicação

feita com JSF.

O JSF é um framework de interface.

Spring MVC

Parte do projeto Spring Framework (que é muito grande, oferecendo até um

Framework para persistência de dados). Tem como principais vantagens o uso do IoC

(Inversão de controle) do Spring e a facilidade na renderização de diversos tipos de saídas

35

Ciclo de requisição e resposta com Frameworks JSFFonte: RAIBLE, 2006

Page 33: Produção Textual Individual 01_2015

(JSP, Tiles, Velocity, Freemaker, Excel, PDF, etc.). A Figura abaixo apresenta o

funcionamento de uma aplicação feita com Spring MVC.

Struts 2

Nascido em meados de 2006, a partir da união dos Frameworks WEB Struts [Husted

2004] e WebWork [Lightbody 2005], é baseado em Actions e já vem com um conjunto de

Taglibs (bibliotecas de tags) prontas para o desenvolvimento AJAX de maneira bem

transparente. É um projeto da Apache Software Foundation [Apache 2007]. A Figura abaixo

apresenta o funcionamento de uma aplicação feita com Struts 2.

 

36

Ciclo de requisição e resposta com Frameworks Spring MVC via GET (esquerda) e POST (direita).

Fonte: RAIBLE, 2006

Page 34: Produção Textual Individual 01_2015

Tapestry

Projeto da Apache Software Foundation, é um Framework no qual se tem muito trabalho no

início do desenvolvimento de um novo projeto. A partir da versão 4.1 já vem com suporte

nativo a AJAX. É um projeto da Apache Software Foundation. A Figura 5 apresenta o

funcionamento de uma aplicação feita com Tapestry.

 

4.2.1 - Comparação Para O Desenvolvimento Web 2.0

Para comparar os Frameworks para o desenvolvimento WEB 2.0 este artigo vai

comparar o suporte a AJAX eles oferecem. Serão feitas duas comparações: uma breve

comparação conceitual e uma comparação prática.

Breve Comparação Conceitual

37

Ciclo de requisição e resposta com Framework Struts 2.Fonte: RAIBLE, 2006

Page 35: Produção Textual Individual 01_2015

A Tabela 1 apresenta um resumo das diferenças entre os Frameworks para o desenvolvimento

WEB 2.0: 

Comparação Prática

Para a comparação prática este artigo vai comparar as várias funcionalidades AJAX

oferecidas por dois dos Frameworks citados anteriormente: O JSF e o Struts 2.

Os motivos que levaram a escolha desses Frameworks foram:

O JSF (Java Server Faces) foi criado pela Sun, que é a criadora da própria linguagem Java

e é definido como padrão por ela e pela JCP (Java Community Process). De todos os

Frameworks Java para WEB é o que possui maior número de aplicativos que oferecem

RAD (Rapid Application Development - Rápido Desenvolvimento de Aplicação -) e mais

programação “visual” para a criação de JSPs com o uso do “drag and drop”, ou seja,

“clica e arrasta” e do WYSIWYG - “What You See is What You Get”, ou seja, “O que

Você Vê é O que Você Tem”.

O Struts 2 nasceu da “união” de dois Frameworks: Struts e WebWork. O Struts foi, por

muitos anos, sinônimo de Java na Internet, a referência em Framework Java para a WEB.

38

Page 36: Produção Textual Individual 01_2015

Muito dificilmente um programador que desenvolve com Java para a WEB há dois anos

ou mais não fez sequer um projeto com o Struts. O WebWork trouxe consigo muitas

facilidades e funcionalidades significativas porém nunca conseguiu tornar-se tão popular

quanto o Struts. Usar o Struts 2 na comparação prática deste artigo é como comparar dois

Frameworks em um. Outra característica importante deste Framework é que de todos os

citados aqui é ó único que já nasceu com funcionalidades AJAX nativas em suas Taglibs.

Não será mostrado como configurar e usar os recursos apresentados durante a

comparação, pois não é a finalidade deste artigo ensinar como usar os Frameworks. A

comparação proposta aqui é para que o desenvolvedor conheça a funcionalidades WEB 2.0

que os Frameworks Java para desenvolvimento WEB oferecem.

Conforme citado anteriormente, o JSF não possui suporte nativo a AJAX, sendo

necessário o uso de algum componente. Neste artigo usaremos os componentes Java

BluePrints AJAX Components da Sun que possuem versões para o Studio Creator e o

NetBeans, que são duas das melhores IDEs para o desenvolvimento JSF. No Struts 2 existem

algumas Taglibs (bibliotecas de Tags) e alguns Plugins que provem as funcionalidades AJAX

às aplicações feitas com este Framework. As funcionalidades AJAX que os componentes da

Java BluePrints AJAX Components e o Struts 2 oferecem são descritos nas seções seguintes.

Auto Completar

Gera uma lista de sugestões conforme o usuário digita na caixa de texto. No JSF é

usado o componente Auto-complete e no Struts 2 a Autocompleter Tag. Em ambos os

Frameworks é possível usar qualquer objeto “coleção” do Java (List, Vector, Array, etc) para

gerar a lista a ser carregada para o usuário. No JSF este recurso possibilita a obtenção de um

valor alfanumérico já no Struts 2 são gerados dois valores, um que representa a chave do valor

selecionado na lista e outro que representa o texto do item selecionado. No JSF a lista aparece

de maneira simples, sem rolagem, nem “zebraba” e sem destaque ao que é digitado, ao

contrário de como aparece com o Struts 2. A Figura abaixo apresenta a diferença de

funcionamento deste recurso nos dois Frameworks:

39

Page 37: Produção Textual Individual 01_2015

 

4.2.2 - Custo Benefício Da Utilização de Frameworks

O grande benefício que um projeto que utiliza frameworks pode trazer ganhos de

qualidade e produtividade. A obtenção de boa estrutura para implementação, os recursos

diversos que proporcionam a facilidade para construir um projeto de software e o

cumprimento pleno da documentação,ajuda a diminuir custos estabelecidos e aumenta a

produtividade dos desenvolvedores em relação à construção do projeto de software.

Além disso, o reuso de componentes, aplicação, objetos e funções, possibilitam aos

projetistas de software o reaproveitamento do conteúdo utilizado em outros projetos que já

foram construídos e evita o trabalho de calcular a maior parte das estimativas relacionadas ao

novo projeto. Com base no conhecimento da equipe de desenvolvimento, das tecnologias e

quais os recursos que podem ser realmente utilizados.

Abaixo, a tabela demonstra os prós e contras da utilização dos Frameworks.

40

Auto-completar com AJAX e JSF com a função autocompleter Tag Struts 2

Page 38: Produção Textual Individual 01_2015

4.2.3 – Disponibilizando Conteúdos na Web

Plataforma de desenvolvimento:

Java Platform, Enterprise Edition (ou Java EE, ou EE, ou em português Plataforma

Java, Edição Empresarial) é uma plataforma de programação para servidores nalinguagem de

programação Java.1 A plataforma fornece uma API e um ambiente de tempo de execução para

o desenvolvimento e execução de softwares corporativos, incluindo serviços de rede e web, e

outras aplicações de rede de larga escala, multicamadas, escaláveis, confiáveis e seguras. Java

EE estende a Java Platform, Standard Edition (Java SE),2 fornecendo uma API

para mapeamento objeto-relacional, arquiteturas multicamada e distribuídas e web services. A

plataforma incorpora um desenho amplamente baseado em componentes modulares rodando

em um servidor de aplicação. Softwares para Java EE são primeiramente desenvolvidos

na linguagem de programação Java. A plataforma enfatiza a convenção sobre

configuração e anotações para configuração.

A Plataforma Java (Enterprise Edition) difere-se da Plataforma Java Standard

Edition (Java SE) pela adição de bibliotecas que fornecem funcionalidade para

implementarsoftware Java distribuído, tolerante a falhas e multicamada, baseada amplamente

41

Page 39: Produção Textual Individual 01_2015

em componentes modulares executando em um servidor de aplicações. A plataforma Java EE

é considerada um padrão de desenvolvimento já que o fornecedor de software nesta

plataforma deve seguir determinadas regras se quiser declarar os seus produtos como

compatíveis com Java EE. Ela contém bibliotecas desenvolvidas para o acesso a base de

dados, RPC, CORBA, etc. Devido a essas características a plataforma é utilizada

principalmente para o desenvolvimento de aplicações corporativas.

A plataforma JEE contém uma série de especificações e containers, cada uma com

funcionalidades distintas. São eles:

JDBC (Java Database Connectivity), utilizado no acesso a bancos de dados;

Servlets, são utilizados para o desenvolvimento de aplicações Web com conteúdo

dinâmico. Ele contém uma API que abstrai e disponibiliza os recursos do servidor Web de

maneira simplificada para o programador.

JSP (Java Server Pages), uma especialização do servlet que permite que conteúdo

dinâmico seja facilmente desenvolvido.

JTA (Java Transaction API), é uma API que padroniza o tratamento de transações dentro

de uma aplicação Java.

EJBs (Enterprise Java Beans), utilizados no desenvolvimento de componentes

de software. Eles permitem que o programador se concentre nas necessidades do negócio

do cliente, enquanto questões de infra-estrutura, segurança, disponibilidade e

escalabilidade são responsabilidade do servidor de aplicações.

JCA (Java Connector Architecture), é uma API que padroniza a ligação a aplicações

legadas.

JPA (Java Persistence API), é uma API que padroniza o acesso a banco de dados através

de mapeamento Objeto/Relacional dos Enterprise Java Beans.

JMS (Java Message Service), é uma API para middleware orientado a mensagens.

Através dela é possível realizar a comunicação de forma assíncrona entre duas ou mais

aplicações

Requisitos necessários para disponibilizar o conteúdo na web:

Web Services é a tecnologia ideal para comunicação entre sistemas, sendo muito

usado em aplicações B2B. A comunicação entre os serviços é padronizada possibilitando a

42

Page 40: Produção Textual Individual 01_2015

independência de plataforma e de linguagem de programação. Por exemplo, um sistema de

reserva de passagens aéreas feito em Java e rodando em um servidor Linux pode acessar, com

transparência, um serviço de reserva de hotel feito em. Net rodando em um servidor

Microsoft.

Para comunicar com o Web Service, é necessário uma implementação do protocolo

SOAP (Simple Object Access Protocol) definido noW3C. Este protocolo é o responsável pela

independência que o Web Service precisa. Atualmente já encontra-se várias implementações

disponíveis em várias linguagens.encontra-se um diagrama mostrando as mensagens trocadas

entre cliente e servidor em uma comunicação SOAP. Existem duas aplicações se

comunicando, um Client Wrapper e um Server Wrapper que estão disponibilizando a

transparência para as aplicações. Entre eles só trafega XML, seguindo o protocolo SOAP

sobre HTTP.

Na figura a seguir encontra-se um diagrama mostrando as mensagens trocadas entre

cliente e servidor em uma comunicação SOAP. Existem duas aplicações se comunicando, um

Client Wrapper e um Server Wrapper que estão disponibilizando a transparência para as

aplicações. Entre eles só trafega XML, seguindo o protocolo SOAP sobre HTTP.

Um Web Service será publicado, e para que outras pessoas possam utilizá-lo é

necessário definir como ele é, como deve ser acessado, e que valores ele retornará. Estas

definições são descritas em um arquivo XML de acordo com a padronizaçãoWeb Service

Description Language(WSDL). Este arquivo deve ser construído para que os usuários do

43

Page 41: Produção Textual Individual 01_2015

serviço possam entender o funcionamento do Web Service e, logicamente, será de acesso

público.

Os Web Services também podem ser utilizados para implementar arquiteturas

orientadas a serviços, as Service-Oriented Architectures (SOA). Neste modelo de arquitetura

os principais requisitos viram serviços e são acessados por outros serviços, modularizando e

aumentando a coesão dos componentes da aplicação.

4.3 – Projeto Orientado a Objetos (Desafio 4)

Como já foi dito na descrição do problema da China Telecon, 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.

Padrão de arquitetura:

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 é:

44

Page 42: Produção Textual Individual 01_2015

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 ideia é 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, a view não se importa de onde está

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

45

Page 43: Produção Textual Individual 01_2015

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. 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.

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)

46

Page 44: Produção Textual Individual 01_2015

          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.

47

Ciclo do Padrão de Projeto.

Fonte: Use a Cabeça, Figura 3 de Freeman & Freeman.

Page 45: Produção Textual Individual 01_2015

Utilizando essa arquitetura, o tempo de desenvolvimento do software diminuirá sem

perde a qualidade e sem aumento de custos.

Framework:

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 Java.

Hibernate:

O Hibernate é um framework open source de mapeamento objeto/relacional

desenvolvido em Java, ou seja, ele transforma objetos definidos pelo desenvolvedor em dados

tabulares de uma base de dados, portanto com ele o programador se livra de escrever uma

grande quantidade de código de acesso ao banco de dados e de SQL.

Se comparado com a codificação manual e SQL, o Hibernate é capaz de diminuir 95% das

tarefas relacionadas a persistência.

Vantagens do Hibernate

A utilização de código SQL dentro de uma aplicação agrava o problema da

independência de plataforma de banco de dados e complica, em muito, o trabalho de

mapeamento entre classes e banco de dados relacional.

O Hibernate abstrai o código SQL da nossa aplicação e permite escolher o tipo de

banco de dados enquanto o programa está rodando, permitindo mudar sua base sem alterar

nada no seu código Java.

Além disso, ele permite criar suas tabelas do banco de dados de um jeito bem

simples, não se fazendo necessário todo um design de tabelas antes de desenvolver seu projeto

que pode ser muito bem utilizado em projetos pequenos.

O Hibernate não apresenta apenas a função de realizar o mapeamento objeto

relacional. Também disponibiliza um poderoso mecanismo de consulta de dados, permitindo

uma redução considerável no tempo de desenvolvimento da aplicação.

48

Page 46: Produção Textual Individual 01_2015

Ferramenta Utilizada

No caso do desenvolvimento do sistema China Telecon poderia ser utilizada

qualquer ferramenta de base Java, como Eclipse ou NetBeans. O que vai definir a escolha de

uma ferramenta seria a afinidade da equipe com determinada ferramenta. No meu caso

utilizaria o netbeans por ter uma interface gráfica mais atraente e por suportar os diversos

Frameworks para Java.

O Netbeans é uma poderosa ferramenta de desenvolvimento Java. Entre muitas melhorias, esta versão dará suporte às plataformas PHP, JavaScript e Ajax, Ruby e Ruby em Rails, Groovy e C/C++.

O Netbeans 7 apresenta algumas melhorias comparativamente a versões anteriores e das quais destacamos:

Suporte para o Java 7 Melhorias a nível do editor Suporte para HTML5 Suporte para quebras de linha Suporte para Git 1.7.х Melhor integração com bases de dados Oracle

O NetBeans tem um interface bem organizado e disponibiliza um conjunto de funções que permitem aos programadores desenvolver aplicações de alto nível. Considerando que a linguagem de programação Java é uma das mais usadas atualmente, o Netbeans torna-se um excelente IDE para desenvolvimento.

49

Page 47: Produção Textual Individual 01_2015

5 – CONCLUSÃO

Durante o desenvolver deste trabalho, foi adquirido e ampliado meus conhecimentos

na área de desenvolvimento de software, ferramentas, IDE’s, Frameworks, Regras de

Negócio, Projetos Orientados a Objetos, Arquitetura de Software, fases de um projeto e tudo

que faz é necessário para o desenvolvimento de um software para uma empresa de grade

porte. Assim será possível tomar melhor decisão de que método seguir ao iniciar um novo

trabalho ou implementar um sistema já existente, sabendo daqui para frente tomar um

caminho que proporcionará um melhor desempenho profissional e uma maior satisfação

quanto ao trabalho desenvolvido, com menos problemas e maior agilidade no decorrer do

processo, me tornando assim um profissional digno com profundos conhecimentos da área em

que atuo.

50

Page 48: Produção Textual Individual 01_2015

6 – REFERÊNCIAS BIBLIOGRÁFICAS

COELHO, Tiago. Gerenciamento de Riscos Utilizando o PMBOK. 2010. 85 f. Monografia

apresentada ao Curso de Ciência da . Faculdade Lourenço Filho, Fortaleza-CE, 2010.

ESCRITÓRIO DE PROJETOS. Partes Interessadas. Disponível em

<http://escritoriodeprojetos.com.br/partes-interessadas.aspx> Acesso em 11 maio.2015.

ESCRITÓRIO DE PROJETOS. Riscos de um Projeto. Disponível em

<http://escritoriodeprojetos.com.br/gerenciamento-dos-riscos-do-projeto.aspx>. Acesso em 11

maio.2015.

ESCRITÓRIO DE PROJETOS. Identificar as Partes Interessadas. Disponível em

<http://escritoriodeprojetos.com.br/identificar-as-partes-interessadas.aspx> Acesso em 11

maio.2015.

HENRIQUE, Antônio dos Santos; RIBEIRO, Nelson Carvalho. Frameworks e seus

Benefícios no Desenvolvimento de Software. 2010, 16 f.

IGNÁCIO , Ana Maria Dias. Um processo de seleção de fornecedores de software.

Disponível em <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/253>.

Acesso em 11 maio.2015.

LIMA, Fabiana de. PMBOK: Trabalhando com gerenciamento de custos. Disponível em

<http://www.devmedia.com.br/pmbok-trabalhando-com-gerenciamento-de-custos/31158>.

Acesso em 11 maio.2015.

MABESE. Compararação: Frameworks Java para Desenvolvimento WEB 2.0.

Disponível em <http://www.mabesi.com/artigos/programacao-web/jsp/1-comparacao-

frameworks-java-para-desenvolvimento-web-20.html>. Acesso em 11 maio.2015.

PAMPLONA, Vitor Fernando. Web Services. Construindo, disponibilizando e acessando

Web Services via J2SE e J2ME . Disponível em

<http://javafree.uol.com.br/artigo/871485/Web-Services-Construindo-disponibilizando-e-

acessando-Web-Services-via-J2SE-e-J2ME.html> Acesso em 12 maio.2015.

51

Page 49: Produção Textual Individual 01_2015

VASILÉSVSKI, Vera. Construção de um sistema computacional para suporte à pesquisa

em fonologia do português do Brasil. Disponível em

<https://repositorio.ufsc.br/xmlui/handle/123456789/91849>. Acesso em 12 maio.2015.

YOSHIRIRO , José Ajisaka Ramos. Comparação entre os principais Frameworks Java

para o ;

desenvolvimento de aplicações WEB 2.0. 14f. Instituto de Estudos Superiores da Amazônia

(IESAM);

52