Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Casos de Uso by Mind Map: Casos de Uso
0.0 stars - 0 reviews range from 0 to 5

Casos de Uso

BIBLIOGRAFIA CONSULTADA COCKBURN, Alistair. [2005] Escrevendo casos de uso eficazes: um guia prático para desenvolvedores de software. Porto Alegre: Bookman, 2005. COCKBURN, Alistair. [s.d.] Structuring use cases with goals. Disponível em: http://alistair. cockburn.us/Structuring+use+cases+with+goals Acesso em: 24-08-2009. LARMAN, Craig.[2007] Utilizando UML e padrões: uma introdução à análise de ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007. RIBEIRO, Antonio Mendes. [2009a] Modelagem de requisitos baseada em objetivos - com utilização de casos de uso. (Notas de aula da disciplina Produtividade com novas tecnologias, Curso de Especialização em Informática - Ênfase Análise de Sistemas). 2009. RIBEIRO, Antonio Mendes. [2009b] Requisitos de sistemas: conceitos básicos. (Notas de aula da disciplina Produtividade com novas tecnologias, Curso de Especialização em Informática - Ênfase Análise de Sistemas). 2009. ROBINSON, Willliam, ELOFSON, Greg. [s.d.] Análise de casos de uso baseada em objetivos. Disponível em: http://umbu.ied.dcc.ufmg.br/ead/file.php/127/Artigos_Tecnicos/ Analise_ com_Casos_de_Uso_baseada_em_ObjetivosR.doc Acesso em: 24-08-2009.  

Conceito

Casos de uso podem ser definidos como   "Um método semi-formal que permite captar, definir e organizar requisitos. De uma forma consistente e estruturada definindo os seus diversos cenários a partir de uma hierarquia de objetivos." (RIBEIRO, 2009b)   Essa definição ressalta a relação entre casos de uso e requisitos. Casos de uso são meios de fazer surgir, apresentar e organizar requisitos. Um caso de uso descreve uma interação de um agente externo com o sistema em desenvolvimento. Cada passo dessa interação é um objetivo ou requisito do sistema. Um caso de uso organiza esses objetivos ou requisitos, fornecendo um método para apresentá-los. A criação dos casos de uso ajuda a fazê-los surgir.   A partir desse conceito, pode-se entender melhor a afirmação de que a visão dos casos de uso de um sistema mostra o conjunto de seus requisitos funcionais.    

Origem

Casos de uso são uma ferramenta de especificação de requisitos criada por Ivar Jacobson [1996], e que hoje são usados em diversas metodologias de desenvolvimento de software. Para Jacobson, o modelo de casos de uso corresponde a uma das visões de um software, e é um dos componentes do modelo de requisitos. Os casos de uso correspondem aos requisitos funcionais de um sistema.   Depois de Jacobson, Cockburn [2005] e Larman [2007] também trouxeram contribuições ao tema. Cockburn dedicou um livro à especificação de casos de uso, analisando padrões, boas práticas e conceitos envolvidos na sua elaboração. Nessa mesma linha, o livro de Larman sobre análise e projeto de sistemas trouxe um capítulo sintetizando esses tópicos.   Um tópico importante é a questão da metodologia para elaboração de casos de uso. A abordagem inicial de Jacobson [1996, op.cit.] não envolvia muito detalhamento nessa questão. Larman trata das práticas para a criação de casos de uso, através de reuniões de trabalho entre os interessados e desenvolvedores, mas não chega a uma abordagem mais formal de como derivar os casos de uso. Uma abordagem desse tipo foi proposta por Robinson e Elofson [s.d.], seguindo um caminho aberto por Cockburn [s.d.], ao relacionarem casos de uso e objetivos.    

Conceitos relacionados

Agente

