Bileşiklerin Spektral Özelliklerinin İncelenmesi

Apresenta-se nesta sub-sec¸˜ao um exemplo de aplicac¸˜ao da linguagem de padr˜oes GRN na mode- lagem de uma Sistema de Acompanhamento e Reparo de Buracos (SARB), descrito por Pressman (2002) (p´agina 326) e reproduzido a seguir.

Descric¸ ˜ao dos requisitos principais do SARB

“Os cidad˜aos podem obter acesso a um site da Web e relatar a localizac¸˜ao e gravidade dos buracos. `

A medida que os buracos s˜ao relatados eles s˜ao registrados num “sistema de reparo do departa- mento de obras p´ublicas” e lhes ´e atribu´ıdo um n´umero de identificac¸˜ao, armazenado por enderec¸o da rua, tamanho (numa escala de 1 a 10), localizac¸˜ao (no meio da rua, na calc¸ada, etc.), distrito (determinado pelo enderec¸o da rua) e prioridade de reparo (determinada pelo tamanho do buraco). Dados da ordem de servic¸o s˜ao associados com cada buraco e incluem a localizac¸˜ao e tamanho do buraco, n´umero de identificac¸˜ao da equipe de reparo, n´umero de pessoas na equipe, equipa- mento atribu´ıdo, horas aplicadas no reparo, estado do buraco (trabalho em andamento, reparado, reparo tempor´ario, n˜ao reparado), quantidade de material de enchimento usado e custo do reparo (calculado a partir de horas aplicadas, quantidade de pessoas, material e equipamento usados). Fi- nalmente, um arquivo de danos ´e criado para conter informac¸˜ao sobre danos relatados devido ao buraco e incluem nome do cidad˜ao, enderec¸o, n´umero do telefone, tipo de dano e quantia em reais de preju´ızo causado pelo dano. O SARB ´e um sistema on-line; todas as consultas devem ser feitas interativamente”.

Aplicac¸ ˜ao da GRN para modelagem do SARB

Com base nos requisitos do SARB, a GRN foi utilizada com o objetivo de modelar o sistema, produzindo um modelo de classes com a indicac¸˜ao dos pap´eis desempenhados por cada classe nos padr˜oes utilizados. Al´em disso, produz-se um hist´orico dos padr˜oes e variantes utilizados, bem como uma lista de decis˜oes de an´alise tomadas quando a linguagem de padr˜oes n˜ao atende aos requisitos do sistema.

Conforme recomendado no processo apresentado na Sec¸˜ao 3.4, a linguagem de padr˜oes GRN deve ser estudada previamente pelo desenvolvedor e os requisitos do sistema devem ser obtidos usando-se quaisquer t´ecnicas da Engenharia de Software. No caso do SARB, consideram-se os

3.5 A Linguagem de Padr˜oes para Gest˜ao de Recursos de Neg´ocios 56 requisitos contidos no texto apresentado nesta sec¸˜ao. Dois sub-sistemas podem ser identificados nos requisitos: o reparo do buraco e o controle de danos causados aos cidad˜aos. Portanto a GRN deve ser aplicada em dois ciclos, cada um deles para um dos sub-sistemas. O modelo de an´alise final produzido aplicando-se a GRN ao SARB ´e mostrado na Figura 3.7. Bal˜oes indicam os padr˜oes da GRN usados para modelar o SARB, sendo que uma mesma classe pode desempenhar pap´eis diferentes em mais do que um padr˜ao. O formato utilizado no interior dos bal˜oes ´e “P#n: papel”, onde “n” ´e o n´umero do padr˜ao e “papel” ´e o papel desempenhado pela classe em tal padr˜ao. Deve-se salientar que m´etodos e operac¸˜oes canˆonicas n˜ao s˜ao inclu´ıdas.

O modelo da Figura 3.7 foi obtido de forma gradual, `a medida que os padr˜oes foram aplicados. Iniciando-se pelo sistema de reparo de buracos, o primeiro padr˜ao da GRN — IDENTIFICAR O RECURSO— ´e aplicado, sendo que o Buraco ´e identificado como sendo o Recurso. As poss´ıveis classificac¸˜oes do buraco, por exemplo, com relac¸˜ao ao distrito, ao tamanho e `a localizac¸˜ao, levam `a aplicac¸˜ao do variante “M´ultiplos Tipos de Recursos” desse padr˜ao. Aplica-se ent˜ao o padr˜ao 2 – QUANTIFICAR O RECURSO, no qual o buraco pode ser caracterizado como sendo simples, pois possui caracter´ısticas que levam a gerenci´a-lo individualmente (outras opc¸˜oes, tais como recursos medidos, instanciados ou tratados em lotes, s˜ao inadequadas nesse exemplo).

