MOdPROCSoft PDF

UNIVERSIDADE FEDERAL DO PAR
CENTRO DE CINCIAS EXATAS E NATURAIS

DEPARTAMENTO DE INFORMTICA
XI SEMANA DE INFORMTICA DA UFPA
Introduo Modelagem de Processos de Software

Carla Alessandra Lima Reis
clima@ufpa.br
www.cultura.ufpa.br/clima
Belm, 2004
Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis
Sumrio
1 INTRODUO ................................................................................................3
2 TECNOLOGIA DE PROCESSO DE SOFTWARE ................................................5
2.1
Fundamentos da Tecnologia de Processo de Software ....................................... 6
2.2
Modelagem e Execuo do Processo de Software............................................. 9
2.3
A Arquitetura de um PSEE ............................................................................... 11
2.4
Gerncia de Workflow e Automao do Processo de Software ....................... 12
3 LINGUAGENS DE MODELAGEM DE PROCESSOS .........................................16

3.1
Paradigmas de Modelagem do Processo de Software....................................... 19
3.2
Classificao das Linguagens de Processo de Software ................................... 21
3.3
Uma Avaliao de Linguagens de Processo ..................................................... 22
3.3.1
SPELL....................................................................................................... 24
3.3.2
E3 ................................................................................................................... 26
3.3.3
SLANG ..................................................................................................... 29
3.3.4
TEMPO ..................................................................................................... 32
3.3.5
LOTOS-SPD ............................................................................................. 33
3.3.6
JIL ............................................................................................................. 37
3.4
Consideraes finais sobre linguagens de modelagem..................................... 39
4 FERRAMENTAS PARA MODELAGEM DE PROCESSOS: EXEMPLO DE

UTILIZAO. ...............................................................................................41
4.1
RUP Builder...................................................................................................... 41
4.2
SPEARMINT.................................................................................................... 45
4.3
APSEE .............................................................................................................. 46
5 CONCLUSES ..............................................................................................48
1. BIBLIOGRAFIA ............................................................................................49
1 Introduo
Dentre as principais reas que constituem a Cincia da Computao, uma das que
mais influenciam o mundo atual a Engenharia de Software, envolvida nos aspectos
tecnolgicos e gerenciais do processo de desenvolvimento de software (ou simplesmente
processo de software, segundo Gimenes [GIM94]). Software tornou-se a base de
sustentao de inmeras organizaes dos mais diversos ramos de atuao espalhados
pelo planeta, consistindo no elemento estratgico da diferenciao de produtos e servios
atuais. Atualmente, o software est embutido em sistemas de uma infindvel lista de
diferentes cincias e tecnologias e, segundo Pressman [PRE01], ser o propulsor dos
novos avanos que influenciam uma ampla gama de indstrias, envolvendo desde a
Educao Elementar at corporaes envolvidas com a Engenharia Gentica.
Apesar dos inmeros avanos recentes nesta disciplina, muito ainda discutido
acerca da baixa qualidade e produtividade da indstria mundial de software, refletindo-se
na insatisfao dos seus usurios e em prejuzos financeiros de enormes propores. Por
outro lado, os computadores esto rapidamente tornando-se componentes comuns do diaa-dia das pessoas que, por sua vez, apontam necessidades com requisitos de
complexidade cada vez maiores.
O fenmeno descrito na literatura especializada como Crise do Software um
reflexo da incapacidade da indstria de software em atender plenamente s necessidades
de um mercado consumidor cada vez mais exigente. Atualmente, segundo Pressman
[PRE01], cerca de 70% dos investimentos da rea so realizados com o objetivo de
manter produtos desenvolvidos anteriormente. Segundo Yourdon [YOU95], a indstria
de software mundial caminha a passos largos para a estagnao.
Com o objetivo de solucionar esses problemas, vrias tecnologias vm sendo
experimentadas no sentido de apoiar o ciclo de vida do software. Um dos esforos mais
significativos corresponde definio de metodologias voltadas a disciplinar o processo
de desenvolvimento atravs do estabelecimento de etapas bem definidas, proporcionando,
desta forma, um mecanismo de controle para o processo. Como conseqncia, muitas
organizaes de desenvolvimento de software buscam a maturidade no processo de
software, usando medidas como o SEI-Capability Maturity Model for Software (SWCMM) [PAU94] para estruturar as iniciativas de melhoria de processo.
O modelo SW-CMM prope cinco estgios, sendo que uma organizao de
desenvolvimento de software pode se encaixar desde o nvel inicial, onde o processo
catico, at o nvel otimizado, onde o gerenciamento de software ideal. Nesse modelo,
algumas reas-chave so identificadas para que uma organizao passe de um nvel ao
outro do modelo, assumindo um papel importante na verificao da qualidade do
software produzido. Uma das reas-chave determinadas pelo SW-CMM, para que uma
organizao possa obter aumento na maturidade dos seus processos, consiste na definio
rigorosa de processos que determinem as estratgias gerenciais adotadas durante o
desenvolvimento de qualquer produto de software pela organizao.

Em face da crescente utilizao de modelos como o SW-CMM para avaliar a
qualidade do software produzido e da inerente complexidade em gerenciar o seu
processo, a comunidade internacional investiu na construo de ferramentas e ambientes
que fornecem apoio automatizado conduo desses projetos. Essa iniciativa evoluiu
para o estabelecimento de uma nova rea de pesquisa e aplicao da Cincia da
Computao denominada Tecnologia de Processo de Software, a qual tambm
influenciada pela crescente utilizao de ferramentas CASE (Computer-Aided Software
Engineering) nas diferentes etapas do processo.
Todo software produzido atravs de algum processo. Entretanto, na maioria das
vezes este processo incoerente e est implcito, levando falta de previsibilidade, falta
de capacidade de repetio dos passos e falta de uma base que permita aperfeioamento.
Para resolver tais problemas so necessrios processos explcitos e coerentes que possam
ser seguidos consistentemente, monitorados, compreendidos e evoludos.
A produo de software envolve atividades complexas desempenhadas por
pessoas com capacidades, experincias e expectativas diferenciadas. Uma forma de
analisar e amadurecer tal processo atravs da sua descrio, a qual consiste de um
modelo de processo de software. A descrio formal de um processo de software uma
atividade que permite que o mesmo seja analisado, compreendido, automatizado
(executado) e melhorado.
Este texto tem como objetivo apresentar a importncia da modelagem de
processos para auxiliar na gerncia do desenvolvimento de software. Parte-se do
princpio que h uma grande diferena entre um processo de desenvolvimento descrito
em um livro de maneira geral, como so descritos o Processo Unificado, Programao
Extrema, PRAXIS, dentre outros, e o processo de desenvolvimento descrito em uma
linguagem de modelagem adaptado organizao que ir segui-lo. Esse processo de
adaptao depende de ferramentas adequadas e de conhecimento acerca do processo e da
organizao.
Sero apresentadas caractersticas da tecnologia de processos de software, das
linguagens e ferramentas de modelagem, assim como ser discutida a adaptao de
processos j existentes para situaes especficas.
2 Tecnologia de Processo de Software

A Tecnologia de Processo de Software surgiu no final da dcada de 1980 e
representou um importante passo em direo melhoria da qualidade de software atravs
de mecanismos que proporcionam o gerenciamento automatizado do desenvolvimento de
software [FEI93]. Diversas teorias, conceitos, formalismos, metodologias e ferramentas
surgiram nesse contexto, enfatizando a descrio de um modelo de processo de software
que automatizado por um ambiente integrado de desenvolvimento de software.
Informalmente, o processo de software pode ser compreendido como o conjunto
de todas as atividades necessrias para transformar os requisitos do usurio em software
[HUM89] [OST87]. O processo de software formado por um conjunto de passos
parcialmente ordenados, relacionados com conjuntos de artefatos, pessoas, recursos,
estruturas organizacionais e restries, tendo como objetivo produzir e manter os
produtos de software requeridos [LON93] [DOW91]. Conforme ilustrado pela figura 2.1,
a partir de um esboo dos requisitos iniciais para o problema a ser resolvido atravs de
software, um modelo de processo de software ser adotado, o qual resultar em software
para atender os requisitos dos usurios.
dados
relatrios
procedimentos
restries
Software
Processo
Problema
Soluo
Figura 2.1 O Processo de Engenharia de Software

A Tecnologia de Processo de Software emergiu como conseqncia da maior
nfase, na comunidade internacional, pela avaliao da qualidade de software a partir da
investigao dos processos adotados no seu desenvolvimento. Seus principais objetivos
so:
Definir ferramentas para descrever os processos e acompanhar a sua execuo1,

controlando a realizao de atividades que ocorrem no desenvolvimento de software,
Os termos interpretao e execuo de processos so utilizados indistintamente nesse

contexto. A terminologia utilizada na literatura em ingls enaction, pois a execuo no
significa que o processo ser totalmente automatizado, e sim que ser executado por pessoas
(desenvolvedores) e ferramentas. O termo automao de processo tambm ser utilizado com o
mesmo significado nesse texto.

registrando as ocorrncias e modificaes, e detectando anomalias que possam ser
corrigidas em projetos correntes e futuros;
Facilitar a adoo de uma estratgia de melhoria da maturidade dos processos de uma

organizao, a partir da prescrio, monitorao e registro automatizado de eventos;
Permitir o registro do conhecimento produzido acerca processos bem sucedidos na

organizao, para ser reutilizado em contextos similares no futuro;
Proporcionar um controle preciso na alocao e consumo de recursos durante o

desenvolvimento de software;
Coletar mtricas dos projetos da organizao e torn-las disponveis para consultas

posteriores.
Desse modo, inmeros ambientes e ferramentas foram propostos nos ltimos

anos na literatura em Engenharia de Software para definir, observar, analisar,
aperfeioar e executar processos de software e constituem o que hoje denominado
Tecnologia de Processo de Software [DER99]. As subsees a seguir aprofundam-se na
definio da terminologia usada na rea.
2.1 Fundamentos da Tecnologia de Processo de Software

O objetivo da rea de processo de software facilitar o desenvolvimento de
produtos de alta qualidade mais rapidamente e com um custo mais baixo [SUT 95]. Para
atingir este objetivo, foi proposto que os processos de software devam ser representados
como software [OST 87] e, desta forma, estejam sujeitos ao rigor da tecnologia de
Engenharia de Software. Esta tecnologia inclui atividades como especificao, anlise,
testes, medio e avaliao, entre outras, cuja realizao contribui para o objetivo de
disciplinar o processo e o melhorar produto resultante (software). Linguagens de
Processo so, portanto, necessrias para descrever e automatizar o processo de software.
Neste sentido, a modelagem e a execuo de processos de software so de fundamental
importncia para o aumento da qualidade do produto de software e tm sido estudadas
pela comunidade de Engenharia de Software com o objetivo de prover ferramentas e
ADSs atendam este requisito.
O trabalho intensivo na rea de processo de software vem gerando muitas
definies e terminologias. Alguns esforos no sentido de padronizar esta terminologia
foram apresentados em [DOW 91], [FEI 93] e [LON 93]. Alm disso, existem diversos
paradigmas de modelagem de processo de software, bem como de execuo de tais
modelos. Nesta seo ser apresentada a terminologia utilizada no decorrer do texto e um
resumo dos aspectos importantes da rea.
Informalmente, o processo de software pode ser compreendido como o conjunto
de todas as atividades necessrias para transformar os requisitos do usurio em software
[HUM89] [OST87]. Um processo de software formado por um conjunto de passos de
processo parcialmente ordenados, relacionados com artefatos, pessoas, recursos,
estruturas organizacionais e restries, tendo como objetivo produzir e manter os
produtos de software finais requeridos [LON93] [DOW91].

Os passos de processos so atividades ou tarefas2. Uma atividade um passo de
processo que produz mudanas de estado visveis externamente no produto de software.
Atividades incorporam e implementam procedimentos, regras e polticas, e tm como
objetivo gerar ou modificar um dado conjunto de artefatos. Elas freqentemente so
organizadas em redes bi-dimensionais, estando associadas com papis, ferramentas e
artefatos. A figura 2.2 apresenta graficamente um exemplo de modelo de processo, aonde
atividades so representadas por crculos rotulados, relacionadas entre si atravs de
relaes de dependncia temporal (por exemplo, entre as atividades a e b) e de
composio (por exemplo, entre a atividade a e seus componentes a.1, a.2 e a.3).
b
c
e
e.1
a.1
a.2
e.2
e.4
e.3
a.3
a.3.1
a.3.2
Figura 2.2 Rede de Atividades

Uma atividade aloca recursos (por exemplo, computadores, impressoras e
material de expediente), escalonada, monitorada e atribuda a desenvolvedores
(agentes), que podem utilizar ferramentas para execut-la (figura 2.3). Uma atividade
tambm pode ser executada somente por ferramentas automatizadas, sem interveno
humana. Toda atividade possui uma descrio, a qual pode especificar os artefatos
necessrios, as relaes de dependncia com outras atividades, as datas de incio e fim
planejadas, os recursos a serem alocados e os agentes responsveis pela mesma
[DOW91].
Neste texto, os termos atividade e tarefa so considerados sinnimos, de acordo com Conradi
[CON94].
produtos de
sada
produtos de
entrada
Atividade
Atividade
prazos
recursos
restries
ferramentas
agentes e
cargos
Figura 2.3 Elementos envolvidos em atividades do processo de software

Um agente est relacionado com as atividades de um processo e pode ser uma
pessoa ou uma ferramenta automatizada (quando a atividade automtica). Os agentes
podem estar organizados em cargos, aos quais podem ser definidas diferentes
responsabilidades. Diferentes agentes tero percepes diferentes acerca do que acontece
durante o processo de software. Como ilustrado na figura 2.4, um gerente, por exemplo,
perceber os aspectos de controle e alocao de recursos e cronogramas para atividades,
enquanto um desenvolvedor perceber as suas atividades como atribuies que devem ser
feitas para produzir um resultado (possivelmente atravs de agendas, aonde as atividades
em que est envolvido so relacionadas, sendo ordenadas segundo algum critrio
definido).
Acompanhamento do P rojeto
b
Processo em Execuo
Viso do
Gerente
c
e
e.1
a.1
P
a.3A
Viso do
Desenvolvedor
e.2
e.4
a.2
e.3
esperando
a.3.1
a.3.2
pronta
A
P
ativa
parada
completa
Agenda do agente Jos

