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.

1. Caso 1 – Bom dia por quê?
Vocês são funcionários de uma empresa de desenvolvimento de software, alocados em diferentes
projetos nos diversos clientes. Um belo dia cada um de vocês foi convidado para participar de
uma reunião emergencial após o expediente, convocada pelo diretor de desenvolvimento a pedido
de uma de suas equipes.
A equipe do projeto estava desenvolvendo um software e algumas funcionalidades já estavam em
uso em ambiente de produção. Tratava-se de uma aplicação para um famoso teatro que tinha
como 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 preciso
reiniciar o servidor para que tudo voltasse ao normal. O servidor estava hospedado em outra
empresa, o que dificultava o restabelecimento do serviço. O teatro não tinha interesse nenhum em
trazer 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 arquitetura
clássica de 3 camadas (apresentação, negócio e persistência), sendo que havia duas
apresentações: uma web, para as atividades administrativas; e uma outra que provia serviços
remotos 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 dos
mapas. O sistema não possuía casos de testes automatizados, a validação do sistema foi feita
pelo próprio usuário. Como o usuário não consegue simular os momentos de pico, esta falha do
sistema 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 da
empresa decepcionado com a equipe do projeto. A equipe já tinha tentado de tudo, mas de nada
adiantou. 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 medidas
vocês tomariam para resolver esse perrengue?

2. Caso 2 – Isso é um Single Sign-On?
Um dia as coisas mudaram, a diretoria de sua empresa mudou. O mais novo diretor recebeu a
incumbência de reativar a Fábrica de Software da empresa e contratou vocês como equipe
especializada de arquitetos para resolver um problema recorrente em toda organização: o controle
de acesso das aplicações.
Todas as aplicações produzidas pela Fábrica de Software necessitavam de um módulo de
segurança, responsável por garantir a autenticação e o acesso seguro às funcionalidades de cada
sistema. Na antiga fábrica, este módulo era reconstruído para cada aplicação. Mas se tinha uma
coisa 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 com
retrabalho. Para o presidente da empresa a impressão que ficou foi: vender software é prejuízo
certo. Graças a novas oportunidades de negócios no mercado local, surgiu a oportunidade de
tentar de novamente. O novo diretor foi contrato para fazer dar certo desta vez e não podia
decepcionar.
Após diversas reuniões entre vocês e o novo diretor, foi identificado que o problema do controle de
acesso não era exclusividade da Fábrica de Software. Estava aí uma oportunidade de matar dois
coelhos com uma cajadada só: reduzir o custo da fábrica e também dos sistemas internos da
empresa. 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 foram
feitos pela antiga fábrica. Se tem algo de bom nisso é que vocês possuem acesso ao código-fonte
e podem modificar o que quiserem. Com base em levantamentos, vocês identificaram que a base
de dados da empresa era LDAP, mas cada cliente da fábrica poderia ter outra, desde banco de
dados até simples arquivos de texto.
Sob a perspectiva de arquitetura de software, como vocês resolveriam este desafio?

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 primeira
coisa que vocês pensaram, mas ninguém pronunciou, foi: “lá vem bomba”. Era um sistema para
controle de fluxos de trabalho, utilizando uma tecnologia específica que demandava bastante
dedicação em pesquisas. Como era desafiador, vocês toparam!
Basicamente o objetivo do projeto era construir uma aplicação Web que reunisse a administração
dos fluxos de trabalho gerenciados por um motor de Workflow, mas não era só isso. A primeira
atividade que vocês se dedicaram foi meter a cara nos livros para descobrir que diabo faz tal
motor. E descobriram! Aprenderam que um motor de Workflow processa fluxos cadastrados e que
em determinados momentos delegam atividades para programas externos. O início de um fluxo
també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 as
telas Web providas pelo fabricante do motor para interagir com os fluxos é bizarra, altamente
toscas, complicadas de usar e completamente inviáveis para o usuário final. O segundo é que o
motor 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 se
ocorre 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 do
Workflow, com o usuário final e com os dados da organização? Como dizia Edson Gomes: “este
sistema é um vampiro, ô ô ôô”.

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 a
equipe de arquitetos da empresa e vocês foram escolhidos para para descascar o abacaxi. O
turnover do projeto estava alto, a equipe era composta por novatos e apenas um remanescente
dos 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és
e 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 a
apresentação utilizava a biblioteca de telas padrão do tablet e a camada de persistência utilizava
uma tecnologia simples de armazenamento.
Após muito penar, vocês descobriram que as camadas não seguiam as regras básicas. A camada
de negócio fazia referência às telas e aos objetos de acesso aos dados, as telas acessavam a
camada de persistência diretamente, pulando a camada de negócio. Ou seja, tava uma tremenda
tosqueira, pouca coisa estava como manda o figurino.
Vocês propuseram refazer a aplicação por completo, mas o gerente do projeto disse: “nem
pensar”. O prazo do projeto já havia estourado e o cliente deu o ultimato. Se falhar desta vez, o
projeto 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 o
tablet e o servidor (na Internet) estava mais perdido do que cachorro que cai de caminhão de
mudança. A sincronização simplesmente não funcionava e essa era a principal preocupação do
cliente.
A solução era corrigir o que estava errado, que era praticamente tudo. Mas como fazer isso sem
assumir que iria jogar a aplicação fora e fazer outra? Use a criatividade pois o cliente colocou um
arquiteto da equipe dele para acompanhar o trabalho. Boa sorte!