Ap´os identificado e quantificado o recurso, inicia-se a modelagem da gest˜ao do recurso. Nesse caso em particular, o tipo de gest˜ao desejado para o buraco ´e o reparo, que encaixa-se no padr˜ao 9 – MANTER O RECURSO. Analisando-se detalhadamente esse padr˜ao, percebe-se que um dos participantes opcionais — Origem — pode ser removido, j´a que n˜ao ´e importante para o sistema que sejam registradas unidades espec´ıficas do Departamento de Obras, mas apenas o pr´oprio de- partamento. Assim, o papel de Destino ´e atribu´ıdo ao Departamento de Obras P´ublicas, que, na verdade, desempenha tamb´em o papel de Origem, porque ´e ele quem requisita um reparo de buraco e, depois, realiza tal reparo.

Finalmente aplicam-se os padr˜oes para complementar detalhes da transac¸˜ao de reparo do bu- raco, tais como: o padr˜ao 13 – IDENTIFICAR O EXECUTOR DA TRANSAC¸ ˜AO, no qual pode-se lidar com a equipe de reparo respons´avel pelo buraco; o padr˜ao 14 – IDENTIFICAR AS TARE- FAS DA MANUTENC¸ ˜AO, que permite a discriminac¸˜ao de cada uma das tarefas necess´arias para o reparo do buraco; e o padr˜ao 15 – IDENTIFICAR AS PEC¸AS DA MANUTENC¸ ˜AO, que permite registrar cada um dos materiais consumidos no reparo.

Durante a an´alise do sistema usando a GRN, faz-se necess´ario, conforme recomendado no passo 4(c) do processo proposto na sec¸˜ao 3.5.5, fazer o mapeamento entre os atributos, m´etodos e operac¸˜oes do padr˜ao versus os atributos, m´etodos e operac¸˜oes das classes concretas do sistema

sendo modelado. No caso do SARB, novos atributos foram adicionados, como por exemplo o atributonumeroDePessoasEquipe(classe Ordem de Servic¸o).

3.5 A Linguagem de Padr˜oes para Gest˜ao de Recursos de Neg´ocios 57

Depto de Obras Públicas

!*listar em ordem alfabética() !*lista ordens de serviço por depto() códigoId : integer

nome : string

Equipe de Reparo

!* listar ordens de serviço por equipe() codigoIdent : integer

nome dos membros : string

Buraco

!*listar por endereço() !* listar por distrito() !* listar por tamanho() !* listar por localização() !* listar prejuízos por buraco() numeroIdentif : integer endereço : string situação : boolean

Ordem de serviço

?abrir Ordem de Serviço() ?fechar Ordem de Serviço() !*listar ordens de serviço pendentes() númeroOrdServ : integer dataInicial : date dataTérmino : date problemasApresentados : string custoDoReparo : float númeroDePessoasEquipe : integer 1 0..n 0..n P#9, P#14, P#15: Manutenção do Recurso P#13: Transação P#9: Destino P#1: Recurso P#2: Recurso Simples P#9: Recurso P#6: Recurso P#6: Comércio de Recurso P#13: Executor da Transação Distrito código : integer nome : string P#1: Tipo de Recurso 1..1 1..1 feita em> 0..n 1..1 Tamanho código : integer descrição : string prioridadeReparo : integer P#1:Tipo de Recurso Localização código : integer descrição : string P#1: Tipo de Recurso Cidadão

!* listar prejuízos por cidadão() código : integer nome : string endereço : string telefone : integer P#1: Tipo de Recurso P#6: Destino 0..n 1..1 < executada por 0..n 1..1 0..n _1..1 0..n 1..1 0..n Tarefa do reparo

!* listar tarefas por equipe de reparo() problema a resolver : string descrição do serviço : string horas gastas no reparo : string custo do reparo : float

Material usado no reparo

quantidade : float custo : float

Material

!* listar por nome() +!* listar material em falta() codigoIdent : integer nome : string

