SlideShare uma empresa Scribd logo
SUMÁRIO
INTRODUÇÃO..............................................................................................................3
OBJETIVO.....................................................................................................................4
DESENVOLVIMENTO...................................................................................................5
Capitulo 11 (Projeto de Arquitetura)..............................................................................6
Capitulo 12 (Arquitetura de Sistemas distribuídos).......................................................9
Capitulo 13 (Arquitetura de aplicações). ....................................................................14
Capitulo 29 (Gerenciamento de Configurações). .......................................................16
OBS: Clique com o botão direito sobre o sumario, e selecione atualizar campo.
(Em caso de você fazer alterações).
E se perguntar clique atualizar somente numero das paginas.
INTRODUÇÃO
O trabalho sobre a empresa China Telecom nos leva a compreender
e analisar a demanda de recursos presentes nas empresas e que são de total
importância para um correto funcionamento e desempenho como pessoas
especialistas, hardwares e softwares, fornecedores, viagens, entre outros).
Devemos entender e analisar o que se incorpora melhor em seu
planejamento, citando como exemplo o PMBKO que é um guia Project Management
Body of Knowledge ou simplesmente Guia PMBOK. Um conjunto de práticas na
gestão de projetos organizado pelo instituto PMI e que é considerado a base do
conhecimento sobre gestão de projetos por profissionais da área.
3
OBJETIVO
Com a realização deste portfolio teremos o objetivo de aprofundar o
conhecimento já adquirido durante o curso através de pesquisas no qual será
abortado pontos importantes para compreender a sua melhor colocação sobre o
tema proposto.
4
DESENVOLVIMENTO
O PMBOK® Guide não é uma metodologia, pois não distingue os
diferentes tipos de projeto (certamente gerenciar projetos administrativos é
totalmente diferente de gerenciar projetos de construção pesada).
Não utiliza peculiaridades de linguagem que respeitem a cultura de
diferentes tipos de empresas e não apresenta modelos específicos de documentos a
serem preenchidos.
Resumidamente podemos chamar de manual que descreve o
universo de conhecimentos para o Gerenciamento de Projetos. Transformou-se em
um padrão á fonte de inspiração para quase todas as metodologias existentes.
1.1 ENGENHARIA E PROJETO DE SOFTWARE
Vamos entender melhor sobre engenharia e projetos de
desenvolvimento de um software. Para isso vamos ver o guia Project Management
Body of Knowledge ou simplesmente Guia PMBOK.
O Guia PMBOK é um conjunto de práticas na gestão de projetos
organizados pelo instituto PMI e é considerado a base do conhecimento sobre
gestão de projetos por profissionais da área.
Devemos ter cuidado no escopo do projeto, mantendo foco no
projeto que foi passado. Para que assim não ocorra erros no projeto, analisando o
que será feito, como vai funcionar, qual o tipo de usuário, deve-se verificar as
documentações, preocupando-se em não acrescentar nada além do que o projeto
está pedindo.
Algumas expressões:
"Metodologia: Um sistema de práticas, técnicas, procedimentos e
regras usado pelas pessoas que trabalham em uma disciplina."
"Metodologia de gerenciamento de projetos define um processo, que
auxilia uma equipe de gerenciamento de projetos no desenvolvimento e controle das
mudanças do plano de gerenciamento do projeto".
Esta expressão está constantemente mencionada nos processos de
Integração (capítulo 4), cada organização poderá ter um próprio processo.
5
O PMBOK torna um projeto melhor estruturado e atende as
demandas de forma eficiente, tendo um conjunto de práticas na construção de um
software.
Riscos: O risco aqui é de um projeto de conjuntos de condições
onde pode ocorrer em forma de oportunidades negativas ou positivas.
Escopo: O gerenciamento do escopo do projeto é responsável por
realizar o projeto com sucesso, tendo um planejamento criado de um processo plano
de gerenciamento de escopo.
Aplicações de conhecimento, habilidades, ferramentas e suas
técnicas nas atividades de um projeto com finalidade de alcançar um objetivo
somente é atingido através do uso de processos e fases.
Agora supondo que a empresa china telecom optasse em
desenvolvimento próprio, vamos ler uma resenha do livro Engenharia de Software, de
Ian Sommerville: Temos então os Capitulos 11, 12, 13 e 29.
Capitulo 11 (Projeto de Arquitetura).
6
O projeto de arquitetura é primeiro estagio no processo de projetos.
No livro diz que ele idêntica subsistemas e estabelece um framework
para controlar a comunicação dos subsistemas, 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, Analise de sistemas, Reuso
em larga escala:
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.
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 requisito crítico, a arquitetura
de sistemas deve ser projetada usando componentes de baixa granularidade e auto
contidos que possam ser prontamente mudados.
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 comunicaçã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.
Um modelo estático de estrutura que mostra os subsistemas ou
componentes desenvolvidos como unidades separadas.
7
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
estruturá-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 do subsistema.
Em um 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.
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 integrá-lo ao
restante do sistema.
O modelo em camadas organiza um sistema em camadas, cada
uma das quais fornecendo um conjunto de serviços.
A abordagem em camadas apóia 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.
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.
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.
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
8
uma para outra função e são transformados ao moverem – se seqüencialmente.
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.
Vantagens: Apoiar o reuso de transformações.
Ele é intuitiva, pois muitas pessoas pensam em termos de
processamento de entrada e saída.
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.
Em modelo de controle centralizado, um subsistema é designado
como controlado de sistema e tem a responsabilidade pelo gerenciamento da
execução de outros subsistemas. Tendo duas classes, dependendo se forem
executados seqüencialmente ou paralelamente.
O modelo retorno 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 seqüenciais.
O modelo gerenciados, aplicados em modelos concorrentes.
Sistema concorrente projetado como um gerenciador de sistema e controla o inicio,
a parada e a coordenação de outros processos do sistema.
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.
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.
A finalidade dessa arquitetura de referencia é ser um meio de
classificação e comparação de ferramentas e ambientes CASE integrados.
Capitulo 12 (Arquitetura de Sistemas distribuídos).
9
Um sistema bem 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: Compartilhamento de recursos, Abertura, Concorrência, Escalabilidade,
Tolerância a defeitos.
Esses sistemas de distribuição comparados aos sistemas que operam com
um processador ou com um cluster de processadores podem ter algumas
desvantagens como: Complexidade, Proteção, Gerenciamento, Imprevisibilidade e
Defeitos que em uma maquina podem se propagar a outra maquinas com
conseqüências inesperadas.
Tipos diferentes de arquiteturas de sistemas distribuídos:
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.
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.
Arquitetura de multiprocessadores
O multiprocessador São processos que podem ser executados separados.
Esse modelo tomam 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
Arquiteturas de objetos distribuídos
10
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 requisitor 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.
CORBA
11
Existem quatro elementos principais desse padrão:
• Um modelo de objeto para objetos de aplicações.
• Um requisitor de objetos.
• Um conjunto de serviços de objetos.
• Um conjunto de componentes comum.
O Corba considera um objeto como se fosse um encapsula mento de
atributos e serviços, como é normal em objetos.
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.
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.
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.
12
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 estes padrões baseados em XML.
13
Capitulo 13 (Arquitetura de aplicações).
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 transações são projetados para processar solicitações de
informações por usuários de um banco de dados. Tecnicamente uma seqüência de
operações é tratada como uma unidade simples.
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.
14
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.
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.
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:
Um analisador léxico, uma tabela de símbolos, um analisador sintático, uma
árvore de sintaxe, um analisador semântico e um gerador de código.
15
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,
diferentes sistemas operacionais, incorporando funções especificas para 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.
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.
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.
Planos de projetos, especificações, projetos, programas, e massa de dados
de teste são normalmente mantidos como itens de configuração para o processo de
planejamento de gerenciamento de configuração, você decide exatamente quais
itens serão controlados.
Todos os documentos podem ser úteis para a evolução do sistema. O
esquema de identificação de itens de configuração deve atribuir um único nome para
todos os documentos sob controle de configuração. 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.
16
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. 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.
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.
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. 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.
17
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.
Uma das três técnicas básicas para identificação da versão de componentes
é 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.
"A versão de componente é identificada pelo conjunto de solicitações de
mudanças que se aplicam ao componente."
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.
Conseqüentemente, 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.
18
1.2 PROGRAMAÇÃO PARA WEB II
Frameworks, sejam elas escritas em PHP ou em qualquer outra
linguagem, oferecem ao programador um conjunto de códigos prontos que permitem
realizar as tarefas mais básicas no desenvolvimento de um aplicativo. Por oferecer
essa estrutura básica, os frameworks tornam o desenvolvimento mais rápido e
reduzem o volume de código repetitivo escrito pelo programador.
Os frameworks também ajudam aos programadores iniciantes a criar
aplicativos mais estáveis, mesmo que eles ainda não dominem completamente a
linguagem de programação e todas as outras tecnologias necessárias para fazer o
aplicativo funcionar.
1.2.1 Comparação de frameworks
Zend Framework é o framework mais famoso do momento. E
também não é pra menos, pois a criadora do framework (a Zend) é a mesma
empresa que mantém o desenvolvimento do PHP. É rico em funcionalidades e é
também o mais rápido. Infelizmente, todo esse poder faz com que esta ferramenta
torne-se muito grande, mas não funciona com o PHP 4.
É um framework para quem deseja construir grandes aplicações.
Além de possuir uma documentação extensa e diversas publicações relacionadas,
existem diversos programadores sérios que testam exaustivamente todos os códigos
que são desenvolvidos antes de liberar para produção.
Symfony um dos frameworks mais poderosos e é muito bem
dividido. Todas as tarefas são modulares e o framework utiliza diferentes camadas
para manejar os dados. É bastante útil para projetos com necessidades de grandes
funcionalidades. Contudo, de todas as opções citadas, é o mais lento de todos.
19
1.2.2 Relacione custo de frameworks
• Melhora a modularização – encapsula mento 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.
É esperado que o framework funcione como uma constituição, definindo, na
seara da regulação, os princípios gerais para o desenvolvimento de padrões
contábeis e o conteúdo informacional dos relatórios, na seara dos usuários da
informação. Para alcançar esse propósito, o framework deve ser constante por longo
período e deve formular as regras gerais que constituem o cerne dos relatórios.
O framework tem como principal função ser suporte e guia para a adoção e o
aprimoramento da informação de custos no setor público, incluindo novas definições
ainda não explicitadas que venham a ser demandadas pelos usuários. Já no
momento do uso, a estrutura servirá de apoio aos usuários (órgãos de controle,
gestores, sociedade em geral etc.) das informações de custos na interpretação de
informações nelas contidas, preparadas em conformidade com os critérios básicos
definidos pelo patrocinador do sistema (no caso o Ministério da Fazenda).
Duas questões merecem destaque em termos de implantação da estrutura: o
aperfeiçoamento contínuo e a replicação do sistema (rollout). É de se esperar que o
framework seja revisado num prazo razoavelmente curto (digamos, cinco anos) com
base na experiência decorrente de sua utilização. Como o efeito do framework é
efetivo apenas após longo período de adoção da mesma (Christensen, 2009), as
contínuas revisões podem levar a uma redução da velocidade de institucionalização
do sistema.
20
1.2.3 Java Hivernate
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.
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.
1.3 PROJETO ORIENTADO A OBJETOS
Sendo assim para o problema da China Telecon, a melhor solução para esta
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.
Contando 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.
21
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.
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).
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
22
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.
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.
23