Nome do Projeto: Sistema Especialista em Culinria
Atividade
Estado Data Incio
Data Fim
Durao prevista
Aquisio de
conhecimento
Pronta
Entrevistar usurio
Ativa
10.07.2002
Criar documento
de anlise
Parada
12.07.2002
Anlise do problema Completa 01.07.2002
12 horas
10.07.2002
8 horas
20 horas
Figura 2.4 Exemplos de diferentes vises para um mesmo processo em

execuo

Um artefato um produto criado ou modificado durante um processo. Tal
produto resultado de uma atividade e pode ser utilizado posteriormente como matria
prima para a mesma ou para outra atividade a fim de gerar novos produtos. Desta forma,
uma atividade pode consumir produtos (de entrada) e gerar novos produtos (de sada). Os
produtos so persistentes e freqentemente possuem verses.
A realizao do processo afetada pelas restries, que podem atingir
atividades, agentes, recursos, artefatos, papis e seus relacionamentos [LON93]. Uma
restrio uma condio definida que um passo de processo deve satisfazer antes ou
depois de ser executado [FEI93].
Um projeto, segundo Conradi [CON94], a instncia de um processo, com
objetivos e restries especficos. Pode-se dizer que um projeto um esforo para
desenvolver um produto de software, ou seja, envolve uma estrutura organizacional,
prazos, oramentos, recursos e um processo de desenvolvimento. Neste sentido, a
gerncia de projetos tem como responsabilidades o planejamento, controle e monitorao
de um processo em execuo, enquanto que a gerncia de processos preocupa-se em
construir, analisar e verificar modelos de processo, para isso obtendo informaes
durante a execuo desse processo a fim de evoluir tais modelos para que possam ser
usados posteriormente [DOW91].
Finalmente, um modelo de processo de software uma descrio formal do
desenvolvimento de software. Vrios tipos de informao devem ser integradas em um
modelo de processo de software para indicar quem, quando, onde, como e por que os
passos so realizados [LON93]. Para representar um modelo de processo de software so
utilizadas linguagens especficas, as quais so discutidas na seo 2.2 a seguir.
2.2 Modelagem e Execuo do Processo de Software

Processos de software devem acomodar atividades desempenhadas por
humanos. Tais atividades so caracterizadas pela criatividade, julgamento, incompleteza,
informalidade, inexistncia de estrutura, e por atividades que no tem qualquer tipo de
apoio automatizado (por exemplo, reunies, negociaes, entre outras). Em contraste
esto os objetivos das linguagens de processo, as quais existem para facilitar a definio
de processos de software de alta qualidade, bem projetados sob a tica da disciplina de
Engenharia de Software [SUT95]. A definio e automao de processos, portanto,
combinam requisitos que so claramente distintos e at mesmo contraditrios, e devem
ser satisfeitos simultaneamente. A combinao exata desses conjuntos de requisitos um
problema em aberto e tem motivado os estudos na rea.
Para representar um modelo de processo de software freqentemente adotada
uma Process Modelling Language (PML3), a qual deve oferecer recursos para descrever e
Segundo Heimbigner (em [HEI91]), linguagens de programao de processos (process

programming languages) se diferenciam por permitir a execuo automtica das instncias
criadas segundo a sintaxe da linguagem. Em virtude da recente nfase em aproximar as PMLs
das linguagens de programao de processos (fornecendo semntica para execuo de PMLs,
sendo que estas tambm so chamadas PMLs de segunda gerao [SUT97]), este texto segue

manipular os passos do processo. As PMLs constituem uma categoria especfica de
linguagens de especificao e programao de computadores voltada definio e
automao do processo de software. Assim sendo, as PMLs possuem algumas
caractersticas prprias, que as distanciam das linguagens de programao de propsito
geral, incluindo, por exemplo, a capacidade de gerenciar atividades que necessitam da
interao humana para serem executadas. Das linguagens de propsito geral so herdadas
caractersticas sintticas como abstrao, modularidade e generalizao. A fim de
modelar apropriadamente o processo de software, as linguagens de processo tambm
utilizam caractersticas das linguagens de sistemas concorrentes, reativos e de tempo real,
tais como: paralelismo, especificao de restries de tempo e descries de interaes
com o ambiente. Finalmente, prover um modelo de dados conceitual, lidar com objetos
persistentes de diferentes granulosidades, permitir transaes longas e gerenciamento de
verses so caractersticas que as linguagens de programao de processos de software
herdam da rea de banco de dados [ARM92] [TOY95].
A modelagem de processos de software freqentemente associada sua
execuo. Na fase de execuo, devem ser levadas em considerao as questes de
coordenao de mltiplos usurios e a interao desses com as ferramentas disponveis.
Para isso, necessrio que se obtenha um modelo de processo executvel (ou
instanciado), ou seja, um modelo que descreva o processo com tal nvel de detalhe que
permita a sua execuo por uma mquina. Portanto, a execuo de modelos de processo
de software deve levar em considerao as questes de coordenao de mltiplos
usurios, assim como a interao entre as ferramentas e os agentes (profissionais
envolvidos no processo).
PSEEs (Process-Centered Software Engineering Environments) ou Ambientes
de Desenvolvimento de Software (ADS) Orientados ao Processo [LIM98]) constituem
um tipo especial de ambientes de desenvolvimento de software que surgiram nos ltimos
anos para apoiar a definio rigorosa de processos de software, objetivando automatizar a
gerncia do desenvolvimento. Tais ambientes geralmente provem servios para anlise,
simulao, execuo e reutilizao das definies de processos, que cooperam no
aperfeioamento contnuo de processos.
A modelagem de processos de software no consiste to somente em escrever
programas que automatizem completamente o processo de desenvolvimento de software;
tampouco descreve tudo o que as pessoas do processo devem fazer [REI99]. Enquanto os
programas de computador so escritos para definir o comportamento de uma mquina
determinstica, os programas de processo so escritos para definir possveis padres de
comportamento entre elementos no-determinsticos (pessoas) e ferramentas
automatizadas [TUL89]. Por conseqncia, segundo Nguyen em [NGU97], um PSEE
deve ainda permitir que as pessoas envolvidas no processo recebam orientao
automatizada e assistncia na realizao de suas atividades, sem interferncia no processo
criativo. Alm disso, processos ainda podem ser modificados dinamicamente (i.e.,
durante a execuo), em resposta a estmulos organizacionais ou mudana nos requisitos
do software em desenvolvimento.
uma abordagem recente, tambm defendida por [FRA00] e [SUT97], que no distingue as
linguagens de modelagem daquelas voltadas programao de processos.
2.3 A Arquitetura de um PSEE

A arquitetura de um PSEE usualmente define como componente central a
Mquina de Processo (process engine, segundo Derniame [DER99]) que auxilia na
coordenao das atividades realizadas por pessoas e por ferramentas automatizadas,
sendo responsvel pela interpretao/execuo dos modelos de processos descritos com
PMLs. Segundo Lima Reis em [LIM98], uma mquina de processos responsvel por:
ativar automaticamente atividades sem interveno humana atravs de uma integrao
com as ferramentas do ambiente; apoiar o envolvimento cooperativo dos
desenvolvedores; monitorar o andamento do processo e registrar o histrico da sua
execuo. Ainda segundo [LIM98], a mquina de processo tambm deve garantir a
execuo das atividades na seqncia definida no modelo de processo (fluxo de controle);
a repetio de atividades; a informao de feedback sobre o andamento do processo; a
gerncia das informaes de processo (incluindo gerncia de verses); a coleta
automtica de mtricas; a mudana do processo durante sua execuo; a interao com as
ferramentas do ambiente e a gerncia de alocao de recursos.
O mecanismo de execuo de processos de um ADS pode conter diversas
instncias simultneas de mquinas de execuo. Isto necessrio porque o ADS pode
estar sendo utilizado para desenvolvimento em diversos projetos em uma organizao.
Portanto, de forma geral um mecanismo de execuo consiste de uma ou vrias mquinas
de execuo. As mquinas de execuo possuem componentes que trabalham na
execuo de processos e na integrao com o restante do ambiente pois a execuo
envolve desde a interface com o usurio at a gerncia dos objetos no banco de dados.
Dentro de um PSEE, o mecanismo de execuo pode ser tratado como mais uma
ferramenta ou pode ser um componente bsico do ambiente. A figura 2.5 ilustra o
funcionamento do mecanismo de execuo no nvel do ambiente de desenvolvimento.
Figura 2.5 O mecanismo de execuo em um PSEE
2.4 Gerncia de Workflow e Automao do Processo de

Software
Nos ltimos anos, diversas tecnologias surgiram com o objetivo de auxiliar o
denvolvimento cooperativo de profissionais nos mais diversos tipos de atividades
humanas. Nesse contexto, as tecnologias conhecidas como CSCW (Computer Supported
Cooperative Work - trabalho cooperativo apoiado por computador), Workflow, e Processo
de Software se destacaram como tecnologias interrelacionadas que estabeleceram
comunidades prprias dentro da Cincia da Computao.
H divergncia na literatura acerca das fronteiras exatas entre estas trs
tecnologias. Por exemplo, [DUI95] e [KRU96] definem que Workflow e Processo de
Software so duas tecnologias componentes da tecnologia CSCW, devido a grande
importncia do aspecto interao humana. Por outro lado, [GEO94] diz que workflow no
pode ser considerado um subconjunto de CSCW por tratar o aspecto de coordenao de
uma maneira mais especializada do que fornecido tradicionalmente por ferramentas
CSCW. Alm disso, muitos autores (citados em [OCA98]), defendem que a tecnologia de
gerncia do Processo de Software um caso especial de Workflow, especializado para
tratar o desenvolvimento de software. Assim, de uma forma geral, pode-se afirmar que as
trs tecnologias cooperam entre si, apresentando muitas vezes terminologias conflitantes,
fruto do desenvolvimento em paralelo, apoiando o envolvimento cooperativo de agentes
humanos atravs de um sistema de computao [OCA98]. O relacionamento prximo
dessas trs tecnologias ainda evidenciado por terem como reas principais trs
elementos chave comuns: comunicao, colaborao e coordenao [KRU96].
Desenvolver sistemas informatizados que atendam de forma satisfatria os requisitos

destas trs reas representa o principal desafio atual dos desenvolvedores de sistemas
groupware, de workflow e de gerncia de processos de software.
Uma tendncia atual a concentrao de esforos na uniformizao dos
conceitos e experincias nas trs reas. Para os propsitos desse texto, vale ressaltar com
um pouco mais de detalhes as principais semelhanas e diferenas entre as tecnologias de
Workflow e Processo de Software, conforme publicado em trabalhos anteriores dos
autores [REI00].
Em Workflow, o principal objetivo modelar e automatizar processos de
negcio (business processes), envolvendo a administrao de organizaes, coordenando
os processos desempenhados por profissionais diversos. Mais formalmente, segundo a
Workflow Management Coalition (WfMC) [WOR99], sistemas workflow estabelecem a
automao total ou parcial de um processo de negcio, na qual documentos, informao
e/ou tarefas so passadas de um participante para outro a partir de aes, de acordo com
um conjunto de regras procedimentais.
Workflow uma disciplina que evoluiu na ltima dcada principalmente devido
a disponibilizao de produtos comerciais por vrias organizaes. Mais de duzentos
sistemas de gerncia de Workflow esto disponveis atualmente no mercado. Assim,
segundo [OCA98], os sistemas de gerncia de Workflow (Workflow Management Systems
- WMS) so sistemas de software que permitem a definio, execuo e monitoramento
de processos de negcio e podem ser utilizados em ambientes internos e externos
organizao para auxiliar a reengenharia, automao e acompanhamento de processos
que envolvem humanos e sistemas de informao heterogneos (outros sistemas de
software).
Em geral, pode-se afirmar que WMSs e PSEEs possuem, atualmente, em
comum:
Representao de atividades atravs de uma grafo parcialmente ordenado de tarefas, a

fim de permitir a definio, execuo e evoluo dos processos. Por um lado, o
processo surge como resultado da cooperao entre humanos: estes decidem a
quantidade e ordenao das atividades a serem realizadas. De outra forma, a interao
humana explicitamente pr-definida e controlada por um modelo de processo:
mudanas nas interaes devem passar obrigatoriamente por mudanas no modelo de
processo adotado. Ambas abordagens so adotadas por sistemas workflow e PSEEs,
que permitem ainda que algumas atividades possam ser automticas, isto , sejam
realizadas automaticamente por software, sem interferncia humana;
Auxiliam no gerenciamento do trabalho distribudo, ou seja, a cooperao de agentes

distribudos geograficamente. Este trabalho cooperativo, ou seja, os agentes
cooperam com o intuito de desenvolver um produto ou atender alguma solicitao.
Esta cooperao caracterizada por perodos alternados de trabalho individual e em
conjunto, trazendo como consequncia que tanto sistemas de workflow quanto PSEEs
devem ser capazes de permitir a interao sncrona e assncrona dos agentes.
Workflow uma tecnologia que evoluiu a partir de produtos comerciais, ao contrrio

dos PSEEs (a maioria experincias acadmicas). Assim, devido a sua origem ser
distante do "mundo acadmico", muitas definies diferentes foram adotadas pelos

diversos fornecedores de WMSs [OCA98]. Em vista disto, em 1993 foi criada a
Workflow Management Coalition, juntando os principais fornecedores, universidades
e usurios para definio de um modelo de referncia e padres de interoperabilidade
entre os produtos [WOR99];
As atividades gerenciadas pelo WMSs, so "caixas-pretas", ou seja, no so definidas

em detalhe. Portanto, no h preocupao com a semntica das operaes
desempenhadas, e sim uma nfase maior na coordenao das atividades. Por sua vez,
a tecnologia de PSEEs engloba a definio rigorosa de granulosidade fina para as
atividades do processo;
WMSs atuam como mecanismo de coordenao de atividades, cujos agentes podem

ser humanos e sistemas de software heterogneos (por exemplo, sistemas de
automao de escritrio, ferramentas de correio eletrnico, entre outros). J nos
PSEEs, a nfase est na integrao cooperativa dos desenvolvedores, envolvendo a
utilizao de ferramentas (que, em alguns instantes, atuam sem interferncia do
usurio - como por exemplo, um compilador);
Na maioria dos WMSs disponveis comercialmente, especial ateno dada

modelagem da estrutura organizacional. Visto que sistemas workflow podem ser
aplicados aos mais diversos domnios de aplicao, estes sistemas so capazes de
acomodar estruturas hierrquicas de agentes humanos definidas pelo usurio.
Sistemas de processo de software do nfase especfica na modelagem dos papis
possveis de serem desempenhados pelos desenvolvedores (por exemplo, analistas,
programadores, revisores, etc.);
Os sistemas de workflow so capazes de atuar nos mais diversos ramos de atuao