Agentes são entidades que se comunicam numa interação. Uma interação corresponde ao envio de uma mensagem entre agentes ou, recursivamente, a uma sequência de interações. Os agentes podem ser internos ou externos ao sistema. O próprio sistema pode ser visto como um agente.   Os agentes externos podem ser primários ou secundários. O agente primário é aquele que busca atingir um objetivo na interação com o sistema. O agente secundário é um auxiliar, de que o sistema se vale, para atingir os objetivos do agente primário.   Por exemplo: se faço compras num site on-line, estou agindo como agente externo, primário, do sistema. Se o sistema usa um outro sistema para efetuar o pagamento (como PagSeguro, por exemplo) esse é um agente secundário.    

Ator

No âmbito de um caso de uso, um ator é um agente externo. Atores são todas as entidades que interagem com o sistema, sejam elas agentes primários ou secundários. No caso do exemplo da loja on-line, acima, tanto o comprador quanto o PagSeguro são atores do sistema.    

Cenário

Os atores primários interagem com o sistema buscando objetivos. Para atingir esses objetivos, tais atores executam uma série de passos, ou interações, com o sistema. O sistema, por sua vez, pode recorrer a atores secundários para auxiliá-lo na consecussão do objetivo do ator. O resultado dessas interações pode ser o objetivo satisfeito ou abandonado. O conjunto dessas interações, mais o resultado obtido, compõe um "cenário" de interação entre ator e sistema.    

Caso de uso

Uma coleção de cenários, que representa um conjunto de interações entre um agente primário e o sistema, buscando atingir um objetivo, corresponde a um caso de uso. O caso de uso pode ser constituído de apenas um cenário, ou por vários. Os cenários podem resultar na obtenção do objetivo (cenários de sucesso) ou no seu abandono.  

Relacionamentos

Inclusão

Extensão

Especialização

Tipologias

Abstratos X Concretos

Casos de uso abstratos são casos de uso compostos por objetivos, enquanto casos de uso conretos são compostos por requisitos e especificações. A diferença diz respeito ao nível de detalhe que é incluído no caso de uso: no primeiro tipo, não são feitas referências às condições concretas de implementação (plataforma, interfaces, etc.), enquanto no segundo tipo esses detalhes já têm lugar.    

Escopo de desenvolvimento

Na classificação de Cockburn [2005], segundo o escopo de desenvolvimento, um caso de uso pode ser: a) de empresa - quando discute o comportamento de toda a organização ou entidade na realização do objetivo do ator primário. Isso pode ser toda uma empresa ou um departamento ou órgão dentro dela; b) de sistema - quando abrange apenas o software ou hardware que se quer desenvolver. O sistema em desenvolvimento se comunica com outros elementos - usuários, sistemas auxiliares, etc. que serão os atores primário e secundários do sistema; c) de subsistema - quando o escopo abrange apenas uma parte (unidade, componente, etc.) do sistema em desenvolvimento.  

Níveis de objetivos nomeados

Para Cockburn [2005], os casos de uso podem ser classificado conforme os níveis de objetivos nomeados. Nesse caso, eles podem ser: a) de nível de resumo: são casos de uso que contextualizam os objetivos de usuário, mostram a sequência de desdobramento dos objetivos relacionados e fornecem um índice para os casos de uso de nível mais baixo; b) de nível de usuário: são os casos de uso principais, mostram um ator primário procurando alcançar um objetivo na utilização do sistema. O objetivo do usuário pode ser atingido ou abandonado; c) de subfunção: quando detalham o comportamento interno do sistema ou de algum de seus componentes. Casos de uso desse tipo são mais raramente escritos do que os anteriores.

Metodologia: derivar a partir de objetivos

Importância dos objetivos

O levantamento de objetivos na análise de requisitos assume relevância por que:   a) objetivos permitem o levantamento completo de requisitos (critério de completude); b) objetivos servem para que se evite o levantamento de requisitos desimportantes (critério de relevância); c) fornecem um modo de apresentar requisitos para as partes interessadas no projeto; d) fornecem um modo de organização para documentos de requisitos complexos; e) fornecem critérios para avaliação de alternativas e solução de conflitos.    

Objetivos, requistos e especificações