Mais conteúdo relacionado

Mais procurados

Metodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informaçãoMetodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informação
Jean Carlos
 
Manual de Modelagem de Processos em BPMN
Manual de Modelagem de Processos em BPMNManual de Modelagem de Processos em BPMN
Manual de Modelagem de Processos em BPMN
Farmanguinhos
 
Modelagem 21102006_2
Modelagem 21102006_2Modelagem 21102006_2
Modelagem 21102006_2
LEANDRO DE SOUZA RAMOS
 
Modelagem 21102006_1
Modelagem 21102006_1Modelagem 21102006_1
Modelagem 21102006_1
LEANDRO DE SOUZA RAMOS
 
Analise sistemas 02
Analise sistemas 02Analise sistemas 02
Analise sistemas 02
Caroline Raquel Rodrigues
 
modelagem sistema da informação Unid 4
modelagem sistema da informação Unid 4modelagem sistema da informação Unid 4
modelagem sistema da informação Unid 4
spawally
 
Aula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasAula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de Sistemas
Gustavo Gonzalez
 
Workflow, Business Intelligence e Ferramentas Colaborativas
Workflow, Business Intelligence e Ferramentas ColaborativasWorkflow, Business Intelligence e Ferramentas Colaborativas
Workflow, Business Intelligence e Ferramentas Colaborativas
igorc2
 