humana (por exemplo, sistemas hospitalares, sistemas administrativos em geral)
enquanto que a tecnologia de processo de software tem aplicabilidade especfica ao
domnio de Engenharia de Software;
Os principais WMSs disponveis, pouco detalhe foi reservado para modelagem de

processos (quando comparada com suporte fornecido pelos PSEEs). Assim, a maioria
das linguagens de programao/modelagem de processos adotados por sistemas
workflow so monoparadigma, isto , representam os diferentes aspectos dos
processos utilizando somente um paradigma de linguagem (por exemplo, orientao a
objetos, procedimental, baseado em regras);
A tecnologia de Processo de Software destaca-se pelos esforos da comunidade em

permitir que os PSEEs suportem a evoluo do processo, isto , viabilizando
modificaes que so realizadas no processo definido. Assim, a maioria dos
ambientes permitem, por exemplo, a modificao dinmica do processo, isto , a
modificao do modelo de processo durante a sua execuo (desde que as
modificaes no provoquem inconsistncias). O mesmo pode se dizer acerca da
reutilizao de processos (o que permite uma evoluo gradativa na qualidade dos
processos a partir da experincia de processos bem sucedidos). Por outro outro lado,
os sistemas de workflow fornecem suporte limitado evoluo do processo;
A WfMC tem definido um modelo de referncia de workflow que serve de ponto de

discusso comum para a padronizao das ferramentas. Este modelo de referncia

estabelece uma Interface de Programao de Aplicaes (API - Application
Programming Interface) e formatos para intercmbio de documentos. Apesar de nem
todos os fornecedores de ferramentas workflow seguirem o padro WfMC, isto
representa um grande avano em relao tecnologia de processo de software, aonde
os muitos padres propostos na literatura no conseguiram sensibilizar os
desenvolvedores.
O Anexo 1 apresenta uma tabela que sumariza os itens discutidos nessa seo.
3 Linguagens de Modelagem de Processos

Satisfazer os objetivos de representar e automatizar processos de software requer
um conjunto bsico de capacidades para as linguagens de processo [SUT 95]. No h um
consenso acerca deste conjunto mnimo de capacidades na literatura disponvel sobre o
assunto. Em geral, toda linguagem de processo procura definir representaes para
atividades e recursos. O estudo apresentado em [SUT 95] apresenta um conjunto bsico
de requisitos construdo a partir da anlise de diversas linguagens. Seus requisitos so:
Descrio de atividades: para definir as etapas componentes de um processo;
Descrio dos artefatos: para definir o sistema de software que est sendo
construdo, incluindo o cdigo-fonte de todos os artefatos produzidos;
Descrio dos recursos: para especificar os recursos humanos e computacionais

disponveis para utilizao nas atividades;
Relacionamentos entre entidades: para indicar os vrios tipos de interconexes

semnticas entre atividades, artefatos e recursos.
A definio de processos prope que possvel e vivel representar processos de

software utilizando programas escritos em linguagens de codificao executveis [SUT
97a]. A utilizao de linguagens de codificao fornecem, pela sua natureza intrnseca, os
benefcios de uma sintaxe formal, uma semntica bem definida (algumas vezes formal,
como em [SAE 91] e [YAS 94]), executabilidade, verificabilidade, gerenciamento de
objetos e de consistncia. Novos requisitos para estas linguagens so levantados em [SUT
95] e [SUT 97a]:
Riqueza semntica. Processos de software so aplicaes multi-facetadas. Para

suportar este domnio, uma linguagem de processo deve atender muitos requisitos
interrelacionados. Tradicionalmente as linguagens de processo derivadas de
linguagens de programao convencionais so mono-paradigma (funcional, baseado
em regras, imperativo ou baseado em Redes de Petri). Uma consequncia danosa
desta abordagem a inexistncia de recursos importantes exigidos pelo domnio de
processo de software, tais como a reflexo computacional 4 (capacidade de alterao
dinmica do processo), e dificuldade na expresso de paralelismo e sincronizao de
eventos. A semntica de uma linguagem de processo deve ser ao mesmo tempo rica e
rigorosa;
Facilidade de uso. A facilidade de utilizao um requisito importante para

linguagens de processos porque os indivduos e organizaes responsveis pela
definio de processos geralmente no so experientes em programao. A riqueza
semntica da linguagem representa, entretanto, que habilidades de engenharia de
A reflexo computacional um recurso especialmente til nas linguagens de processo para

permitir que o prprio programa de processo se altere dinamicamente, acomodando de forma
mais natural as mudanas que ocorrem durante a execuo do processo.

software so necessrias para programar efetivamente nestas linguagens. Isto um
impedimento na adoo em massa de linguagens de processo. Um fator decisivo para
o sucesso de uma linguagem encontrar o equilbrio entre a necessidade de rigor
tcnico e a facilidade de utilizao;
Abstraes apropriadas. Uma representao clara e consisa de processos de

software requer tipos e nveis apropriados de abstrao. O desenvolvimento e
manuteno de programas de processo complicado se o usurio necessitar construir
abstraes especficas de processo a partir de abstraes de nvel mais baixo, como
em linguagens derivadas de linguagens de programao de propsito geral (por
exemplo, APPL/A). Linguagens de processo devem prover conceitos e construes
embutidos que sejam mapeados naturalmente no domnio de processo de software.
Linguagens que lidam com isto (com vrios nveis de sucesso) incluem MVP-L,
ProcessWeaver, LOTOS/SPD e Oikos;
Facilidade de composio. A programao de processos de software em geral

difcil. Assim, importante permitir que componentes de processo maiores possam
ser compostos de componentes menores para facilitar a reutilizao. Alm disso, a
habilidade de programar processos que sejam compostos por elementos que sejam de
diferentes paradigmas de linguagens ou representem diferentes aspectos semnticos
pode trazer maior flexibilidade no processo desenvolvimento de programas de
processo;
Facilidade de visualizao. A maioria das linguagens de programao de processo

textual. Poucas linguagens de processo permitem representar graficamente o processo
(ex: SLANG - ver figura 3.1, E3, SLANG). Representaes grficas de processo
ajudam fortemente o entendimento e comunicao de processos. Idias simples so
geralmente melhor representadas visualmente, e isto pode ajudar dramaticamente o
projeto e verificao de processos. Por outro lado, estruturas de processo mais
complexas e dinmicas podem ser expressas mais facilmente em linguagens textuais,
uma vez que as representaes grficas possam se tornar confusas. Assim,
representaes de processo estritamente visuais no so ideais para processos
complexos em geral;
Mltiplos paradigmas de controle. Na opinio de Sutton e Osterweil [SUT 97a], um

dos recursos mais importantes na linguagem APPL/A a incorporao de triggers em
uma linguagem de programao imperativa (Ada), permitindo a combinao de
controle pr-ativo e reativo 5 na programao de processos. A combinao destes dois
estilos de controle tambm achada em muitas outras linguagens de processo (por
exemplo em Adele-TEMPO, EPOS, HFSP, Marvel, Merlin e ProcessWeaver).
Linguagens baseadas em regras, como Marvel e Merlin, permitem o controle reativo
mas podem apenas simular o controle pr-ativo com pr e ps-condies previamente
programadas, o que difcil e trabalhoso. Linguagens baseadas em estados e em
redes, como ProcessWeaver e SLANG suportam o controle pr-ativo, mas no
Gerncia pr-ativa aquela que direciona o processo em direo a um objetivo, enquanto que o
gerncia reativa descreve como o processo responde a contigncias. [SUT 97a]

suportam o controle reativo. Assim, difcil utiliz-las para descrever as reaes em
contingncias;
Figura 3.1 - Exemplo de visualizao de processo em SLANG [BAN 94]
Gerncia de Recursos. Processos de produo fazem uso de muitos tipos diferentes

de recursos. Recursos incluem, por exemplo, os humanos envolvidos na execuo dos
processos e as ferramentas utilizadas para ajud-los na realizao de suas atividades.
Diferentes recursos possuem diferentes atributos (ver na figura 3.2 um exemplo de
definio de recurso no ambiente Spearmint). Por exemplo, um recurso humano deve
possuir privilgios de acesso e um nmero de horas disponveis para um projeto,
enquanto que um ferramenta pode ser caracterizada em termos das pr-condies que
devem ser satisfeitas para iniciar sua utilizao. Poucos sistemas suportam a definio
de recursos explicitamente. Por exemplo, APPL/A, HFSP, Marvel e SLANG no

provem qualquer mecanismo para definio de recursos (alm dos formalismos de
definio de artefatos e atividades). Os poucos sistemas que provem algum nvel de
descrio de recursos suportam apenas a descrio de recursos humanos e ferramentas
(ex: EPOS). Algumas caractersticas importantes no podem ser modeladas, como por
exemplo, como acomodar as distines entre recursos que so compartilhveis vs
exclusivos, consumveis vs. no-consumveis, ativos vs. passivos, concretos vs.
lgicos, preemptivos vs no-preemptivos;
Relacionamentos e consistncia. Processos de produo devem ser capazes de

capturar e manipular diversos tipos de relacionamentos entre os atividades, artefatos e
recursos. Muitos tipos de relacionamentos devem ser suportados para servirem de
base para anlise do impacto de mudanas e gerncia de consistncia.
Compendiando, pode-se observar que os vrios paradigmas que so encontrados

em linguagens de programao de aplicao convencionais podem ser teis para auxiliar
na representao e execuo dos diversos aspectos dos processos.
Figura 3.2 - Definio de atributos de um artefato em Spearmint [BEC 98]
3.1 Paradigmas de Modelagem do Processo de Software

Os modelos de processo de software so classificados atravs da abordagem
utilizada para representao e descrio do processo. Gimenes [GIM 94] apresenta uma
classificao de modelos de processo de software:
Baseado em atividades: Estes modelos contm uma entidade principal que

representa uma unidade gerencivel de trabalho (conjunto de aes) a ser executada.

Essas entidades so chamadas de atividades ou tarefas. A maioria dos modelos de
processo de software envolve alguma noo de atividade.
Funcional e Comportamental: Na abordagem funcional o modelo v o processo

como funes matemticas. [KAT 89] um exemplo desta abordagem. A abordagem
comportamental est relacionada com o conceito de comportamento do paradigma de
orientao a objetos. Nesta abordagem, o processo visto como um conjunto de
entidades que cooperam entre si, caracterizadas por atributos e aes. O conjunto de
aes que podem ser tomadas pelas entidades define o comportamento total do
processo.
Baseado em Regras: As aes do processo so representadas atravs de regras

associadas s pr e ps condies, que so expresses lgicas que devem ser
satisfeitas antes e depois das aes associadas regra serem executadas,
respectivamente. Um exemplo dessa abordagem se encontra em [KAI 90].
Baseado em Objetivos ou Planejamento: O processo de software visto como um

conjunto de objetivos de alto nvel acrescido da descrio de como decompor esses
objetivos em sub-objetivos. Um objetivo pode ser visto como um estado a ser atingido
(meta).
Baseado em Produtos: O processo de software descrito em termos de produtos.

Aes so aplicadas sobre os produtos, sem necessariamente estarem associadas a
uma atividade gerencivel contendo as aes.
Baseado em Cargos e Funes: Um Cargo/Funo representa um conjunto de

permisses e obrigaes associadas a um objetivo funcional. Um modelo baseado em
cargos/funes define tipos de cargos/funes, suas estruturas e propriedades.
Tendo em vista a classificao dos modelos de processo de software, as

linguagens de modelagem utilizam vrios paradigmas para modelar processos que viro a
ser executados [CON 94]. Alguns destes paradigmas so: bancos de dados ativos,
programao de processos, redes de tarefas e paradigma hbrido.
Os Bancos de Dados Ativos so bancos de dados com regras do tipo EventoCondio-Ao embutidas que modelam as atividades do processo de software. Este
paradigma utilizado pelo ambiente Adele [BEL 94], onde as regras so derivadas do
formalismo ECA e executadas por triggers.
Na abordagem de Programao de Processos, o modelo semntico uma
linguagem de programao (usualmente procedural). O ambiente Arcadia [TAY 88]
possui a linguagem de programao de processos APPL/A que uma extenso da
linguagem Ada para definio de processo de software. Esta linguagem prov um
paradigma de programao imperativo.
A abordagem de Redes de Tarefas relaciona o processo de software com sistemas
de tempo real. O ambiente MELMAC [DEI 90] usa redes FUNSOFT (redes de Petri de
alto nvel) para descrever todas as entidades do processo.
O Paradigma Hbrido derivou da observao de que nenhum paradigma simples
satisfaz todos os requisitos de modelagem de processos. A linguagem SPELL do
ambiente EPOS [CON 94] uma linguagem multiparadigma.
3.2 Classificao das Linguagens de Processo de Software

As linguagens de processo de software 6 constituem uma nova categoria das
linguagens de programao de software voltadas a definio e automao do processo de
software. Assim sendo, elas possuem algumas caractersticas especficas, que as
distanciam das linguagens de propsito geral, como por exemplo a necessidade de
suportar atividades "semi-automticas", ou seja, que necessitam da interao humana
para serem executadas.
Diversas classificaes so encontradas na literatura com o objetivo de facilitar o
estudo das linguagens de processo de software. Neste texto, ser utilizada uma
classificao dos paradigmas de linguagens de processo de software adaptada de [LON
94] e [SUT 97a], apresentada a seguir:
Linguagens Procedimentais. So linguagens geralmente derivadas de linguagens de

programao convencionais, onde o fluxo de execuo de um programa
determinado pela estruturas de repetio e seleo, e os programas so estruturados
em componentes hierrquicos;
Linguagens Orientadas a Redes. So linguagens que baseiam-se em Redes de Petri

com o objetivo de expressar concorrncia e paralelismo das operaes de uma
maneira mais natural;
Linguagens Orientadas a Objetos. O paradigma de objetos influencia o

desenvolvimento de linguagens de processo de software. Conceitos como
encapsulamento de dados, troca de mensagens e herana so utilizados com o objetivo
de mapear os conceitos de atividades, recursos e artefatos de um processo;
Linguagens Baseadas em Regras. Cada processo representado por um conjunto de

objetivos, condies, restries e efeitos. Este paradigma permite a coordenao
reativa de processos;
Linguagens Formais. Esta categoria de linguagens estabelece uma semntica formal

que permite a verificao e validao dos programas de processo. Podem auxiliar na
verificao de deadlocks e propriedades dinmicas do processo;
Linguagens Hbridas. Devido natureza hbrida dos processos h a necessidade de

