A complexidade do sistema é potencialmente reduzida devido à uniformidade das interfaces para atuadores e sensores.

A descrição dos padrões de requisitos também poderia fornecer referências a outros padrões de projeto e de requisitos relacionados.

capítulo 7 MoDeLaGeM De reqUIsItos: fLUxo, CoMPortaMeNto, PaDrÕes e aPLICaÇÕes BaseaDas Na weB (weBaPP) 197

m

r

w

a

Os desenvolvedores Web normalmente são céticos quando lhes é sugerida a ideia de análise de requisitos para WebApps. “Afinal de contas”, argumentam eles, “o processo de desenvolvi- mento para Web deve ser ágil e a análise toma muito tempo. Ela irá nos retardar quando sim- plesmente precisamos projetar e construir uma WebApp.”

O levantamento de requisitos realmente toma tempo, porém resolver o problema errado leva mais tempo ainda. A pergunta para cada desenvolvedor de WebApp é simples — você tem certeza de que entendeu os requisitos do problema? Se a resposta for um inequívoco “sim”, poderia ser possível pular a fase de modelagem de requisitos, porém se a resposta for “não”, a modelagem de requisitos deve ser realizada.

7.5.1 Que nível de análise é suficiente?

O grau com o qual a modelagem de requisitos para WebApps é enfatizado depende dos se- guintes fatores:

Tamanho e complexidade do incremento de WebApp.

•

Número de interessados (a análise pode ajudar a identificar requisitos conflitantes pro-

•

venientes de várias fontes).

Tamanho da equipe de desenvolvimento de WebApps.

•

Nível em que os membros da equipe de desenvolvimento de WebApps trabalharam juntos

•

antes (a análise pode ajudar a desenvolver um entendimento comum do projeto). Nível de êxito da organização é diretamente dependente do êxito das WebApps.

•

O contrário dos pontos anteriores é que à medida que um projeto se torna menor, que o número de interessados diminui, que a equipe se torne mais coesa e a aplicação seja menos crítica, é razoável aplicar uma abordagem de análise menos rígida.

Embora seja uma boa ideia analisar o problema antes de começar o projeto, não é verdade que toda análise deve preceder todo o projeto. De fato, o projeto de uma parte específica da Web- App exige apenas uma análise daqueles requisitos que afetam apenas essa parte da WebApp. Um exemplo para o CasaSegura: poderíamos projetar de forma válida toda a estética do site (layouts, esquemas de cores etc.) sem ter analisado as necessidades funcionais para recursos de comér- cio eletrônico. Precisaríamos analisar apenas aquela parte do problema relevante ao trabalho de projeto do incremento a ser entregue.

7.5.2 Entrada da modelagem de requisitos

Uma versão ágil do processo de software genérico discutido no Capítulo 2 pode ser aplica- da quando WebApps forem criadas. O processo incorpora uma atividade de comunicação que identifica interessados e categorias de usuário, o contexto de negócio, metas de aplicação e de informação definidas, requisitos gerais da WebApp e cenários de uso — as informações se tor- nam entrada para a modelagem de requisitos. Estas são representadas na forma de descrições de linguagem natural, descrições gerais, esboços e outras representações de informação.

A análise captura essas informações, as estruturam usando um esquema de representação formalmente definido (onde apropriado) e depois produz modelos mais rigorosos como saída. O modelo de requisitos fornece uma indicação detalhada da verdadeira estrutura do problema e dá uma visão da forma da solução.

A função ACS-EVC (vigilância através de câmeras) do CasaSegura foi introduzida no Ca-

pítulo 6. Quando foi introduzida, essa função parecia relativamente clara e foi descrita com certo nível de detalhamento como parte de um caso de uso (Seção 6.2.1). Entretanto, um 14 Essa seção foi adaptada de Pressman e Lowe [Pre08] com permissão.

198 paRtE doiS MoDeLaGeM

reexame do caso de uso poderia revelar informações que estão faltando, ambíguas ou não claras. Alguns aspectos de informações faltantes emergiriam naturalmente durante o projeto. Exemplos poderiam incluir o layout específico dos botões de função, seu aspecto estético, o tamanho das visões instantâneas, a colocação de visões das câmeras e planta do imóvel ou até mesmo minúcias como o comprimento máximo e mínimo das senhas. Alguns desses aspectos são decisões de projeto (como o layout dos botões) e outros são requisitos (como o tamanho das senhas) que, fundamentalmente, não influenciam os trabalhos iniciais de projeto.

