• Autora

    Pós-Graduando em Especialização em Informática – Ênfase Análise de Sistemas pela UFMG, Bacharel em Sistemas de Informação (2006) pela Faculdades Pitágoras (Campus Fadom), técnica em Informática (2002) e em Contabilidade (1998). Atualmente Analista de Suporte Júnior III.

  • Direitos Autorais

    Alguns dos materiais (artigos, pdf’s, link’s) disponíveis ou utilizados na edição desse Blog, foram retirados de páginas da internet. Se acaso, algum desses itens for protegido por direitos autorais, queira o detentor do mesmo, me comunicar por email e o material será imediatamente retirado ou darei os devidos créditos!
  • Categorias

  • Arquivos

  • Análise de Sistemas

    • 13,313 hits

Modelagem Orientada a Objetivos

OBJETIVOS

Estimulam a elaboração de requisitos sendo a sua base; [Dardenne 1991, Ross 1977, Rubin 1992];

Dizem  que proporcionam um critério para a integralidade da especificação dos requisitos –  a especificação é completa se todos os objetivos declarados são obtidos pela especificação [Yue 1987];

Fornecem uma justificação para a exigência de requisitos – um requisito existe devido a algum objetivo subjacente que fornece uma base para o mesmo [Dardenne 1991, Sommerville 1997];

Representam as raízes para a detecção de conflitos entre requisitos e para a resolução  eventual dos mesmos [Robinson 1989, van Lamsweerde 1998];

São geralmente mais estáveis do que os requisitos necessários para que sejam alcançados [Anton1994].

Resumo: Requisitos “implementam” objetivos da mesma forma como programas implementam especificações de projeto (design).

Mesmo sendo os objetivos reconhecidos como importantes, a sua utilização na modelagem baseada em objetos é rara, particularmente, nas metodologias baseadas na  UML.

Cockburn é frequentemente citado como tendo introduzido objetivos  na análise orientada a objeto [Cockburn 1997, Cockburn 1997].

Ele define casos de uso para satisfazer os objetivos: “Todas as interações que se referem a um mesmo objetivo. … O objetivo é um objetivo estratégico no que diz respeito ao sistema.”

Ele vê  cinco possibilidades para o uso de objetivos:

(1) atribuir requisitos não-funcionais a objetivos,

(2) acompanhar o projeto pelos objetivos,

(3) obter  requisitos diferentes  a partir do não alcance dos objetivos,

(4) utilização de objetivos associados a design das suas realizações,

(5) casar objetivos do usuário com conceitos operacionais.

Recentemente, Bock demonstrou  como objetivos podem auxiliar na escolha de parâmetros a partir de  modelos de objeto [Bock 2000, Bock 2001].

Objetivos às vezes são chamados de  funcionalidades (features).

Funcionalidade – “um serviço que o  sistema fornece  para atender as necessidades de uma ou mais partes interessadas (stakeholders).”-P. 89 [Leffingwell 2000].

Segundo  Leffingwell: [um software satisfaz requisitos => que satisfaz casos de uso => que satisfazem funcionalidades => que satisfazem necessidades dos usuários]

Assim, os analistas usam documentos diferentes para descrever diferentes níveis de abstração de um  sistema.

Embora as pessoas possam não chegar a um acordo em relação aos termos objetivo, funcionalidades, ou objetivos de software [Gross 2001], a maioria concorda que objetivos fornecem  um alvo para a especificação mais detalhada de software mostrada a seguir.

Um método Orientado a Objetivos
O método abaixo mostra como obter especificações com UML a partir de objetivos. Este é uma síntese dos  métodos comuns com UML, tais como o Rational Unified Process [Kruchten 2000], e os métodos de análise de requisitos orientados a objetivos, tais como KAOS [Dardenne 1993].

O método consiste em cinco atividades:

O que

Como

Quem

1. Eliciar o contexto do sistema. Informações sobre o sistema proposto, e de seu contexto. Por meio de entrevistas, coleta de documentos, observação, etc. Analista
2. Definir os objetivos do sistema. Baseado no contexto do sistema. Analista
3. Derivar requisitos. Objetivos  são refinados ao nível de requisitos. Analista
4. Derivar casos de uso. Casos de uso organizacionais, de sistema e de baixo nível. São derivados a partir dos requisitos. Analista
5. Derivar modelos UML. Outros modelos UML, tais diagramas de classe e seqüência. São derivados dos requisitos  ou casos de uso Analista

