Resumo do portifolio 5 sementre - Ads - Unopar

Prévia do material em texto

DESENVOLVIMENTO
Engenharia e Projeto de Software
Desafio 01
Analisamos, dentre as dificuldades e facilidades mapeadas na literatura, quais e por que as mesmas estão presentes no processo de gerenciamento de projetos com base no guia PMBOK. Verificamos quais os possíveis argumentos que os gestores vivenciam no gerenciamento de projetos no que diz respeito aos sucessos e fracassos apresentados. O estudo se concentrou em profissionais com certificação PMP por apresentarem o conhecimento em Gerenciamento de Projetos com base no guia PMBOK e, por ser uma área de crescimento onde as empresas buscam profissionais com melhores práticas e vantagem competitiva. Valendo-se do questionário estruturado como instrumento de coleta de dados e analisando os resultados, os principais pontos encontrados dizem respeito ao tempo em que os gerentes lidam com gerenciamento de projetos, as dificuldades encontradas pelos gerentes em sua prática profissional, a área do PMBOK com maior dificuldade de ser gerenciada, os itens que geram sucessos e fracassos nos projetos. A entrevista semi-estruturada evidenciou que o gerenciamento de projetos apresenta algumas dificuldades presentes na prática profissional dos gerentes. Sugerimos investigar melhor o impacto que a certificação PMP proporciona aos gerentes de projetos e se
a relação maturidade organizacional e experiência em gerenciamento de projetos é fator de sucesso para o projeto.
Algumas áreas da competência, segundo PMBoK estão relacionadas abaixo:
Riscos Esta área descreve os processos relativos à realização do gerenciamento de riscos em um projeto. Temos cinco processos de planejamento e um de controle. Os processos desta área de conhecimento tem como objetivo determinar como os riscos serão identificados, analisados e como as respostas serão planejadas e como risco será planejado, criam uma lista de riscos identificados no projeto com diversas técnicas que ajudam a gerar essa lista de riscos, buscam priorizar os riscos com base no grau de criticidade, permitem atribuir probabilidade numérica aos riscos, definem estratégias e ações para lidar com os riscos negativos e positivos, monitoram os risco com novos risco sendo identificados, revisão das análises de riscos, definição de outras prioridades de riscos, etc.
Os processos dessa área são: Planejar o Gerenciamento dos Riscos, identificar os riscos, realizar a análise qualitativa de riscos, realizar a análise quantitativa dos riscos, planejar as respostas aos riscos, monitorar e controlar os riscos.
Escopo Esta área descreve os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário e apenas o trabalho necessário, para que seja concluído com sucesso.
Os processos dessa área são: Coletar requisitos, definir o escopo, cria a EAP, verificar o Escopo e Controlar o Escopo.
.
Fornecedores Os processos de gerenciamento das aquisições do projeto envolvem acordos, incluindo contratos, que são documentos legais entre um comprador e um fornecedor. Um contrato representa um acordo mútuo que obriga o fornecedor a oferecer algo de valor (por exemplo, produtos, serviços ou resultados especificados) e obriga o comprador a fornecer uma compensação monetária ou de outro tipo. O acordo pode ser simples ou complexo, e pode refletir a simplicidade ou complexidade dos resultados e do esforço necessário.
Desafio 02
CAPITULO 11 – Projeto de Arquitetura
O projeto de arquitetura é primeiro estagio 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:
1 -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.
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 refete 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:
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.
3 ModeloCliente – Servidor
O modelo de arquitetura cliente – servidor é um modelo em que o sistem é 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.
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.
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.
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 esta 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.
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 ate serem convertidos em dados se saída.
8 Modelos de Controle
Os modelos de controle tem 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.
10 Arquitetura de Referência
As arquiteturas de referencia 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 referencia forenece 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 referencia é um modelo para ambientes CASE que identifica cinco conjuntos de serviços que um ambiente CASE deve fornecer. Ele deve também fornecer recursos de plug in para ferramentas CASE individuais que usam esses serviços. Os cincos níveis de referencias 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 recusros para a definição e aprovação de modelos de processo.
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.
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 máquina 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.
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.
5 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 encapsulamentode 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 interface
para 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.
6 COMPUTAÇÃO INTERORGANIZACIONL DISTRIBUIDA
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.
7 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 principio, 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 nos 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 esta recuperando se torna visível para outros.
8 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 pratico.
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.
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 PROCESSAMENTOS 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 Processamento. O processamento realiza a computação usando essas entradas.
3 Saída. 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 processamento (saída).
São sistemas orientados a funções, pois os registros e as transações são processados em serie, sem necessidade de manter o estado entre as transações.
2 SISTEMAS DE PROCESSAMENTO 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 dado.
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 numero 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 maquina 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 esta 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 adicionadosou 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 esse 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.
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
O 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 sequencia 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 maquina. 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 esta 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 esta 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.
6. Um gerador de código que ‘caminha’ pela árvore de sintaxe e gera o código de maquina 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.Ha 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.
 1PLANEJAMENTO 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.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 seruteis para a evolução futura do sistema devem ser controlados pelo sistema de gerenciamento de configuração.