quantidade em estoque : float 0..n 1..1 é um V é denunciado por V P#15: Peça P#15: Peça usada na manutenção P#14: Tarefa da Manutenção Arquivo de Prejuízos ? registrar prejuízo() ? cancelar prejuízo()

!* computar total de prejuízo no período() !* listar prejuízos no período() numeroPrejuizo : integer data : date situação : boolean valor do prejuízo : float tipo de dano : string

0..n 1..1 0..n 1..1 ^ refere-se a ^ refere-se a solicita >

Figura 3.7: Modelo de An´alise do SARB com padr˜oes

Tendo modelado o sub-sistema de reparos, parte-se agora para o sub-sistema de controle dos preju´ızos causados pelos buracos. Analisando-se os aspectos semˆanticos da GRN, pode-se concluir que esse sub-sistema refere-se a um tipo de transac¸˜ao n˜ao coberta pela GRN: o controle do preju´ızo n˜ao se encaixa em quaisquer das trˆes principais atividades abordadas na GRN: n˜ao se trata de uma locac¸˜ao, na qual um recurso muda temporariamente de propriet´ario, n˜ao se trata tampouco de uma comercializac¸˜ao, em que a posse do recurso ´e transferida para outro propriet´ario, e tamb´em n˜ao se trata de uma manutenc¸˜ao, na qual um recurso com problemas passa por servic¸os e trocas de pec¸as para voltar a funcionar.

Entretanto, se analisarmos apenas a sintaxe dos padr˜oes da GRN e compararmos os atributos envolvidos no controle dos preju´ızos causados pelos buracos, vemos que a classe Comercializac¸˜ao

3.6 Considerac¸˜oes Finais 58

do Recurso, do padr˜ao 6 – COMERCIALIZAR ORECURSO, possui semelhanc¸as que a tornam atra- tiva para ser reutilizada na modelagem desse sub-sistema. Feitas as devidas adaptac¸˜oes, o padr˜ao 6 ´e ent˜ao utilizado para concluir a etapa de an´alise do SARB. Esse tipo de uso de um padr˜ao ´e deno- minado “abstrac¸˜ao do dom´ınio”, ou, em inglˆes, “flexing” por Butler et al. (2000). A pr´e-condic¸˜ao

para fazer a abstrac¸˜ao de dom´ınio ´e que o padr˜ao possua a estrutura computacional requerida, em- bora n˜ao carregue a semˆantica do dom´ınio antecipada por seu projetista. Neste trabalho, chamamos isso de “processo de substituic¸˜ao semˆantica/sint´atica”, e usamos, na Tabela 3.1, a referˆencia geral ao padr˜ao (USAR O RECURSO).

O resultado da modelagem do SARB usando a GRN ´e o modelo de classes mostrado na Fi- gura 3.7 e o hist´orico de padr˜oes usados na modelagem (Tabela 3.1). Outro poss´ıvel resultado da modelagem poderia ter sido uma lista das decis˜oes de an´alise tomadas durante o processo, na qual estariam discriminados os requisitos n˜ao atendidos pela GRN e como tais requisitos foram modelados (por meio de classes adicionais, relacionamentos, etc.). Essa lista de decis˜oes seria importante durante a implementac¸˜ao da aplicac¸˜ao espec´ıfica e em sua futura manutenc¸˜ao. Ela n˜ao foi necess´aria no caso do SARB, j´a que a GRN apoiou a modelagem de todos os seus requisitos.

Tabela 3.1: Hist´orico de padr˜oes usados na instanciac¸˜ao do SARB

Padr˜ao Variante Participante Classe da Aplicac¸˜ao

1-Identificar o Recurso M´ultiplos tipos Recurso Buraco Tipo de Recurso Distrito Tipo de Recurso Tamanho Tipo de Recurso Localizac¸˜ao Tipo de Recurso Cidad˜ao 2 - Quantificar o Recurso Recurso Simples Recurso Buraco 9 - Manter o Recurso Sem origem Recurso Buraco

Manutenc¸˜ao do Recurso Ordem de Servic¸o

Destino Departamento de Obras P´ublicas 13 - Identificar o Executor da

Transac¸˜ao

Sem comiss˜ao Executor da Transac¸˜ao Equipe de Reparo Transac¸˜ao Ordem de Servic¸o 14 - Identificar as Tarefas da

Manutenc¸˜ao