Eliciação é um processo comum a todos os métodos de análise de  sistemas. Definir objetivos e derivar requisitos são comuns nos métodos  orientados  a objetivos. Finalmente, definir casos de uso em vários  níveis de abstração e derivar os seus  modelos associados são comuns nos métodos orientados a objetos.

Adicionar objetivos  ao   método UML de análise acarreta  os seguintes benefícios.

Abstração. Objetivos  proporcionam descrições de alto nível, funcionais e não funcionais descrições compreensíveis do “o que” o sistema deve fazer, sem a complexidade de descrever como o sistema funciona [van Lamsweerde 2001].
Direção. Objetivos fornecem aos analistas uma checklist de atividades a completar [Sommerville 1997, Yue 1987].
Rastreabilidade. Objetivos fornecem uma ponte ligando os pedidos das partes interessadas (stakeholders) às  especificações do sistema [Robinson 1990, Robinson 1998].
Análise. Objetivos fornecem um meio para analisar o sistema antes da sua construção. Tal análise é importante, e inclui: análise de conflitos [Robinson 1994, van
Lamsweerde 1998] e de cobertura  [Yue 1987].

Definindo objetivos e requisitos de um sistema

Definindo objetivos e requisitos de um sistema

Requisitos derivados dos objetivos por refinamento

Os analistas detalham os objetivos adicionando detalhes, informações que restringem o Sw.

Os analistas estruturam os objetivos em função de como eles se relacionam uns com os outros.

Estruturação é importante quando existem muitos objetivos. Talvez, no caso de sistemas com um pequeno número de objetivos, digamos 25, podemos  ter  simplesmente fornecer uma  lista de objetivos.

Sistemas ==> Hierarquia estruturada de objetivos

Definindo uma  hierarquia de objetivos:

1°) Definir pelo menos um objetivo inicial e duas perguntas: como? e porque?

Alguns objetivos iniciais podem ser obtidos através de entrevistas, observações, bem como a revisão dos documentos  e sistemas existentes.

2°) Selecionar um objetivo e perguntar: “Como pode este objetivo ser satisfeito ?” e “Por que é que isto é um objetivo do sistema?”

As perguntas “Como” detalharão os objetivos em sub-objetivos; o que  expande a hierarquia de forma descendente através da introdução de objetivos que são mais especializados.

Objetivo: G conjunção de sub-objetivos: G1 e G2 e … Gn.

A figura 1(gráfico de árvore) ilustra uma estrutura hierárquica de objetivos. O objetivo mais abstrato, G1, é mostrado na parte superior, enquanto os objetivos mais  específicos, G8.1 e G9.1, são mostrados na parte inferior. Os objetivos G8 e G9 são apresentados como duas alternativas  para satisfazer o objetivo G1.2.1. Portanto, descrevemos o refinamento do objetivo G1.2.1, como um ou-refinamento. Em contrapartida, o refinamento do  objetivo G1 é mostrado como um e-refinamento: todos os sub-objetivos de um e-refinamento devem ser satisfeitos como o meio para cumprir o objetivo.

Hierarquia de Objetivos

A Figura 2 mostra a estrutura hierárquica de objetivos da Figura 1 representada no RequisitePro TM. Indentação e numeração hierárquica mostram a mesma informação da figura acima, permitindo ao mesmo tempo mais ordem e apresentação prática e textual.

Definição de Objetivos RequisitePro

Patterns de Refinamento

Um analista cria uma  hierarquia de objetivos  através do refinamento dos mesmos. Um objetivo é detalhado  adicionando mais detalhes específicos.


A tabela I apresenta  dois patterns  básicos que os analistas usam para gerar uma  hierarquia de  objetivos
:

Disjunçãosimplesmente  especifica alternativas para satisfazer um objetivo. Conjunçãodetalha a  descrição de um objetivo. Quanto mais detalhes  específicos  fornecidos,  maior a hierarquia dos objetivos relativa à descrição operacional necessária aos projetistas de software  e programadores.

Dois padrões de refinamento são freqüentemente utilizados[Darimont 1996]:

Marco decompõem o que se obtém num conjunto   de etapas intermediárias, a soma das quais  satisfazem o objetivo global.

Casos detalha o resultado num conjunto de casos, que se somam para satisfazer o objetivo total.

Tal como acontece com todos os patterns de refinamento, a soma dos e-sub-objetivos satisfazem o objetivo.

DisjunçãoConjunção

Quando parar de perguntar ‘Como’

Quando o refinamento deve parar? Quando um analista deve parar de perguntar “como”? Para responder esta pergunta, é necessário  ter uma compreensão mais profunda de requisitos.