Microsoft solutions framework
Microsoft solutions frameworkMicrosoft solutions framework
Microsoft solutions framework
Albert José
 
Do Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use CaseDo Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use Case
Robson Silva Espig
 
Naked Objects
Naked ObjectsNaked Objects
Naked Objects
elliando dias
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
Guilherme
 
FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010
nathan85
 
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Messias Batista
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
armeniocardoso
 
Aps lista de exercícios
Aps lista de exercíciosAps lista de exercícios
Aps lista de exercícios
Guilherme
 
Modelagem de Sistemas de Informação 07
Modelagem de Sistemas de Informação 07Modelagem de Sistemas de Informação 07
Modelagem de Sistemas de Informação 07
Danielle Ballester, PMP,PSM,SFC,SDC,SMC,SPOC,SCT
 
Aula Qualidade - Fluxograma
Aula Qualidade - FluxogramaAula Qualidade - Fluxograma
Aula Qualidade - Fluxograma
Caio Roberto de Souza Filho
 
Teamcenter
TeamcenterTeamcenter
Teamcenter
Raihsa
 
Introdução a analise de sistemas i
Introdução a analise de sistemas iIntrodução a analise de sistemas i
Introdução a analise de sistemas i
Ray Fran Pires
 

Mais procurados (20)

Metodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informaçãoMetodologias de desenvolvimento de sistemas de informação
Metodologias de desenvolvimento de sistemas de informação
 
Manual de Modelagem de Processos em BPMN
Manual de Modelagem de Processos em BPMNManual de Modelagem de Processos em BPMN
Manual de Modelagem de Processos em BPMN
 
Modelagem 21102006_2
Modelagem 21102006_2Modelagem 21102006_2
Modelagem 21102006_2
 
Modelagem 21102006_1
Modelagem 21102006_1Modelagem 21102006_1
Modelagem 21102006_1
 
Analise sistemas 02
Analise sistemas 02Analise sistemas 02
Analise sistemas 02
 
modelagem sistema da informação Unid 4
modelagem sistema da informação Unid 4modelagem sistema da informação Unid 4
modelagem sistema da informação Unid 4
 