Um objetivo é uma propriedade que se deseja obter do ambiente. Objetivos dizem respeito apenas ao estado desejado do ambiente, não fazendo referências a condições do sistema (interfaces, tecnologia, etc.).   Um requisito é um tipo especial de objetivo, que especifica um comportamento desejado do sistema. Para isso, um requisto deve fazer alguma consideração sobre o modo como o sistema será implementado ou sobre variáveis controladas e monitoradas pelo sistema. Um requisito é um elo de ligação entre objetivos, que são puramente ambientais, e especificações, que dizem respeito unicamente ao funcionamento interno do sistema.   Especificações são tipos de requisitos que dizem respeito unicamente ao comportamento do sistema e às suas variáveis. Ao contrário dos requisitos, as especificações não fazem referência a variáveis ambientais.    

Passos

A especificação de casos de uso a partir de objetivos envolve, segundo Robinson [s.d.], os seguintes passos:   a) eliciar o contexto do sistema; b) definir os objetivos do sistema; c) derivar os requisitos; d) derivar os casos de uso; e) derivar os modelos UML.   Os passos a) e b) referem-se à descoberta de um conjunto inicial de objetivos, ponto de partida para o trabalho posterior. Pode-se perguntar "de onde vêem" esses objetivos iniciais?  

De onde vêem os objetivos?

Os objetivos de um sistema nem sempre estão explicitos. Os explicitios podem ser captados através de entrevistas com os interessados, através do exame de documentos da organização e de ferramentas como uma lista de deficiências e problemas do sistema atual. Os obetivos implícitos devem ser eliciados, ou seja, deve-se fazê-los vir à tona, usando técnicas específicas. O detalhamento dessas técnicas foge ao escopo deste trabalho.

Como derivar requisitos?

No processo de derivação dos requisitos, parte-se de um conjunto inicial de objetivos/requisitos. A partir destes, pergunta-se sucessivamente "como tal objetivo pode ser atingido?", obtendo-se um aprofundamento da análise, ou "por que tal objetivo está aqui?", permitindo-se esclarecer os objetivos superiores do sistema.   Os sucessivos refinamentos para cima ou para baixo conduzem à criação de uma árvore de objetivos. Nela, cada objetivo pode ser sucessivamente refinado em termos de outros objetivos ou de requistos. Os sub-objetivos podem estar relacionados por conjunção (valor lógico "E") ou por disjunção (lógico "OU").   Na obtenção de sucessivos refinamentos, é importante saber quando parar o detalhamento. A orientação de Robinson [s.d.] é que tal refinamento deve ser suspenso no momento em que os requisitos derem lugar à especificações do sistema. As especificações referem-se ao comportamento do sistema, sem referências ao ambiente que o cerca. Nos sucessivos detalhamentos de objetivos e requisitos, tende-se a chegar ao momento em que as diretrizes referem-se apenas ao comportamento interno do sistema, sem referência a variáveis ambientais. Esse é o momento em que o refinamento dos objetivos deve ser suspenso.  

Como derivar casos de uso?

A técnica para derivar os casos de uso a partir da árvore de objetivos são tratadas, de uma maneira mais formal, em Robinson [s.d.]. A idéia geral está descrita abaixo, de uma maneira mais informal.   O ponto de partida da derivação de casos de uso é a hierarquia de objetivos. Dado um objetivo qualquer nessa hierarquia, os seus filhos podem ser ordenados para dar origem a um caso de uso. O tipo de caso de uso criado depende do tipo de itens que o compõe. Caso sejam objetivos, isso dará origem a um caso de uso abstrato, caso sejam requisitos, tratar-se-á de um caso de uso concreto ou mesmo de um de baixo nível.   Robinson mostra como, a partir do objetivo "o elevador deve mover passageiros entre os andares", pode-se derivar um caso de uso abstrato, correspondente aos seus sub-objetivos, e um caso de uso concreto, correspondente aos requisitos derivados. O caso de uso é criado lançando-se objetivos e requisitos como ações do sistema, e preenchendo as ações do usuário (ator principal) relacionadas a entradas ou saídas.   Nesse caso, as ações do sistema implicaram as ações do ator. Também poderia acontecer o oposto: as ações do ator implicarem as ações do sistema.