Cenários e Casos de Uso
Álvaro Palitot
Everton Guerra
Guilherme Carvalho
João Kuae
Universidade Federal de Pernambuco – Centro de Informática
Cx. Postal 7851, CEP 50732-970, Recife-PE, Brasil
(+55 81) 2126-8430, Fax: (+55 81) 3271-8438
{aabp,egm2,ggc,jmkc}@cin.ufpe.br
Abstract
1. Introdução
2. Casos de Uso
In software engineering, a use case is a technique for capturing the
potential requirements of a new system or software change. Each use case
provides one or more scenarios that convey how the system should interact
with the end user or another system to achieve a specific business goal. Use
cases typically avoid technical jargon, preferring instead the language of the
end user or domain expert.
A collection of possible scenarios between the system under discussion and
external actors, characterized by the goal the primary actor has toward the
system's declared responsibilities, showing how the primary actor's goal might
be delivered or might fail.
Use cases are goals (use cases and goals are used interchangeably) that are
made up of scenarios. Scenarios consist of a sequence of steps to achieve the
goal, each step in a scenario is a sub (or mini) goal of the use case. As such
each sub goal represents either another use case (subordinate use case) or an
autonomous action that is at the lowest level desired by our use case
decomposition.
This hierarchical relationship is needed to properly model the requirements
of a system being developed. A complete use case analysis requires several
levels. In addition the level at which the use case is operating at it is important
to understand the scope it is addressing. The level and scope are important to
assure that the language and granularity of scenario steps remain consistent
within the use case.
2.1. Atores e sua relação com os Casos de Uso
Actors are basically users of the system. They are actually user types or
categories. Actors are external entities (people or other systems) who interact
with the system to achieve a desired goal. Use Cases are what happens when
actors interact with the system. An actor uses the system to achieve a desired
goal. By recording all the ways our system is used ("cases of use" or Use Cases)
we accumulate all the goals or requirements of our system.
A use case is a collection of possible sequences of interactions between the
system under discussion and its Users (or Actors), relating to a particular goal.
The collection of Use Cases should define all system behavior relevant to the
actors to assure them that their goals will be carried out properly. Any system
behavior that is irrelevant to the actors should not be included in the use
cases.
2.2. Definindo casos de uso
There are many methods of defining how to pick or create a use case. The
use cases in this report are generated using a goal oriented Structuring
Methodology presented by Alistair Cockburn of Humans and Technology.
Examining all the Actor's goals that the system satisfies yields the functional
requirements. Goals summarize system function in understandable verifiable
terms of use that users, executives and developers can appreciate and leave
little open to interpretation.
Use Cases:
 Hold Functional Requirements in a easy to read, easy to track text
format.
 Represents the goal of an interaction between an actor and the system.
The goal represents a meaningful and measurable objective for the
actor.
 Records a set of paths (scenarios) that traverse an actor from a trigger
event (start of the use case) to the goal (success scenarios).
 Records a set of scenarios that traverse an actor from a trigger event
toward a goal but fall short of the goal (failure scenarios).
 Are multi-level, one use case can use/extent the functionality of
another.
Use Cases Do Not...
 Specify user interface design. They specify the intent, not the action
Detail
 Specify implementation detail (unless it is of particular importance to
the actor to be assured that the goal is properly met)
Use Cases are used during many stages of software development.
 To Capture the Requirements of the systems.
 To act as a spring board for the software design.
 To validate the software design against.
 For Software Test and Quality Assurance. (Tests are performed to
validate proper and complete implementation of the use cases)
 Potentially as an initial framework for the on line help and user manual.
2.3.
3. Cenários
Scenarios are used to represent paths of possible behavior through a use case, and
these are investigated to elaborate requirements. Scenarios have been advocated as
an effective means of communicating between users and stakeholders and anchoring
requirements analysis in real world experience.
Scenarios often describe information at the instance or example level. Scenarios
may be used to validate requirements, as ‘test data’ collected from the observable
practice, against which the operation of a new system can be checked. Alternatively,
scenarios may be seen as pathways through a specification of system usage, and
represented as animations and simulations of the new system.
3.1. Engenharia de Requisitos baseada em Cenários
Estágios da Engenharia de Requisitos baseada em Cenários
Elicit and document use case. In this stage use cases are elicited directly from users
as histories of real world system usage or are created as visions of future system
usage. The use case model is validated for correctness with respect to its syntax and
semantics. The paper does not report this stage is in detail.
Analyze generic problems and requirements. A library of reusable, generic
requirements attached to models of application classes is provided. A browsing tool
matches the use case and input facts acquired from the designer to the appropriate
generic application classes and then suggests high level generic requirements attached
to the classes as design rationale “trade-offs.” Generic requirements are proposed at
two levels: first, general routines for handling different event patterns, and secondly,
requirements associated with application classes held in the repository. The former
provide requirements that develop filters and validation processes as specified in
event based software engineering methods (e.g., Jackson System Development [27]);
while the latter provide more targeted design advice; for instance, transaction
handling requirements for loans/hiring applications.
Generate scenarios. This step generates scenarios by walking through each possible
event sequence in the use case, applying heuristics which suggest possible exceptions
and errors that may occur at each step. This analysis helps the analyst to elaborate
pathways through the use case in two passes; first for normal behavior and secondly
for abnormal behavior. Each pathway becomes a scenario. Scenario generation is
supported by a tool which automatically identifies all possible pathways through the
use case and requests the user to select the more probable error pathways.
Validate system requirements using scenarios. Generation is followed by toolassisted validation which detects event patterns in scenarios and presents checklists of
generic requirements that are appropriate for particular normal and abnormal event
patterns. In this manner requirements are refined by an interactive dialogue between
the software engineer and the tool. The outcome is a set of formatted use cases,
scenarios, and requirements specifications which have been elaborated with reusable
requirements.
Although the method appears to follows a linear sequence, in practice the stages are
interleaved and iterative.
4. UML
A UML permite ao analista representar o sistema seguindo diferentes visões. Cada visão
possui uma grande dependência das outras visões, garantindo assim a coerência e
completeza do modelo, e conseqüentemente do sistema de software. A relação entre os
diagramas deve ser garantida pelo projetista mas não é assegurada pela UML. Este
trabalho estuda a relação entre os diagramas de modo a garantir que o sistema projetado
pelo conjunto de diagramas seja coerente.
5. Casos de uso ágeis
A metodologia ágil propõe uma mudança de atitude. Os valores propostos por
ela podem dificultar bastante a adaptação de uma equipe de desenvolvimento.
Pessoas e interações são mais valorizadas que processos e ferramentas. É
importante a equipe de desenvolvimento estar sempre em contato com os usuários
daquele determinado software. A comunicação entre estas partes é essencial para o
sucesso do projeto e deve ser suficiente para que todos os stakeholders sempre saibam
o estágio do produto.
Documentações extensivas que demoram muito tempo para serem elaboradas
atrasam o projeto e pouco agregam ao contratante. A metodologia ágil determina que
muito mais valor é agregado para o cliente quando é mostrado partes do software
funcionando ao invés da mais compreensiva documentação possível. Isto é, pequenas
partes são desenvolvidas e apresentadas ao cliente que avalia se está realmente como
acordado.
Outro ponto de destaque é a valorização da colaboração do cliente sobre
negociações contratuais com o mesmo. Isto é percebido ao abandonar o documento
que descreve todo o software detalhadamente a ponto de permitir que seja assinado
um contrato formal. Existe muito mais valor quando o cliente participa da equipe de
desenvolvimento influenciando diretamente nas decisões e no rumo do
desenvolvimento.
Com esta metodologia o cliente tem total capacidade de perceber se o
software está exatamente como desejado. É possível acontecer e, até normal que
aconteça, mudanças nas pequenas partes apresentadas. O interessante é perceber que
estas mudanças serão simples de resolver uma vez que o restante do software já foi
devidamente apresentado e aprovado pelo cliente. Outra característica essencial é
que fica fácil para o cliente identificar o que precisa ser modificado e explicar
claramente como gostaria que ficasse já que o software está na sua frente, mesmo
que em uma versão um pouco diferente da almejada.
Com a metodologia ágil, portanto, o foco do desenvolvimento torna-se oferecer
frequentemente pequenas partes usáveis de software ao cliente utilizando a técnica
just-in-time, pois é feito de acordo com as necessidades do mesmo. Ao final da
interação recebe-se feedback para nova etapa.
A utilização de casos de parece contradizer este tipo de metodologia, mas os
casos de uso também podem ser ágeis. A utilização de casos de uso na documentação
contribui muito para o entendimento de todos, mas as documentações extensas
tornam o processo muito custoso. Uma documentação deve possuir conteúdo
exatamente suficiente para que os programadores entendam as decisões do sistema e
que os usuários e clientes entendam quais funcionalidades e casos de uso o sistema irá
prover para que possam dar feedback.
Os casos de uso ágeis propõem a construção de uma documentação simples
somente com nomes e breves descrições de todos os casos de uso. Deve-se apenas
detalhar os casos de uso quando pretende implementá-los a curto prazo não sendo
necessário entender completamente os casos de uso que serão trabalhos a longo
prazo. Deve-se sempre questionar a importância de cada documento ou detalhamento.
É essencial para documentar algo saber quanto será gasto para tal, quando será
necessário (curto/longo prazo), qual a forma mais rápida de fazê-lo e quem se
beneficiará com tal documentação? A reflexão sobre estas perguntas permite a equipe
identificar necessidade de documentos.
A idéia é escrever pouco de forma mais clara, sempre, sendo mais curto,
econômico e fácil de ler. Escrever casos de uso ágeis implica em não detalhar todos os
casos de uso com diagramas UML, não descrever interface, utilizar sempre menos de
10 passos para descrever o cenário principal e focar nos objetivos do usuário. A
depender das prioridades e características do projeto, casos de uso podem ser
descritos completamente detalhados, somente parágrafos descritivos ou pequenas
descrições de 1 ou 2 frases. Mas é sempre importante entender que os casos de uso
não serão lidos por compiladores, mas por seres humanos. Logo, devem ser adaptados
as necessidades da equipe.
Outra proposta é detalhar depois e adiantar o processo de desenvolvimento.
Incrementos acontecem de acordo com a necessidade percebida. Normalmente a cada
interação com o cliente onde é apresentada parte do software detalham-se os novos
casos de uso com seus fluxos alternativos. A metodologia just-in-time permite que
partes usáveis do software sejam criadas e entregues ao cliente rapidamente e
freqüentemente.
6. Conclusão