Casos de Uso

Origem: Wikipédia, a enciclopédia livre.

Este artigo precisa ser wikificado.

Por favor ajude a formatar este artigo de acordo com as diretrizes estabelecidas no livro de estilo.
Remova este aviso somente depois de todo o texto estar wikificado.

Foi proposta a fusão deste artigo com: Caso de uso.

[editar] Introdução

O processo de identificação de requisitos na engenharia de software tem uma função fundamental no correto desenvolvimento do projeto, pode-se no entanto facilmente tornar num processo extenso e trabalhoso. Ao longo do desenvolvimento da área de engenharia de computação iniciada em meados da década de 80, vários autores sugeriram diversas técnicas para um processo mais rápido e eficiente de levantamento e validação de requisitos de sistemas de software. Uma das técnicas mais populares é a utilização de casos de uso para descrever claramente todos os requisitos de um dado sistema, esta técnica foi conceitualizada por Ivar Jacobson, e desenvolvida por várias outras personalidades do campo, é de mencionar especialmente o contributo de Alistair Cockburn. Este artigo pretende justamente elucidar sobre a utilização de casos de uso na engenharia de software. Incluindo, como elaborar um caso de uso corretamente; quais os seus benefícios e limitações para o processo de levantamento de requisitos, e quais alternativas e processos complementos devem ser tidos em conta na sua utilização.

[editar] Enquadramento

A engenharia de requisitos em si mesmo consiste num processo que ocorre ao longo do tempo onde são identificados todos os diferentes requisitos que um dado sistema de software deverá satisfazer quando se encontrar funcional. Este processo pode ser desenvolvido recorrendo a várias diferentes técnicas, algumas delas complementares entre si. O objectivo final é o de obter todos os requisitos idealizados para o sistema, possivelmente classificados por ordem de importância, descritos o mais claramente possível e devidamente validados pelos stakeholders do sistema.

A clareza com que os requisitos são descritos e a sua abrangência que é idealizada pelos stakeholder é a máxima prioridade do processo tendo em vista não só a necessidade de transição do conhecimento dos requisitos do sistema para os programadores que o irão implementador e utilizadores que o irão utilizar, mas também para garantir que todo o conteúdo pretendido pelos stakeholders está identificado antes do processo de implementação começar de modo a facilitar a arquitectura e planeamento de implementação da solução evitando re-arquicteturas e re-construções desnecessárias.

Como referido anteriormente, existem várias técnicas para auxiliar a tarefa de levantamento de requisitos. Entre as mais reconhecidas e aconselhadas encontram-se as seguintes que iremos descrever neste artigo apenas muito sucintamente:

• Entrevistas com stakeholders do sistema
• Workshops de requisitos
• Listagem contratual de requisitos
• Prototipagem
• Casos de uso
• Identificação de stakeholders

Entrevistas com stakeholders do sistema

Consiste em efetuar entrevistas com os utilizadores e visionários do sistema tentando obter uma ideia das várias necessidades que o sistema deve satisfazer. Workshops de requisitos

Sessões de grupo com os utilizadores e visionários do sistema promovendo o debate e discussão de ideias sobre o sistema a desenvolver. Listagem contratual de requisitos

Consiste em elaborar uma listagem contendo todas as necessidades que o sistema deverá satisfazer.

Prototipagem

Criação, apresentação e debate de modelos de interacção não funcionais que ajudem a ilustrar como o sistema se deverá comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema.

Diagrama de Caso de Uso

Descreve a funcionalidade proposta para o novo sistema. Um Caso de Uso representa uma unidade discreta da interacção entre um usuário (humano ou máquina) e o sistema. Um Caso de Uso é uma unidade de um trabalho significante. Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são todos Casos de Uso. Cada Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto. Um Caso de Uso pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.

Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.

Expansão de Diagrama de Casos de uso

Consiste na explicitação de todas as diferentes funcionalidade do sistema, que permitirá inferir e identificar mais claramente outras necessidades.

Identificação de stakeholders