Aula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de SistemasAula1 e aula2 - Analise e Projeto de Sistemas
Aula1 e aula2 - Analise e Projeto de Sistemas
 
Workflow, Business Intelligence e Ferramentas Colaborativas
Workflow, Business Intelligence e Ferramentas ColaborativasWorkflow, Business Intelligence e Ferramentas Colaborativas
Workflow, Business Intelligence e Ferramentas Colaborativas
 
Microsoft solutions framework
Microsoft solutions frameworkMicrosoft solutions framework
Microsoft solutions framework
 
Do Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use CaseDo Diagrama de Fluxo de Dados ao Use Case
Do Diagrama de Fluxo de Dados ao Use Case
 
Naked Objects
Naked ObjectsNaked Objects
Naked Objects
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010FEI - Modelagem de negocios - 2° semestre 2010
FEI - Modelagem de negocios - 2° semestre 2010
 
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
Aula07 - Sistemas Distribuídos - Aula de Revisão da NP1
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
 
Aps lista de exercícios
Aps lista de exercíciosAps lista de exercícios
Aps lista de exercícios
 
Modelagem de Sistemas de Informação 07
Modelagem de Sistemas de Informação 07Modelagem de Sistemas de Informação 07
Modelagem de Sistemas de Informação 07
 
Aula Qualidade - Fluxograma
Aula Qualidade - FluxogramaAula Qualidade - Fluxograma
Aula Qualidade - Fluxograma
 
Teamcenter
TeamcenterTeamcenter
Teamcenter
 
Introdução a analise de sistemas i
Introdução a analise de sistemas iIntrodução a analise de sistemas i
Introdução a analise de sistemas i
 

Destaque

Presentation_DAI
Presentation_DAIPresentation_DAI
Presentation_DAI
Bandeep Singh
 
Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012
Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012
Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012
Erika Zuza
 
Industrial Ppt
Industrial PptIndustrial Ppt
Industrial Ppt
Bandeep Singh
 
Alen philip sachin tendulkar
Alen philip   sachin tendulkarAlen philip   sachin tendulkar
Alen philip sachin tendulkar
Alen philip
 
Daybreak Everywhere: Chapter IV
Daybreak Everywhere:  Chapter IVDaybreak Everywhere:  Chapter IV
Daybreak Everywhere: Chapter IVcrlupi810
 
Proyecto curso alumnas cuarto semestre ENFEMEC
Proyecto curso alumnas cuarto semestre ENFEMECProyecto curso alumnas cuarto semestre ENFEMEC
Proyecto curso alumnas cuarto semestre ENFEMEC
kimberlymildred
 
Presentación3
Presentación3Presentación3
Presentación3
danijuve34
 
Proyecto linea
Proyecto lineaProyecto linea
Proyecto linea
Ronald Campos Castillo
 
Cube srl - Engineering Consulting
Cube srl - Engineering ConsultingCube srl - Engineering Consulting
Cube srl - Engineering Consulting
Stefano Rossi
 
Ouri
OuriOuri
Metodologías de enseñanza
Metodologías de enseñanzaMetodologías de enseñanza
Metodologías de enseñanza
orientacionderechoalciudadano
 
Excel features
Excel featuresExcel features
Excel features
Alen philip
 
Chapter 4 forms of a business organisation
Chapter 4   forms of a business organisationChapter 4   forms of a business organisation
Chapter 4 forms of a business organisation
yash gupta
 

Destaque (16)

Presentation_DAI
Presentation_DAIPresentation_DAI
Presentation_DAI
 
Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012
Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012
Palestra FATERN aula_inaugural_pós_mídias_sociais_Profa_Erika_Zuza_27.04.2012
 
Examen
ExamenExamen
Examen
 
El tennis
El tennisEl tennis
El tennis
 
Industrial Ppt
Industrial PptIndustrial Ppt
Industrial Ppt
 
Alen philip sachin tendulkar
Alen philip   sachin tendulkarAlen philip   sachin tendulkar
Alen philip sachin tendulkar
 
Susana
SusanaSusana
Susana
 
Daybreak Everywhere: Chapter IV
Daybreak Everywhere:  Chapter IVDaybreak Everywhere:  Chapter IV
Daybreak Everywhere: Chapter IV
 
Proyecto curso alumnas cuarto semestre ENFEMEC
Proyecto curso alumnas cuarto semestre ENFEMECProyecto curso alumnas cuarto semestre ENFEMEC
Proyecto curso alumnas cuarto semestre ENFEMEC
 
Presentación3
Presentación3Presentación3
Presentación3
 
Proyecto linea
Proyecto lineaProyecto linea
Proyecto linea
 
Cube srl - Engineering Consulting
Cube srl - Engineering ConsultingCube srl - Engineering Consulting
Cube srl - Engineering Consulting
 
Ouri
OuriOuri
Ouri
 
Metodologías de enseñanza
Metodologías de enseñanzaMetodologías de enseñanza
Metodologías de enseñanza
 
Excel features
Excel featuresExcel features
Excel features
 
Chapter 4 forms of a business organisation
Chapter 4   forms of a business organisationChapter 4   forms of a business organisation
Chapter 4 forms of a business organisation
 