Porém, algumas informações faltantes poderiam realmente influenciar o próprio projeto como um todo e estarem mais relacionadas a um real entendimento dos requisitos. Por exemplo:

P1: Qual a resolução de vídeo fornecida pelas câmeras do CasaSegura?

P2: O que acontece se uma condição de alarme for encontrada enquanto a câmera esti- ver sendo monitorada?

P3: Como o sistema manipula câmeras que possam ser deslocadas e ampliadas/ reduzidas?

P4: Que informações deveriam ser fornecidas juntamente com a visão das câmeras? (Por exemplo, posição? hora/data? último acesso anterior?)

Nenhuma dessas perguntas foram identificadas ou consideradas no desenvolvimento inicial do caso de uso, muito embora as respostas poderiam ter um efeito substancial em diferentes as- pectos do projeto.

Consequentemente, é razoável concluir que embora a atividade de comunicação forneça uma boa fundamentação para o entendimento, a análise de requisitos refina esse entendimento através de interpretações adicionais. À medida que a estrutura do problema é delineada como parte do modelo de requisitos, invariavelmente surgem perguntas. São essas perguntas que preenchem as lacunas — ou, em alguns casos, realmente nos ajudam, em primeiro lugar, a en- contrar as lacunas.

Em suma, as entradas para o modelo de requisitos serão as informações coletadas durante a atividade de comunicação — qualquer uma, desde um e-mail informal até uma descrição de projeto detalhado contendo cenários de uso e especificações de produto completas.

7.5.3 Saída da modelagem de requisitos

A análise de requisitos fornece um mecanismo disciplinado para representar e avaliar o con- teúdo e função de uma WebApp, os modos de interação que os usuários irão encontrar e o am- biente e a infraestrutura em que a WebApp reside.

Cada uma dessas características pode ser representada como um conjunto de modelos que permitem que os requisitos da WebApp sejam analisados de maneira estruturada. Embora os modelos específicos dependam em grande parte da natureza da WebApp, há cinco classes prin- cipais de modelos:

Modelo de conteúdo

• — identifica o espectro completo do conteúdo a ser fornecido pela WebApp. Conteúdo pode ser texto, gráficos, imagens, vídeo e áudio.

Modelo de interações

• — descreve a maneira através da qual os usuários interagem com a WebApp.

Modelo funcional

• — define as operações que serão aplicadas ao conteúdo da WebApp e descreve outras funções de processamento independentes do conteúdo, mas necessá- rias para o usuário final.

Modelo de navegação

• — define a estratégia geral de navegação para a WebApp.

Modelo de configuração

• — descreve o ambiente e a infraestrutura na qual a WebApp reside.

capítulo 7 MoDeLaGeM De reqUIsItos: fLUxo, CoMPortaMeNto, PaDrÕes e aPLICaÇÕes BaseaDas Na weB (weBaPP) 199 Podemos desenvolver cada um desses modelos usando um esquema de representação (em geral chamado “linguagem”) que permite que seu intuito e estrutura sejam comunicados e ava- liados facilmente entre os membros da equipe de engenharia de Web e outros interessados. Como consequência, várias questões fundamentais (por exemplo, erros, omissões, inconsistên- cias, sugestões para aperfeiçoamento ou modificações, pontos a ser esclarecidos) são identifi- cadas e posteriormente trabalhadas.

7.5.4 modelo de conteúdo para Webapps

O modelo de conteúdo contém elementos estruturais que dão uma visão importante dos re- quisitos de conteúdo para uma WebApp. Estes englobam objetos de conteúdo e todas as classes de análise — entidades visíveis aos usuários criadas ou manipuladas à medida que o usuário interage com a WebApp.15

O conteúdo pode ser desenvolvido antes da implementação da WebApp, enquanto a WebApp está sendo construída ou bem depois de estar em funcionamento. Em todos os casos, ela é in- corporada via referência navegacional na estrutura geral da WebApp. Um objeto de conteúdo po- deria ser uma descrição textual de um produto, um artigo descrevendo um evento de noticiário, uma fotografia de ação tirada durante um evento esportivo, a resposta de um usuário em um fó- rum de discussão, uma animação do logotipo de uma empresa, um breve vídeo de apresentação ou um áudio agregado a um conjunto de slides de uma apresentação. Os objetos de conteúdo poderiam ser armazenados como arquivos distintos, incorporados diretamente em páginas Web ou obtidos dinamicamente de um banco de dados. Em outras palavras, um objeto de conteúdo é qualquer informação coesa que deve ser apresentada a um usuário final.