representar diferentes aspectos do processo com diferentes paradigmas. Assim sendo,
diversas linguagens de processo combinam os diferentes paradigmas descritos acima
com o objetivo de proporcionar maior facilidade de desenvolvimento e manuteno.
Linguagem de processo de software a expresso adotada neste texto para identificar

linguagens de especificao de processo, linguagens de projeto de processo ou linguagens de
programao (implementao) de processo [BEC 98]. Uma descrio mais detalhada destas
duas expresses apresentada a seguir, nesta seo.

Para identificar as caractersticas das linguagens de processo, importante
entender a distino entre as diferentes fases do ciclo de vida do processo. Durante a
especificao de requisitos (anlise do processo), os objetos principais so entender o
processo e explicit-lo, para facilitar sua comunicao, compreenso e entendibilidade. O
modelo resultante descreve o comportamento esperado e desejado do processo, os papis
a serem realizados e outros procedimentos de alto nvel. Por outro lado, a etapa de
implementao se preocupa em produzir um suporte automatizado para o processo que
facilite a obteno dos objetivos e metas que foram definidos na fase de requisitos. O
resultado desta etapa geralmente um cdigo complexo que inclui muitos detalhes
relativos a integrao com ferramentas e codificao de passos de processo. A maioria
destes detalhes so irrelevantes durante a anlise ou projeto.
Assim, outra classificao importante para as linguagens de processo, apresentada
em [BEC 98] [AMB 97], refere-se classificao das linguagens de processo de acordo
com a fase do ciclo de vida de processo suportada e o nvel de abstrao fornecido:
Linguagens de Especificao de Processo. So utilizadas na etapa de especificao

dos requisitos do processo;
Linguagens de Projeto de Processo. Oferecem recursos para serem utilizadas

durante o projeto do processo;
Linguagens de Programao (implementao) de Processo. So definidas para

serem utilizadas durante a programao e execuo de processos.
Muitas linguagens apresentadas na literatura podem ser classificadas

simultaneamente como de Especificao, de Projeto e de Implementao de Processo,
como por exemplo Merlin, Marvel e SPELL.
A tabela 1, a seguir, apresenta um resumo da avaliao realizada sobre as
linguagens SPELL (ambiente EPOS [CON 94]), E3 [BAL 94], Merlin [JUN 94], SLANG
(ambiente SPADE [BAN 94]), a abordagem multi-paradigma do ambiente SOCCA [ENG
94] (combinando diagramas de fluxo de objetos, diagramas de transio de estados e a
linguagem PARADIGM), PEACE-PDL (do ambiente PEACE [ARB 94]), TEMPO (do
ambiente ADELE [BEL 94]), LOTOS/SPD [YAS 94], JIL [SUT 97a], e ProNet [CHR
95]. A tabela resultado da combinao de estudos de [LON 94], [SUT 97a] e
observaes pessoais do autor. As sees a seguir apresentam as caractersticas principais
de algumas destas linguagens (e os paradigmas utilizados).
3.3 Uma Avaliao de Linguagens de Processo

Nesta seo, sero apresentadas diversas das linguagens mais representativas de
modelagem/programao de processo de software encontradas na literatura especializada.
N
Procedimental
Orientado
Redes
aX
Orientado
Objetos
aX
Baseado
Regras
T
X
X
X
em X
X
X
X
X
X
Semntica Redes
baseada Petri
em PRO
Formal
LOG
de Diagramas Lgica
ER
e Auto
Transi
Epist
LOTOS/S
PD uma
extenso
de LOTOS
o
de mica
Estados
Redes de
Petri e
semnti
ca baseada
em PRO
LOG
Especificao
Projeto
Estilo
lgico
Implementao X
Visualizao
eX
Facilidade
de
uso
Especifi
Visual JIL X
cao
Formal.
Possvel
represen
(grfica)
tao
grfica
com
GLOTOS
Verificvel
Reflexiva
Tratamento de
X
X
Excees
Executvel
Por simula X
Tabela 2.1 Avaliao de linguagens de processo de software de acordo com os seus

paradigmas e caractersticas de execuo.
3.3.1 SPELL
SPELL [COW 91] uma linguagem de processo de paradigma hbrido
desenvolvida para o ambiente EPOS [CON 94] do Norwegian Institute of Technology.
SPELL adota essencialmente um modelo de dados orientado a objetos, onde so
definidos tipos bsicos (classes) que so estendidos (especializadas) durante o
desenvolvimento (figura 3.3). O modelo de processo adotado por SPELL consiste de uma
rede encadeada de tarefas, onde cada uma das tarefas so associadas a descries de
outras atividades, produtos, ferramentas e papis. As atividades interagem entre si, com
as ferramentas e humanos. SPELL uma linguagem concorrente e reflexiva que foi
baseada em Prolog, e segundo [AMB 97], SPELL pode ser considerada um Prolog
estendido com orientao a objetos (tipos), reflexo (no estilo de metatipos SmallTalk) e
gerncia de tarefas concorrentes. Ela suporta modelagem orientada a objetos (modelo de
dados Entidade-Relacionamento com triggers).
Um tipo task em SPELL expressa o conhecimento acerca de um passo de
desenvolvimento e constitui uma regra de ativao com um programa (script) a ser
executado. So definidas PR e PS condies em torno da seo de cdigo, que servem
como "envelope" de cada tarefa. Pr e ps condies estticas so utilizadas para o
raciocnio para frente e para trs 7, enquanto que as pr e ps condies dinmicas so
teis para a ativao dinmica de atividades. Assim, redes de tarefas SPELL podem
expressar tanto modelos de processo orientados a objetivos (utilizando regras estticas e
restries para planejamento automtico da rede), como modelos orientados a atividades
(usando as pr e ps condies e scripts) [AMB 97].
O tipo task possui parmetros formais e decomposies, isto , um conjunto de
operandos de entrada e sada e de subtarefas, respectivamente. Isto expressa uma
gramtica de grafos mnima ou template para descrever fragmentos da rede.
Uma task pode ser associada com um cargo e ento executada por agentes que
ocupem o cargo. Projetos so atividades especiais, contendo as requisies e logs de
mudanas, informaes acerca do versionamento de artefatos, recursos disponveis, e
protocolos de comunicao. Conceitos e formalismos associados para modelagem de
verses, transaes e espaos de trabalho so expressados fora de SPELL.
Uma instncia de task potencialmente ativa, e permanece em uma rede de
tarefas (ou plano) que serve para conectar as tarefas vizinhas. Os construtores
FORMALS e DECOMPOSION (restries estticas que expressam uma gramtica de
grafos) e as pr e ps condies estticas ajustam a estrutura e o fluxo de controle desta
rede de tarefas.
A execuo de uma tarefa pode ocorrer em qualquer nodo da rede, no apenas nas
folhas. O fluxo de controle pode ser busy (ativado por gatilhos), periodic, opportunistic,
ou lazy (orientado a objetivos), enquanto que a execuo de uma tarefa pode ser
automtica ou manual (ao humana), com procedimentos arbitrrios de reviso e
negociao.
Forward ou Backward chaining.

A seo de cdigo de uma tarefa (chamada CODE) responsvel por tornar
dinamicamente uma ps-condio verdadeira. Isto pode disparar outras atividades na
rede, tornando verdadeiras as pr-condies de outras tarefas. O script de uma tarefa
pode ser re-executado, repetindo o padro acima.
Figura 3.3 - Os tipos primitivos (classes) do ambiente EPOS utilizados por SPELL
A linguagem SPELL suporta vrios nveis de abstrao e composio para
modelar elementos de processo externos. Entretanto, a verso apresentada em [CON 94]
definida somente para suportar a programao de processos (sem suporte a anlise ou
projeto). Alm disso, SPELL possui uma representao grfica (um exemplo exposto na
figura 3.4) e reflexiva, permitindo que modelos de processo sejam especializados
hierarquicamente e refinados dinamicamente em tempo de execuo, podendo ainda ser
versionados [AMB 97]. Requisitos de processo no-automatizveis (anlise e projeto de
processo) no so bem suportados, embora alguns aspectos da linguagem possam ser
utilizados para descrever processos mais informais ou incompletos. Ainda segundo
[AMB 97], SPELL fornece um suporte fraco para anlise formal dos modelos, assim
como no possibilita mltiplas vises do processo.
Figura 3.4 - Rede de tarefas na representao grfica de SPELL [LIM 98]
3.3.2
E3
Um dos principais objetivos do projeto E3 [BAL 94] construir um mtodo para

projetar modelos de projeto antes da sua implementao. Inicialmente, a metodologia de
desenvolvimento de software orientado a objetos de Coad e Yourdon [COA 92] foi
investigada e utilizada para projetar tanto o exemplo ISPW6 8 e quanto o processo de
software de uma empresa de software regional. Com estas experincias, foi obtido um
ncleo principal de classes e relacionamentos associados com a modelagem de processo
de software e um conjunto de domnios identificar os diferentes aspectos (vises) a serem
tratados. Assim, os principais benefcios deste estudo foram:
A construo de uma interessante metodologia de projeto de processo de software

baseado na tcnica de Coad e Yourdon [COA 92];
Diferentes cones foram criados para identificar as classes de processo (objetos,

tarefas, papis, dados e ferramentas), alm de um novo conjunto de relacionamentos
(associaes, segundo a terminologia de [COA 92]) de herana, subtarefa, entrada e
sada, pr-ordem, feedback, responsabilidade e uso;
Este exemplo foi proposto no 6 International Software Process Workshop (ISPW6) e consiste
de vrios componentes importantes dos processos de software do mundo real desempenhando
um papel muito importante na verificao e avaliao de ambientes e linguagens de processo de
software [LIM 98].
O modelo de processo composto por quatro submodelos que so os de atividades,

dados, papis, e ferramentas. Cada submodelo derivado por herana a partir das
classes principais. A apresentao grfica do modelo de processo estruturada em
quatro vises, chamadas Viso de Herana (Inheritance View), Viso de Tarefa (Task
View), Viso de Decomposio de Tarefa (Task Decomposition View) e Viso do
Usurio (User View).
Assim sendo, o mtodo E3 estende a metodologia de Coad e Yourdon e apresenta

algumas representaes grficas novas para tipos especiais de classes e associaes. A
figura 3.5 apresenta os principais cones e associaes criadas pelo mtodo.
A seguir, so apresentadas as classes principais:
Classe Task (Tarefa). As atividades do processo de software so modeladas como

objetos de Task. Uma task pode ser subdividida em subtasks (atravs da associao
subtask). A ordem de execuo de tarefas encadeadas fornecida pelas relaes de
feedback e preorder. Uma tarefa representada graficamente como um retngulo
rachurado. A vida de um objeto task passa por um nmero de estados identificveis
pelo atributo state. A classe fornece algumas operaes (mtodos), dentre as quais:
handleCompletion (chamada por uma subtarefa para notificar a mudana de estado),
startExecution (para iniciar a sua execuo), restart ( ativada por uma classe que
falhou para garantir a reexecuo), e readyToInteract (para notificar a tarefa que o
usurio est pronto para interagir).
Figura 3.5 - Classes e relaes introduzidas por E3
Classe Role (cargo). Atividades que requerem interveno humana devem ser
modeladas como tarefas com um cargo associado. A associao entre tarefas e papis
especificada no nvel de modelo, isto , uma tarefa deve estar conectada pela relao

responsible ao cargo que estar encarregado de realiz-la. Subclasses de Role so
representadas graficamente como chapus;
Classe Data (Dados). Os objetos desta classe representam os artefatos de software

produzidos e consumidos durante o processo;
Classe Tool (Ferramenta). Algumas atividades do desenvolvimento de software so

realizadas por ferramentas automticas, ou ferramentas de projeto, ou compiladores.
O conectivo use conecta ferramentas a dados que necessitam ser tratados. A classe
Tool oferece a operao run que inicia a execuo da ferramenta.
A linguagem E3 fortemente baseada em notao grfica e, na descrio da

linguagem em [BAL 94] no h evidncia de suporte a reflexo (apesar de [LON 94]
garantir que h) e outros aspectos diretamente relacionados programao de processos.
As figuras 3.6 e 3.7 mostram exemplos de diagramas de decomposio de tarefas e de
especializao de papis. Uma ferramenta CASE chamada E3p-draw para o desenho de
diagramas segundo a notao desta metodologia apresentada em [JAC 95].
Figura 3.6 - Decomposio de Tarefas em E3 [BAL 94]
Figura 3.7 - Diagrama de especializao de papis [BAL 94]
3.3.3 SLANG
O projeto SPADE (Software Process Analysis, Design and Enactment) vem sendo
desenvolvido no Instituto Politecnico di Milano e CEFRIEL. O ambiente baseado em
uma linguagem de modelagem de processo de software chamada SLANG (SPADE
Language) que um formalismo baseado em uma rede de Petri de alto nvel. SLANG
fornece recursos para modelagem, execuo e evoluo de processos. Alm disso,
permite descrever a interao com humanos e ferramentas externas de uma maneira
uniforme. As principais caractersticas de SLANG so:
Modelos de processos podem ser estruturados de uma maneira modular utilizando-se

a construo atividade. Atividades (isto , fragmentos do processo) podem ser
dinamicamente instanciados;
Atividades podem ser manipuladas dinamicamente por outras atividades, ou seja,

SLANG reflexiva;
Artefatos do processo, incluindo modelos de processo, so mantidos em um banco de

dados orientado a objetos.
A linguagem SLANG fortemente tipada. As definies de tipos seguem o estilo

orientado a objetos, organizando os tipos em uma hierarquia definida por um
relacionamento "-um". Cada tipo define um tipo abstrato de dados, isto , uma estrutura
que s pode ser acessada pelas operaes exportadas.
Uma especificao de processo em SLANG um par de conjuntos:
SLANGSpec = (ProcessTypes, ProcessActivities)
ProcessTypes um conjunto de descries de tipos organizados hierarquicamente
e ProcessActivities um conjunto de instncias do tipo Activity. Como os modelos de
processo SLANG so baseados em uma notao de rede de Petri de alto nvel, dados do
processo so representados por tokens. Cada token um objeto tipado, no qual possvel
aplicar operaes definidas na descrio do seu tipo ou herdadas de super-tipos. Em
SLANG, tokens so associados a valores, e transies so associadas com regras. Cada
token implementado e manipulado como um objeto em um banco de dados orientado a
objetos. Cada regra composta por uma condio, utilizada para extrair uma tupla
habilitada (isto , tokens que satisfaam a condio) do banco de dados, e um conjunto de
clusulas para especificar como criar a tupla de sada. Assim, SLANG integra tcnicas
orientadas a objeto para a modelagem de produtos, com redes de Petri estritamente para
modelagem de processo. Esta abordagem justificada por:
Os artefatos produzido durante o desenvolvimento de software so complexos e