Semelhante a Trabalho individual

O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
Athena542429
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
Priscila Stuani
 
Desenvolvimento de softwares/sistemas
Desenvolvimento de softwares/sistemasDesenvolvimento de softwares/sistemas
Desenvolvimento de softwares/sistemas
Geraldo Munguambe
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
Nécio de Lima Veras
 
Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
Halan Ridolphi
 
Processos de software
Processos de softwareProcessos de software
Processos de software
Dann Volpato
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Processos de software
Processos de softwareProcessos de software
Processos de software
Computação Depressão
 
aula7 software ciclo de vida analise req
aula7 software ciclo de vida analise reqaula7 software ciclo de vida analise req
aula7 software ciclo de vida analise req
patriciaalipiosilva
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
Carlos Henrique Martins da Silva
 
Aula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptxAula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptx
AlexandreLisboadaSil
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
Nécio de Lima Veras
 
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Lucas Furtado de Oliveira
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
Robson Silva Espig
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Luiz Costa
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Fernando Palma
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
Caroline Raquel Rodrigues
 
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
Deep Tech Brasil
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
Fco Edilson Nascimento
 
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídosAula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Messias Batista
 

Semelhante a Trabalho individual (20)

O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
 
Desenvolvimento de softwares/sistemas
Desenvolvimento de softwares/sistemasDesenvolvimento de softwares/sistemas
Desenvolvimento de softwares/sistemas
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
aula7 software ciclo de vida analise req
aula7 software ciclo de vida analise reqaula7 software ciclo de vida analise req
aula7 software ciclo de vida analise req
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Aula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptxAula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptx
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
Entendendo a Tríade Model-View-Controller (MVC) Utilizando Padrões de Projeto...
 
Analise de Requisitos de Software
Analise de Requisitos de SoftwareAnalise de Requisitos de Software
Analise de Requisitos de Software
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
 
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
 
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídosAula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
 

Último

A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...
ANDRÉA FERREIRA
 
AUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃO
AUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃOAUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃO
AUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃO
FernandaOliveira758273
 
UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...
UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...
UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...
Manuais Formação
 
planejamento maternal 2 atualizado.pdf e
planejamento maternal 2 atualizado.pdf eplanejamento maternal 2 atualizado.pdf e
planejamento maternal 2 atualizado.pdf e
HelenStefany
 
7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx
7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx
7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx
alphabarros2
 
Slides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptx
Slides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptxSlides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptx
Slides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptx
LuizHenriquedeAlmeid6
 
Aula 02 - Introducao a Algoritmos.pptx.pdf
Aula 02 - Introducao a Algoritmos.pptx.pdfAula 02 - Introducao a Algoritmos.pptx.pdf
Aula 02 - Introducao a Algoritmos.pptx.pdf
AntonioAngeloNeves
 
filosofia e Direito- É a teoria que explica como a sociedade se organizou co...
filosofia e Direito- É a teoria que explica como a sociedade se organizou  co...filosofia e Direito- É a teoria que explica como a sociedade se organizou  co...
filosofia e Direito- É a teoria que explica como a sociedade se organizou co...
SidneySilva523387
 
PALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇO
PALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇOPALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇO
PALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇO
ARIADNEMARTINSDACRUZ
 
Roteiro para análise do Livro Didático.pptx
Roteiro para análise do Livro Didático.pptxRoteiro para análise do Livro Didático.pptx
Roteiro para análise do Livro Didático.pptx
pamellaaraujo10
 
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdfO Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
silvamelosilva300
 
Slides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptx
Slides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptxSlides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptx
Slides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptx
LuizHenriquedeAlmeid6
 
REGULAMENTO DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...
REGULAMENTO  DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...REGULAMENTO  DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...
REGULAMENTO DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...
Eró Cunha
 
Planejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTAL
Planejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTALPlanejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTAL
Planejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTAL
katbrochier1
 
Psicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptx
Psicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptxPsicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptx
Psicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptx
TiagoLouro8
 
As sequências didáticas: práticas educativas
As sequências didáticas: práticas educativasAs sequências didáticas: práticas educativas
As sequências didáticas: práticas educativas
rloureiro1
 
FUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.ppt
FUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.pptFUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.ppt
FUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.ppt
MarceloMonteiro213738
 
UFCD_10789_Metodologias de desenvolvimento de software_índice.pdf
UFCD_10789_Metodologias de desenvolvimento de software_índice.pdfUFCD_10789_Metodologias de desenvolvimento de software_índice.pdf
UFCD_10789_Metodologias de desenvolvimento de software_índice.pdf
Manuais Formação
 
A Núbia e o Reino De Cuxe- 6º ano....ppt
A Núbia e o Reino De Cuxe- 6º ano....pptA Núbia e o Reino De Cuxe- 6º ano....ppt
A Núbia e o Reino De Cuxe- 6º ano....ppt
WilianeBarbosa2
 
Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...
Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...
Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...
samucajaime015
 