Executor da Transac¸˜ao ao inv´es de executor da tarefa

Manutenc¸˜ao do Recurso Ordem de Servic¸o Tarefa da Manutenc¸˜ao Tarefa do Reparo 15 - Identificar as Pec¸as da

Manutenc¸˜ao

Default Manutenc¸˜ao do Recurso Ordem de Servic¸o Pec¸a usada na Manutenc¸˜ao Material usado no reparo Pec¸a Material

6 - Comercializar/Usar o Recurso Sem origem Recurso Buraco

Com´ercio do Recurso Arquivo de Preju´ızos Destino Cidad˜ao

3.6

Considerac¸ ˜oes Finais

Este Cap´ıtulo apresentou uma vis˜ao geral do processo proposto nesta tese, possibilitando a com- preens˜ao do escopo do trabalho. Descreveu em detalhes o primeiro passo desse processo, que trata da construc¸˜ao de uma linguagem de padr˜oes para um dom´ınio espec´ıfico. Como exemplo, apre-

3.6 Considerac¸˜oes Finais 59 sentou a linguagem de padr˜oes GRN, que continuar´a sendo utilizada nos demais cap´ıtulos para ilustrar o processo proposto.

Em s´ıntese, pode-se dizer que o processo geral proposto atende `a necessidade de novos m´etodos para desenvolvimento e instanciac¸˜ao de frameworks que, embora sendo uma tecnologia poderosa de reuso, tem seu uso inibido tanto pela complexidade de desenvolvimento quanto pela dificuldade de instanciac¸˜ao.

A linguagem de padr˜oes GRN tamb´em contribui para o reuso, por´em num n´ıvel de abstrac¸˜ao mais alto: seus padr˜oes proporcionam a desenvolvedores inexperientes um caminho a seguir quando precisam modelar sistemas no dom´ınio de gest˜ao de recursos de neg´ocios. O resultado do uso da GRN ´e um diagrama de classes para uma aplicac¸˜ao espec´ıfica, composto de diversas partes que representam as soluc¸˜oes para problemas comuns no dom´ınio. Informac¸˜oes sobre o comportamento dinˆamico do sistema tamb´em poderiam ser fornecidas pela GRN, por exemplo por meio de diagramas de seq¨uˆencia da UML, o que ajudaria o usu´ario inexperiente a entender mais rapidamente o dom´ınio tratado. Por´em, a vers˜ao atual da GRN mostra apenas o comportamento est´atico dos padr˜oes, ficando como sugest˜ao para trabalho futuro a inclus˜ao de modelos dinˆamicos. O pr´oximo cap´ıtulo descreve em detalhes mais dois passos do processo proposto: a construc¸˜ao do framework caixa branca (passo 2) e a instanciac¸˜ao desse framework para aplicac¸˜oes espec´ıficas, tendo como base apenas o framework caixa branca (passo 4a).

C

´

4

O Processo de Construc¸ ˜ao e

Instanciac¸ ˜ao de um Framework Caixa

Branca

4.1

Considerac¸ ˜oes Iniciais

Neste Cap´ıtulo, detalham-se os processos de construc¸˜ao e instanciac¸˜ao de um framework caixa branca com base em uma linguagem de padr˜oes para um dom´ınio espec´ıfico. Esses dois pro- cessos referem-se aos passos 2 e 4a do processo geral da Figura 8.1 e foram agrupados em um mesmo cap´ıtulo por serem estritamente relacionados: o framework caixa branca constru´ıdo no passo 2 ´e instanciado utilizando-se o processo mostrado no passo 4a. O processo de construc¸˜ao e instanciac¸˜ao do framework GREN ´e utilizado para ilustrar os processos gerais apresentados neste Cap´ıtulo.

O Cap´ıtulo est´a organizado da seguinte forma: na sec¸˜ao 4.2 descreve-se o processo de cons- truc¸˜ao de um framework caixa branca com base em uma linguagem de padr˜oes, exemplificado na sec¸˜ao 4.3 pelo processo de construc¸˜ao do framework GREN. Na sec¸˜ao 4.4 ´e detalhado o processo de instanciac¸˜ao do framework, usando como base a linguagem de padr˜oes com a qual ele foi constru´ıdo. O exemplo de instanciac¸˜ao do framework GREN, usando a linguagem de padr˜oes

4.2 O Processo de Construc¸˜ao 61