estritamente interrelacionados. O paradigma de objetos torna possvel descrever
facilmente tanto a estrutura de artefatos quanto os seus relacionamentos;
O processo de desenvolvimento de software composto por mltiplas atividades que

so executadas em paralelo e necessitam ser sincronizadas. A notao de Rede de
Petri estendida adotada por SLANG torna a modelagem destes aspectos natural e de
fcil entendimento.

Os recursos embutidos de SLANG so orientados para modelar atividades e
produtos. tambm possvel integrar e controlar diferentes tipos de ferramentas em dois
nveis de granulosidade (ativao/trmino de uma ferramenta e ativao de servios
individuais de uma ferramenta). SLANG no possui construtores para descrever cargos,
objetivos ou espaos de trabalho. Cargos podem ser implementados como objetos (isto ,
tokens) com suas operaes associadas (mtodos de objetos e regras de transio) em um
atividade SLANG. Espaos de trabalho podem ser explicitamente gerenciados atravs da
especificao de algumas atividades SLANG necessrias para sua criao e manipulao.
A abordagem adotada pelos projetistas de SLANG foi a de prover uma linguagem
simples onde conceitos especficos de processo so modelados explicitamente pelo
projetista de processo.
SLANG oferece facilidade de modularizao que torna possvel estruturar um
modelo de processo como uma hierarquia de redes SLANG. A construo para
modularizar processo chamada atividade 9. Cada atividade uma rede SLANG com
uma interface e implementao definidos. A implementao de uma atividade pode
incluir a ativao a outras atividades e cada ativao implica na criao de uma nova
instncia (cpia ativa) da atividade chamada, que executada assincronamente com o
chamador. Cada instncia de uma atividade SLANG (uma cpia ativa) executada
independente pelo interpretador SLANG. Assim, durante a execuo de processo,
mltiplas cpias ativas so executadas concorrentemente por muitos interpretadores
SLANG. A consistncia (representada pela atomicidade de uma transio em rede de
Petri) sempre garantida uma vez que uma transio SLANG executada como uma
transao ACID.
Em SLANG, uma atividade o termo utilizado para identificar um fragmento da rede.
Figura 3.8 - Definio de uma atividade SLANG [BAN 93]

A evoluo suportada atravs dos recursos reflexivos (late binding, invocao
dinmica, e visibilidade de programas como dados). Em particular, definies de
atividades (sua representao grfica) e estados das cpias ativas (o estado das atividades
em execuo) podem ser vistas como tokens e, assim, podem ser manipuladas por
qualquer atividade SLANG como um token qualquer.
O ambiente SPADE-1 inclui um editor grfico para SLANG, um compilador
(verificao de erros) e um interpretador SLANG, um monitor de processo (para exibir o
estado da execuo do processo), e dois prottipos de agenda.
3.3.4 TEMPO
TEMPO uma linguagem de programao de processo baseado no conceito de
cargo e conexo construda para o ambiente ADELE [NOU 94]. Um tipo de processo de
software definido como um conjunto de objetos realizando um papel (role). Um papel
permite que seja redefinido dinamicamente as propriedades comportamentais de objetos
que esto realizando um papel no processo, permitindo assim o acrscimo de novas
funcionalidades a um objeto em tempo de execuo. Uma conexo expressa como os
processo cooperam.
Um modelo de processo de software definido como uma combinao de tipos de
processo de software. Um tipo processo identifica e descreve um conjunto de atividades.
Processos de software so atividades que executam concorrentemente e de forma
assncrona. Em TEMPO, os protocolos para comunicao e sincronizao entre processos
de software so descritos por regras temporais evento-condio-ao (TECA). Todas as
manipulaes feitas em um objeto durante o processo de software geram eventos.
TEMPO capaz de lidar com modelos de processo de software definidos pelo
usurio, mltiplas vises de artefatos de software, eventos temporais, atividades de longa
durao, e prov suporte a comunicao entre atividades de software. Um modelo de
processo de software de tamanho considervel pode ser escrito atravs do agrupamento
de vrios tipos de processo de software. Um tipo processo de software possui uma
definio recursiva. Por exemplo, uma atividade para verificar um documento de projeto
de um mdulo consiste de dois sub-processos:
Um subprocesso que modela a atividade de modificao, permitindo que ocorram

modificaes no documento de projeto;
Um subprocesso que modela a atividade de reviso, permitindo a aprovao de

qualquer modificao que for realizada no documento de projeto.
A figura 3.9 abaixo mostra o processo MonitorDesign especificado em TEMPO,

composto pelos subprocessos ModifyDesign e ReviewDesign. possvel ainda definir,
para cada tipo de processo, propriedades adicionais como atributos, mtodos e restries
temporais (usando regras TECA). Uma regra TECA tem o formato When Event DO
Method onde Event um predicado expressando um evento atual ou do passado do
sistema ou de um objeto, e Method um mtodo. Um exemplo de regra TECA
mostrado na figura 3.10. Esta linha expressa que o evento delete sensible verdadeiro
sempre que existe uma tentativa de eliminar um componente (!cmd==remove), o qual
seja tanto um componente de uma configurao liberada (!object/comp/state == released)
ou que tenha tido no passado seu estado validado (!object@(status == validated)). A
expresso !object representa o nome do objeto recebendo o mtodo !cmd. De modo
similar, todos os parmetros do mtodo chamado pode ser verificados, assim como os
valores anteriores dos atributos do objeto.
A linguagem TEMPO baseada na abordagem orientada a objetos, onde tipos de
processos, tipos de dados e tipos de conexes so definidos em um esquema de processo
e instanciados como objetos no banco de dadas do ambiente Adele. Tipos podem ser
includos no esquema de processo se e somente se o tipo a ser adicionado no alterar o
grafo de herana para tipos j definidos. Alm disso, tipos s podem ser excludos se no

existirem instncias ativas do tipo. As caractersticas reflexivas da linguagem permitem
que regras TECA sejam alteradas em tempo de execuo, assim como definem que
objetos possam assumir vrios papis durante a sua (a vinculao de um objeto a sua
classe realizada dinamicamente, na sua instanciao).
Figura 3.10 - Regra TECA em TEMPO [BEL 94]
Figura 3.9 - Monitor_Design em TEMPO [BEL 94]
3.3.5 LOTOS-SPD
As tcnicas de especificao formal vem sendo utilizadas na Engenharia de
Software para proporcionar a construo de programas corretos e com alta exigncia de
qualidade. Para estas linguagens so definidas semnticas formas, permitindo a
verificao matemtica de uma srie de propriedades de qualidade de software, como
completude e correo.
LOTOS [ISO 87] uma linguagem padro ISO que conseguiu a aceitao das
comunidades acadmicas e cientficas para a especificao, simulao e validao de
sistemas distribudos e protocolos de comunicao. LOTOS representa os aspectos de
ordenao temporal de sistemas, possuindo construes para representar paralelismo de
atividades e sincronizao de eventos. LOTOS possui uma representao grfica
chamada G-LOTOS, que tambm um padro ISO [ISO 89].
Em geral, quase se utiliza LOTOS para descrever processo de software,
necessrio especificar a ordem temporal de execuo e argumentos de atividades
primitivas que fazem uso de ferramentas de desenvolvimento de software. Para executar
tal processo em um ambiente distribudo, os desenvolvedores devem se comunicar entre
si, trocando mensagens com informao e sincronizao de eventos. Entretanto, estas

comunicaes so to numerosas que complicado e arriscado para os projetista de
processo descrev-las detalhadamente em uma descrio de processo de software. Alm
disso, como muitos processos so compostos de atividades paralelas e/ou alternativas, o
entendimento destas descries seria muito difcil.
LOTOS/SPD [YAS 94] (LOTOS for Software Process Description) uma
extenso da linguagem LOTOS voltada modelagem de processo de software. Em
LOTOS/SPD no necessrio descrever detalhadamente a comunicao entre os
desenvolvedores, apenas necessria uma descrio completa do processo. Foi
desenvolvida ainda uma ferramenta que consegue derivar descries individuais (para
cada desenvolvedor), na mesma linguagem, a partir de uma descrio completa. Para a
execuo de especificaes LOTOS/SPD esto disponveis trs facilidades: a gerncia do
progresso no processo de software com troca automtica de mensagens entre os
desenvolvedores, a exibio do estado atual do processo, e orientao de atividades
automticas com ativao de ferramentas.
No modelo de processo adotado por LOTOS/SPD, assumido que cada atividade
no processo uma ao de entrada, de sada ou de entrada/sada. Uma atividade, em
LOTOS/SPD descrita como na figura 3.11.
Person!x?y : type ... [x = tool1(x), y = tool2(z), ...]
Figura 3.11 - Atividade em LOTOS/SPD [YAS 94]
Na figura 3.11, Person o identificador de um desenvolvedor, um agente do
processo. A expresso !x?y : type ... a parte de entrada/sada. O contedo dos colchetes
o contedo do trabalho, aonde so descritas as ferramentas ativadas quando a atividade
acionada. Uma ao de sada (como a disponibilizao de um arquivo x, aps a sua
manipulao pela ferramenta tool1) descrita para !x[x = tool1(x)]. De maneira similar,
uma ao de entrada descrita como ?y : type[y = tool2(z)], onde y um dado do tipo
type, e y = tool2(z) representa que o dado y a entrada para uma computao utilizando a
ferramenta tool2 com o dado existente z. Por exemplo, uma atividade na qual um
engenheiro de software SE modifica uma especificao de um sistema (ele edita um
arquivo chamado oldspec e torna disponvel um novo arquivo spec) descrito como na
figura 3.12 em LOTOS/SPD. suposto que edit representa uma ferramenta para edio
de arquivos e o arquivo gerado pela atividade atribudo varivel spec.
SE?spec : file[spec = edit(oldspec)]
Figura 3.12 - Uma atividade de edio em LOTOS/SPD [YAS 94]
A descrio de um processo completo realizada pela especificao de todas as
atividades de todos os desenvolvedores envolvidos no processo com sua ordem temporal.
Por exemplo, uma sequncia de sucessivas atividades onde: (1) um engenheiro de
software (SE) disponibiliza uma especificao de um sistema (spec), e ento (2) um
programador (PG) torna o programa (code) disponvel baseado na especificao (spec),