O esquema de identificação de itens de configuração deve atribuir um único nome para todos os documentos sob controle de configuração. 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.
1.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
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 analise de custo e beneficio 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 equipede 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.
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.
3.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 numero explicito e único de versão. Isso é o mais comumente usado 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.
3.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.
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 disponiveis, 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 literis 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 compias 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ê esta 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 maquina – alvo?
5. A versão apropriada do compilador e de outras ferramentas requeridas esta 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 um 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.
Programação para Web II
Desafio 03
Comparação de frameworks para desenvolvimento web (Java).
Classifica-se um framework de acordo com duas dimensões: como ele é utilizado e onde é utilizado. No tratamento de como um framework pode ser utilizado, será analisado o ponto de como introduzir as particularidades de uma aplicação. Neste sentido Willemann e Ibarra (2007) os classificam em:
Caixa branca: são baseados na especialização por herança e sobrescrita de métodos, modificando assim as funcionalidades básicas do framework.
Caixa preta: são os frameworks focados na composição, devendo utilizar as funcionalidades já presentes no framework, ou seja, neste tipo de framework as funcionalidades internas não podem ser vistas nem modificadas e devem-se utilizar as interfaces fornecidas pelo framework. Neste framework as instanciações e composições feitas é o que determinam as particularidades da aplicação.
Caixa cinza: são frameworks híbridos, misturam os dois focos, herança e composição, ou seja, são frameworks baseados em herança (caixa branca) com algumas funcionalidades prontas.
A seguir são apresentadas as formas de utilização de um framework.
Frameworks de suporte ou de integração midleware: oferecem serviços de sistema de baixo nível, tais como dispositivos de interface para periféricos (drivers) e de acesso a arquivos, sendo normalmente usados para integrar aplicações e componentes distribuídos, como frameworks BORBA ORB, DCOM, implementações do padrão ODMG, entre outros (MATOS, 2008).
Frameworks de aplicação ou de infraestrutura: são frameworks que cobrem funcionalidades que podem ser aplicadas a diferentes domínios. Ou seja, são independentes do domínio ao qual será endereçado, como por exemplo, osframeworks para sistemasoperacionais, comunicação, redes e para construção de interfaces (MATOS, 2008).
Frameworks de domínio: capturam conhecimento e especialidade em um domínio de problema particular. Representam um projeto geral de aplicações para domínios específicos, como telecomunicações, manufatura, jogos, controle de produção, multimídia e engenharia financeira (MATOS, 2008).
 Custo Benefício de frameworks no desenvolvimento Web