Ideal requisitos são um conjunto mínimo  de descrições que restringem  o comportamento do sistema como um meio para alcançar as  propriedades desejada do meio ambiente.

Propriedades do domínio só devem ser incluídas quando necessário.

Por exemplo, como parte do refinamento de um objetivo: “Dado que o objetivo G1 pode ser satisfeito primeiro por  G1.1 e então por G1.2,  precisamos  implementar G1.2 por que G1.1 é  satisfeito pelo ambiente através da propriedade de domínio , P1”.

Da mesma forma, requisitos só precisam  ser incluídos se são necessários para descrever  as  interações do sistema com o meio ambiente.

Pode ser difícil para os analistas  reconhecer quando estão descrevendo propriedades do domínio e detalhes do sistema desnecessários. Por exemplo, dada uma série de refinamentos de objetivos, G1 ← G1.1 … ← G1.1.1.1.n, até que ponto é que o enésimo sub-objetivo torna-se um detalhe de implementação  desnecessário, em vez de um requisito do  sistema?

Um requisito:

=> Descreve simultaneamente  o ambiente e o sistema.

=> Especifica uma porção do sistema e as propriedades do domínio do qual  ele depende.

Um requisito derivado de muitos passos  de refinamento provavelmente não faz  referência ao ambiente.

Uma descrição que só referencia as propriedades do sistema é um tipo especial de requisito, chamado de especificação.

A Figura 3 mostra os comportamentos requeridos  como a intersecção entre comportamentos ambientais e comportamentos  implementáveis [Jackson 1995].

O sistema interage com uma parte do mundo, que exibe o comportamento ambiental,  representado pelas propriedades do domínio .

Comportamentos implementáveis   são executadas pelo sistema.

=>Um requisito refere-se às propriedades tanto do ambiente quanto do sistema.

=>Uma propriedade de domínio refere-se apenas a propriedades do ambiente.

=>Uma especificação de um sistema refere-se apenas a propriedades do sistema, mostra a forma como o sistema produz os seus comportamentos.

Requisitos como a interseção dos comportamentos ambientais e os implementáveis

O refinamento dos objetivos deve parar quando as descrições dos objetivos   não mais se referem às  propriedades do domínio.

Após esse ponto, o desenvolvimento se move da  análise para a fase de design (projeto).  Evidentemente, um projetista pode desejar refinar os objetivos como um meio para descrever o funcionamento interno do sistema.

Veja um exemplo:

Objetivo do sistema: movimento de passageiros.

Requisitos: descrição dos controles do elevador.

Especificações (Detalhes de implementação): descrições do rotor do motor.


Nota: Tudo que se refere ao sistema e suas propriedades de domínio o qual se trabalha é um requisito.

Objetivos, requisitos e especificações são semelhantes. Conforme apresentado na introdução, um objetivo é uma propriedade desejada do ambiente.

=>Requisito é um tipo especial de objetivo que tem certas restrições na utilização dos valores monitorizados e controlados.

=>Especificação é mais restrita, na medida  que apenas se refere às propriedades do sistema.

Analistas usam  objetivos para ajudar a decidir, para um certo sistema, se uma descrição é um requisito ou se é uma especificação. Isso é importante, por que o trabalho com as especificações  pode ser deixado de lado, até que a análise dos requisitos esteja satisfatória.

Assim, um analista pode dizer, “Se eu refinar o objetivo G1.1.1.1., será o início da especificação do sistema. Eu tenho que terminar meus requisitos antes que  eu comece  a fase de especificação . Então, eu vou verificar os outros objetivos para ver se eles estão suficientemente detalhados. “

Por que perguntar ‘por que?’

Ao fazer perguntas Por que, um analista pode obter a lógica dos objetivos do  sistema. Por exemplo, um analista pode ser apresentado ao  objetivo, “O controlador do elevador deve abrir e fechar as portas do elevador”. ” Por quê? “, pergunta o analista. Para um controlador de  elevador, isso pode parecer óbvio. Um  controlador  de elevador existe para controlar as portas e mover o elevador entre andares. Além disso, por que temos  softwares controladores de elevador?

Colocando questões Por que sobre o sistema  elevador, os analista são levados a considerar o custo dos controladores de elevador . Anteriormente, o trabalho dos ascensoristas era relativamente barato e software de controle de elevador  não existiam. Agora, o software de controle de elevadores é mais barato do que o trabalho do seu operador, quando amortizado ao longo da vida do elevador. Por conseguinte, quando a decisão sobre o controlador do elevador  é revista levando em conta a solução de software , esta parece melhor. Assim, estratégias de alto nível orientam as decisões de baixo nível.