Último (20)

A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...A festa junina é uma tradicional festividade popular que acontece durante o m...
A festa junina é uma tradicional festividade popular que acontece durante o m...
 
AUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃO
AUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃOAUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃO
AUTISMO LEGAL - DIREITOS DOS AUTISTAS- LEGISLAÇÃO
 
UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...
UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...
UFCD_7211_Os sistemas do corpo humano_ imunitário, circulatório, respiratório...
 
planejamento maternal 2 atualizado.pdf e
planejamento maternal 2 atualizado.pdf eplanejamento maternal 2 atualizado.pdf e
planejamento maternal 2 atualizado.pdf e
 
7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx
7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx
7 ano - Rede e hierarquia urbana - Geografia - Alpha.pptx
 
Slides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptx
Slides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptxSlides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptx
Slides Lição 12, Central Gospel, O Milênio, 1Tr24, Pr Henrique.pptx
 
Aula 02 - Introducao a Algoritmos.pptx.pdf
Aula 02 - Introducao a Algoritmos.pptx.pdfAula 02 - Introducao a Algoritmos.pptx.pdf
Aula 02 - Introducao a Algoritmos.pptx.pdf
 
filosofia e Direito- É a teoria que explica como a sociedade se organizou co...
filosofia e Direito- É a teoria que explica como a sociedade se organizou  co...filosofia e Direito- É a teoria que explica como a sociedade se organizou  co...
filosofia e Direito- É a teoria que explica como a sociedade se organizou co...
 
PALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇO
PALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇOPALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇO
PALAVRA SECRETA - ALFABETIZAÇÃO- REFORÇO
 
Roteiro para análise do Livro Didático.pptx
Roteiro para análise do Livro Didático.pptxRoteiro para análise do Livro Didático.pptx
Roteiro para análise do Livro Didático.pptx
 
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdfO Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
O Mito da Caverna de Platão_ Uma Jornada em Busca da Verdade.pdf
 
Slides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptx
Slides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptxSlides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptx
Slides Lição 12, CPAD, A Bendita Esperança, A Marca do Cristão, 2Tr24.pptx
 