Melhora a modularização – encapsulamento dos detalhes voláteis de implementação através de interfaces estáveis.
Aumenta a reutilização – definição de componentes genéricos que podem ser replicados para criar novos sistemas.
Extensibilidade – favorecida pelo uso de métodos hooks que permitem que as aplicações estendam interfaces estáveis.
Inversão de controle – IoC – o código do desenvolvedor é chamado pelo código do framework. Dessa forma, o framework controla a estrutura e o fluxo de execução dos programas. 
De acordo com Willemann e Ibarra (2007), a principal vantagem na utilizando deframeworks é a redução de custos, sendo que já existe uma estrutura definida e que o desenvolvimento pode concentrar-se em desenvolver as regras específicas do negócio em que o sistema deve atuar. Um framework ainda proporciona uma maior reutilização de códigos e a fatoração de problemas em aspectos comuns a várias aplicações, permite também obter sistemas com códigos menos frágeis e com menos defeitos.
Entretanto, caso se decida construir um framework deve ter em mente que é uma tarefa complexa, pois o reuso não acontece por acaso, devendo ser adequadamente planejado. Iniciar a construção de um framework sem um bom planejamento pode trazer mais prejuízos do que vantagens. 
Com certeza, construir uma aplicação e construir um framework paralelamente, demora muito mais do que construir uma aplicação isolada. Isso tudo pelo fato de que quando se constrói um framework, deve-se planejá-lo de forma que atenda a mais do que uma aplicação, ou seja, atenda a um domínio específico de aplicações e não somente uma. As vantagens de um framework só aparecem em longo prazo, na medida em que a estrutura torna-se consistente e de domínio das equipes de desenvolvimento.
Programação Java Web (plataforma de desenvolvimento).
Os critérios que mais contribuíram para selecionar as ferramentas que utilizaremos ao longo do livro são simples: popularidade e experiência. Além das ferramentas selecionadas estarem entre as mais populares, elas fazem parte do dia-a-dia dos autores. Isso com certeza possibilita criar um texto ao mesmo tempo técnico e composto de dicas, que são baseadas na experiência adquirida pelo uso de tais ferramentas. 
Além disso, se você desenvolver seu projeto usando o Apache Tomcat e o MySQL, encontrará com mais facilidade algum serviço de hospedagem que tenha exatamente essa configuração. Não basta ter uma excelente ideia de um novo produto para a internet e executá-lo somente em seu computador doméstico. É preciso pensar no futuro: seu produto pode ser o próximo a ser comprado por alguns milhões de dólares por alguma megaempresa da internet!
Projeto Orientado a Objetos
Desafio 04
A melhor solução para China Telecom seria realmente adotar um software de uma empresa especializada e com um bom suporte. Mas nos baseando na hipótese de a empresa querer desenvolver seu próprio software, para reduzir os custos seria necessário também reduzir o tempo de desenvolvimento do mesmo e manter a qualidade e produtividade no desenvolvimento. Além de contar com uma equipe de profissionais capacitados, também seria necessário adotar padrões e técnicas que irão ajudar a desenvolver um bom sistema para a empresa.
Analisando entre os padrões existentes, é fácil chegar a conclusão que o melhor padrão para ser adotado no desenvolvimento do software em questão seria a arquitetura MVC. 
A arquitetura MVC foi desenvolvida para ser usado em projetos de interface visual em Smalltalk, linguagem de programação que juntamente com o C++ ganhou grande reconhecimento na época, o MVC foi criado na década de 70, e após esses anos de sua criação ainda é um pattern aplicável nas mais variadas aplicações, principalmente em aplicações web.
Quando um software começa a ficar grande e complexo, muitos dados são apresentados para os usuários, sentimos a necessidade de aplicar uma arquitetura que facilite nosso trabalho, desde a organização do projeto, as divisões das responsabilidades até as possíveis modificações que poderão ser efetuadas ao longo do desenvolvimento do software para isso precisaram dividir o projeto em três objetos para aplicar o MVC.
Para a Gamma et al. o MVC é:
MVC é composto por três tipos de objetos. O modelo é o objeto de aplicação, a vista é a apresentação na tela e o controlador define a maneira como a interface do usuário reage às entradas do mesmo. Antes do MVC, os projetos de interface para o usuário tendiam em agrupar esses objetos. MVC para aumentar a flexibilidade e a reutilização. (GAMMA et al. 2000, p. 20).
          O MVC tem como principal objetivo: separar dados ou lógicos de negócios (Model) da interface do usuário (View) e o fluxo da aplicação (Controller), a idéia é permitir que uma mensagem da lógica de negócios possa ser acessada e visualizada através de várias interfaces. Na arquitetura MVC, á lógica de negócios, ou seja, nosso Model não sabe quantas nem quais as interfaces com o usuário esta exibindo seu estado, a view não se importa de onde esta recebendo os dados, mas ela tem que garantir que sua aparência reflita o estado do modelo, ou seja, sempre que os estados do modelo mudam, o modelo notifica as view para que as mesmas atualizem-se.