Determinação clara de quem irá usar o sistema e de quem o visionou, discertindo quais os objectivos iniciais por detrás da ideia, de modo a poder entender o que esperam que o sistema cumpra.

[editar] Definição

O processo sobre o qual este artigo se foca é o da utilização de casos de uso na engenharia de requistos.

Cada chamado caso de uso descreve um cenário de possivel interação, podendo ser com um utilizador ou um outro sistema. Os casos de uso devem ser o mais claros possivel para que todos os eventuais leitores de diferentes campos e backgrounds os possam entender de igual modo. Devendo-se assim evitar termos técnicos ou obscuros que possam possivelmente dificultar a compreensão inequivoca da funcionalidade descrita.

Cada caso de uso deve descrever somente uma funcionalidade ou objectivo do sistema. É então comum, para sistemas minimamente complexos, serem necessários bastantes casos de uso para uma correcta e completamente descrição de todas as funcionalidades requeridas pelo sistema.

Os casos de uso devem ser identificados através de nomes curtos que identifiquem a sua actividade inequivocamente, para tal são usualmente utilizadas as formas verbais activas...

Para facilitar a visão geral do sistema é usual agregar casos de uso similares em pacotes e criar diagramas que ilustrem essa agregação e qual a interação com outros sistemas ou utilizadores do sistema.

Os casos de uso nestes diagramas são usualmente representados por ovais com setas a indicar quais os utilizadores ou sistemas externos que interagem com eles.

A criação destes diagramas deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o actor não tem conhecimento sobre o estado interno do sistema quando acede a uma dada funcionalidade. Devendo as interações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de interação simplifica a descrição dos requisitos e evita falsas assumpções sobre como a funcionalidade será implementada no sistema.

O standard mais seguido para a elaboração de diagramas de caso de uso, também habitualmente referidos como modelos de caso de uso, é o introduzido pelo UML. Embora sendo este o standard mais comum, é de notar que existem alternativas e que na prática o standard utilizado é o definido pelo manual de qualidade do projecto em curso que habitualmente deve ser préviamente definido de acordo com as necessidades previstas do projecto, podendo vir a ser redefinido consoante alterações lógicas encontradas durante processo.

O nivél de detalhe da descrição do caso de uso dependerá sempre do nivél de formalidade exigido pelo projecto e do estado actual de desenvolvimento. Em nivéis iniciais pode-se assumir uma descrição mais breve e sucinta, em estados mais avançados será de esperar um maior detalhe e cuidado.

Exemplo de um caso de uso:

É de referir que um caso de uso bem elaborado não inclui somente um diagrama correcto e uma descrição clara. È habitual um caso de uso conter mais secções que ajudem na eficiência do processo de levantamento de requisitos, no próprio workflow de trabalho e na facilidade de imediata compreensão e rápida leitura do caso de uso por elementos estranhos à sua criação.

Também importante para garantir a usabilidade específica do caso de uso é o intrusamento entre os diversos casos de uso do projecto. É imperativo elaborar casos de uso que tanto facilitem o acesso à vista global do sistema, como explicitem completamente todos os promenores de todas as funcionalidades requisitadas.

[editar] Secções habituais nos Caso de Uso

Há alguns cuidados a ter para ter a certeza que um caso de uso está correctamente compreendido. Habitualmente é adoptado um standard que requere o preenchimento de alguns campos relativos ao caso de uso de modo a facilitar o trabalho em grupo e a clareza do relacionamento entre vários casos de uso, e do caso de uso em relação aos actores e ao próprio sistema.

Algumas das secções habitualmente utilizadas incluem:

• Nome
• Iteração ou estado de desenvolvimento
• Sumário
• Pré-condições
• Triggers
• Linha de Eventos
• Percursos Alternativos
• Pós-condições
• Regras de negócio
• Notas
• Autor e data

Nome

Identificador inequivoco do caso de uso, deve ser escrito em formato de verbo/substantivo e ser suficiente para o utilizador perceber a que se refere o caso de uso.

Iteração ou estado de desenvolvimento

