Pós Ruy - Dinâmica dos Casos Reais

725 views
669 views

Published on

Casos utilizados na dinâmica dos Problemas Reais da aula na faculdade Ruy Barbosa do curso de Componentes Web da disciplina Componentes de Software e Aplicações Web : 2 e 3 camadas.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
725
On SlideShare
0
From Embeds
0
Number of Embeds
194
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pós Ruy - Dinâmica dos Casos Reais

  1. 1. Caso 1 – Bom dia por quê?Vocês são funcionários de uma empresa de desenvolvimento de software, alocados em diferentesprojetos nos diversos clientes. Um belo dia cada um de vocês foi convidado para participar deuma reunião emergencial após o expediente, convocada pelo diretor de desenvolvimento a pedidode uma de suas equipes.A equipe do projeto estava desenvolvendo um software e algumas funcionalidades já estavam emuso em ambiente de produção. Tratava-se de uma aplicação para um famoso teatro que tinhacomo objetivo automatizar os pontos de venda de ingressos e gerenciamento das apresentações.Sempre que havia uma atração famosa o sistema de vendas aleatoriamente travava. Era precisoreiniciar o servidor para que tudo voltasse ao normal. O servidor estava hospedado em outraempresa, o que dificultava o restabelecimento do serviço. O teatro não tinha interesse nenhum emtrazer os servidores para dentro de casa, até mesmo porque todos indícios apontavam a aplicação– e não a infraestrutura – como o bicho-papão causador de problemas.Na reunião, a equipe de desenvolvimento afirmou que a aplicação estava utilizando a arquiteturaclássica de 3 camadas (apresentação, negócio e persistência), sendo que havia duasapresentações: uma web, para as atividades administrativas; e uma outra que provia serviçosremotos acessados pelos pontos de venda para sincronização dos mapas das poltronas do teatro.Segundo a equipe, o travamento só ocorre com as funcionalidades referentes à sincronização dosmapas. O sistema não possuía casos de testes automatizados, a validação do sistema foi feitapelo próprio usuário. Como o usuário não consegue simular os momentos de pico, esta falha dosistema não foi detectada e nem consegue ser reproduzida em ambiente de homologação.Um pequeno detalhe, o prazo para entrega do sistema já era piada de mal gosto, o projeto jáestava dando prejuízo, o cliente estava puto da vida com aquela novela e o presidente daempresa decepcionado com a equipe do projeto. A equipe já tinha tentado de tudo, mas de nadaadiantou. Só resta agora passar a batata quente.Para isso uma nova equipe foi criada, e vocês – participantes desta reunião – faziam parte dela.Vocês não tiveram escolha, já era! E agora Josés, como arquitetos do BOPE, quais medidasvocês tomariam para resolver esse perrengue?
  2. 2. Caso 2 – Isso é um Single Sign-On?Um dia as coisas mudaram, a diretoria de sua empresa mudou. O mais novo diretor recebeu aincumbência de reativar a Fábrica de Software da empresa e contratou vocês como equipeespecializada de arquitetos para resolver um problema recorrente em toda organização: o controlede acesso das aplicações.Todas as aplicações produzidas pela Fábrica de Software necessitavam de um módulo desegurança, responsável por garantir a autenticação e o acesso seguro às funcionalidades de cadasistema. Na antiga fábrica, este módulo era reconstruído para cada aplicação. Mas se tinha umacoisa que o novo diretor não queria era retrabalho desnecessário.A antiga fábrica teve sérios problemas com descumprimento de prazos e de altos custos comretrabalho. Para o presidente da empresa a impressão que ficou foi: vender software é prejuízocerto. Graças a novas oportunidades de negócios no mercado local, surgiu a oportunidade detentar de novamente. O novo diretor foi contrato para fazer dar certo desta vez e não podiadecepcionar.Após diversas reuniões entre vocês e o novo diretor, foi identificado que o problema do controle deacesso não era exclusividade da Fábrica de Software. Estava aí uma oportunidade de matar doiscoelhos com uma cajadada só: reduzir o custo da fábrica e também dos sistemas internos daempresa. Isso sim seria um ótimo cartão de visitas.Percebeu-se que cada sistema da empresa – construídos com as mais diversas tecnologias –possuía uma base de segurança diferente. Olha só que coincidência, todos os sistemas foramfeitos pela antiga fábrica. Se tem algo de bom nisso é que vocês possuem acesso ao código-fontee podem modificar o que quiserem. Com base em levantamentos, vocês identificaram que a basede dados da empresa era LDAP, mas cada cliente da fábrica poderia ter outra, desde banco dedados até simples arquivos de texto.Sob a perspectiva de arquitetura de software, como vocês resolveriam este desafio?
  3. 3. Caso 3 – Couve-flor não, é Workflow!Almoço no shopping, equipe reunida. De repente um dos diretores da empresa, por coincidência,encontra todo mundo reunido e fala: “surgiu um projeto novo que é a cara de vocês”. A primeiracoisa que vocês pensaram, mas ninguém pronunciou, foi: “lá vem bomba”. Era um sistema paracontrole de fluxos de trabalho, utilizando uma tecnologia específica que demandava bastantededicação em pesquisas. Como era desafiador, vocês toparam!Basicamente o objetivo do projeto era construir uma aplicação Web que reunisse a administraçãodos fluxos de trabalho gerenciados por um motor de Workflow, mas não era só isso. A primeiraatividade que vocês se dedicaram foi meter a cara nos livros para descobrir que diabo faz talmotor. E descobriram! Aprenderam que um motor de Workflow processa fluxos cadastrados e queem determinados momentos delegam atividades para programas externos. O início de um fluxotambém pode ser disparado por um programa externo.Se o motor já faz tudo, para que serve este projeto? Por dois motivos básicos. O primeiro é que astelas Web providas pelo fabricante do motor para interagir com os fluxos é bizarra, altamentetoscas, complicadas de usar e completamente inviáveis para o usuário final. O segundo é que omotor precisa delegar atividades que ele não sabe fazer, tais como: acessar sistemas da empresa,buscar documentos na intranet e enviar mensagens para celular. Toda interação com o motor seocorre via WebServices, seja ela de entrada (motivo 1) ou de saída (motivo 2).Como vocês – arquitetos de renome – projetariam esta aplicação que interage com o motor doWorkflow, com o usuário final e com os dados da organização? Como dizia Edson Gomes: “estesistema é um vampiro, ô ô ôô”.
  4. 4. Caso 4 – Era uma vez uma aplicação que nunca ficava pronta...Era uma vez um projeto que nunca ficava pronto. Por ironia do destino (ou não), apelaram para aequipe de arquitetos da empresa e vocês foram escolhidos para para descascar o abacaxi. Oturnover do projeto estava alto, a equipe era composta por novatos e apenas um remanescentedos primórdios do projeto.Tratava-se de um sistema para apoiar atividades de fiscalização de estabelecimentos comerciais.Os agentes levariam consigo um tablet que rodaria a dita cuja aplicação que nunca ficava pronta.O gerente do projeto estava desesperado e relatou que cada tentativa de corrigir um problema,outro pior aparecia. Sabe quando você puxa o lençol curto para cobrir a cabeça e descobre os pése vice-versa? Era isso que acontecia.Vocês iniciaram os trabalhos fazendo a verificação da arquitetura e inspeção do código-fonte.Segundo o antigo membro da equipe, a aplicação seguia o modelo de 3 camadas, onde aapresentação utilizava a biblioteca de telas padrão do tablet e a camada de persistência utilizavauma tecnologia simples de armazenamento.Após muito penar, vocês descobriram que as camadas não seguiam as regras básicas. A camadade negócio fazia referência às telas e aos objetos de acesso aos dados, as telas acessavam acamada de persistência diretamente, pulando a camada de negócio. Ou seja, tava uma tremendatosqueira, pouca coisa estava como manda o figurino.Vocês propuseram refazer a aplicação por completo, mas o gerente do projeto disse: “nempensar”. O prazo do projeto já havia estourado e o cliente deu o ultimato. Se falhar desta vez, oprojeto será cancelado com aplicação de multas exorbitantes.A aplicação além de apresentar crash difíceis de rastrear, o processo de sincronização entre otablet e o servidor (na Internet) estava mais perdido do que cachorro que cai de caminhão demudança. A sincronização simplesmente não funcionava e essa era a principal preocupação docliente.A solução era corrigir o que estava errado, que era praticamente tudo. Mas como fazer isso semassumir que iria jogar a aplicação fora e fazer outra? Use a criatividade pois o cliente colocou umarquiteto da equipe dele para acompanhar o trabalho. Boa sorte!

×