Metodologia Tropos

Inteligncia Artificial 2007/02

Renata S.S. Guizzardi
 Pergunta inicial

Pra que fazer uma anlise da organizao, tal

como Tropos prope? Isso til para o
desenvolvimento de software? No uma
perda de tempo?
 Atividades de Desenvolvimento

Anlise de Requisitos
Requisitos Iniciais (Early Requirements)
Requisitos Finais (Late Requirements)
Projeto Arquitetural
Projeto Detalhado
 Requisitos Iniciais

compreenso do contexto organizacional no

qual o sistema a ser desenvolvido ser
implantado

foco:
a organizao como hoje
 Requisitos Finais

Modelar a relao dos atores da organizao

com o sistema a ser desenvolvido

foco:
a organizao como deve ser (requisitos)
 Projeto Arquitetural

Modelar a relao do agente de sistema com

seus sub-agentes

foco:
o sistema e seus sub-componentes
 Conceitos
Entidades:
Ator
Objetivo
Plano/Tarefa
Recurso
Relaes
Dependncia
Meio-fim
Contribuio
 Diagramas
Dependncia Estratgica (Strategic Dependency)
objetivo: modelar as dependncias entre os atores da
organizao.
captura as motivaes e os desejos dos atores que fazem
parte da organizao e apresenta sua rede de
relacionamentos.
Razo Estratgica (Strategic Rationale)
objetivo: modelar a perspectiva de um ator em especial
captura as motivaes, desejos, preocupaes, planos e
recursos de um ator.
Misto:
a ferramenta TAOM usa diagramas mistos.
Sugesto: salvar vrios diagramas para guardar as vises
de cada etapa do modelo (em TAOM4E, fazer copy paste
com o boto direito do mouse em cima do modelo)
 Requisitos Iniciais

Modelar um Diagrama de Dependncia

Estratgica com os atores principais da
organizao
Modelar um ou mais Diagramas de Razo
Estratgica, mostrando a perspectiva interna
de um ou mais atores.
 Dependncia Estratgica:
passo a passo
Definir os atores da organizao.
Definir seus objetivos iniciais.
Baseado nos objetivos iniciais, definir
dependncias entre esses atores.
Ex. Dependncia Estratgica
Equilbrio de dependncias
 Desquilbrio de Dependncias
Pode ser um problema a ser resolvido com a anlise:
Se um ator A depende de um ator B, mas o ator B no depende do
ator A, ento pode haver falta de motivao do ator B em honrar os
compromissos assumidos com A.
Um desequilbrio tambm ocorre quando h muito mais
dependncias de A para B do que de B para A, ou se as
dependncias de A para B se do em termos de objetivos
cruciais, enquanto que de B para A, os objetivos so menos
importantes.
H casos em que o problema o equilbrio Lock de
dependncias
Quando um ator A depende de um ator B para atingir um objetivo
G1, o ator B depende do ator A para atingir um objetivo G2, sendo
que para atingir G1 preciso atingir G2 e vice-versa.
O analista ter que observar bem o caso para decidir que como
proceder, ora para equilibrar um relacionamento
desbalanceado, ora para acabar com um lock de
dependncias.
 Razo Estratgica: passo a passo
Analisar objetivos internos
Decompor objetivos
Encontrar meios de realiz-los: planos e recursos
Analisar contribuies
Delegar objetivos
Identificar planos que realizam objetivos
Identificar recursos usados ou produzidos por planos
e objetivos
Identificar dependncias que o ator tenha para obter
recursos ou executar planos
 Ex. Razo Estratgica

Decomposio s ocorre
qdo h dois ou mais sub-objetivos.
Um objetivo que atinge um outro
qualifica um relacionamento
Meio-fim.
Means-end tambm ocorre
qdo um objetivo acidentalmente
atinge outro, mas no foi criado
para isso.
 Ex.2 Razo Estratgica

um plano um
procedimento passo a passo
enquanto um objetivo a
expresso de um desejo.

recursos podem ser usados/ ou produzidos por um plano ou

consumidos objetivo.
Questes de Ordenao e Cardinalidade

No h ordenao na execuo de objetivos/planos

decompostos ou ligados a partir de uma ligao
meio-fim. H apenas uma idia intuitiva de que se
realizem no sentido esquerda/direita.
Tambm no h definio de cardinalidade.
Esse tipo de detalhe no o foco da anlise nesse
ponto e sim as relaes de dependncia e uma viso
abstrata de objetivos, planos e recursos dos atores.
A idia abstrair desses detalhes e deix-los para a
etapa de modelagem de processo, que aqui se dar
em projeto detalhado.
 Ex. Delegao
A dependncia sempre entre
dois atores. A relao why
expressa apenas a motivao
da relao.

Meio-fim vs. Contribuio:

-a contribuio , em geral,
acidental enquanto o meio
pode ter sido criado para
atingir o fim.
-H uma idia de completude
(se h um meio apenas para
atingir um fim, intui-se que
ele a atinge por completo,
enquanto a contribuio
sempre parcial).
- Ainda assim, isso
subjetivo e no h consenso.
 Particularidades do why
O objetivo delegado e ligado ao why pode ser o prprio
objetivo G1 do dependedor (como no ex.) ou pode ser um outro
objetivo motivado por G1, em geral, que atinja G1 parcialmente.
Por exemplo, um objetivo receber solicitaes de clientes
entre a Union Technik e o Call Center, motivado pelo objetivo
gerenciar servio de manuteno. Outros objetivos poderiam
ser delegados a outros atores.
Nesse caso, porm, recomenda-se sempre que possvel,
decompor os objetivos antes de deleg-los. Ex.: Objetivos
receber solicitaes de clientes e monitorar servio
decompostos dentro de Union Technik e, depois, receber
solicitaes de clientes delegado ao Call Center. Isso deixa o
modelo mais claro.
Em TAOM4E, pode-se encontrar dificuldade (bug) em expressar
dois objetivos com o mesmo nome. Nesse caso, adotamos
ndices 1, 2, assim por diante, para referenciar o mesmo
objetivo.
 Delegao de Objetivo vs.
