usuário”, descrito de acordo com o metamodelo UCModel. A Figura 5-16 apresenta a especificação desse caso de uso usando um diagrama de atividades que explora o perfil ProfileUCModel para definir a semântica dos vários elementos que fazem parte da especificação. A Figura 5-17 apresenta a descrição textual desse mesmo caso de uso usando o gabarito organizado na seção 4.5.3.2 e apresentado na Tabela 4-10 – página 81.
É importante frisar que, em termos semânticos, as especificações de caso de uso apresentadas no diagrama de atividades (Figura 5-16) e na descrição textual (Figura 5-17) são idênticas. Na prática, a descrição textual apresentada na Figura 5-17 foi gerada automaticamente a partir do diagrama de atividades da Figura 5-16, com o apoio ferramental que será detalhado no capítulo 6.
Observando a especificação do caso de uso “Autenticar usuário”, representada como um diagrama de atividades na Figura 5-16, é possível visualizar os elementos do metamodelo UCModel definidos nas seções anteriores. Os itens listados a seguir estão destacados no diagrama (Figura 5-16) com o mesmo número do item.
1) O caso de uso e seus elementos básicos são representados pela atividade, estereotipada como <<use_case_description>>, e seus tagged-values. No diagrama tanto o estereótipo quanto as tagged-values são representados como um comentário associado à atividade;
2) Todas as ações do diagrama são estereotipadas para indicar o seu tipo (<<actor_action>>, <<system_action>> ou <<system_response>>);
3) Os pontos de ativação dos fluxos alternativos são marcados pelos nós de decisão do diagrama;
4) O ponto de ativação do fluxo de exceção é marcado pelo fluxo de interrupção partindo direto da ação onde essa exceção é gerada (estereótipo <<interrupt>>, também representado pelo ícone ).
5) As condições que restringem a execução dos fluxos alternativos e de exceção são definidas como condições de guarda associadas ao início desses fluxos;
6) As seqüências de ações que compõem os fluxos alternativos e de exceção são etiquetadas com os identificadores dos fluxos;
125 7) As regras são representadas como Constraints e estão estereotipadas
(classificadas) de acordo com o seu tipo, e;
8) As regras estão sempre associadas às ações que restringem.
126
Identificação: UC001
Nome: Autenticar usuário
Descrição: Esse caso de uso permite que o usuário faça login na aplicação
Ator(es): Internauta
Criticalidade: Alta
Freqüência de uso: Média
Pré-condições: O ator não está autenticado
Pós-condições: O menu da aplicação é apresentado de acordo com o perfil do usuário
Trigger: Ator acessa qualquer página da aplicação
Fluxo Principal: 1. Sistema solicita login e senha juntamente com uma opção “Esqueci a
senha”
2. Internauta fornece login e senha [A1] 3. Sistema valida login e senha [R1, R2]
4. Sistema apresenta o menu da aplicação de acordo com o perfil do usuário [A2]
Fluxos Alternativos: [A1] Ator seleciona “Esqueci a senha”
A1.1. Sistema solicita o login
A1.2. Internauta fornece o login
A1.3. Sistema valida o login [R1]
A1.4. Sistema gera uma senha temporária [R3]
A1.5. Sistema envia a senha temporária para o email do internauta [E1]
A1.6. Sistema registra a nova senha
A1.7. Sistema avisa para qual email a senha temporária foi enviada.
A1.8. Caso de uso é encerrado
[A2] Login ou senha inválida
A2.1. Sistema avisa que o login ou a senha são inválidos
A2.2. Vai para 1
Fluxos de Exceção: [E1] Erro no envio do email
E1.1. Sistema avisa que não foi capaz de enviar o email e pede que o
usuário contacte o suporte.
E1.2. Caso de uso é encerrado
Regras: R1 – É obrigatório que o login esteja registrado como válido
R2 – É obrigatório que a senha fornecida seja idêntica à senha associada ao login
R3 – É obrigatório que a senha temporária seja um número de 8 dígitos
Figura 5-17 – Descrição textual do caso de uso “Autenticar usuário” de acordo com o gabarito apresentado na Tabela 4-10 – página 81
No diagrama de atividades da Figura 5-16 é possível, também, observar a aderência desse modelo às restrições estabelecidas no escopo do metamodelo UCModel. A Tabela 5-12 lista as regras aplicadas ao exemplo da Figura 5-16, destacando os itens do diagrama onde a aderência à regra pode ser observada.
Tabela 5-12- Restrições aplicadas ao caso de uso "Autenticar usuário" da Figura 5-16
Metaclasse Restrições Item
UseCase 1) ID é obrigatório 2) Nome é obrigatório 3) Resumo é obrigatório 4) Criticalidade é obrigatória 5) Freqüência de uso é obrigatória 6) Pré-condição é obrigatória 7) Pós-condição é obrigatória
8) Deve ter pelo menos um ator associado
1
MainFlow 1) Deve possuir pelo menos uma transação 2
AlternativeFlow 1) Condição de guarda é obrigatória 5
127 3) Deve ser referenciado por pelo menos uma ação do
UseCase
3 4) Deve estar sempre associado a ações do mesmo tipo,
ou seja, sempre é disparado por ações do mesmo tipo 3 6) Se for disparado por uma SystemAction, então sua
primeira ação tem que ser uma SystemResponse ou uma UML::ActivityFinalNode
9
7) Se for disparado por uma SystemResponse, então sua primeira ação tem que ser uma SystemResponse, uma
SystemAction ou uma UML::ActivityFinalNode
10
ExceptionFlow 1) Condição de guarda é obrigatória 5
2) Deve ter pelo menos uma ação 6
3) Deve ser referenciado por pelo menos uma ação do
UseCase
4 4) Deve estar sempre associado a ações do mesmo tipo,
ou seja, sempre é disparado por ações do mesmo tipo 4 5) Se for disparado por uma SystemAction, então sua
primeira ação tem que ser uma SystemResponse ou outra SystemAction
4
ActorAction 1) Descrição da ação é obrigatória 2) Deve ter um ator associado
3) Não pode ser a última ação de um fluxo 4) Deve ser sucedida por uma SystemAction,
IncludeUCAction ou ExtendUCAction
11
SystemAction 1) Descrição é obrigatória
2) Deve ser sucedida por outra SystemAction,
SystemResponse, UML::ActivityFinalNode, IncludeUCAction ou ExtendUCAction
12
SystemResponse 1) Descrição é obrigatória
2) Deve ser sucedida por uma ActorAction,
UML::ActivityFinalNode, IncludeUCAction ou ExtendUCAction
13
ConceptualRule 1) Descrição é obrigatória
2) Deve ser referenciada por pelo menos uma ação do UseCase
7 e 8
5.6 Conclusão
Este capítulo apresentou o metamodelo UCModel, definido no escopo deste trabalho com o objetivo de oferecer um arcabouço sintático e semântico a partir do qual é possível estruturar a especificação do comportamento do sistema através de um conjunto de critérios e restrições que apóiam a especificação de casos de uso.
Dois princípios nortearam a definição do metamodelo UCModel:
O conceito de transação de casos de uso (JACOBSON, 1992), a partir do qual foi elaborado um conjunto de ações especializadas para especificação das seqüências de ações do caso de uso, e;
As perspectivas de projeto Web, que reforçaram a especialização das ações do sistema a partir da definição das perspectivas onde essas ações atuam.
128 A formalização sintática e semântica da especificação dos casos de uso, proporcionada pelo UCModel, é um dos elementos chave da abordagem proposta nesta tese, pois ela traz a possibilidade de explorar cenários relacionados à garantia da qualidade da especificação e do produto final, como:
Definição de um apoio computacional para verificação automática de defeitos sintáticos nas especificações de casos de uso, ou seja violações das regras do metamodelo UCModel;
Elaboração de um conjunto de orientações para descrição de casos de uso, baseado na semântica dos elementos do UCModel;
Elaboração de regras de transformação modelo-modelo com o propósito de derivar modelos de testes funcionais a partir dos modelos de especificação.
Com relação ao primeiro cenário, uma ferramenta denominada UseCaseAgent foi definida e implementada com o objetivo de apoiar a construção e verificação sintática de especificações de casos de uso, segundo os conceitos preconizados pelo UCModel, além de permitir a geração da descrição textual do caso de uso a partir do seu diagrama de atividades.
No segundo cenário, o conjunto de orientações definido a partir da semântica do UCModel apoiou a elaboração de um conjunto de questões de uma técnica customizável de inspeção de diagramas de atividades baseada em checklist, chamada ActCheck (MELLO, 2011). Adicionalmente, a descrição textual do caso de uso, obtida a partir do diagrama de atividades, oferece a possibilidade do uso de técnicas de inspeção de casos de uso não especificamente projetadas a partir dos conceitos do metamodelo UCModel, mas alinhadas conceitualmente com a estrutura de especificação preconizada por esse metamodelo. Como exemplo, duas técnicas desenvolvidas por pesquisadores brasileiros podem ser aplicadas nesse contexto: a técnica GUCCRA (BELGAMO e FABBRI, 2004) e a técnica desenvolvida por GREGOLIN e DEBONI (2008), ambas avaliadas experimentalmente (BELGAMO et al., 2005; SANTOS e TRAVASSOS, 2010).
Para o terceiro cenário, uma outra ferramenta denominada ModelT2 (ALBUQUERQUE et al., 2010) também foi definida e implementada com o objetivo de derivar modelos de testes funcionais a partir dos modelos de especificação.
Dessa forma, o metamodelo UCModel contribui para o objetivo geral deste trabalho, oferecendo um arcabouço conceitual a partir do qual técnicas e ferramentas de apoio à especificação e garantia da qualidade podem ser definidas e implementadas.
129 O capítulo 6 apresenta o apoio computacional elaborado com o objetivo de apoiar a abordagem de especificação e garantia da qualidade proposta neste trabalho. Detalhes sobre a utilização das ferramentas UseCaseAgent e ModelT2 também são apresentados nesse capítulo.
130