PRINCÍPIOS DE MODELAGEM DE SISTEMAS BASEADOS EM

CASOS DE USO ORIENTADOS A ASPECTOS

Clayton Kossoski (UTFPR) kossoski.clayton@gmail.com

Simone Nasser Matos (UTFPR) snasser@utfpr.edu.br

RESUMO
O desenvolvimento de software atualmente é muito complexo. Qualquer projetista
preocupado com reuso, manutenibilidade, controle do desenvolvimento,
gerenciamento de partes específicas, modularização e abordagens especificas de
para criação racional de software está ciente que o desenvolvimento de software
pode ser difícil e demorado. A Orientação a Objetos despontou como um novo
paradigma de desenvolvimento desde que foi lançada trouxe muitos conceitos
importantes e avanços no desenvolvimento. No entanto a orientação a objetos
também possui alguns problemas, como espalhamento de código, que atrapalha no
desenvolvimento resultando em linhas de códigos repetitivas. O desenvolvimento
orientado a aspectos surgiu como alternativa tentar amenizar estes problemas da
orientação a objetos e neste artigo serão apresentados seus conceitos principais.

Palavras-Chave: Engenharia de Software, Aspectos, Paradigmas.

Introdução

O Desenvolvimento de Software Orientado a Aspectos (DSOA) propõe uma

nova abordagem para melhorar a modularidade para requisitos funcionais e não
funcionais; plataformas específicas, além da criação de sistemas mais
compreensíveis que são fáceis de configurar e estender, trazendo um maior
envolvimento dos stakeholders no projeto. (JACOBSON e NG, 2004).
Independente do tamanho do sistema que se proponha desenvolver
descobre-se que muitas partes formam fragmentos de código relacionados com a
atividade de autorização, persistência, depuração, rastreamento, distribuição, loggin,
manipulação de exceção, entre outras. Às vezes, uma parte considerável de uma
operação ou de classe não tem nenhum relacionamento com aquilo que se propõe
fazer.
Este presente artigo tem o objetivo de explanar os principais conceitos da
Análise Orientada a Aspectos, apresentando uma abordagem teórica com exemplos
simples.

Desenvolvimento Orientado a Aspectos

O Desenvolvimento de Software Orientado a Aspectos refere-se à

redundância, como características transversais (crosscutting concerns), em que se
encontram fragmentos de código em muitas operações e classes em um sistema, e
estes códigos atravessam as operações de classes. (JACOBSON e Ng, 2004).
Organizar os requisitos de software em nichos de funcionalidades,
interesses, preocupações, responsabilidades, entre outras se denomina separation
of concerns, separação de preocupações ou conceitos. O agrupamento de requisitos
segundo um critério estabelecido é uma das atividades indispensáveis para
desenvolver software orientado a aspectos com sucesso. (RESENDE e SILVA,
2005). Este conceito tem levado a Engenharia de Software a sugerir mudanças no
desenvolvimento de software e dividir problemas em partes cada vez menores.
Um aspecto representa um concern transversal dentro do sistema que está
sendo modelado. Os aspectos podem ter comportamento local e estrutura de dados
local. Eles definem a estrutura e o comportamento, organizados em interfaces
transversais, que serão combinados com a estrutura e o comportamento de classes
por meio de crosscutting (CHAVEZ, 2004).
A divisão das preocupações, interesses e responsabilidades, propicia ao
desenvolvedor destinar esforços em uma pequena parcela de um todo que será
maior depois de integrado, consequentemente reduz a taxa de erros em cada
módulo, favorece uma melhor interpretação do que se está elaborando, e um
atendimento aos requisitos de maneira mais gerenciável.
O DSOA tem como cunho principal fornecer ao desenvolvedor uma maneira
mais prática de analisar e programar software, sugerindo maior modularização,
separação de códigos que se espalham (espalhamento) e códigos que se
atravessam (crosscutting), unindo partes menores ao todo maior. Isto permite uma
melhor visibilidade do sistema, melhor interpretação de conceitos, união de todos
estes pequenos pedaços de maneira mais prática e menos cansativa. Separar
códigos em pequenos módulos auxilia a entender o que se está elaborando,
compreende-se melhor o que foi proposto.
Identificar, separar e compor características transversais de alto nível de
abstração provê melhor entendimento do problema e da solução, rastreabilidade
entre as diversas características, reusabilidade de soluções de maior granularidade,
e diminuição da distancia entre as fases de desenvolvimento. (SILVA, 2006).

Desenvolvimento dirigido a caso de uso

Cada caso de uso representa o comportamento do sistema com o usuário.

Os casos de uso exploraram os requisitos do usuário em sua perspectiva, são
candidatos naturais como as técnicas para modelar e organizar os usuários e
preocupações iniciais das partes interessadas.
O desenvolvimento dirigido a use case pressupõe que o desenvolvimento de
software é orientado a modelo. (JACOBSON e NG, 2004).
Na sua forma mais simples, segue uma sequência de modelos: modelo de
caso de uso, de design do modelo para modelo de implementação. A cada iteração
do ciclo da vida do software, se realiza as seguintes atividades.

 Encontrar os casos de uso e especificar cada um;

 Design de cada utilização;
 Concepção e execução de cada classe;
 Teste de cada caso de uso.

Isto significa que se tem que reunir as especificidades de um caso de uso

durante o projeto em alguma unidade de modularidade, que se chama de fatia (slice)
de caso de uso.
O slice de cada caso de uso recolhe pedaços de classes, operações, e
assim sucessivamente, que são específicos a um caso de uso de um modelo.
Estende-se este conceito ainda mais longe, um módulo de caso de uso que reúne as
especificidades de um caso de uso de todos os modelos e artefatos em um projeto
em uma única unidade.
O desenvolvimento paralelo é beneficiado através de casos de uso.
 Existe uma hierarquia de slices de caso de uso. Assim, um modelo é
constituído por duas estruturas:

 Elemento da estrutura, que identifica os elementos.

 Caso de uso da estrutura, que define o conteúdo desses elementos.

Existem duas representações de casos de uso, elipse e retangular.

Quando se deseja mostrar a visão geral do sistema, se utiliza casos de uso
na notação de uma elipse.
Através do exemplo de um Sistema de Gerenciamento de Hotel, Jacobson e
Ng mostram as duas representações de casos de uso, a notação em elipse e a
notação retangular conforme apresentados na Figura 1 e Figura 2.

Reservar Quarto

Figura 1: Reservar Quarto com a notação elipse.

Fonte: Adaptado de Jacobson e Ng. (2004, pg. 58).

Reservar Quarto
Fluxos
{básico} Reservar Quarto
{alt} Submissão Duplicada
{sub} Checar Preço do Quarto

Figura 2: Fluxos em Compartimentos

Fonte: Adaptado de Jacobson e Ng. (2004, pg. 58).

Se for necessário explorar detalhes de cada um dos casos de uso, uma

elipse em notação pode não ser uma visualização suficiente. Neste caso, a notação
retangular é mais apropriada.
A notação retangular é útil quando se deseja mostrar com mais detalhes os
fluxos de um caso de uso. Isso ocorre, quando se percebe que um caso de uso em
elipse pode ser contraditório ou não representar as especificidades, quando se deve
ter uma iteração implementada em particular, ou quando se quer destacar partes
significantes arquiteturais do caso de uso.

Descrevendo use cases

Quando se descreve um caso de uso, começa-se pelo mais simples ou mais

típico cenário e traça-se através dele usa sequencia de eventos. Este é chamado de
fluxo básico. Um caso de uso pode ter um ou mais fluxos básicos, dependendo do
número de caminhos do use case que podem ser instanciáveis. Depois de descrever
o caminho básico, gradualmente descreve se como as diferentes variações são
tratadas sobre os fluxos básicos. As suas variações de trajetória são chamados de
fluxos alternativos. Conforme vamos descrevendo um caso de uso, podemos
perceber que alguma das sequencias de interação são repetitivas, e que podem ser
descritas separadamente. Para descrever mais a fundo outros fluxos dentro de um
fluxo existem os subfluxos de caso de uso.
Este comportamento do use case pode ser especificado em um número de
caminhos dependendo de quem se destina a leitura. Atualmente a forma textual é a
mais frequentemente utilizada para especificar os comportamentos dos use cases.
Casos de usos, como classes, são elementos generalizáveis, e os seus
fluxos podem ser concretos ou abstratos. Um fluxo é concreto quando as etapas que
constituem o fluxo são definidas, isto é, se tem todo o texto que descreve o fluxo.
Um fluxo é abstrato quando tiver um nome, mas o fluxo em si não é especificado.
No quadro 1 é demonstrado uma declaração específica de caso de uso,
conforme apresentada em JACOBSON e NG (2004), o caso de uso representa o
fluxo de dados referentes à reserva de um quarto em um sistema de hotel conforme
apresentado na figura 3.
 Check in Cliente

Sala de Reserva

Cliente Funcionário do Hotel

Check out Cliente

Figura 3: Diagrama de Caso de Uso Reserva Hotel

Fonte: Adaptado de Jacobson e Ng (2004).

Especificação do Use Case: Reserva de Quarto

Descrição breve
Este use case descreve como um cliente reserva um quarto em um hotel.
Fluxo básico
B1: Sala de reserva
O use case inicia quando um cliente quer reservar um quarto.
1. O cliente seleciona um quarto para reservar.
2. O sistema mostra os tipos de quartos do hotel tem e suas tarifas.
3. O cliente executa o Checar Preço do Quarto.
4. O cliente faz a reserva e escolhe o quarto.
5. O sistema deduz do banco de dados o número de quartos do tipo específico.
6. O sistema cria uma nova reserva com os detalhes fornecidos.
7. O sistema mostra o número de confirmação de reserva e as instruções do check-in.
8. O use case termina.
Fluxos Alternativos
A1 – Submissão duplicada
No passo 5 do fluxo básico existe uma idêntica reserva no sistema (com mesmo nome, e-mail, início
e término das datas), o sistema mostra a reserva existente e pergunta ao cliente se ele procede com
a nova reserva.
1. Se o cliente continua, o sistema procede com a reserva, e o use case continua.
2. Se o cliente indica que a nova reserva é duplicada, o use case termina.
A2...
...
Subfluxos
S1 – Checar o preço do quarto
1. O cliente seleciona o tipo de quarto desejado e indica o período para ficar.
2. O sistema processa o custo para o período específico.
Precondições
O cliente precisa estar logado no sistema.
Pós-condições
Se for confirmada a reserva um novo registro é criado, e a número de quartos disponíveis
específicos diminui. Se a reserva não ocorre, não há mudança no banco de dados.
Requerimentos especiais
O sistema pode manipular cinco reservas concorrentes. Cada reserva não pode durar mais que 20
segundos.
Quadro 1: Especificação de caso de uso: Reserva de Quarto
Fonte: Adaptado de Jacobson e Ng (2004, pg. 55).
 No Quadro 1, a descrição de fluxo básica possui no passo 3 um subfluxo,
Checar Preço de Quarto, ele é sublinhado para denotar esta referência. Este
subfluxo é descrito depois em S1. Com a inserção de subfluxo, mantém-se menos
desordenado a descrição do caso de uso. Assim múltiplos fluxos podem referenciar
ou usar o subfluxo. Já nesta fase podem-se identificar possíveis aspectos, o
subfluxo é um deles.
O fluxo alternativo A1 manipula a submissão duplicada de reservas, note
que o fluxo básico não checa submissão duplicada e não contém referência para o
fluxo alternativo. Uma descrição de use case pode conter vários fluxos básicos,
alternativos e subfluxos, depende da complexidade que se queira demonstrar.

Definir o conjunto de casos de uso candidatos a aspectos

O termo candidato a aspecto é utilizado para indicar que na fase inicial do

desenvolvimento, na análise de requisitos, o projetista ainda não pode garantir que o
caso de uso poderá ser implementado utilizando a tecnologia; ficando esta decisão
para a fase posterior do projeto.
Hornung (2010, pg. 63) propõe a utilização de quatro critérios para a
identificação dos possíveis candidatos a aspectos que são:

1. O caso de uso estar associado a mais de um caso de uso. Em analogia ao

problema de espalhamento, onde possivelmente, a implementação deste
caso de uso possuirá trechos de código, relacionados com sua
funcionalidade, espalhados por vários locais do sistema.
2. Ser um caso de uso do tipo não funcional. Os casos de uso deste tipo, em
geral são implementados como aspecto.
3. Estar associado a um caso de uso através do relacionamento <<extend>>.
Este tipo de caso de uso geralmente inclui funcionalidades extras ao
comportamento do caso de uso base.
4. Alterar o fluxo de execução do caso de uso base, não estando diretamente
relacionado com o seu objetivo, permitindo assim que sua remoço não
impeça a realização.
 Os critérios são independentes, basta que um seja satisfeito para que o caso
de uso seja classificado como candidato a aspecto. Após realizar esta verificação, o
caso de uso colaborador se enquadra em critérios propostos, passa a se
classificados como candidato a aspecto. (HORNUNG, 2010).
Para desenvolver casos de uso candidatos a aspecto, HORNUNG (2010)
enfatiza a necessidade de decompor em subprocessos e tratá-los separadamente.

Primeiro passo: Como entrada, um subprocesso necessita os elementos que

compõem o Modelo de Requisitos da Aplicação. A partir da análise da Descrição
Textual dos casos de uso, as responsabilidades são obtidas, através do critério
Responsabilidade = Verbo + Complemento, conforme apresentado no Quadro 2.
Verbo Pergunta ao Verbo Complemento Responsabilidade
Verificar... O quê? Opção Verificar Opção
Executar... O quê? Ação Executar Ação
Quadro 2: Responsabilidades do caso de uso.
Fonte: Adaptado de HORNUNG (2010).

Hornung enfatiza que seja feita a descrição textual do caso de uso para
serem geradas as responsabilidades e verificar problemas de semantica. O
problemas de semântica ocorre quanto há responsabilidades com nomes diferentes
mas que semanticamente possuem as mesmas funcionalidades.
Um modelo de descrição textual é apresentado na tabela abaixo.

Nome do Caso de Uso “Processar Opção”

Ações do usuário Responsabilidades do sistema
1. Selecionar opção 2. Verificar a opção selecionada
3. Executar uma ação a partir da opção
escolhida
4. Apresentar o resultado da opção
escolhida
Tabela 1: descrição textual de um caso de uso
Fonte: Adaptado de Hornung (2010).

Segundo Passo: O objetivo é identificar as responsabilidades que ficam

espalhadas através dos casos de uso, quando estão presentes em mais de uma
Descrição Textual. Após esta identificação, o projetista deve analisar as
responsabilidades a procura de erros.
Terceiro Passo: o Diagrama de Casos de Uso é adaptado a fim de melhor
representar as responsabilidades identificadas. Como resultado deste subprocesso,
tem-se o Conjunto de Responsabilidades da Aplicação, o Conjunto de
Responsabilidades Espalhadas e o Modelo de Requisitos da Aplicação onde as
responsabilidades espalhadas foram identificadas e representadas. O objetivo deste
passo é representar no Diagrama de Caso de Uso as responsabilidades
encontradas no Segundo Passo. Estes casos de uso devem ser associados aos
seus originais através do estereótipo <<crosscuts>>; este é utilizado para indicar
que o comportamento entrecorta o caso de uso associado.
Quarto Passo: O objetivo é a identificação e representação entre os casos
de uso base e seus colaboradores. O termo “colaborador" utiliza-se para representar
um caso de uso que contribui de alguma forma para a realização de outro caso de
uso, sendo este segundo, representado pelo termo “base".
Na UML, a associação entre os casos de uso é representada pelos
estereótipos <<include>> e <<extend>>, a extensão para representar os casos de
uso com características transversais é <<crosscut>>.
Para identificar os aspectos Hornung (2010) também sugere que seja feita
uma tabela onde aparecem todos os casos de uso, e outra onde aparecem todos os
relacionamentos entre eles, com os colaboradores de cada um, e que seja feito um
cruzamento de use case através de uma matriz de associação, onde podem ser
melhor vistos os relacionamentos.

Conclusão

O planejamento de software é muito importante, definir passos para se

extrair responsabilidades, funcionalidades e até conceitos não foram vistos antes
apenas na extração de requisitos é muito importante.
O projeto de um sistema deve ser feito visando a sua melhoria futura,
inserção de novas funcionalidades, a modularização facilitada, através dela é
possível inserir ou extrair partes com facilidade, sem a necessidade de alterar muito
o código fonte, sendo restrita alteração na área desejada. A orientação a aspectos
surgiu para melhorar a modularização, evitando a repetição e o entrelaçamento de
código e desponta como uma melhoria na orientação a objetos recebeu a
contribuição de outras tecnologias e a partir delas extraiu o melhor, o aspecto, uma
nova abordagem promissora para o desenvolvimento de software atual.

Referências

CHAVEZ, Christina v. F. G. Um Enfoque Baseado em Modelos para o Design

Orientado a Aspectos. 2004. 298 f. Tese (Doutorado em Informática) –
Departamento de Informática, PUC-Rio, Rio de Janeiro, 2004.

HORNUNG, Rafael. Um Método para Identificação Antecipada de Candidatos a

Aspecto no Desenvolvimento de Frameworks de Domínio. 2010. 129 f.
Dissertação (Mestrado em Informática), Curitiba, 2010.

JACOBSON; Ivar; NG, Pan-Wei. Aspect-Oriented Software Development with

Casos de uso. Upper Saddle River: Pearson Education, Inc, 2004.

RESENDE, Antônio M. P. de.; SILVA, Claudiney. C. da. Programação Orientada a

Aspectos em Java – Desenvolvimento de Software Orientado a Aspectos. Rio de
Janeiro: Brasport, 2005.

SILVA, Lyrene da. Uma Estratégia Orientada a Aspectos para Modelagem de

Requisitos. 2006. 222 f. Tese (Doutorado em Informática) – Departamento de
Informática, PUC-Rio, Rio de Janeiro, 2006

Área temática: Tecnologia.