Delegao de Plano
Delegao aberta:
Quem decide como o
objetivo ser atingido o dependido
(Tcnico)

Delegao fechada:
Quem decide como o
objetivo ser atingido o dependedor (Call Center), i.e.
h um procedimento especfico indicado pelo dependedor.
Aquisio de Recurso
Prtica redundante, deve
ser evitada

O Depto Financeiro
depende do Tcnico para
obter a nota de servio e o
Tcnico se compromete a
envi-la.
O diagrama misto pode confundir, ento...

Ok

Externamente aos atores, s h delegao.

A relao entre um ator e seus prprios planos, objetivos e
recursos s ocorre dentro da perspectiva do ator.
 Objetivo vs. Plano

A diferena que na esquerda, o analista est representando que h um

procedimento passo a passo para a realizao de, por exemplo, analisar
problema: abrir bomba de gasolina, fazer medio, etc. Lembrar que
decomposio s permitida entre elementos de mesmo tipo (ex. direita).
 Modelar alternativas
No h como modelar alternativas (OU) com o relacionamento
meio-fim.
Ento um artifcio comum abstrair os planos para objetivos,
modelar uma decomposio-OU e depois identificar um plano
para cada sub-objetivo decomposto.
Nesse caso, muito interessante usar softgoals para mostrar
em que caso cada plano pode ser vantajoso (anlise de
contribuio).
Em certos casos, pode-se chegar inclusive a uma deciso,
usando as diferentes gradaes da anlise de contribuio (+,
-, ++, --). Ver exemplo a seguir:
 Tomando uma deciso a partir de
alternativas

Analisando as contribuies:
Como h mais risco em
usar a intuio (impreciso)
do que medir com instrumento
(independncia de equipamentos)
para atingir analisar problema,
ento optou-se por medir com
instrumento prprio (plano)
 Ex. Anlise de Contribuio

anlise aponta um problema que deve ser

solucionado, possivelmente por um
sistema (Ex. definir que um agente de controle de
pagamento estime o tempo mdio de resoluo de
um problema e confira o tempo gasto pelo tcnico)
 Requisitos Finais

Inserir o ator de sistema, modelando as

dependncias entre os demais atores e este
novo ator (Diagrama de Dependncia
Estratgica)
Analisar a perspectiva do ator de sistema
(Diagrama de Razo Estratgica).
 Ex. Requisitos Finais (1/2)

AManD: Agente de Manuteno Distribuda

 Ex. Requisitos Finais (2/2)

A gradao da anlise de
contribuies pode ser +, -,
++, --. Em TAOM4E, modificar o
default + usando a janela de
propriedades.
 Usos Tpicos de Softgoal
Qualificar um objetivo ou plano j modelado (Ex. objetivo=obter
info de localizao do tcnico; softgoal= dinamicamente)
Representar um objetivo para o qual um ator no possui um
mtodo objetivo para avaliar satisfabilidade (Ex. Call Center tem
um softgoal de atender bem o cliente)
Representar requisitos no-funcionais de software (Ex.
segurana, privacidade, etc.)
Em geral, um softgoal tende a ser resolvido com um
objetivo/plano com o progresso da anlise.
No caso de processo: o Call Center estabelece que atender bem
responder imediatamente ao receber uma ligao qual tcnico vai
atender o cliente.
No caso de um requisito no-funcional, a segurana garantida
com uso de firewall, criptografia e autenticaro de usurio (senha).
 Projeto Arquitetural

Decompor o ator de sistema em sub-

componentes, adicionando novos atores
correspondentes a esses componentes.
Modelar dependncia entre o ator de sistema
e seus sub-atores.
Ex. Projeto Arquitetural (1/2)
 Ex. Projeto Arquitetural Em Proj. Arq., pode ser til
(2/2) identificar como os demais
atores da organizao vo
interagir com os sub-atores
de sistema (ex. Call center
depende do Seleciona
Tcnico para obter
recomendao de tcnico)

Daqui em diante,
refina-se o modelo
de cada um dos sub-atores
 Mais sobre Anlise de Contribuio
Em cada fase, a anlise de contribuio
serve a uma proposta:
Requisitos Iniciais: opes dos atores da
organizao ao conduzir o processo atual (Ex.
tcnico escolhe entre resolver o problema mais ef
icientemente ou no
).
Requisitos Finais: escolha dos requisitos da
soluo (Ex. usar GPS ou no).
Projeto Arquitetural: refinamento de requisitos;
alternativas de projeto (Ex. definio da melhor
arquitetura diviso em sub-atores; escolha de
plataforma de desenvolvimento).
 Planos em Projeto Arquitetural
Um plano em projeto arquitetural tudo aquilo que
ser de fato implementado no sistema.
H uma questo subjetiva quanto a granularidade na
subdiviso de planos.
Vamos adotar a seguinte: subdividimos o plano at
que ele possa ser descrito em uma seqncia
coerente de passos que definem uma funcionalidade
parecido com Casos de Uso em UML.
Nota-se, assim que a etapa de Projeto em orientao
a agentes (OA) , em geral, mais abstrata que um
Projeto OO.