Os objetos de conteúdo podem ser determinados diretamente dos casos de uso, exa- minando-se a descrição do cenário para referências diretas e indiretas ao conteúdo. Por exemplo, uma WebApp que oferecesse suporte ao CasaSegura seria estabelecida em Casa- SeguraGarantida.com. Um caso de uso, Comprando Componentes Específicos do CasaSe-

gura, descreve o cenário necessário para adquirir um componente do CasaSegura e contém a seguinte sentença:

Serei capaz de obter informações descritivas e de preço para cada componente do produto.

O modelo de conteúdo deve ser capaz de descrever o objeto de conteúdo Componente.

Em muitos casos, uma simples lista dos objetos de conteúdo, com uma breve descrição de cada objeto, é suficiente para definir os requisitos para o conteúdo a ser projetados e implementados. Entretanto, em alguns casos, o modelo de conteúdo pode se beneficiar de uma análise mais rica que ilustre graficamente os relacionamentos entre os objetos de conteúdo e/ou a hierarquia do conteúdo mantido por uma WebApp.

Por exemplo, consideremos a árvore de dados [Sri01] criada para um componente de Casa- SeguraGarantida.com e ilustrada na Figura 7.10. A árvore representa uma hierarquia de

informações usadas para descrever um componente. Dados simples ou compostos (um ou mais valores de dados) são representados com retângulos de fundo branco. Os objetos de conteúdo são representados como retângulos chapados. Na figura, a descrição é definida por cinco obje- tos de conteúdo (os retângulos chapados). Em alguns casos, um ou mais desses objetos seriam ainda mais refinados à medida que a árvore de dados fosse se expandindo.

Uma árvore de dados pode ser criada para qualquer conteúdo composto de vários objetos de conteúdo e dados. A árvore de dados é desenvolvida em uma tentativa de definir relações hierárquicas entre os objetos de conteúdo e de fornecer um meio para revisar o conteúdo de modo que omissões e inconsistências sejam reveladas antes de o projeto começar. Além disso, a árvore de dados serve como base para o projeto do conteúdo.

200 paRtE doiS MoDeLaGeM

7.5.5 modelo de interações para Webapps

A grande maioria das WebApps possibilita um “diálogo” entre o usuário final e a funcio- nalidade da aplicação, o conteúdo e o comportamento de uma aplicação. Esse diálogo pode ser descrito por meio de um modelo de interações que pode ser composto de um ou mais dos seguintes elementos: (1) casos de uso, (2) diagramas de sequência, (3) diagramas de estados,16 e/ou (4) protótipos de interfaces do usuário.

Em muitos casos, um conjunto de casos de uso já basta para descrever a interação em um nível de análise (um maior refinamento e detalhes serão introduzidos durante a fase de projeto). Entretanto, quando a sequência de interação for complexa e envolver várias classes de análise ou muitas tarefas, às vezes vale a pena representá-la usando uma forma esquemática mais ri- gorosa.

O layout da interface do usuário, o conteúdo que ela apresenta, os mecanismos de intera- ção que implementa e a estética geral das conexões de WebApps para usuários têm muito a ver com a satisfação do usuário e com o êxito geral da WebApp. Embora possa se argumentar que a criação de um protótipo de interface do usuário seja uma atividade de projeto, é uma boa ideia realizá-la durante a criação do modelo de análise. O quanto antes uma representação física de uma interface do usuário puder ser revisada, maior a probabilidade de que os usuários finais obterão aquilo que realmente desejam. O projeto de interfaces do usuário é discutido em deta- lhes no Capítulo 11.

Pelo fato de as ferramentas para construção de WebApps serem abundantes, relativamente baratas e funcionalmente poderosas, é melhor criar o protótipo de interface usando-as. O pro- tótipo deve implementar os principais links de navegação e representar o layout geral da tela em grande parte da mesma forma que será construído. Por exemplo, se o intuito é oferecer cinco funções principais de sistema para o usuário final, o protótipo deve representá-las já que o usuá- rio irá vê-las assim que entrar na WebApp. Serão fornecidos links gráficos? Onde será exibido o menu de navegação? Que outras informações o usuário verá? Perguntas como essas devem ser respondidas pelo protótipo.

7.5.6 modelo funcional para Webapps

Muitas WebApps oferecem uma ampla gama de funções computacionais e manipuladoras que podem ser associadas diretamente ao conteúdo (seja usando-o, seja produzindo-o) e que 16 Diagramas de sequência e diagramas de estados são modelados usando-se a notação da UML. Os diagramas de estados são

descritos na Seção 7.3. Veja o Apêndice 1 para mais detalhes.

Descrição de marketing Fotografia Descrição técnica Esquema Vídeo Preço no atacado Número da peça Nome da peça Tipo de peça Componente Descrição Preço Preço no varejo Figura 7.10 Árvore de dados para um componente de casaSeguraGarantida.com

capítulo 7 MoDeLaGeM De reqUIsItos: fLUxo, CoMPortaMeNto, PaDrÕes e aPLICaÇÕes BaseaDas Na weB (weBaPP) 201 frequentemente são sua meta principal de interação com o usuário. Por essa razão, os requisitos funcionais têm de ser analisados e, quando necessário, modelados.

O modelo funcional lida com dois elementos de processamento da WebApp, cada um dos quais representando um diferente nível de abstração procedural: (1) funcionalidade observável pelo usuário fornecida pela WebApp aos usuários finais e (2) as operações contidas nas classes de análise que implementam comportamentos associados à classe.

A funcionalidade observável pelos usuários engloba quaisquer funções de processamento ini- ciadas diretamente pelo usuário. Uma WebApp financeira poderia implementar uma série de fun- ções financeiras (por exemplo, uma calculadora de crédito educativo para o ensino superior ou uma calculadora para planos de aposentadoria). Essas funções poderiam, na verdade, ser imple- mentadas usando-se operações dentro das classes de análise, porém, do ponto de vista do usuá- rio final, a função (mais precisamente, os dados fornecidos pela função) é o resultado visível.

Em um nível de abstração procedural mais baixo, o modelo de requisitos descreve o proces- samento a ser realizado pelas operações das classes de análise. Essas operações manipulam atributos de classes e estão envolvidas, já que as classes colaboram entre si para cumprir deter- minado comportamento exigido.

Independentemente do nível de abstração procedural, o diagrama de atividades UML pode ser utilizado para representar detalhes do processamento. No nível de análise, os diagramas de atividades devem ser usados apenas onde a funcionalidade é relativamente complexa. Grande parte da complexidade de muitas WebApps ocorre não na funcionalidade fornecida, mas sim na natureza das informações que podem ser acessadas e nas maneiras pelas quais podem ser manipuladas.

Um exemplo de funcionalidade relativamente complexa do CasaSeguraGarantida.com

é tratado por um caso de uso intitulado Obter recomendações para a disposição dos sensores no espaço disponível. O usuário já desenvolveu um layout para o espaço a ser monitorado e, nesse caso de uso, escolhe esse layout e solicita posições recomendadas para os sensores de acordo com o layout. CasaSeguraGarantida.com responde com uma representação gráfica

do layout com informações adicionais sobre os pontos recomendados para posicionamento dos sensores. A interação é bastante simples, o conteúdo é ligeiramente mais complexo, porém a funcionalidade subjacente é muito sofisticada. O sistema deve empreender uma análise relati- vamente complexa do layout do andar para determinar o conjunto ótimo de sensores. Ele tem de examinar as dimensões dos ambientes, a posição das portas e janelas e coordená-las com as capacidades e especificações dos sensores. Nada trivial! Um conjunto de diagramas de ativida- des pode ser usado para descrever o processamento para esse caso de uso.

O segundo exemplo é o caso de uso Controlar câmeras. Neste, a interação é relativamente simples, porém há grande risco de funcionalidade complexa, dado que essa “simples” opera- ção requer comunicação complexa com os dispositivos localizados remotamente e acessíveis via Internet. Uma outra possível complicação está relacionada com a negociação do controle, quando várias pessoas autorizadas tentam monitorar e/ou controlar um único sensor ao mes- mo tempo.

A Figura 7.11 ilustra um diagrama de atividades para a operação assumirControleDaCamera() que faz parte da classe de análise Camera usada no caso de uso Controlar cameras. Deve-se

notar que duas operações adicionais são chamadas dentro do fluxo procedural: solicitarBlo- queioCamera(), que tenta bloquear a câmera para esse usuário e obterUsuarioCameraAtual(), que recupera o nome do usuário que está controlando a câmera no momento. Os detalhes cons- trutivos indicando como essas operações são chamadas, bem como os detalhes da interface para cada operação, não são considerados até que o projeto da WebApp seja iniciado.

7.5.7 modelos de configuração para Webapps

Em alguns casos, o modelo de configuração nada mais é que uma lista de atributos no servidor e no cliente. Entretanto, para WebApps mais complexas, uma série de detalhes de configuração