REGULAMENTO DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...
REGULAMENTO  DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...REGULAMENTO  DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...
REGULAMENTO DO CONCURSO DESENHOS AFRO/2024 - 14ª edição - CEIRI /UREI (ficha...
 
Planejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTAL
Planejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTALPlanejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTAL
Planejamento BNCC - 4 ANO -TRIMESTRAL - ENSINO FUNDAMENTAL
 
Psicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptx
Psicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptxPsicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptx
Psicologia e Sociologia - Módulo 2 – Sociedade e indivíduo.pptx
 
As sequências didáticas: práticas educativas
As sequências didáticas: práticas educativasAs sequências didáticas: práticas educativas
As sequências didáticas: práticas educativas
 
FUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.ppt
FUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.pptFUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.ppt
FUNCAO EQUAÇÃO DO 2° GRAU SLIDES AULA 1.ppt
 
UFCD_10789_Metodologias de desenvolvimento de software_índice.pdf
UFCD_10789_Metodologias de desenvolvimento de software_índice.pdfUFCD_10789_Metodologias de desenvolvimento de software_índice.pdf
UFCD_10789_Metodologias de desenvolvimento de software_índice.pdf
 
A Núbia e o Reino De Cuxe- 6º ano....ppt
A Núbia e o Reino De Cuxe- 6º ano....pptA Núbia e o Reino De Cuxe- 6º ano....ppt
A Núbia e o Reino De Cuxe- 6º ano....ppt
 
Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...
Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...
Aula de fundamentos de Programação Orientada a Objeto na linguagem de program...
 

Trabalho individual

  • 1. SUMÁRIO INTRODUÇÃO..............................................................................................................3 OBJETIVO.....................................................................................................................4 DESENVOLVIMENTO...................................................................................................5 Capitulo 11 (Projeto de Arquitetura)..............................................................................6 Capitulo 12 (Arquitetura de Sistemas distribuídos).......................................................9 Capitulo 13 (Arquitetura de aplicações). ....................................................................14 Capitulo 29 (Gerenciamento de Configurações). .......................................................16 OBS: Clique com o botão direito sobre o sumario, e selecione atualizar campo. (Em caso de você fazer alterações). E se perguntar clique atualizar somente numero das paginas.
  • 2. INTRODUÇÃO O trabalho sobre a empresa China Telecom nos leva a compreender e analisar a demanda de recursos presentes nas empresas e que são de total importância para um correto funcionamento e desempenho como pessoas especialistas, hardwares e softwares, fornecedores, viagens, entre outros). Devemos entender e analisar o que se incorpora melhor em seu planejamento, citando como exemplo o PMBKO que é um guia Project Management Body of Knowledge ou simplesmente Guia PMBOK. Um conjunto de práticas na gestão de projetos organizado pelo instituto PMI e que é considerado a base do conhecimento sobre gestão de projetos por profissionais da área. 3
  • 3. OBJETIVO Com a realização deste portfolio teremos o objetivo de aprofundar o conhecimento já adquirido durante o curso através de pesquisas no qual será abortado pontos importantes para compreender a sua melhor colocação sobre o tema proposto. 4
  • 4. DESENVOLVIMENTO O PMBOK® Guide não é uma metodologia, pois não distingue os diferentes tipos de projeto (certamente gerenciar projetos administrativos é totalmente diferente de gerenciar projetos de construção pesada). Não utiliza peculiaridades de linguagem que respeitem a cultura de diferentes tipos de empresas e não apresenta modelos específicos de documentos a serem preenchidos. Resumidamente podemos chamar de manual que descreve o universo de conhecimentos para o Gerenciamento de Projetos. Transformou-se em um padrão á fonte de inspiração para quase todas as metodologias existentes. 1.1 ENGENHARIA E PROJETO DE SOFTWARE Vamos entender melhor sobre engenharia e projetos de desenvolvimento de um software. Para isso vamos ver o guia Project Management Body of Knowledge ou simplesmente Guia PMBOK. O Guia PMBOK é um conjunto de práticas na gestão de projetos organizados pelo instituto PMI e é considerado a base do conhecimento sobre gestão de projetos por profissionais da área. Devemos ter cuidado no escopo do projeto, mantendo foco no projeto que foi passado. Para que assim não ocorra erros no projeto, analisando o que será feito, como vai funcionar, qual o tipo de usuário, deve-se verificar as documentações, preocupando-se em não acrescentar nada além do que o projeto está pedindo. Algumas expressões: "Metodologia: Um sistema de práticas, técnicas, procedimentos e regras usado pelas pessoas que trabalham em uma disciplina." "Metodologia de gerenciamento de projetos define um processo, que auxilia uma equipe de gerenciamento de projetos no desenvolvimento e controle das mudanças do plano de gerenciamento do projeto". Esta expressão está constantemente mencionada nos processos de Integração (capítulo 4), cada organização poderá ter um próprio processo. 5
  • 5. O PMBOK torna um projeto melhor estruturado e atende as demandas de forma eficiente, tendo um conjunto de práticas na construção de um software. Riscos: O risco aqui é de um projeto de conjuntos de condições onde pode ocorrer em forma de oportunidades negativas ou positivas. Escopo: O gerenciamento do escopo do projeto é responsável por realizar o projeto com sucesso, tendo um planejamento criado de um processo plano de gerenciamento de escopo. Aplicações de conhecimento, habilidades, ferramentas e suas técnicas nas atividades de um projeto com finalidade de alcançar um objetivo somente é atingido através do uso de processos e fases. Agora supondo que a empresa china telecom optasse em desenvolvimento próprio, vamos ler uma resenha do livro Engenharia de Software, de Ian Sommerville: Temos então os Capitulos 11, 12, 13 e 29. Capitulo 11 (Projeto de Arquitetura). 6
  • 6. O projeto de arquitetura é primeiro estagio no processo de projetos. No livro diz que ele idêntica subsistemas e estabelece um framework para controlar a comunicação dos subsistemas, 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, Analise de sistemas, Reuso em larga escala: 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. 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 requisito crítico, a arquitetura de sistemas deve ser projetada usando componentes de baixa granularidade e auto contidos que possam ser prontamente mudados. 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 comunicaçã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. Um modelo estático de estrutura que mostra os subsistemas ou componentes desenvolvidos como unidades separadas. 7
  • 7. 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 estruturá-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 do subsistema. Em um 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. 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 integrá-lo ao restante do sistema. O modelo em camadas organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de serviços. A abordagem em camadas apóia 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. 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. 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. 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 8
  • 8. uma para outra função e são transformados ao moverem – se seqüencialmente. 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. Vantagens: Apoiar o reuso de transformações. Ele é intuitiva, pois muitas pessoas pensam em termos de processamento de entrada e saída. 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. Em modelo de controle centralizado, um subsistema é designado como controlado de sistema e tem a responsabilidade pelo gerenciamento da execução de outros subsistemas. Tendo duas classes, dependendo se forem executados seqüencialmente ou paralelamente. O modelo retorno 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 seqüenciais. O modelo gerenciados, aplicados em modelos concorrentes. Sistema concorrente projetado como um gerenciador de sistema e controla o inicio, a parada e a coordenação de outros processos do sistema. 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. 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. A finalidade dessa arquitetura de referencia é ser um meio de classificação e comparação de ferramentas e ambientes CASE integrados. Capitulo 12 (Arquitetura de Sistemas distribuídos). 9
  • 9. Um sistema bem 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: Compartilhamento de recursos, Abertura, Concorrência, Escalabilidade, Tolerância a defeitos. Esses sistemas de distribuição comparados aos sistemas que operam com um processador ou com um cluster de processadores podem ter algumas desvantagens como: Complexidade, Proteção, Gerenciamento, Imprevisibilidade e Defeitos que em uma maquina podem se propagar a outra maquinas com conseqüências inesperadas. Tipos diferentes de arquiteturas de sistemas distribuídos: 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. 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. Arquitetura de multiprocessadores O multiprocessador São processos que podem ser executados separados. Esse modelo tomam 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 Arquiteturas de objetos distribuídos 10
  • 10. 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 requisitor 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. CORBA 11
  • 11. Existem quatro elementos principais desse padrão: • Um modelo de objeto para objetos de aplicações. • Um requisitor de objetos. • Um conjunto de serviços de objetos. • Um conjunto de componentes comum. O Corba considera um objeto como se fosse um encapsula mento de atributos e serviços, como é normal em objetos. 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. 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. 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. 12
  • 12. 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 estes padrões baseados em XML. 13
  • 13. Capitulo 13 (Arquitetura de aplicações). 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 transações são projetados para processar solicitações de informações por usuários de um banco de dados. Tecnicamente uma seqüência de operações é tratada como uma unidade simples. 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. 14
  • 14. 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. 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. 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: Um analisador léxico, uma tabela de símbolos, um analisador sintático, uma árvore de sintaxe, um analisador semântico e um gerador de código. 15
  • 15. 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, diferentes sistemas operacionais, incorporando funções especificas para 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. 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. 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. Planos de projetos, especificações, projetos, programas, e massa de dados de teste são normalmente mantidos como itens de configuração para o processo de planejamento de gerenciamento de configuração, você decide exatamente quais itens serão controlados. Todos os documentos podem ser úteis para a evolução do sistema. O esquema de identificação de itens de configuração deve atribuir um único nome para todos os documentos sob controle de configuração. 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. 16
  • 16. 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. 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. 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. 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. 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. 17
  • 17. 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. Uma das três técnicas básicas para identificação da versão de componentes é 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. "A versão de componente é identificada pelo conjunto de solicitações de mudanças que se aplicam ao componente." 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. Conseqüentemente, 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. 18
  • 18. 1.2 PROGRAMAÇÃO PARA WEB II Frameworks, sejam elas escritas em PHP ou em qualquer outra linguagem, oferecem ao programador um conjunto de códigos prontos que permitem realizar as tarefas mais básicas no desenvolvimento de um aplicativo. Por oferecer essa estrutura básica, os frameworks tornam o desenvolvimento mais rápido e reduzem o volume de código repetitivo escrito pelo programador. Os frameworks também ajudam aos programadores iniciantes a criar aplicativos mais estáveis, mesmo que eles ainda não dominem completamente a linguagem de programação e todas as outras tecnologias necessárias para fazer o aplicativo funcionar. 1.2.1 Comparação de frameworks Zend Framework é o framework mais famoso do momento. E também não é pra menos, pois a criadora do framework (a Zend) é a mesma empresa que mantém o desenvolvimento do PHP. É rico em funcionalidades e é também o mais rápido. Infelizmente, todo esse poder faz com que esta ferramenta torne-se muito grande, mas não funciona com o PHP 4. É um framework para quem deseja construir grandes aplicações. Além de possuir uma documentação extensa e diversas publicações relacionadas, existem diversos programadores sérios que testam exaustivamente todos os códigos que são desenvolvidos antes de liberar para produção. Symfony um dos frameworks mais poderosos e é muito bem dividido. Todas as tarefas são modulares e o framework utiliza diferentes camadas para manejar os dados. É bastante útil para projetos com necessidades de grandes funcionalidades. Contudo, de todas as opções citadas, é o mais lento de todos. 19
  • 19. 1.2.2 Relacione custo de frameworks • Melhora a modularização – encapsula mento 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. É esperado que o framework funcione como uma constituição, definindo, na seara da regulação, os princípios gerais para o desenvolvimento de padrões contábeis e o conteúdo informacional dos relatórios, na seara dos usuários da informação. Para alcançar esse propósito, o framework deve ser constante por longo período e deve formular as regras gerais que constituem o cerne dos relatórios. O framework tem como principal função ser suporte e guia para a adoção e o aprimoramento da informação de custos no setor público, incluindo novas definições ainda não explicitadas que venham a ser demandadas pelos usuários. Já no momento do uso, a estrutura servirá de apoio aos usuários (órgãos de controle, gestores, sociedade em geral etc.) das informações de custos na interpretação de informações nelas contidas, preparadas em conformidade com os critérios básicos definidos pelo patrocinador do sistema (no caso o Ministério da Fazenda). Duas questões merecem destaque em termos de implantação da estrutura: o aperfeiçoamento contínuo e a replicação do sistema (rollout). É de se esperar que o framework seja revisado num prazo razoavelmente curto (digamos, cinco anos) com base na experiência decorrente de sua utilização. Como o efeito do framework é efetivo apenas após longo período de adoção da mesma (Christensen, 2009), as contínuas revisões podem levar a uma redução da velocidade de institucionalização do sistema. 20
  • 20. 1.2.3 Java Hivernate 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. 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. 1.3 PROJETO ORIENTADO A OBJETOS Sendo assim para o problema da China Telecon, a melhor solução para esta 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. Contando 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. 21
  • 21. 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. 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). 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 22
  • 22. 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. 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. 23