MVC é um conceito (paradigma) de desenvolvimento e design que tenta separar uma aplicação em três partes distintas. Uma parte, a Model, esta relacionada ao trabalho atual que a aplicação administra outra parte a View esta relacionada a exibir os dados ou informações dessa uma aplicação e a terceira parte, Controller, em coordenar os dois anteriores exibindo a interface correta ou executando algum trabalho que a aplicação precisa completar. (GONÇALVES, 2007, p. 141).
 Model: ou modelo é a camada que contém a lógica da aplicação, é responsável pelas regras de negócio, para sistemas persistentes, o modelo representa a informação (dados) dos formulários e as regras SQL para manipular dados do banco, o modelo mantém o estado persistente do negócio e fornece ao controlador á capacidade de acessar as funcionalidades da aplicação, o modelo é o principal responsável toda aplicação deve representar o modelo atua isoladamente não tem conhecimento de quais serão a ou as interfaces que terá de atualizar, o modelo somente acessa á base de dados e deixa os dados prontos para o controlador este por sua vez encaminha para a visão correta.
 View: ou visão é a camada de apresentação com usuário, é a interface que proporcionará á entrada de dados e a visualização de respostas geradas, nas aplicações web é representado pelo HTML que é mostrado pelo browser, geralmente a visão contém formulários, tabelas, menus e botões para entrada e saída de dados.  A visão deve garantir que sua apresentação reflita o estado do modelo, quando os dados do modelo mudam, o modelo notifica as vistas que dependem dele, cada vista tem a chance de atualizar-se. Desta maneira permite ligar muitas vistas a um modelo podendo fornecer diferentes apresentações, essa camada não contém códigos relacionados á lógica de negócios, ou seja, todo o processamento é feito pelo Modelo e este repassa para a visão, evidenciaremos abaixo um exemplo de duas vistas atuando sobre o mesmo modelo.
Controller: já descrevemos da view e do modelo, mas, temos de concordar que tudo isso se tornaria uma bagunça se tivesse alguém para organizar esta arquitetura, um controlador funciona de intermediário entre a camada de apresentação e a camada de negócios, sua função como já diz é controlar coordenar o envio de requisições feitas entre a visão e o modelo. O controller define o comportamento da aplicação,o controle é quem interpreta as solicitações (cliques, seleções de menus) feitas por usuários com bases nestes requerimentos o controlador comunica-se com o modelo que seleciona a view e atualiza-a para o usuário, ou seja, o controlador controla e mapeia as ações.
          Embora o MVC só contenha três camadas há outra camada fundamental para o bom andamento da arquitetura, esta é um mecanismo de eventos necessário a comunicação entre outros três elementos, este elemento permite uma comunicação assíncrona que é invocada quando algum evento interessante acontece, esta quarta camada contém os beans de entidade onde se localizam os métodos get e set das classes.
5. Design Patterns aplicados na arquitetura MVC
A arquitetura MVC utiliza padrões de projetos em suas camadas analisamos a arquitetura agora com os patterns.
O MVC usa outros padrões de projeto, tais como Factory Method, para especificar por falta (by default) a classe controladora para uma vista e Decarator, para acrescentar capacidade de rolagem (scrolling) a uma vista. Mais os principais relacionamentos do MVC são fornecidos pelos padrões Observer, Composite, Strategy. (GAMMA et al. , 2000, p. 22)
          Os designs patterns nos ajuda á explicar a arquitetura MVC, e com eles podemos perceber que por traz do MVC pode conter um conjunto de padrões trabalhando juntos em uma mesma estrutura. Abordamos agora os patterns Observer e Strategy que são padrões comportamentais e o Composite padrão estrutural, o objetivo de abordar os patterns é para facilitar a compreensão de como a arquitetura MVC trabalha, sabendo que é um padrão de arquitetural que confundem projetistas e desenvolvedores.
          Nas palavras de Gamma et al. os principais padrões que o MVC utiliza são os Observer, Composite e o Strategy. Analisemos a Figura 3 do livro de Padrões de Projetos dos autores Freeman & Freeman que nos ajudará a explicar como os padrões contribuem na arquitetura MVC:
          A visualização ou a View juntamente com o padrão Composite está á disposição do usuário esperando por qualquer evento, quando este evento é ativado o controlador é avisado sobre o evento, este avisa para a visão se atualizar, e ao mesmo tempo manda o modelo para que ele atue para contemplar o evento provocado pelo usuário, depois de atuado o modelo fica pronto para ser acessada pela visualização esta por sua vez acessa e atualiza-se para o usuário assim funciona a arquitetura MVC em conjunto com os padrões de projetos.
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 actualmente, o Netbeans torna-se um excelente IDE para desenvolvimento.