Descrição do estado actual do caso de uso à medida que este vai evoluindo.

Sumário

Curto resumo do caso de uso.

Pré-condições

Listagem das condições que se devem verificar quando o utilizador inicia este caso de uso. Não incluem triggers.

Triggers

Eventos que ocorrem dando inicio ao caso de uso. Podem ser externos, temporais ou internos.

Linha de Eventos

Esta secção descreve o curso de eventos ou cenário que se realiza. Usualmente é descrito através de uma sequência de eventos numerados.

Percursos Alternativos

Descrição de percursos alternativos à linha de eventos básica.

Pós-condições

Descrição do estado do sistema após a execução do caso de uso

Regras de negócio

Secção reservada para informação adicional relativa à politica da empresa ou restrições impostas pelo tipo de negócio.

Notas

Informação adicional relativamente ao caso de uso, não coberta pelas secções anteriores.

Autor e data

Listagem dos autores e datas das várias versões revistas.

[editar] Vantagens do Caso de Uso

A utilização de casos de uso é uma técnica relativamente recente, mais fléxivel, que contrasta com a documentação extensiva que usualmente pretende mas tipicamente falha em registar todos os requisitos possiveis de um sistema antes deste começar a ser construido.

As vantagens da utilização de casos de uso no processo de engenharia de requisitos incluem:

• A modelação de um caso de uso (incluindo a sua especificação) é geralmente aceite como uma excelente técnica para a captura dos requisitos funcionais de um sistema.
• Casos de uso desencorajam o design prematuro.
• Casos de uso podem ser usados a base para o esforço de estimação, planeamento e validação.
• Casos de uso são reutilizaveis dentro de um projecto. O caso de uso pode evoluir com cada iteração, desde um método de levantamento de requisitos, para linhas gerais de desenvolvimento aos programadores, para um caso de teste, até á documentação.
• Caminhos alternativos de um caso de uso registam comportamento adicional que pode melhorar a robustez do sistema.
• Casos de uso são uteis para sondar o verdadeiro âmbito do sistema. Podem ser facilmente adicionados ou removidos consoante a mudança de prioridades no desenvolvimento do projecto do sistema.
• Casos de uso são facilmente entendidos por todos os tipos de utilizadores, criando uma ponte entre os que desenvolvem o software e os stakeholders do sistema.
• As especificações de um caso de uso não requere a utilização de uma dada linguagem, podem ser escritos nos mais diversos estilos para encaixar com as necessidades do projecto.
• A utilização de casos de uso permite descrever um requisito como se contasse uma história. torna-se mais facil descrever requisitos sobre a forma de uma história ou cenário.
• Os casos de uso estão ligados directamente com a interação do sistema, isto permite aos designers da interface um maior envolvimento no processo de desenvolvimento do projecto quer antes ou em paralelo com os programadores de software.
• Casos de uso colocam os requisitos em contexto, são claramente descritos em relação às tarefas do negócio.
• Os diagramas de caso de uso ajudam os stakeholders a entender a natureza e escopo da area de negócio ou sistema em desenvolvimento.
• Diagramas de caso de uso podem ser gravados usando a notação UML e mantidos usando diferentes ferramentas CASE.
• Casos de uso e diagramas de caso de uso podem ser completamente integrados com outras deliverables de analise e design criados usando uma ferramenta CASE para produzir requisitos, design e repositório de implementação mais completos.

[editar] Limitações

As limitações da utilização de casos de uso incluem:

• Não facilitarem muito o levantamento dos requisitos não funcionais do sistema.
• O facto de utilizar um template de caso de uso não assegura clareza, esta dependerá sempre de quem elabora o caso de uso.
• A sua correcta interpretação requer sempre um processo de aprendizagem e ambientação, por parte quer dos utilizadores quer dos programadores.
• Utilizadores so sistema Extreme Programming por vezes consideram os casos de uso demasiado centrados na documentação, preferindo antes seguir descrições de uma utilização.

[editar] Referências

• Requirements Engineering: Main Techniques

• Use Case