representada como na figura 3.13 abaixo (supondo que edit, view e makeprog so
ferramentas para edio de arquivos, exibio de arquivos e construo de programas,
respectivamente).
SE?spec : file[spec = edit()];
PG!spec?code:file[spec=view(spec),
code=makeprog()]; exit
Figura 3.13 - Processo de software simples em LOTOS/SPD [YAS 94]
O operador ";" utilizado na figura 3.13 anterior, conecta duas atividades e fornece
a execuo sucessiva delas. Em LOTOS, so definidos os seguintes operadores para
controlar a execuo das aes (admitindo que e so aes LOTOS):
Execuo seletiva: [] ;
Execuo paralela assncrona: ||| ;
Execuo paralela sncrona: |[G]| ;
Execuo sucessiva: >> ;
Interrupo: [> .
Assim sendo, o processo de software MakeCode descrito informalmente abaixo

e em LOTOS/SPD na figura 3.14.
SE edita uma especificao antiga de um sistema oldsp, e disponibiliza uma nova

especificao chamada spec;
P1, P2 e QE editam verses antigas de dois programas e um arquivo com dados de

teste chamados olds1, olds2, oldstd e criam novas verses chamadas src1, src2 e tstdt,
respectivamente em paralelo;
QE cria um mdulo executvel do sistema (code) com os dados de teste tstdt e decide
quando o processo deve ser repetido ou terminado (ele coloca "NO" para repetio e
"OK" para trmino na varivel res);
SE seleciona repetio ou trmino do processo a partir dos resultado do teste de QE

(res);
Sempre que o processo estiver em execuo, SE pode interromp-lo.
Process MakeCode[SE,P1,P2,QE]
(oldsp:file, olds1:file, olds2:file, oldtd:file): exit :=
(( SE?spec:file[spec=makedocument(oldsp)];

(P1!spec?src1:file[spec=view(spec), src1=edit(olds1)]; exit
||| P2!spec?src2:file[spec=view(spec), src2=edit(olds2)]; exit
||| QE!spec?tstdt:file[spec=view(spec), tstdt=edit(oldtd)]; exit))
>>
(QE?code:file[code=compile(src1,src2)];
QE?res:string[res=testcode(code,tstdt)];
(SE!"Try again" [res="NO"];
MakeCode[SE,P1,P2,QE(spec,src1,src2,tstdt)
[] SE!"OK"[res="OK"]; exit ) )
)
[> SE!"Interruption"; exit
endproc
Figura 3.14 - MakeCode especificado em LOTOS/SPD [YAS 94]
A abordagem utilizada por LOTOS/SPD possui como principais vantagens:
Possibilidade realizar verificao formal de propriedades do processo (por exemplo,

comprovao de ausncia de deadlock);
A notao formal, precisa, e permite expressar concorrncia e sincronizao de uma

maneira mais elegante do que os outros paradigmas convencionais;
LOTOS/SPD simplifica dramaticamente a tarefa de especificar processos de software

em LOTOS;
Diversas ferramentas para auxiliar na simulao e execuo de especificaes

LOTOS esto disponveis.
Algumas problemas so encontrados na implementao de LOTOS/SPD

apresentada em [YAS 94]:
LOTOS/SPD no reflexiva, no permitindo a modificao dinmica de processos

durante a sua execuo;
As especificaes so de difcil legibilidade. Mesmo com a utilizao do formalismo

grfico G-LOTOS, este problema no solucionado pois a notao G-LOTOS no
adequada para modelagem de processos de software;
No esto disponveis construes especficas para gerncia de recursos;
A principal promessa da especificao formal, a possibilidade de se verificar

formalmente propriedades de software, no alcana plenamente os seus objetivos pois
no esto disponveis atributos para verificao de qualidade de modelos de processo
de software.
3.3.6 JIL
JIL [SUT 97a] uma linguagem de processo de software recente, desenvolvida
sob a influncia dos ltimos acontecimentos na rea de processo de software. uma
linguagem multi-paradigma que objetiva suportar todas as facetas do processo de
software.
A construo principal de JIL um passo (step), que procura representar um
passo (etapa, atividade) no processo de software. Um programa JIL uma composio de
passos, cada um dos quais podendo conter um conjunto de sub-unidades. Os elementos
da especificao de um passo incluem:
Objetos e declaraes. Os parmetros e declaraes locais para os artefatos de

software utilizados em um passo;
Recursos. Especificao dos todos os recursos necessrios por um passo, incluindo

pessoas, software e hardware;
Conjunto de sub-passos. As subdivises de um passo;
Restries do passo. Restries ou prescries na ordem de execuo relativa de

sub-passos;
Especificao de controle pr-ativo. Uma especificao imperativa da ordem dos

sub-passos que sero executados (invocao direta);
Especificao de controle reativo. Uma especificao de controle reativa de

condies e eventos em resposta aos sub-passos que so executados (ativao
indireta);
Pr-condies, restries e ps-condies. Definem a condies de consistncia de

um artefato que devam ser satisfeitas (respectivamente) antes, durante e depois da
execuo de um passo;
Tratamento de excees.
Um exemplo de uma especificao de JIL exibida na figura 3.15. Como a

diviso de elementos na especificao de um passo pode sugerir, JIL uma linguagem
fatorada, ou seja, prov representaes independentes para semnticas independentes.
Isto possui muitas consequncias. Primeiro, os vrios aspectos de um passo podem ser
especificados relativamente independentes uns dos outros. Por exemplo, os sub-passos
para um passo podem ser dados sem indicar qualquer fluxo de controle pr-ativo ou
reativo, e o fluxo de controle pode ser especificado sem se preocupar com os recursos ou
as pr e ps-condies. Segundo, a relativa independncia de elementos em uma
especificao de passo permite que os passos sejam definidos utilizando-se apenas um
subconjunto de elementos (muitos elementos so opcionais). Isto promove a flexibilidade
na especificao de processo, uma vez que apenas aqueles elementos que so importantes
para um determinado propsito sero especificados. Por outro lado, isto impe
dificuldades adicionais interpretao dos processos, uma vez que vrios tipos e
combinaes de elementos podem ser apresentados em um passo.
Figura 3.15 - Exemplo de uma especificao de um passo em JIL [SUT 97a]

JIL prov uma grande variedade de paradigmas de controle para permitir
abordagens alternativas de especificao do fluxo de controle do processo. O paradigma
de controle de JIL caracterizado por trs principais recursos:
A combinao de controle pr-ativo e reativo (controle genrico do processo);
Integrao de pr e ps-condies (controle de granulosidade fina). Um exemplo de

controle reativo mostrado na figura 3.16;
A habilidade de construir processos fracamente organizados sem necessitar de

programao detalhada. Assim, os agentes humanos realizam algumas tarefas na
ordem que for conveniente. Um exemplo de restrio na execuo de passos
apresentado na figura 3.17. Neste exemplo, permitido que a identificao de classes
e objetos sejam realizadas em paralelo.
Figura 3.16 - Exemplo de controle reativo em JIL [SUT 97a]
Figura 3.17 - Exemplo de restries na ordenao de passos em JIL [SUT 97a]

Uma representao grfica para JIL est sendo preparada com o nome de VisualJIL [SUT 97b]. Visual-JIL um sistema grfico interativo que suporta o
desenvolvimento de programas de processo em Little-JIL, um subconjunto de JIL que foi
cuidadosamente selecionado para possibilitar sua representao grfica.
3.4 Consideraes finais sobre linguagens de modelagem

Este texto apresentou uma comparao entre os diversos paradigmas de
linguagens de processo de software. Pde-se observar as principais caractersticas de cada
um dos paradigmas convencionais de modelagem de processo, listadas a seguir:
As linguagens procedimentais so as que apresentam maiores dificuldades

para expressar concorrncia e paralelismo, elementos importantssimos na
descrio de processos de software. Contudo, o paradigma expressa
naturalmente o encadeamento de atividades;
As linguagens funcionais podem descrever os elementos do processo

hierarquicamente. Entretanto, no fcil descrever aes paralelas e a
sincronizao
entre
atividades
concorrentes
realizadas
pelos
desenvolvedores. Alm disso, no fcil extrair o trabalho de cada
desenvolvedor a partir da descrio funcional completa do processo;
Nas linguagens baseadas em regras no fcil entender o fluxo de controle

de todo o processo e descrever atividades paralelas explicitamente;
Com a utilizao de linguagens baseadas em Redes de Petri, o paralelismo

de atividades naturalmente descrito. As descries so legveis, utilizandose as representaes grficas de Redes de Petri. Entretanto, necessria uma
extenso substancial ao modelo para permitir o fluxo de dados (vrias
extenses so encontradas na literatura, mas no existe uma notao padro).
Assim, ferramentas para anlise e execuo podem ser modificadas para
tratar com dados;
Linguagens orientadas a objetos apresentam inmeras vantagens

decorrentes da integrao do encapsulamento de dados com a herana,
permitindo a construo de modelos organizados hierarquicamente
compostos por elementos simples. O paradigma de objetos acomoda
naturalmente a concorrncia e paralelismo de atividades (embora no seja
to simples na modelagem de sincronizao de eventos quanto linguagens
derivadas de LOTOS);
Linguagens baseadas em especificao formal se preocupam em descrever

o processo atravs de relaes matemticas, formalmente verificveis.
Linguagens baseadas em LOTOS expressam concorrncia e sincronizao de
eventos de uma maneira extremamente elegante. As linguagens de
especificao formal, entretanto, so de difcil utilizao, exigindo muitas
habilidades para o programador de processos. A promessa de verificar
formalmente os processos de software ainda no atingiu sua maioridade (por
ainda no terem sido identificadas caractersticas especficas de processo que
possam ser verificadas formalmente).
A rea caminha para a utilizao de linguagens multi-paradigma (ou de

paradigma hbrido), que permitam a descrio de todos os aspectos dos processos.
Linguagens modernas, como JIL [SUT 97a, 97b], implementam diferentes paradigmas
para permitir um preciso controle das atividades (com fluxo de controle flexvel),
gerncia de recursos, e capacidades reflexivas.
Muita confuso ainda existe na literatura na distino entre linguagens de
modelagem e aquelas voltadas especificamente programao de processos. Durante a
realizao deste trabalho foi possvel identificar que:
Linguagens de modelagem procuram representar o processo atravs de uma

viso genrica (muitas vezes grfica), aonde possvel observar as
caractersticas de processo atravs dos seus conceitos bsicos (por exemplo,
atividades, recursos, agentes);
Linguagens de programao de processos tm como principal objetivo

permitir a execuo (automao) de programas de processo por ADS. O
formalismo empregado normalmente de baixo nvel, representando o
processo atravs de construes sintticas textuais.
Observa-se que h uma tendncia de agregar s linguagens de programao de

processo notaes grficas, a fim de permitir a sua utilizao em diferentes nveis de
abstrao, acomodando as atividades de projeto e programao de processos.
4 Ferramentas para Modelagem

Exemplo de utilizao.
de
Processos:
Com o objetivo de apresentar exemplos prticos de modelagem de processos esse

captulo mostra telas das ferramentas de apoio definio de processos: RUP Builder,
Spearmint e APSEE.
4.1 RUP Builder

A ferramenta RUP Builder da Rational/IBM permite adaptao do processo
unificado [JAC99] para as necessidades especficas de um projeto. Considerando que o
processo unificado um conjunto amplo de atividades e componentes, provida uma
forma de filtrar os elementos mais relevantes e gerar um guia na web com a viso
selecionada pelo gerente.
A figura a seguir apresenta a tela de seleo de configurao, que consiste no
primeiro passo para a definio do processo. Neste momento o usurio escolhe o tamanho
do projeto, sendo que pequenos projetos so definidos como aqueles em que trabalham
at 15 pessoas trabalhando no mesmo endereo e com uma durao especfica.
Figura 4.1 - Tela de seleo da configurao no RUP Builder.

Em seguida os componentes do processo unificado so selecionados assim como
os plug-ins que indicam a tecnologia a ser adotada no projeto (ver figura 4.2).
Figura 4.2 - Tela de seleo de componentes do processo.

As vises a serem disponibilizadas para os usurios do processo so editadas no
prximo passo. A figura 4.3 mostra a o contedo da viso do analista enquanto a figura
4.4 mostra a viso do gerente. Essas vises podem ser escolhidas e configuragas.
Figura 4.3 - Edio das vises a serem disponibilizadas no processo.
Figura 4.4 - Edio das vises no RUP Builder -contedo da viso do gerente (Manager).
O passo seguinte a configurao da publicao do guia de processo segundo o
RUP, conforme a figura 4.5.
Figura 4.5 - Configurao da Publicao do Processo.

O resultado do uso da ferramenta pode ser visualizado como um guia web com as
fases do processo, de acordo com as configuraes de gerao. Por exemplo, a figura 4.6
e a figura 4.7 mostram o resultado do uso do RUP Builder para um processo que contm
somente as vises do analista e do desenvolvedor. Dentro de cada viso possvel
identificar os passos necessrios para realizao das tarefas.
Figura 4.6 - Guia do Processo gerado a partir do RUP Web.
Figura 4.7 - Guia do Processo gerado a partir do RUP Builder.

importante salientar que no caso do RUP Builder no utilizada uma PML
nem realizada execuo automatizada do processo modelado, sendo o guia gerado
apenas para documentao e orientao da equipe.
4.2 SPEARMINT
O ambiente Spearmint [IES04] [BEC98] uma ferramenta que compe a soluo
de gerncia de processos chamada Vincent. A PML adotada a MVP-L e a principal
caracterstica da ferramenta a de permitir modelagem e documentao do processo.
Uma das funcionalidades a gerao do guia web de processos, assim como feito no
RUP Builder. As figuras a seguir mostram duas vises distintas de um modelo de
processos para Extreme Programming.
Figura 4.8 - Processo de Software no SPEARMINT - viso do gerente.
Figura 4.9 - Processo de Software no SPEARMINT - viso do desenvolvedor.
4.3 APSEE
O modelo APSEE o resultado de um projeto de pesquisa internacional que
envolve, no Brasil, a Universidade Federal do Par e a Universidade Federal do Rio
Grande do Sul, e na Alemanha, a Universidade de Stuttgart10. APSEE distingue-se por
fornecer uma infraestrutura que integra diferentes servios voltados modelagem,
simulao [SIL99], execuo [LIM02d], reutilizao ([REI01b], [REI01d] e [REI02f]),
visualizao [SOU02] e aperfeioamento de processos.
A linguagem APSEE-PML auxilia a descrio de processos, sendo tambm til
para habilitar polticas em modelos de processos de software. A figura 4.10 apresenta um
resumo da notao grfica fornecida para a APSEE-PML usada para a descrio de um
modelo de processo. As atividades normais so aquelas desempenhadas por pessoas,
enquanto que as automticas so realizadas sem interveno humana. As conexes
simples e mltiplas so responsveis por descrever o encadeamento temporal das
atividades: o tipo end-start restringe o incio da execuo da atividade destino para
apenas depois do trmino da atividade origem; o tipo end-end habilita o trmino do
10
Projeto apoiado pelo CNPq, FAPERGS, DLR e pela Fundao Alexander von Humboldt.

destino somente aps o trmino da atividade origem; finalmente, a conexo do tipo startstart habilita o incio da atividade destino para ocorrer somente aps o incio da origem.
Fragmentos e Atividades
Id-Modelo de Processo
Id-Atividade
Atividade Decomposta
(fragmento)
Atividade Folha
Normal
AUTOMATIC
Id-Atividade
Conexes de Artefato
Artefatos
Atividade (Artefato
de Entrada)
Conexo de Artefato
Atividade (Artefato
De Sada)
Conexo de Artefato
Conexo Branch
ou Join
Conexo de Artefato
Id-Artefato
Tipo-Artefato
Conexo de Artefato
Atividade Folha Automtica
Conexes Mltiplas
Conexes Simples
Tipo_Sinc
Conexo de Seqncia
condio
Conexo de Feedback
Tipo (J)
Aonde:
Tipo_S inc
Dependncia: end_start,
start_start, end_end or ? (Indefinido)
condio: expresso lgica avaliada
em tempo de execuo
Conexo Join
Tipo (B)
Tipo_S inc
Conexo Branch
Aonde:
Tipo_Sinc: end_start, start_start,
end_end or ? (Undefined)
Tipo: AND, OR ou XOR (OR e XOR
possuem condies associadas)
Figura 4.10. Representao grfica para elementos usados na modelagem de

processos
A figura 4.11 descreve um modelo de processo construdo na notao APSEE a
partir de um sub-processo do Rational Unified Process (RUP) [KRU00]. O modelo
contm seis atividades (Analyse the Problem, Understand Stakeholder Needs, Evaluation,
Define the System, Manage the Scope of the System, Define the System Definition), anode
so manipulados trs artefatos (Initial Requirements Spec, Vision e System Use Case). As
demais conexes presentes no modelo so de dois tipos: conexes simples (por exemplo,
a conexo start-start entre Analyse the Problem e Understand Stakeholder Needs) e
conexes de feedback (e.g., entre Evaluation e Analyse the Problem).
Figura 4.11- O sub-processo Requirements Workflow do RUP na notao

APSEE
5 Concluses
A tecnologia de processo de software quando combinada com outras tcnicas de
Engenharia de Software pode trazer inmeros benefcios para o aumento da qualidade do
software produzido.
Esse texto representa um passo na disseminao da Tecnologia de Processo de
Software no sentido de ampliar a discusso do tema no pas. Acredita-se que o
aprofundamento da divulgao desse assunto possa levar a um aumento significativo na
qualidade dos processos adotados e, por conseqncia, nos produtos resultantes de
organizaes de desenvolvimento de software.
Apesar de tudo que a comunidade internacional j desenvolveu, a modelagem e
automao de processos ainda uma tarefa complexa que demanda profissionais
altamente especializados. Esforos ainda devem ser realizados no sentido de unificar a
terminologia, notaes e requisitos no contexto das solues automatizadas para
reutilizao de processos de software, a fim de amadurecer a pesquisa na rea. Alm
disso, a tecnologia de processo de software vem absorvendo os recentes avanos no
contexto de linguagens de programao para facilitar a construo e manuteno dos
programas de processos. Assim, por exemplo, a programao orientada a aspectos um
campo inovador que pode trazer inmeros benefcios modelagem de processos segundo
mltiplas perspectivas [REI02d].
A necessidade de acomodar modificaes em modelos de processos em
execuo tambm constitui um tpico importante de pesquisa atual. Processos so
suscetveis a modificaes, isto , a intrnseca natureza dinmica do desenvolvimento de
software tem como conseqncia que os processos originalmente prescritos dificilmente
so executados sem qualquer modificao. Assim, algumas modificaes devem ser
toleradas, desde que no levem a estados inconsistentes [LIM02e].
Outra tendncia recente integrar PSEEs a ferramentas tradicionais de gerncia
de projetos e/ou de workflow. O ambiente MILOS [MAU00] gerencia processos de
software na Internet integrando modelagem, planejamento e execuo. Sua mquina de
execuo est integrada com o gerenciador Microsoft Project - o qual fornece a interface
para o gerente do projeto oferecendo, ainda, interface para os agentes utilizando applets
Java e comunicao via e-mail. A sinergia de integrar diferentes solues j disponveis
nas empresas de desenvolvimento parece ser um caminho vivel para a popularizao da
tecnologia de processo de software.
Finalmente destaca-se a importncia da modelagem de processos para auxiliar a
gerncia de desenvolvimento de software provendo documentao e orientao para os
participantes do processo. Espera-se que a tecnologia de processos seja amplamente
adotada em organizaes de desenvolvimento de software preocupadas com a qualidade
de seus produtos.
6 Bibliografia
[AMB 97]
AMBRIOLA, V.; CONRADI, R.; FUGGETA, A. Assessing process-centered software

engineering environments. In: ACM Transactions on Software Engineering and
Methodology, v. 6, n. 3, Jul. 1997, p. 283-328.
[ARB 94]
ARBAOUI, S.; OQUENDO, F. PEACE: Goal-Oriented Logic-Based Formalism for

Process Modelling. In: FINKELSTEIN, A. et al. (Ed.). Software Process Modelling
and Technology. Tauton: Research Studies Press, 1994. p. 249-278.
[ARM 92]
ARMENISE, P. et al. Software Processes Representation Languages: Survey and

Assessment.
In:
INTERNATIONAL
CONFERENCE
ON
SOFTWARE
ENGINEERING AND KNOWLEDGE ENGINEERING, 4., 1992, Capri, Italy.
Proceedings... [S.l.]: IEEE Press, June 1992.
[BAL 94]
BALDI, M.; GAI, S.; JACCHERI, M. L.; LAGO, P. Object Oriented Software Process
Model Design in E3. In: Software Process Technology, B.A. Nuseibeh (editor),
Research Studies Press, 1994. Disponvel na internet por www em
http://www.polito.it/~ezmaint/articles.html.
[BAN 93]
BANDINELLI, S.; FUGGETTA, A.; GRIGOLLI, S. Process Modeling in-the-large with

SLANG. Proceedings of the 2nd International Conference on Software Process,
IEEE Press, p. 75-83, 1993.
[BAN 94]
BANDINELLI, S.; FUGGETTA, A.; GHEZZI, C.; LAVAZZA, L. SPADE: An

Environment for Software Process Analysis, Design and Enactment. FINKELSTEIN,
A. et al. (Ed.). Software Process Modelling and Technology. Tauton: Research
Studies Press, 1994. p.223-248.
[BAR 92]
BARGHOUTI, N.S. Supporting Cooperation in the MARVEL Process-Centered SDE,

ACM SigSoft, vol. 17, N. 5, p. 21-31, 1992.
[BEC 98]
Ulrike Becker-Kornstaedt; Dirk Hamann; Ralf Kempkens; Peter Rsch; Martin

Verlage; Richard Webby; Jrg Zettel. Support for the Process Engineer: The
Spearmint Approach to Software Process Definition and Process Guidance.
Proceedings of the 11th International Conference on Advanced Information Systems
Engineering. Lecture Notes In Computer Science. Pages: 119 - 133, 1999. ISBN:3540-66157-3 Springer-Verlag London, UK .
[BEL 94]
BELKHATIR, N.; ESTUBLIER, J.; MELO, W.; ADELE-TEMPO: An Environment to

Support Process Modelling and Enaction. In: FINKELSTEIN, A. et al. (Ed.). Software
Process Modelling and Technology. Tauton: Research Studies Press, 1994. p. 187222.
[CHE 90]
CHEN, P. Modelagem de Dados: A abordagem Entidade-Relacionamento para

Projeto Lgico. Makron Books, 1990.
[CHR 95]
CHRISTIE, A. Software Process Automation: the technology and its adoption.

Springer, 1995.
[COA 92]
COAD, P.; YOURDON, E. Anlise Baseada em Objetos. So Paulo, Editora

Campus, 1992.
[CON 94]
CONRADI, R. et al. EPOS: Object-Oriented Cooperative Process Modelling. In:

FINKELSTEIN, A. et al. (Ed.). Software Process Modelling and Technology.
Tauton: Research Studies Press, 1994. p. 33-70.
[CUR 92]
CURTIS, B. et al. Process Modelling. Communications of the ACM, New York, v.

35, n. 9, Sept. 1992.

[DAL 97]
DAL PIZZOL, A. Uma Avaliao de Linguagens de Processo de Software. Trabalho

Individual, Porto Alegre: CPGCC-UFRGS, 1997.
[DEI 90]
DEITERS, W.; GRUHN, V. Managing Software Process in the Environment

MELMAC, ACM SigSoft, Vol 15, No. 6, 1990.
[DER99]
DERNIAME, J.; KABA, B.; WASTELL, D. (Eds.). Software Process: Principles,

Mehodology and Technology. Lecture Notes in Computer Science, 1500.
Springer, 1999.
[DOW 91]
DOWSON, M.; NEJMEH, B.; RIDDLE, W. Fundamental Software Process Concepts.

In: EUROPEAN WORKSHOP ON SOFTWARE PROCESS MODELLING, 1., 1991,
Milan, Italy. Proceedings... [S.l.]: AICA Press, May 1991.
[DUI95]
DUITSHOF, M. Workflow Automation in Three Administrative Organizations,

M.Sc. Thesis, Departament of Computer Science - Section Information Systems University of Twente - The Netherlands., 1995.
[ENG 94]
ENGELS, G.; GROENEWEGEN, L. SOCCA: Specifications of Coordinated and

Cooperative Activities. In: FINKELSTEIN, A. et al. (Ed.). Software Process Modelling
and Technology. Tauton: Research Studies Press, 1994. p. 71-102.
[FEI93]
FEILER, P. H.; HUMPHREY, W.S. Software Process Development and Enactment:

Concepts and Definitions. In: INTERNATIONAL CONFERENCE ON THE
SOFTWARE PROCESS, 2., 1993, Berlin. Proceedings... Berlin: IEEE Computer
Society Press, Mar. 1993.
[FRA02]
FRANCH, X.; RIB, J. Supporting Process Reuse in PROMENADE. Research

Report n. LSI-02-14-R, Departament de Llenguatges i Sistemes Informtics,
Universitat Politcnica de Catalunya, Feb. 2002. Disponvel na Internet por www em
http://www.lsi.upc.es/dept/techreps/html/R02-14.html
[GEO94]
GEORGAKOPOULOS, D. et. al. An Overview of Workflow Management: From

Process Modeling to Workflow Automation Infrastructure. Disponvel na Internet
por
www
em
http://www.informatik.unitrier.de/~ley/db/indices/atree/g/Georgakopoulos:Dimitrios.html
[GIM94]
GIMENES, I. O Processo de Engenharia de Software: Ambientes e Formalismos,

XIII Jornada de Atualizao em Informtica, XIV Congresso da Sociedade Brasileira
de Computao, Caxambu-MG, 1994.
[GRU98]
GRUNDY., J. A Decentralized Architecture for Software Process Modeling and

Enactment. IEEE Internet Computing, V. 2, N. 5: Sept.-Oct. 1998, p. 53-62.
[HUM 89]
HUMPHREY, W.S. The Software Engineering Process: Definitions and Scope. ACM
Sigsoft Software Engineering Notes, New York, v. 14, n. 4, June 1989, p. 82-83.
Trabalho apresentado em: International Software Process Workshop, 4., 1988,
Devon, UK.
[HUM89]
HUMPHREY, W.S. The Software Engineering Process: Definitions and Scope. ACM
Sigsoft Software Engineering Notes, New York, v. 14, n. 4, June 1989, p. 82-83.
Trabalho apresentado em: International Software Process Workshop, 4., 1988,
Devon, UK.
[IES04]
http://www.iese.fraunhofer.de/Products_Services/vincent/ (Acesso em agosto de

2004).
[ISO 87]
ISO-Information Processing Systems-Open Systems Interconnection. LOTOS - A

Formal Description Technique Based on the Temporal Ordering of Observational
Behaviour. DIS 8807, 1987.
[ISO 89]
ISO-Information Processing Systems-Open Systems Interconnection. G-LOTOS: A

Graphical Syntax for LOTOS. ISO/IEC JTC1/SC21 N 3253, 1989.

[JAC 95]
JACCHERI, M.; AMERIO, E.; MALNATI, G. SENESI, P. E3 p-draw: a tool to produce

and reuse software process models. Relatrio tcnico. Dipartamento de Automatica
e Informatica, Politecnico de Torino. Disponvel na Internet por www em
http://www.polito.it/articles/e3
[JAC98]
JACCHERI, M. L.; LAGO, P.; PICCO, G.P. Eliciting Software Process Models with
the E3 Language. ACM Transactions on Software Engineering and
Methodology, Summer 1998. Em http://www.polito.it/~patricia/articles/tosem.pdf.zip
[JAC99]
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James; The Unified

Software Development Process. Massachusetts: Addison-Wesley, 1999.
[JUN 94]
JUNKERMANN, G. et al. MERLIN: Supporting Cooperation in Software

Development Through a Knowledge-Based Environment. In: FINKELSTEIN, A. et al.
(Ed.). Software Process Modelling and Technology. Tauton: Research Studies
Press, 1994. p. 103-130.
[KAI 90]
KAISER, G.E.; BARGHOUTI, N.S.; SOKOLSKY, M.H. Preliminary Experience with

Process Modeling in the Marvel Software Development Environment Kernel, Annual
Hawaii Int. Conf. On System Science, 23., Proceedings... Vol II, p. 131-140, 1990.
[KAT 89]
KATAYAMA, T. A Hierarchical and Functional Software Process Description and Its

Enaction, International Conference on Software Engineering, 11., Proceedings... p.
343-352, 1989.
[KRU00]
KRUCHTEN, P. The Rational Unified Process: An Introduction. 2nd edition.

Addison-Wesley, 2000.
[KRU96]
KRUKE, V. Reuse in Workflow Modeling. Diploma thesis. Norway: Norwegian

University of Sciente and Technology. 1996. Disponvel na internet por www em
http://www.pvv.ntnu.no/~crukis (Janeiro 2000).
[LIM02a]
LIMA REIS, C.A.; REIS, R.Q.; ABREU, A.; NUNES, D.J. APSEE: Um Modelo Formal
e Flexvel para Execuo de Processos de Software. In: Workshop Iberoamericano
de Ingeniera de Requisitos y Ambientes Software, 5. (IDEAS2002) Memrias...
CYTED. Havana, Cuba. Abr. de 2002.
[LIM02b]
LIMA REIS, C. A.; REIS, R.Q.; SCHLEBBE, H.; NUNES, D.J. A Policy-based
Resource Instantiation Mechanism to Automate Software Process Management.
Workshop on Software Engineering Decision Support (SEDECS'2002). In: Software
Engineering & Knowledge Engineering, 14. (SEKE2002). Proceedings Ischia,
Itlia. Jul. 15-19, 2002. ACM Press.
[LIM02c]
LIMA REIS, C.A.; REIS, R.Q.; SCHLEBBE, H.; NUNES, D.J. Resource Instantiation
Policies in Software Process Environments. In: Annual International Computer
Software and Applications Conference, 26. (COMPSAC2002). Proceedings
Oxford, Inglaterra. Ago. 26-29, 2000. Los Alamitos: IEEE Computer Society Press.
[LIM02d]
LIMA REIS, C.A. APSEE: Um Modelo Flexvel para Execuo de Processos de

Software. Tese de Doutorado. Porto Alegre: PPGC-UFRGS, 2003. disponvel em
www.cultura.ufpa.br/clima
[LIM02e]
LIMA REIS, C.A. et al. Flexible Software Process Enactment Support in the APSEE
Model. In: IEEE Symposia on Human-Centric Computing Languages and
Environments. Proceedings Arlington, USA. Sept. 2002. Los Alamitos: IEEE
Computer Society Press.
[LIM98]
LIMA, C. Um Gerenciador de Processos de Software para Ambiente

PROSOFT. Dissertao de Mestrado, Porto Alegre: CPGCC-UFRGS, 1998.

[LON 93]
LONCHAMP, J. A Structured Conceptual and Terminological Framework for the

Software Process Engineering. In: INTERNATIONAL CONFERENCE ON THE
SOFTWARE PROCESS, 2., 1993, Berlin. Proceedings... Berlin: IEEE Computer
Society Press, Mar. 1993.
[LON 94]
LONCHAMP, J. An Assessment Exercise, p. 335-356, In: FINKELSTEIN, A. et al.

(Ed.). Software Process Modelling and Technology. Tauton: Research Studies
Press, 1994. p. 335-356.
[MAU00]
MAURER, F.; DELLEN, B.; BENDECK, F.; GOLDMANN, S.; HOLZ, H.; KTTING,
B.; SCHAFF M. Merging Project Planning and Web-Enabled Dynamic Workflow
Technologies. IEEE Internet Computing, May/June 2000. Los Alamitos: IEEE
Computer Society Press.
[MUR89]
MURATA, T. Petri Nets: Properties, Analysis and Applications. IEEE,

Proceedings v. 77, n. 4, pp. 541-580, 1989. Los Alamitos: IEEE Computer
Society Press.
[NGU97]
NGUYEN, M.; WANG, A. Total

(http://www.idt.unit.no/~epos/Papers)
[OCA98]
OCAMPO, C.; BOTELLA, P. Some Reflections on applying Workflow

Technology to Software Process. Internal Report LSI-98-5-R, Department de
Lenguatges i Sistemes Informtics, UPC, Barcelona, Feb 1998.
[OST87]
OSTERWEIL, L. Software Process are Software Too. In: INTERNATIONAL

CONFERENCE ON SOFTWARE ENGINEERING, 9., 1987, Monterey, California.
Proceedings... Monterey: IEEE Computer Society Press, 1987.
[PAU94]
PAULK, M. The Capability Maturity Model:Guidelines for Improving the Software

Process. Carnegie Mellon University, Software Engineering Institute. AddisonWesley, 1994.
[PRE 95]
PRESSMAN, R.S. Engenharia de Software. So Paulo: Makron Books, 1995.
[PRE01]
PRESSMAN, R.S. Software Engineering: A Practitioners Approach (European

Edition). 5 edio, London: McGraw-Hill, 2001.
[REI 98]
REIS, R. Uma Proposta de Suporte ao Desenvolvimento Cooperativo de Software

no Ambiente PROSOFT. Dissertao de Mestrado, CPGCC-UFRGS, 1998.
[REI00]
REIS, R.Q.; NUNES, D.J. Reutilizao de Processos de Software. Exame de

Qualificao nmero 46. Porto Alegre: PPGC-UFRGS, Jan. 2000.
[REI01a]
REIS, R. Q.; LIMA REIS, C.A. NUNES, D.J. Automated Support for Software
Process Reuse: Requirements and Early Experiences with the APSEE model. In:
INTERNATIONAL WORKSHOP ON GROUPWARE, 7. Proceedings Darmstadt,
Germany, Sept. 2001. Los Alamitos: IEEE Computer Society Press.
[REI01b]
REIS, R.Q. APSEE-StaticPolicy: Sintaxe, semntica algbrica e exemplos de

uma linguagem para verificao automtica de polticas estticas em modelos
de processos de software. Relatrio de Pesquisa nmero 311. Porto Alegre:
PPGC-UFRGS, 50 p. Jul. 2001.
[REI01c]
REIS, R.Q.; LIMA REIS, C.A.; NUNES, D.J. APSEE-StaticPolicy: Verificao de

Polticas Estticas em Modelos de Processos de Software. In: SIMPSIO
BRASILEIRO DE ENGENHARIA DE SOFTWARE, 15. (SBES2001). Anais...
IME/COPPE: Rio de Janeiro. Out. 2001.
[REI01d]
REIS, R.Q. Descrio da Metodologia INRECA para desenvolvimento de

aplicaes CBR atravs de Modelos Reutilizveis de Processos de Software
do ambiente APSEE. Relatrio de Pesquisa RP-322. Porto Alegre: PPGC-UFRGS,
77p., Jul.2001
Software
Process
Model
in
Epos.

[REI02a]
REIS, R.Q.; Lima Reis, C.A.; YAMIN, A.; AUGUSTIN, I.; NUNES, D.J.; GEYER, C.
Towards a Software Process Model to Support the Design of Mobile Computing
Applications. In: World Conference on Integrated Design & Process Technology, 6.
(IDPT2002) Proceedings... Society for Design and Process Science. Pasadena,
EUA. Jun. 2002.
[REI02b]
REIS, R.Q.; LIMA REIS, C.A.; SCHLEBBE, H.; NUNES, D.J. Automatic Verification
of Static Policies on Software Process Models. In: WANG, Y.; BRYANT, A. (Eds.)
Annals of Software Engineering. Vol. 14, Special volume on Process-based
Software Engineering. Oct. 2002. Boston, MA, USA: Kluwer Academic Publishers
(aceito para publicao).
[REI02c]
REIS, R.Q.; LIMA REIS, C.A.; SCHLEBBE, H.; NUNES, D.J. APSEE-Reuse:
Automated Support for Software Process Reuse. In: Workshop Iberoamericano de
Ingeniera de Requisitos y Ambientes Software, 5. (IDEAS2002) Memrias...
CYTED. Havana, Cuba. Abr. de 2002.
[REI02d]
REIS, R.Q.; LIMA REIS, C.A.; SCHLEBBE, H.; NUNES, D.J. Towards an AspectOriented Approach to Improve the Reusability of Software Process Models. In:
International Workshop on Early Aspects: Aspect-Oriented Requirements
Engineering and Architecture Design; International Conference on Aspect-Oriented
Software Development, 1. Proceedings Enschede, The Netherlands. New York:
ACM Press. Apr. 2002.
[REI02e]
REIS, R.Q.; LIMA REIS, C.A.; SCHLEBBE, H.; NUNES, D.J. Early Experiences on
Promoting Explicit Separation of Details to Improve Software Processes Reusability.
In: IEEE Annual International Computer Software and Applications Conference, 26.
(COMPSAC2002). Proceedings Oxford, Inglaterra. Ago. 26-29, 2000. Los
Alamitos: IEEE Computer Society Press.
[REI02f]
REIS, R.Q. APSEE: Um Meta-Modelo para Apoiar a Reutilizao de Processos

de Software. Tese de Doutorado. Porto Alegre: PPGC-UFRGS. Jul. 2002.
[REI99]
REIS, R.Q.; NUNES, Daltro Jos. Uma Avaliao dos Paradigmas de

Linguagens de Processo de Software. Trabalho Individual II, Porto Alegre: PPGCUFRGS, 49 p., Maro 1999.
[RID 98]
RIDDLE, W.E. Fundamental Process Modeling Concepts. Software Engineering

Institute,
Pennsylvania,
http://Isdis.cs.uga.edu/activities/NSFworkflow/FundConc.html
[RIL 94]
RILEY, J.D. An Object-Oriented Approach to Software Process Modeling and

Definition. Conference on TRI-ADA'94, Proceedings... p. 16-22, 1994.
[ROM 93]
ROMBACH, H. D.; VERLAGE, M. How to assess a software process formalism from

a project member's point of view. International Conference on Software Process, 2.,
Proceedings... p. 90-104. IEEE Computer Society Press, 1993.
[ROS 77]
ROSS, D.; SCHOMAN, K. Structured Analysis for Requirements Definition. IEEE

Transactions on Software Engineering, New York, v. 3, n.1, Jan. 1977. p. 6-15
[ROS 85]
ROSS, D. Applications and Extensions of SADT. IEEE Computer, New York, v. 18,
n. 4, Apr. 1985. p. 25-35.
[ROS 94]
ROSA, A.C.A. Et al. Requisitos para uma Linguagem de Programao de Processo

de Software. In: ENCONTRO INTERUNIVERSITRIO DE INFORMTICA DO
PARAN, 2., 1994, Maring, Paran. Anais... Maring: [S.n.], 1994.
[SAE 91]
SAEKI, M.; KANEKO, T.; SAKAMOTO. A method for software process modeling and
description using LOTOS. In: International Conference on the Software Process, 1.
Proceedings... p. 90-104. IEEE Computer Society Press, 1991. Redondo Beach,
California, October, 1991.

[SCH02]
SCHLEBBE, H. Java-PROSOFT Manual. Fakultt Informatik, Universitt Stuttgart.

2002.
Disponvel
por
www
em
http://www.informatik.unistuttgart.de/ifi/bs/schlebbe/prosoft_doc/guide.
[SIL99]
SILVA, F. Um modelo de simulacao de processos de software baseado em

agentes cooperativos. In: Simposio Brasileiro de Engenharia de Software, 13.
Anais... Florianopolis : UFSC, 1999. p. 163-178.
[SOU01]
SOUSA, A.L.R.; LIMA REIS, C.A.; REIS, R.Q.; NUNES, D.J. Interao Humana
Durante Execuo de Processos de Software: Classificao e Exemplos.
Relatrio de Pesquisa RP 310. Porto Alegre: PPGC-UFRGS, Jun. 2001.
[SUT 90]
SUTTON, S.; HEIMBIGNER, D.; OSTERWEIL, L.J. Language Constructs for

Managing Changes in Process Centered Environments. ACM SIGSOFT Symposium
on Software Development Environments, 4., Proceedings..., Software Engineering
Notes 15, 6, p. 206-217, 1990.
[SUT 95]
SUTTON, S.; OSTERWEIL, L. An Analysis of Process Languages. Disponvel na

Internet por www em http://laser.cs.mass.edu/abstracts/process.html
[SUT 97a]
SUTTON, S.; OSTERWEIL, L. The Design of a Next-Generation Process Language.

In: ACM SIGSOFT Symposium on the Foundations of Software Engineering, 5.
Zurich. Proceedings... Sept, 1997. Lecture Notes in Computer Science #1301, p.
142-158.
[SUT 97b]
SUTTON, S.; LERNER, B.; OSTERWEIL, L. Experience Using the JIL Process
Programming Language to Specify Design Process. Computer Science Dept.,
University of Massachusetts, Technical Report 97-68. Sept, 1997. Disponvel na
Internet por www em http://laser.cs.umass.edu/~blemer/icse98-stan.ps
[SUT95]
SUTTON, S.; OSTERWEIL, L. An Analysis of Process Languages. Disponvel na

Internet por www em http://laser.cs.umass.edu/abstracts/95-078.html
[TOY95]
TOYOTA, C. M., ROSA, A. C. A. Projeto de uma Linguagem Multiparadigma

para Programao do Processo de Software. Encontro Interuniversitrio de
Informtica do Paran, 3. Curitiba, Paran. 1995.
[TUL89]
TULLY, C. Representing and Enacting the Software Process. ACM SigSoft

Software Engineering Notes, New York, v. 14, n. 4, June 1989. Trabalho
apresentado em: International Software Process Workshop, 4., 1988, Devon, UK.
[WAN00]
WANG, Y.; KING, G. Software Engineering Processes: Principles and

Applications. Boca Raton: CRC Press, 2000.
[WOR99]
Workflow Management Coalition. http://www.aiim.org/wfmc
[YAS 94]
YASUMOTO, K.; HIGASHINO, T.; TANIGUCHI, K. Software Process Description

using LOTOS and Its Enaction. In: International Conference on Software
Engineering, 16., (ICSE'94), Proceedings... ACM. Disponvel na Internet por www
em http://www.acm.org/pubs/citations/proceedings/soft/257734/p169-yasumoto
[YOU 95]
YOURDON, E. Declnio e Queda dos Analistas e Programadores. So Paulo,

Makron Books, 1995.
Anexo 1 Resumo comparativo entre as tecnologias de Workflow e Processo de Software

Tabela 1 Caractersticas de Ambientes para Workflow e Processo de Software (adaptado de
[REI99])
Workflow
Processo de Software
Modelagem, reengenharia e
automao de processos de
negcio
Modelagem, execuo,
simulao, verificao,
reutilizao e aperfeioamento
do processo produo de
software
Grossa, com atividades

definidas em alto nvel
Fina, com atividades descritas

e decompostas objetivando o
mximo detalhamento
Fundamentos tericos
Tecnologia baseada
principalmente em produtos
comerciais
Diversas teorias e modelos

formais
Disponibilidade das
implementaes
Vrias implementaes
comerciais
Vrios prottipos acadmicos

e poucos produtos comerciais
Agentes
Pessoas em geral
Gerentes e Desenvolvedores
de Software
Integrao de Ferramentas
Externas
Software de automao de
escritrio e SBBDs
Ferramentas CASE
Modelagem da Estrutura
Organizacional
Detalhada, permitindo a
definio de estruturas
prprias da organizao
usuria
Limitada, restrita definio

de cargos envolvidos com o
desenvolvimento de software
Aplicabilidade em domnios
diferentes da produo de
software
Extensiva
Limitada
Paradigmas para
Modelagem de Processos
Mono-paradigma
Multi-paradigma
Evoluo do Processo
Limitado
Evoluo dinmica e
reutilizao de modelos
Modelo de referncia para

padronizao
Workflow Management
Coalition
No existe
Objetivos
Granulosidade da definio
do processo

MOdPROCSoft PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MOdPROCSoft PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO PAR

CENTRO DE CINCIAS EXATAS E NATURAIS

XI SEMANA DE INFORMTICA DA UFPA

Introduo Modelagem de Processos de Software

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Fundamentos da Tecnologia de Processo de Software ....................................... 6

Modelagem e Execuo do Processo de Software............................................. 9

A Arquitetura de um PSEE ............................................................................... 11

Gerncia de Workflow e Automao do Processo de Software ....................... 12

3 LINGUAGENS DE MODELAGEM DE PROCESSOS .........................................16

Paradigmas de Modelagem do Processo de Software....................................... 19

Classificao das Linguagens de Processo de Software ................................... 21

Uma Avaliao de Linguagens de Processo ..................................................... 22

Consideraes finais sobre linguagens de modelagem..................................... 39

4 FERRAMENTAS PARA MODELAGEM DE PROCESSOS: EXEMPLO DE

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

2 Tecnologia de Processo de Software

Figura 2.1 O Processo de Engenharia de Software

Definir ferramentas para descrever os processos e acompanhar a sua execuo1,

Os termos interpretao e execuo de processos so utilizados indistintamente nesse

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Facilitar a adoo de uma estratgia de melhoria da maturidade dos processos de uma

Permitir o registro do conhecimento produzido acerca processos bem sucedidos na

Proporcionar um controle preciso na alocao e consumo de recursos durante o

Coletar mtricas dos projetos da organizao e torn-las disponveis para consultas

Desse modo, inmeros ambientes e ferramentas foram propostos nos ltimos

2.1 Fundamentos da Tecnologia de Processo de Software

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Figura 2.2 Rede de Atividades

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Figura 2.3 Elementos envolvidos em atividades do processo de software

Agenda do agente Jos

Figura 2.4 Exemplos de diferentes vises para um mesmo processo em

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

2.2 Modelagem e Execuo do Processo de Software

Segundo Heimbigner (em [HEI91]), linguagens de programao de processos (process

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

2.3 A Arquitetura de um PSEE

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Figura 2.5 O mecanismo de execuo em um PSEE

2.4 Gerncia de Workflow e Automao do Processo de

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Representao de atividades atravs de uma grafo parcialmente ordenado de tarefas, a

Auxiliam no gerenciamento do trabalho distribudo, ou seja, a cooperao de agentes

Workflow uma tecnologia que evoluiu a partir de produtos comerciais, ao contrrio

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

As atividades gerenciadas pelo WMSs, so "caixas-pretas", ou seja, no so definidas

WMSs atuam como mecanismo de coordenao de atividades, cujos agentes podem

Na maioria dos WMSs disponveis comercialmente, especial ateno dada

Os sistemas de workflow so capazes de atuar nos mais diversos ramos de atuao

Os principais WMSs disponveis, pouco detalhe foi reservado para modelagem de

A tecnologia de Processo de Software destaca-se pelos esforos da comunidade em

A WfMC tem definido um modelo de referncia de workflow que serve de ponto de

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

Introduo a Modelagem de Processos de Software - Profa. Carla A. Lima Reis

3 Linguagens de Modelagem de Processos

Descrio de atividades: para definir as etapas componentes de um processo;

Descrio dos recursos: para especificar os recursos humanos e computacionais

Relacionamentos entre entidades: para indicar os vrios tipos de interconexes

A definio de processos prope que possvel e vivel representar processos de