Derivando casos de uso

Na  UML, um caso de uso “descreve uma sequência de ações que  um sistema executa que gera um resultado de valor para um determinado ator ” -p.491 [LEFFINGWELL 2000].

Casos de uso  podem descrever um sistema em diferentes níveis de abstração [Regnell 1996].

Reconhecemos três tipos comuns de casos de uso, com base em seus atores e no uso de declarações de especificação [Cockburn 1997, Larman 2001]:


Casos de uso de negócios incluem atores de múltiplas organizações, com o foco no fluxo de informações entre as organizações. Cada declaração no caso de uso é um objetivo ou um requisito, conforme definido na introdução. Um caso de uso de workflow inter-organizacional é um exemplo típico.
Casos de uso de tarefa incluem atores de uma única organização, com o foco no estabelecimento do processamento de informação necessário para fornecer valor aos atores. Cada declaração no caso de uso ou é um objetivo ou um requisito. Um caso de uso de interface do usuário é um exemplo típico.
Casos de uso de baixo nível resultam da decomposição ou organização de casos de uso de tarefa; as declarações desse caso de uso  são  especificações, na medida em que se referem a propriedades do sistema e não a propriedades do domínio. Um caso de uso de serviço do sistema, como persistência de dados, é exemplo típico.

Assim temos:

Casos de uso  baseados em declarações de objetivos são abstratos,

Casos de uso baseados em requisitos e especificações  são concretos.

Os analistas derivam casos de uso a partir da  hierarquia de objetivos. Para cada nó dessa hierarquia:

• Se tiver sub-objetivos, então um caso de uso abstrato pode ser definido com os sub-objetivos como passos.
• Se tiver sub-requisitos, então um caso de uso concreto pode ser definido com os sub-requisitos como passos.
• Se é um requisito folha, então um caso de uso de baixo nível pode ser definido usando declarações de especificação.

Um nó com um e-refinamento tem cada sub-nó (objetivo ou requisito) como um passo devidamente ordenado no caso de uso.  Um nó com um ou-refinamento pode:

(1) incluir apenas um dos nós, ou

(2) incluir cada sub-nó, juntamente com uma condição para sua aplicação, definindo, assim, caminhos alternativos do caso de uso.

Considerando os sub-nós filhos, e outros sub-nós ancestrais, mais detalhes  podem ser adicionados diretamente ao caso de uso, ou através de extensões  de casos de uso separados.

As definições de objetivo, requisito,  e especificação  orientam a definição da hierarquia de objetivos e casos de uso.

Os objetivos fornecem a lógica e a estrutura para os requisitos  que fornecem detalhes suficientes para a definição dos casos de uso. As suas definições, juntamente com  a diferenciação dos atores, permitem organizar de forma clara os casos de uso em de negócios, de tarefas ou de baixo nível. Classificações alternativas, tais como casos de uso essenciais e reais, são mais  subjetivas [Larman 2001].

Requisitos (Casos de Uso) => UML

Resumo, a análise direcionada por objetivos com casos de uso reduz a complexidade e guia a análise.

_________________________________________________________________________________________________________________________________________________________

Este resumo foi elaborado mediante artigo:

Análise com Casos de Uso baseada em Objetivos

William N. Robinson, Dept. of Computer Information Systems, Georgia State
University, U.S.A.
Greg Elofson, Graduate School of Business, University of New Orleans, U.S.A.


<!–[if mso & !supportInlineShapes & supportFields]> SHAPE \* MERGEFORMAT <![endif]–>

Analistas

<!–[if mso & !supportInlineShapes & supportFields]> <![endif]–>

Definem as propriedades desejadas do ambiente, ou objetivos

Sendo estas baseadas no ambiente, os objetivos, não limitam explicitamente o comportamento do software; que é a função dos requisitos.

Elipse: Sendo estas baseadas no ambiente, os objetivos, não limitam  explicitamente o comportamento do software; que é a função dos requisitos.

Necessidades dos stakeholders (interessados)

Elipse: Necessidades dos stakeholders (interessados)<!–[if mso & !supportInlineShapes & supportFields]> SHAPE \* MERGEFORMAT <![endif]–><!–[if mso & !supportInlineShapes & supportFields]> <![endif]–>

Requisitos derivados dos objetivos por refinamento

Os analistas detalham os objetivos adicionando detalhes, informações que restringem o Sw.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: