Escolar Documentos
Profissional Documentos
Cultura Documentos
Belm
2011
Belm
2011
Banca Examinadora
minha famlia.
AGRADECIMENTOS
Agradeo a Deus, por ter me permitido concluir mais uma etapa importante da minha
vida, ter me dado fora para vencer desafios e superar obstculos, me permitido chegar at
aqui e aberto caminhos para que eu possa ir mais longe. E o mais importante, ter me permitido
fazer amigos, me divertir e aprender muitas coisas para a vida.
Obrigado, Tia, Jorge, Salim e Nathlia, por terem me suportado e acompanhado de
perto as partes complicadas do caminho, e por todos os gestos de amor, compreenso e ajuda
recebidos. Agradeo a todos os meus familiares e amigos e todos aqueles que um dia
dividiram comigo um sorriso.
todos aqueles que escutaram meus desabafos e me incentivaram de alguma forma
todas as vezes quando o trabalho tornou-se pesado e at mesmo insuportveis para que um s
corao suportasse, saibam que sempre me senti mais feliz e motivado quando escutei um v
em frente e nunca desista. Todas as oraes, palavras de apoio e incentivo recebidas,
agradeo-as todas e desejo que bnos e felicidades sejam lanadas a quem torceu por mim e
me desejou a graa de poder completar essa parte do caminho.
Agradeo a meu orientador, prof. Dr. Rodrigo Quites Reis, pelos incentivos, puxes de
orelha e todo o tempo, esforo, apoio e ateno dispensados para a concluso desse trabalho.
E a todos os membros do LABES-UFPA e pela sorte que tive de participar desse grupo de
pesquisa, muito bom estar com vocs, eu no imaginava que sera to legal fazer parte.
Agradeo a cada professor que durante o curso de graduao contribuiu para o nosso
aprendizado e formao, saibam que vocs so muito importantes e sempre sero lembrados
pelos seus alunos. Tratem os alunos sempre com pacincia, lembrem-se que eles esto
aprendendo e todos sempre estamos e que ficamos velhos e o novo sempre vem.
Enfim, agradeo a todos aqueles que, eu tendo entrado em contato ou no, tenhamos
vivido uma mesma poca ou no, tenhamos concordado ou no, conectamos idias,
sentimentos, e que contriburam para minha formao. Todos vocs so importantes pra mim
e sempre considerados em grande medida. Desejo a todos amor, sade e felicidades.
Obrigado.
SUMRIO
2.
INTRODUO .........................................................................................................................................16
1.1.
Contexto do Trabalho........................................................................................................................... 17
1.2.
Motivao ............................................................................................................................................ 19
1.3.
Justificativa .......................................................................................................................................... 19
1.4.
1.5.
3.
2.2.
2.3.
3.3.
Mquina de Execuo .......................................................................................................................... 41
3.3.1.
Gramticas de Grafos .................................................................................................................. 42
3.3.2.
Regras da Mquina de Execuo ................................................................................................. 42
3.4.
4.1.
4.2.
Consideraes Iniciais .......................................................................................................................... 48
4.2.1.
Decises de Projeto ..................................................................................................................... 50
4.2.2.
Formalismos Utilizados ............................................................................................................... 52
4.3.
4.4.
Caracterizao das Atividades Peridicas ............................................................................................ 59
4.4.1.
Definies .................................................................................................................................... 61
4.4.2.
Tipos de Atividades Peridicas .................................................................................................... 64
4.4.3.
Requisitos .................................................................................................................................... 65
4.4.4.
Casos de Uso ............................................................................................................................... 67
4.5.
4.6.
4.7.
4.8.
4.9.
Interao Com o Usurio ..................................................................................................................... 88
4.9.1.
Manager Console ........................................................................................................................ 89
4.10. Trabalhos Correlatos ............................................................................................................................ 93
4.10.1.
Microsoft Project Professional 2010 ........................................................................................... 95
4.10.2.
Oracle BPEL Process Manager ..................................................................................................... 99
4.11.
5.
CONCLUSES ........................................................................................................................................103
5.1.
5.2.
5.3.
5.4.
LISTA DE FIGURAS
10
11
LISTA DE TABELAS
12
13
LISTA DE SIGLAS
ADS
CMMI
MPS-BR
OMG
PML
PSEE
SEI
SOFTEX
SPEM
14
RESUMO
15
ABSTRACT
Software systems are present in all places and activities performed with or without human
intervention, assuming key roles for the achievement of business objectives and adding value
to products and services. Because of the close relationship between software quality and the
process used in its development, efforts have been done for the improvement of software
processes and the development of computational tools and environments that can give support
in the process. In this sense, within the research area called Software Process Technology,
were created the Process-centered Software Engineering Environments or PSEEs, allowing
aid to the modeling and execution of software processes.
During the software development process some activities must be performed several times
in pre-determined periods of time. Among them, the activities known as umbrella activity
transversely occur during the process, are recurring and applicable throughout the process and
focus mainly on the management, monitoring and control of the project; these activities are
periodic activities because they occur in predetermined time periods ordering a well-defined
objective.
This paper proposes a mechanism for modeling and execution of periodic activities in the
WebAPSEE environment, a PSEE developed by the Software Engineering Laboratory of
UFPA. Focusing on providing the automated control for periods enactment, aiming to
contribute to reduce the effort by process/project managers in the performance of part of its
activities and ensure compliance with process models. This work intends to implement into
the WebAPSEE a literature approach as characteristic of some activities that occur during the
software process, however, not implemented satisfactorily by other environments, invariably
dealing the problem with simple repetitions or require a great effort by the project/process
manager to achieve the same result.
KEYWORDS: Software Process Technology, Process-centered Software Engineering
Environment, WebAPSEE, Periodic Activities.
16
1. INTRODUO
17
1.1.
Contexto do Trabalho
Segundo (LIMA REIS, 2003) e (SOUSA et al., 2001), o termo utilizado mais frequentemente na literatura
process enactment, que significa que o processo no ser totalmente automatizado como sugere o termo
execuo, mas executado por pessoas e mquinas, porm, o termo execuo mais utilizado na literatura
nacional. Neste trabalho ser utilizado o termo execuo com o sentido de enaction.
18
19
1.2.
Motivao
1.3.
Justificativa
20
(SANTOS et al., 2010; 2011) foram feitos estudos com usurios e desenvolvedores do
componente Manager Console do WebAPSEE em busca de sugestes de melhoria para o
sistema na viso dos prprios usurios e desenvolvedores. Uma das sugestes indicadas como
possibilidade de melhoria do sistema foi a implementao de atividades peridicas no mesmo
devido o grande esforo necessrio atualmente para se modelar e monitorar essas atividades
no ambiente.
1.4.
Objetivos do Trabalho
Dentro desse contexto apresentado como introduo, este trabalho pretende contribuir
para o desenvolvimento do WebAPSEE integrando ao ambiente um mecanismo para a
modelagem e execuo de atividades peridicas. As atividades peridicas so previstas na
literatura como caracterstica de algumas atividades que ocorrem durante processos de
software. Porm, elas no so implementadas de forma satisfatria por outros ambientes, que
tratam apenas simples repeties ou que necessitam de um esforo muito grande por parte do
gerente de projetos/processos para alcanar o mesmo resultado.
1.5.
Organizao do Texto
21
22
De modo geral, os usurios dos PSEEs podem estar atuando em dois papis principais:
gerente e desenvolvedor. Gerente a denominao geral usada para designar aqueles que tm
como responsabilidade a monitorao, gerncia e manuteno do modelo de processo sendo
executado, enquanto o Desenvolvedor atua no desenvolvimento de software realizando
atividades que contribuem diretamente com a produo do mesmo. Ambos interagem com o
PSEE durante a execuo de um processo, porm possuem objetivos diferentes (LIMA REIS,
2003).
Apesar de todo o avano obtido, as ferramentas que apoiam o desenvolvimento de
software, de forma geral, ainda so incompletas e possuem limitaes. A definio e execuo
de atividades peridicas, por exemplo, no tratada de forma satisfatria pelas ferramentas
existentes, ocasionando um grande esforo por parte do gerente de processos/projeto para a
definio e controle dessas atividades durante o processo de desenvolvimento de software
sem o apoio adequado. Para tanto, o gerente necessita realizar tarefas repetitivas e gerenciar
essas atividades dispersas pelo processo.
Muitos modelos que estabelecem diretrizes para a modelagem e execuo de processos
surgiram procurando orientar gerentes de processo a como definir processos. O SPEM
(Software & Systems Process Engineering Meta-Model Specification) (OMG, 2008),
atualmente na verso 2.0, um modelo criado para definir software e processos de
desenvolvimento de sistemas e seus componentes. Seu objetivo acomodar um grande
nmero de mtodos de processos de desenvolvimento focando em prover informaes e
estruturas necessrias para se modelar processos aos engenheiros de processo. O SPEM,
entretanto, no fornece um apoio especfico definio de atividades peridicas, logo,
ferramentas que se baseiam exclusivamente nele tambm no oferecem apoio esse grupo de
atividades.
Cada processo pode ser descrito de vrias maneiras, utilizando texto, figuras ou uma
combinao desses recursos (PFLEEGER, 2004). O processo pode ser orientado a tarefas,
metas, documentos, tarefas e documentos, de acordo com a forma como o processo
visualizado (SOUSA et al., 2001). Processos orientados a documentos, por exemplo, tm
como elemento central os documentos consumidos e produzidos durante o processo, sendo
que o processo todo se desenvolve centrado no consumo e produo de documentao. Nos
processos de software orientados a metas, a visualizao do processo baseia-se em metas a
serem atingidas, sem distinguir as tarefas ou documentos. Processos de software orientados a
tarefas ou atividades consistem em processos de software onde as atividades so o principal
23
2.1.
24
Interessado qualquer um que tenha interesse no sucesso de um projeto executivos, usurios finais,
engenheiros de software, desenvolvedores e etc. (PRESSMAN, 2011) seja um indivduo ou grupo, responsvel
ou afetado pelo produto de uma tarefa, atividade ou processo (SOFTEX, 2011). O termo utilizado no ingls
stakeholder, o qual pode ser eventualmente utilizado neste texto.
25
formal
de
sistemas
desenvolvimento
orientado
reuso
26
27
28
29
Requisitos de Prescrio
ID
Requisito
Descrio
R1
Fluxo de controle
R2
Automao de
processo
R3
Gerncia de
objetos
R4
Registro da
histria do
processo
R5
Coleta de mtricas
R6
Iterao
R7
Restries e
alocao de
recursos
Requisitos de Interao
Descrio
R8.1
Permitir diferentes
vises de processo
R8.2
Mostrar estado
atual e histrico do
processo
R8.3
Modificao
dinmica do
processo durante a
execuo
R8.4
Independncia do
formalismo de
modelagem de
processos
R8.5
Monitorao de
eventos e
tratamento de
excees
Orientar
desenvolvedores
nas suas tarefas
Requisito
R9
Inter
ao
com
dese
nvol
vedo
res
ID
R9.1
30
R9.2
Fornecer
visualizao
adequada das
tarefas do processo
R9.3
Obter feedback do
andamento do
processo
R9.4
Fornecer
visualizao dos
estados do processo
(atual e anterior) e
mecanismo de
undo
R9.5
Flexibilizar a
interao
R10.1
Permitir
comunicao
informal
R10.2
Permitir gerncia
de reunies e
horrios
R10.3
Permitir
monitorao de
produtos e
processos
R10.4
Controlar o acesso
aos objetos
R10.5
Mltiplos nveis de
compartilhamento
de objetos
R10.6
Registro do
histrico dos
objetos e
mecanismos de
undo e redo
Requisitos de Flexibilidade
ID
Requisito
Descrio
R11
Modificao
dinmica durante a
execuo
R12
Execuo de
processos
incompletos
31
Instanciao do
processo durante
execuo
R14
Escolhas entre
caminhos
alternativos
R15
Adaptao ao
usurio
Gerncia e
tratamento de
eventos
R13
R16
2.2.
Atividades Peridicas
Alm das atividades estruturais de arcabouo que funcionam como alicerce para um
processo de software (seo 2.1), existem atividades de apoio ao processo de
desenvolvimento de software que acontecem vrias vezes durante o processo em intervalos de
tempo pr-determinados, as quais podemos denominar atividades peridicas. Como exemplo,
podemos considerar algumas atividades inerentes dos processos de apoio ao processo de
construo do software, tais como: gerao de releases do processo de Gerncia de
Configurao, coleta de mtricas referente ao processo de Medio, inspees/revises de
documentos do processo de Garantia da Qualidade, entre outros.
Ambientes que auxiliam o processo de software so de grande ajuda no acompanhamento
do projeto e apoio gerncia, trazendo benefcios tais quais os expostos no incio deste
captulo. Um mecanismo que apoie a utilizao de atividades peridicas em um ambiente de
desenvolvimento de software poder diminuir o esforo do gerente para definir e monitorar
essas atividades e atividades guarda-chuva no processo.
Muitos ambientes apoiam a utilizao de atividades repetidas e com execuo paralela,
mas no apoiam a utilizao de atividades peridicas (ver seo 4.10. Trabalhos Correlatos).
32
Para se gerenciar atividades peridicas atualmente, mesmo com o apoio das ferramentas
existentes, necessrio um grande esforo por parte do gerente de processos. necessrio
que este inicialmente identifique os pontos onde devem ser inseridas as atividades peridicas
e, de forma repetitiva, insira as atividades em cada ponto onde elas devem ocorrer. Onde
houver uma atividade peridica necessrio que o gerente tambm defina pessoas para
realizarem as tarefas, recursos a serem utilizados, artefatos a serem produzidos e consumidos,
dentre outros elementos relacionados ao processo que possam vir a interferir na execuo
desta atividade. Para cada ponto do processo onde a atividade peridica ocorra necessrio
que se defina novamente todos esses elementos.
Qualquer alterao que deva ser efetuada em todos os perodos de uma atividade peridica
necessita que o gerente percorra novamente o processo em busca dos pontos onde as
alteraes devem ser feitas, pois, da forma como so definidas, as ocorrncias da atividade
peridica ficam dispersas pelo processo. Afora o grande esforo para a definio dessas
atividades, monitor-las tambm no nada fcil, visto que deve-se procurar cada instncia da
atividade e ter uma idia geral delas, mesmo que elas estejam dispersas pelo processo.
Nas sees do captulo 4 as atividades peridicas sero apresentadas com mais detalhes,
inclusive com definies de termos utilizados no contexto de atividades peridicas neste
trabalho (seo 4.4).
33
2.3.
34
3. O AMBIENTE WEBAPSEE
35
3.1.
Arquitetura Geral
36
Dois dos principais componentes por meio dos quais os usurios interagem diretamente
com o ambiente so apresentados a seguir.
3.1.1. ManagerConsole
No WebAPSEE o gerente e os engenheiros de processo so responsveis pela modelagem
e instanciao do processo, ou seja, pela definio do fluxo das tarefas a serem realizadas,
assim de prazos, custos, estimativas e mtricas utilizadas, artefatos produzidos e consumidos e
pessoas e grupos envolvidos (FRANA, 2009).
O componente Manager Console do WebAPSEE, que pode ser visualizado na Figura 3.2,
o ponto de interao entre gerentes e o ambiente. Ele apresenta um editor de processos que
utiliza formulrios e uma PML grfica, a WebAPSEE-PML (Figura 3.4), baseada em redes de
atividades, utilizado pelo gerente de processos/projetos de software para modelagem,
execuo e acompanhamento dos processos de desenvolvimento da organizao, assim como
a representao de dados da organizao, tudo de forma visual.
O Manager Console permite aos engenheiros de processos modelar processos, gerenciar
execues de processos, visualizarem relatrios, cadastrar e gerenciar informaes
organizacionais, entre outros recursos fornecidos (COSTA, 2010).
37
Figura 3.2 Viso do gerente no WebAPSEE: componente Manager Console e sua PML
grfica.
3.1.2. TaskAgenda
A TaskAgenda (Figura 3.3) o ponto de interao entre os desenvolvedores e o ambiente
WebAPSEE. Atravs dela o desenvolvedor visualiza uma lista que relaciona tarefas a serem
realizadas, sendo permitido que cada desenvolvedor visualize apenas as tarefas pelas quais
responsvel. Alm da relao de tarefas a serem realizadas, a TaskAgenda permite que o
desenvolvedor visualize os artefatos a serem produzidos e os recursos a serem utilizados no
desempenho de cada tarefa. As atividades exibidas na TaskAgenda podem assumir os estados:
espera, pronta, ativa, pausada, e finalizada.
O desenvolvedor, por meio da TaskAgenda, fornece feedback sobre o andamento das suas
atividades e ainda permitido que ele faa upload de artefatos produzidos, requisitados em
algumas tarefas, e download de recursos disponveis que auxiliem a execuo das tarefas. O
feedback fornecido pelo desenvolvedor pela TaskAgenda imediatamente visualizado pelo
gerente no editor de processos do ManagerConsole (SALES, E., 2009).
38
3.2.
39
40
41
3.3.
Mquina de Execuo
42
43
44
45
O lado direito (R) da regra mostra que o processo e o modelo de processo foram mantidos
e a atividade foi criada com o tipo Activity_Normal, como solicitado, com o identificador
new_id; sendo tambm criadas ligaes com uma Agenda de agentes envolvidos e recursos
requeridos. Essa regra, portanto, define a semntica para insero de uma atividade Normal
em um dado Modelo de Processo de um Processo especfico e os estados do modelo
necessrios (antes) e resultantes (aps) para que a regra seja aplicada. As regras da proposta
inicial para o ambiente APSEE podem ser consultadas no trabalho de (LIMA REIS, 2003).
3.4.
46
47
4.1.
Viso Geral
48
4.2.
Consideraes Iniciais
49
Um diferencial deste trabalho, apoiado por todo esse aporte oferecido pela mquina de
execuo do WebAPSEE, ser permitir no s a modelagem, mas a execuo e o
acompanhamento das atividade peridicas. Como o ambiente WebAPSEE possui uma PML
grfica que facilita a modelagem, o acompanhamento e a comunicao do processo, inserir
uma representao grfica para a atividade peridica no processo igualmente facilitar a
modelagem, o acompanhamento e a comunicao das mesmas.
Quanto execuo destas atividades, o ambiente de execuo deve garantir, basicamente:
50
51
Grupos
de
Regras
Regras
para
Execuo
do
Processo
Regras
para
Definio
do
Processo
Regras
para
Excluses
Tipos de Regras
Grupos
dentro do
escopo
10
11
12
Definio de Atividades
Consistncias
52
Grupos
de
Regras
Regras
para
Cpias
Tipos de Regras
Excluir conexes
Cpia de atividades
Cpia de Artefatos
Grupos
dentro do
escopo
Dentre os grupos que esto no escopo, existem regras referentes a: insero de atividades
peridicas e perodos no processo; vinculao de perodos a prazos temporais; conexo de
artefatos a atividades peridicas; excluso de atividades peridicas e de perodos; regras para
manter a consistncia entre os estados de perodos e das atividades peridicas; e regras para
manter a consistncia entre as regras para atividades peridicas criadas e as regras j
existentes no sistema;
Esto fora do escopo, por exemplo, as regras referentes a: insero de marcos e vinculao
de prazos a marcos; definio de conexes entre as atividades peridicas e outras atividades;
conexo de Agentes ou Grupos diretamente a atividades peridicas; conexo de recursos
diretamente a atividades peridicas; reutilizao de processos por perodos; e a cpia de
atividades peridicas.
53
4.3.
54
Figura 4.1 (1) Projeto que utiliza o processo de medio; (A), (B) e (C) Atividades
decompostas nas quais foi aplicado o processo de medio (contido em I, II e III).
Na Figura 4.1 o processo indicado por (1) o processo raiz do projeto onde vrias
atividades decompostas, que encapsulam sub-processos e demais elementos do processo, so
definidas. Neste cenrio, apesar da medio ter sido aplicada em vrios pontos, tomaremos
como exemplo apenas trs desses pontos do projeto onde medio foi aplicada: as atividades
decompostas (A), (B) e (C), tendo seus processos internos mostrados em (1.1), (1.2) e (1.3),
respectivamente.
55
Em cada uma dessas atividades o processo de medio foi aplicado em (I.), (II.) e (III). O
processo de medio padro aplicado formado pelas atividades: Coleta de Mtricas,
Elaborao de Indicadores, Reviso de Indicadores, Revisar Plano de Medio e Anlise,
Anlise Preliminar dos Indicadores e Apresentao e Anlise dos Indicadores.
Na Figura 4.2, observa-se o resultado final da execuo dos processos em cada ponto
analisado. Nos trs pontos, o processo padro foi utilizado, entretanto, devido situaes
ocorridas durante o processo que necessitaram mudanas, pode-se perceber que h pequenas
diferenas na modelagem do processo, especialmente em (II.), quando uma das atividades
passou a executar paralelamente ao fluxo principal.
56
Figura 4.2 Cada execuo do processo de medio nas atividades da Figura 4.1.
Embora algumas adaptaes locais tenham sido feitas, certamente o processo de medio
continuou buscando alcanar os mesmos objetivos, portanto, essas modificaes no
descaracterizaram o processo de medio, apenas foram adaptaes feitas ao longo do
processo quando foi preciso.
Na Figura 4.3 apresentado o mesmo cenrio, porm com a utilizao de uma atividade
peridica (D) para abstrair o processo de Medio a partir de um nico ponto. A atividade
peridica executa cada perodo do processo de medio (I.), (II.) e (III.) nos mesmos prazos
57
58
59
Observa-se ainda que os perodos executados podem ser executados paralelamente (como em
II. e III.), dependendo de como forem configurados. Desta forma, as atividades peridicas
podem ser inseridas em vrios outros cenrios, como na gerncia de releases e baselines, na
manuteno do planejamento de gerncia do conhecimento, entre outros, apoiando de forma
flexvel a execuo de processos.
4.4.
60
No senso comum tm-se a ideia de que perodo algo que acontece de forma regular e
bem definida, sendo essa regularidade representada por meio de uma quantificao de tempo,
utilizada para caracterizar um conjunto de acontecimentos ou eventos. Utilizando-se desse
conceito, algumas ferramentas permitem a modelagem de processos com a criao de tarefas
peridicas, entretanto, essas atividades se aproximam mais de atividades repetidas com
durao e intervalos de tempo entre repeties regulares (ver seo 4.10. Trabalhos
Correlatos).
Uma forma mais didtica de se passar uma noo mais geral de perodos, e mostrar que o
termo pode ser utilizado de forma mais abrangente e flexvel, como est sendo apresentado no
contexto deste trabalho, fazendo-se uma analogia a outros campos de estudo que utilizam o
termo perodo de forma no regular. Em (FERREIRA, 2009), temos como exemplo de
perodos os perodos geolgicos, tidos como a diviso de cada uma das eras e que se
subdivide em pocas: cronologicamente, na era Mesozoica temos o perodo Trissico
(durao: aproximadamente 51,4 milhes de anos), o perodo Jurssico (durao:
aproximadamente 54,1 milhes de anos) e o perodo Cretceo (durao: aproximadamente 80
milhes de anos); segundo a geologia, essa era especialmente conhecida, por exemplo, pelo
aparecimento, domnio e desaparecimento dos dinossauros e a separao da Pangia em
Laursia, para o norte, e Gondwana, para o sul. Nesse exemplo pode-se perceber como os
perodos so agrupados por caractersticas comuns entre eles (aparecimento, domnio e
desaparecimento dos dinossauros e separao da Pangia) e a durao de cada perodo no
necessariamente regular (51,4 milhes de anos, 54,1 milhes de anos e 80 milhes de anos).
Portanto, o termo perodo de fato aplicado em vrios contextos diferentes (assim como
outros termos/definies), mas sempre objetivando definir algum acontecimento ou evento
com caractersticas gerais bem definidas que pode ser referenciado pelo intervalo de tempo
em que ocorreu, tendo este sido previsto ou no. Sendo assim, os perodos podem ser
agrupados de acordo com alguma caracterstica geral que seja comum entre eles.
Dois perodos podem ocorrer entre intervalos de tempo de mesma durao em dois
momentos diferentes do processo, logo, a durao do perodo pode ser utilizada como
caracterstica comum para definir um conjunto de perodos, mesmo que o intervalo de tempo
entre perodos seja varivel. Perodos podem ocorrer com durao varivel, mas
implementando um mesmo conjunto de tarefas para produzir um documento, logo, este
conjunto de perodos tm em comum a realizao de certas tarefas a fim de produzir um
documento.
61
4.4.1. Definies
Seguem algumas definies de termos definidos para serem utilizados no contexto deste
trabalho:
Perodo tempo decorrido entre dois eventos marcantes de incio e fim. Eventos esses
temporais ou baseados na mudana de estado de outras atividades (atividades-marco).
Cada perodo representa uma fase de realizao do conjunto de tarefas de uma atividade
peridica especfica, portanto, pode-se tambm dizer que perodo a realizao de uma
atividade peridica, ocorrida de forma previsvel entre dois eventos marcantes de incio e fim.
Um perodo caracterizado por tudo o que acontece durante o desempenho de um
conjunto de tarefas entre dois eventos definidos de incio e fim com um objetivo definido.
Perodos de uma mesma atividade peridica possuem os mesmos objetivos gerais. Cada
perodo deve ter sua prpria periodicidade definida e ser executado como um modelo de
processo independente de outros perodos, sendo tratado como uma unidade executvel ou
62
Prazo de incio3: tempo limite previsto para que certa atividade ou perodo inicie
sua execuo. Na prtica, ser o tempo previsto em que um perodo ou atividade
estar autorizado a executar. Pode estar vinculado a evento temporal ou a marcos;
63
Prazo de durao4: tempo limite previsto para que certa atividade ou perodo
execute (o tempo transcorrido entre o prazo de incio e o prazo de fim);
Prazo de fim5: tempo limite previsto para que certa atividade ou perodo finalize
sua execuo. Na prtica, ser o tempo previsto em que um perodo ou atividade
dever ser encerrado. Pode estar vinculado a evento temporal ou a marcos.
4
5
64
65
4.4.3. Requisitos
De forma geral, inclusive para viabilizar a modelagem e execuo das atividades
peridicas, qualquer mecanismo de execuo deve procurar seguir os requisitos apresentados
em (LIMA REIS, 2003), oriundos de reviso da literatura sobre a execuo de processos (ver
seo 2.1.3). Estes requisitos visam garantir que o modelo de processo seja executvel com o
mnimo de alteraes na infraestrutura subjacente; ainda, estabelecem requisitos de interao
do mecanismo de execuo com seus usurios e de flexibilidade na execuo de processos.
Para definio do modelo proposto neste trabalho, considerando os requisitos para
execuo de processos presentes em (LIMA REIS, 2003) e algumas definies encontradas na
literatura, identificou-se como requisitos funcionais das atividades peridicas os itens
apresentados na Tabela 3. Esses requisitos foram gerados a partir de consultas a literatura,
reunies e entrevistas com especialistas, usurios e desenvolvedores do ambiente WebAPSEE
principalmente em decorrncia dos trabalhos de Iniciao Cientficas realizados pelo autor
desse trabalho, encontrados em (SANTOS et al., 2010; 2011), os quais foram comentados
anteriormente no captulo 1.
Tabela 3 Requisitos funcionais para atividades peridicas.
Requisitos Funcionais
ID
Descrio
RF-01
O sistema deve permitir que uma atividade seja criada como sendo peridica ou que uma
atividade ou conjunto de atividades seja configurado como tal aps sua criao.
RF-02
O sistema deve permitir a definio de perodos regulares para uma atividade, onde a
periodicidade igual para todos os perodos de uma mesma atividade.
RF-03
RF-04
O sistema deve permitir que o usurio configure a quantidade de perodos que uma
atividade peridica deve realizar e que esta possa ser consultada e alterada
posteriormente.
RF-05
O sistema deve permitir que a atividade peridica e seus perodos possam ser editados
durante sua execuo.
RF-06
O sistema deve permitir que as alteraes realizadas em perodos especficos possam ser
propagadas para os outros perodos ainda no iniciados.
RF-07
O sistema deve permitir que perodos incompletos sejam executados e partes abstratas
sejam instanciadas durante a execuo.
66
Requisitos Funcionais
ID
Descrio
RF-08
O sistema deve permitir que o histrico de execuo da atividade peridica e cada perodo
possa ser consultado.
RF-09
O sistema deve permitir que se possa optar por autorizar ou no que perodos da atividade
capazes de executar sejam adiantados caso um perodo em execuo seja finalizado antes
do prazo previsto.
RF-10
O sistema deve permitir que se possa optar por autorizar ou no que perodos, os quais
tenham o prazo de incio sido alcanado, e no houverem outras restries, executem
mesmo que o perodo que o anteceda cronologicamente no tenha sido concludo
(execuo concorrente).
RF-11
O sistema deve permitir que prazos de perodos possam ser definidos atravs de eventos
temporais ou atravs de marcos.
RF-12
O sistema deve permitir que possa existir mais de um marco associado a cada perodo.
RF-13
O sistema deve permitir que conexes sejam utilizadas entre atividades peridicas e outras
atividades.
RF-14
O sistema deve permitir que apenas um perodo de uma atividade peridica seja falhado
ou que uma atividade peridica seja falhada a partir do perodo em execuo.
RF-15
O sistema deve permitir que perodos no iniciados de uma atividade peridica sejam
cancelados ou que uma atividade peridica no iniciada seja cancelada.
RF-16
RF-17
O sistema deve permitir que o usurio responsvel por executar um perodo seja
notificado de sua tarefa assim que o prazo de incio do perodo for alcanado e demais
dependncias forem satisfeitas e deve receber o feedback da realizao das tarefas.
RF-18
O sistema deve garantir que o controle de perodos no seja perdido e seja persistente.
RF-19
O sistema deve garantir que um perodo no possa ter seu prazo de incio com valor
menor que o prazo de finalizao do perodo ou atividade que o antecede; nem prazo de
finalizao maior que o prazo de incio do perodo ou atividade que o sucede.
RF-20
O sistema deve garantir, para que um marco seja associado ao prazo inicial de um
perodo, que a atividade-marco exista.
RF-21
O sistema deve garantir, para que um marco seja associado ao prazo final de um perodo,
que a atividade-marco exista e ocorra paralelamente ou posteriormente ao perodo.
RF-22
O sistema deve garantir que, quando chegar o tempo previsto para incio de um perodo,
se o perodo anterior estiver finalizado e no houverem outras restries, que a atividade
fique pronta para que o perodo seja executado e as tarefas disponveis aos responsveis.
67
Requisitos Funcionais
ID
Descrio
RF-23
O sistema deve garantir que, quando chegar o tempo previsto para incio de um perodo,
se o perodo anterior no estiver finalizado e no houverem outras restries (como a
oriunda do RF-09), que assim que este seja finalizado, a atividade fique pronta para que o
perodo seja executado e as tarefas disponveis aos responsveis.
RF-24
O sistema deve garantir que, quando conexes forem adicionadas a uma atividade
peridica, respeite-se e mantenha-se a consistncia da atividade, seus perodos e prazos
iniciais e finais, com as conexes.
RF-25
O sistema deve garantir que atividades no-peridicas que j tenham iniciado sua
execuo no possam se transformar em atividades peridicas.
RF-26
Vale ressaltar que, como as atividades peridicas so apenas um dos grupos de atividades
pertencentes ao processo de software e este trabalho objetiva inserir seu uso em uma
ferramenta que fornece apoio ao processo de software, muitos dos requisitos para execuo de
processos apresentados em (LIMA REIS, 2003) dependem do Mecanismo de Execuo e
Linguagem de Modelagem de Processos adotados pelas ferramentas. Portanto, no
responsabilidade direta das atividades peridicas aqui propostas atenderem todos os requisitos
de execuo de processos; na verdade, as atividades peridicas vo, na maioria das vezes,
utilizar as capacidades fornecidas pelas prprias ferramentas.
68
69
Os casos de uso, apresentados nas Figuras 4.4 e 4.5, so descritos de forma textual nas
tabelas a seguir e posteriormente, ao final da seo, ser apresentada uma matriz de
relacionamento entre os casos de uso e os requisitos funcionais:
70
ID: UC 01
Caso de Uso Gerenciar Atividade Peridica
Geral:
Descrio: Caso de uso relativo s funcionalidades aplicveis atividade peridica como um
todo, modelagem e definio destas. Este caso de uso viabiliza que uma atividade
peridica possa ser criada, excluda, cancelada, falhada e alterada em tempo de
execuo.
Requisito(s): RF-01, RF-05, RF-08, RF-13, RF-14, RF-15, RF-18, RF-19, RF-24 e RF-25.
Relacionado(s)
Tabela 4.1 Caso de Uso 1.1. Criar Nova Atividade Peridica.
ID: UC 1.1.
Caso de Uso: Criar Nova Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite criar uma atividade peridica e
adicion-la no processo.
Requisito(s): RF-01 e RF-18.
Relacionado(s)
Tabela 4.2 Caso de Uso 1.2. Tornar Peridica uma Atividade No-Peridica.
ID: UC 1.2.
Caso de Uso: Tornar Peridica uma Atividade No-Peridica
Descrio: Caso de uso relativo funcionalidade que permite transformar uma atividade noperidica em atividade peridica.
Requisito(s): RF-01, RF-18, RF-19, RF-24 e RF-25.
Relacionado(s)
Tabela 4.3 Caso de Uso 1.3. Configurar Atividade Peridica.
ID: UC 1.3.
Caso de Uso: Configurar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite editar o nome de uma atividade
peridica, seu tipo, estimativas da atividade e o roteiro (objetivos) e conectar a
atividade peridica a outras atividades.
Requisito(s): RF-05, RF-13, RF-18, RF-19 e RF-24.
Relacionado(s)
71
ID: UC 1.4.
Caso de Uso: Excluir Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite excluir uma atividade peridica.
Requisito(s): RF-05, RF-18 e RF-24.
Relacionado(s)
Tabela 4.5 Caso de Uso 1.5. Cancelar Atividade Peridica.
ID: UC 1.5.
Caso de Uso: Cancelar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite Cancelar uma atividade
peridica que no tenha iniciado a execuo de nenhum de seus perodos.
Requisito(s): RF-05, RF-15, RF-18 e RF-24.
Relacionado(s)
Tabela 4.6 Caso de Uso 1.6. Falhar Atividade Peridica.
ID: UC 1.6.
Caso de Uso: Falhar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite Falhar uma atividade peridica
que tenha algum de seus perodo em execuo.
Requisito(s): RF-05, RF-14, RF-18 e RF-24.
Relacionado(s)
Tabela 4.7 Caso de Uso 1.7. Consultar Atividade Peridica.
ID: UC 1.7.
Caso de Uso: Consultar Atividade Peridica
Descrio: Caso de uso relativo funcionalidade que permite consultar Verses (execues
anteriores) de uma atividade peridica.
Requisito(s): RF-08.
Relacionado(s)
72
ID: UC 02
Caso de Uso Gerenciar Perodos
Geral:
Descrio: Caso de uso relativo a funcionalidades aplicadas aos perodos, individualmente ou
em grupo. Este caso de uso viabiliza a adio de perodos uma atividade
peridica, a remoo, falha ou cancelamento de perodos; a definio de perodos
regulares ou vaiveis; o reuso de modelos de processos previamente definidos e
armazenados; permisso para execuo concorrente de perodos, permisso para
que perodos sejam adiantados e outras configuraes de periodicidade e
dependncia entre perodos.
Requisito(s): RF-02, RF-03, RF-04, RF-05, RF-06, RF-08, RF-09, RF-10, RF-14, RF-15, RFRelacionado(s) 16, RF-18, RF-19, RF-22, RF-23, RF-24 e RF-26.
Tabela 5.1 Caso de Uso 2.1. Adicionar Perodo.
ID: UC 2.1.
Caso de Uso: Adicionar Perodo
Descrio: Caso de uso relativo funcionalidade que permite adicionar um perodo a uma
atividade peridica, caso esta no tenha sido finalizada.
Requisito(s): RF-04, RF-05, RF-18, RF-19 e RF-24.
Relacionado(s)
Tabela 5.2 Caso de Uso 2.2. Configurar Perodos.
ID: UC 2.2.
Caso de Uso: Configurar Perodos
Descrio: Caso de uso relativo funcionalidade que permite definir a periodicidade do
conjunto de perodos da atividade peridica, se regular ou varivel; a definio de
um roteiro especfico para cada perodo; a modelagem dos perodos inclusive
durante a execuo e que perodos incompletos sejam executados; permite que
alteraes realizadas em um perodo especfico possam ser propagadas para
perodos no iniciados e que outro perodo possa receber ou no essa propagao;
que perodos possam ser adiantados ou executados de forma concorrente e o reuso
de modelos de processo previamente definidos e armazenados.
Requisito(s): RF-02, RF-03, RF-05, RF-06, RF-07, RF-09, RF-10, RF-16, RF-18, RF-19, RFRelacionado(s) 22, RF-23, RF-24 e RF-26.
73
ID: UC 2.3.
Caso de Uso: Remover Perodo
Descrio: Caso de uso relativo funcionalidade que permite remover um perodo da
atividade peridica.
Requisito(s): RF-04, RF-05, RF-18 e RF-24.
Relacionado(s)
Tabela 5.4 Caso de Uso 2.4. Falhar Perodo.
ID: UC 2.4.
Caso de Uso: Falhar Perodo
Descrio: Caso de uso relativo funcionalidade que permite Falhar um perodo, caso este
tenha sido iniciado.
Requisito(s): RF-05, RF-14 e RF-18.
Relacionado(s)
Tabela 5.5 Caso de Uso 2.5. Cancelar Perodo.
ID: UC 2.5.
Caso de Uso: Cancelar Perodo
Descrio: Caso de uso relativo funcionalidade que permite Cancelar um perodo, caso este
no tenha sido iniciado.
Requisito(s): RF-05, RF-15 e RF-18.
Relacionado(s)
Tabela 5.6 Caso de Uso 2.6. Consultar Perodos.
ID: UC 2.6.
Caso de Uso: Consultar Perodos
Descrio: Caso de uso relativo funcionalidade que permite consultar os perodos de uma
atividade peridica em qualquer estado de execuo que eles estejam.
Requisito(s): RF-08.
Relacionado(s)
74
ID: UC 03
Caso de Uso Gerenciar Prazos
Geral:
Descrio: Caso de uso relativo funcionalidade de criao de prazos de incio e fim para
perodos, configurao dos prazos, alterao e remoo.
Requisito(s): RF-05, RF-08, RF-11, RF-12, RF-18, RF-19, RF-24 e RF-26.
Relacionado(s)
Tabela 6.1 Caso de Uso 3.1. Criar Prazo.
ID: UC 3.1.
Caso de Uso: Criar Prazo
Descrio: Caso de uso relativo funcionalidade que permite criar prazos de incio e fim para
um perodo e relacion-los a uma data.
Requisito(s): RF-05, RF-11, RF-12, RF-18, RF-19, RF-24 e RF-26.
Relacionado(s)
Tabela 6.2 Caso de Uso 3.2. Configurar Prazos.
ID: UC 3.2.
Caso de Uso: Configurar Prazos
Descrio: Caso de uso relativo funcionalidade que permite editar as datas de prazos
previamente definidos.
Requisito(s): RF-05, RF-11, RF-18, RF-19, RF-24 e RF-26.
Relacionado(s)
Tabela 6.3 Caso de Uso 3.3. Remover Prazo.
ID: UC 3.3.
Caso de Uso: Remover Prazo
Descrio: Caso de uso relativo funcionalidade que permite remover prazos previamente
definidos.
Requisito(s): RF-05, RF-12 e RF-18.
Relacionado(s)
75
ID: UC 3.4.
Caso de Uso: Consultar Prazos
Descrio: Caso de uso relativo funcionalidade que permite consultar todos os prazos de
incio e fim relacionados a um perodo.
Requisito(s): RF-08.
Relacionado(s)
ID: UC 04
Caso de Uso Gerenciar Marcos
Geral:
Descrio: Caso de uso relativo funcionalidade que permite a vinculao de prazos a
marcos, a criao desses marcos, a alterao e remoo.
Requisito(s): RF-11, RF-12, RF-18, RF-19, RF-20, RF-21, RF-24 e RF-26.
Relacionado(s)
Tabela 7.1 Caso de Uso 4.1. Criar Marco.
ID: UC 4.1.
Caso de Uso: Criar Marco
Descrio: Caso de uso relativo funcionalidade que permite criar um marco e associ-lo a
um prazo de incio ou de fim de um perodo.
Requisito(s): RF-05, RF-11, RF-12, RF-18, RF-19, RF-20, RF-21, RF-24 e RF-26.
Relacionado(s)
Tabela 7.2 Caso de Uso 4.2. Configurar Marco.
ID: UC 4.2.
Caso de Uso: Configurar Marco
Descrio: Caso de uso relativo funcionalidade que permite editar marcos associados a
prazos, selecionando-se uma atividade-marco e o estado esperado da atividademarco.
Requisito(s): RF-05, RF-11, RF-12, RF-18, RF-19, RF-20, RF-21, RF-24 e RF-26.
Relacionado(s)
76
ID: UC 4.3.
Caso de Uso: Remover Marco
Descrio: Caso de uso relativo funcionalidade que permite remover um marco e
desassoci-lo de seu respectivo prazo.
Requisito(s): RF-05, RF-12, RF-18 e RF-26.
Relacionado(s)
Tabela 7.4 Caso de Uso 4.4. Consultar Marcos.
ID: UC 4.4.
Caso de Uso: Consultar Marcos
Descrio: Caso de uso relativo funcionalidade que permite consultar todos os marcos
vinculados a prazos de incio e fim definidos para um perodo.
Requisito(s): RF-08.
Relacionado(s)
ID: UC 05
Caso de Uso: Fornecer Feedback da Tarefa Realizada
Descrio: Caso de uso relativo funcionalidade que viabiliza a comunicao ao
desenvolvedor das tarefas das quais ele responsvel de executar dentro de um
perodo e a coleta do feedback dessas execues, fornecidas pelos responsveis.
Requisito(s): RF-17 e RF-18.
Relacionado(s)
77
Tabela 9 Matriz de relacionamento Casos de Uso x Requisitos Funcionais.
Requisitos Funcionais
Casos de
Uso
UC 01
UC 02
RF
01
RF
02
RF
03
RF
04
RF
05
RF
06
RF
07
x
x
RF
08
RF
09
RF
10
RF
11
RF
12
x
x
RF
13
RF
14
RF
15
RF
16
RF
17
RF
18
RF
19
UC 03
UC 04
UC 05
RF
20
RF
21
RF
22
RF
23
RF
24
RF
25
RF
26
78
4.5.
Extenso da WebAPSEE-PML
Baseando-se nas gramticas de grafos, o ambiente WebAPSEE tem sua PML formalmente
definida em seu grafo-tipo que estabelece a sintaxe da linguagem utilizada no ambiente (seo
3.2, Figura 3.5). Para que as atividades peridicas possam ser utilizadas no ambiente
necessrio, inicialmente, que sejam inseridos novos smbolos no alfabeto da linguagem
WebAPSEE-PML, para estender a sintaxe da linguagem.
A insero de novos elementos no algo trivial, visto que, cada um dos elementos
presentes na WebAPSEE-PML est integrado de forma que cada smbolo, associado a um
nome e um conjunto de atributos, utilizado para representar e raciocinar sobre o estado do
processo (LIMA REIS, 2003), no podendo haver inconsistncias. As setas no diagrama
representam arcos do grafo, sendo que, setas pontilhadas representam relacionamentos e setas
slidas representam chamadas de mensagem; o relacionamento Is_a, por exemplo, representa
uma relao de herana, sendo assim, de acordo com o grafo-tipo, uma Atividade
Decomposta (Activity_Dec), uma Atividade Normal (Activity_Normal) e uma Atividade
Automtica (Automatic), so uma Atividade (Activity) e herdam de Atividade seus atributos.
A parte principal do grafo-tipo da WebAPSEE-PML, referente s atividades, destacada na
Figura 4.6.
79
80
Para seguir o padro adotado no modelo original, utilizou-se a lngua inglesa. No modelo
da Figura 4.7, uma atividade peridica (Periodic), uma (Is_a) atividade que tem (has) um
conjunto de perodos (Period). Cada perodo possui uma identificao prpria (Id), um estado
(Pr-st) e datas de incio previsto (BeginDue) e fim previsto (EndDue), que so associadas a
datas. Um perodo ainda definido (Defined_by) por um modelo de processo (Process
Model), que pode ter outras atividades. Os marcos (Milestone) possuem uma identificao
(Id) e um estado (M-st), eles so aplicados a um perodo (To) e referenciam uma Atividade
Normal (refers_to), da qual ele espera um estado (Req_A-st), para que ele possa ativar um
prazo de incio ou fim (Dep, que pode ser end-end, para prazo de fim, ou start-start, para
prazo de incio) do perodo.
Como comentado na seo 3.2, nem todos os smbolos do alfabeto so visuais, ou seja,
disponveis visualmente ao usurio. Com relao aos elementos inseridos na WebAPSEEPML, apenas o elemento que representa a atividade peridica visvel ao usurio e
manipulvel graficamente pelo editor grfico do ManagerConsole.
81
4.6.
Objetivando-se a execuo das atividades peridicas, aos elementos inseridos no grafotipo, apresentados na Figura 4.7, foram adicionados alguns smbolos necessrios s regras de
transformao. Alm disso, como a execuo envolve transformaes encadeadas, foi
necessrio inserir alguns smbolos sinalizadores aos marcos, como os relacionados a outros
elementos do grafo-tipo de (LIMA REIS, 2003) (Figura 3.6), para identificar situaes
especficas do processo, porm, o funcionamento desses smbolos sinalizadores o mesmo de
um atributo de um vrtice. A Figura 4.8 apresenta a estrutura sinttica e adicionados os
smbolos que auxiliam na execuo, tanto para as atividades peridicas quanto os j existentes
para os outros elementos a partir do grafo-tipo original.
Ao elemento Milestone foram adicionados os smbolos True e False. O sinal True marca
que uma condio foi avaliada e verdadeira; o sinal False marca que uma condio foi
avaliada e falsa. Desta forma, quando o marco, receber a indicao do sinal True, indica que
ele foi alcanado; enquanto o sinal for False, ele permanece aguardando (M-st = waiting).
A partir da utilizao dos elementos da WebAPSEE-PML em conjunto com os elementos
de execuo, pode-se desenvolver as regras para dar semntica de execuo s atividades
peridicas.
82
Observa-se no diagrama da Figura 4.9 que um perodo, a partir do momento que criado,
entra no estado de Requisitos (Requirements), onde ainda no h atividades definidas para
este perodo e ele se resume a uma descrio dos seus requisitos. Passa ento para o estado
Abstrato (Abstract) quando atividades so definidas de forma abstrata dentro de um perodo,
ou seja, sem que ainda estejam definidos agentes para sua realizao, mas apenas cargos ou
apenas o tipo de recursos, por exemplo, e o perodo no est pronto para ser realizado, mesmo
que o prazo para incio do mesmo tenha sido alcanado. Quando alguma atividade do perodo
instanciada ela passa para o estado Esperando (Waiting), quando se espera apenas que as
dependncias para incio do perodo sejam satisfeitas para que ele possa ser executado.
Quando todas as dependncias para incio do perodo esto satisfeitas, prazo de incio e
marcos foram alcanados, e h atividades instanciadas, o perodo passa ento ao estado Pronto
(Ready), quando as atividades instanciadas so disponibilizadas nas TaskAgendas dos
desenvolvedores aguardando que estes dem inicio. Quando alguma atividade do perodo
iniciada, ele passa ento para o estado Ativo (Active) representando que o perodo est em
execuo; durante a execuo do perodo, se todos os desenvolvedores (agentes) solicitarem
pela TaskAgenda que todas as atividades do perodo sejam pausadas, o perodo passa para o
83
estado Pausado (Paused), bastando que uma atividade volte a executar para ele retornar ao
estado Ativo. Por fim, quando todas as atividades de um perodo forem finalizadas pelos
desenvolvedores, o perodo entra no estado Concludo (Finished).
Tambm procurando manter a consistncia com os estados definidos dos outros tipos de
atividades e seguindo o mesmo padro do ambiente WebAPSEE, os estado de uma Atividade
Peridica, como so compostas de perodos, depende dos estados dos perodos que a compe
e so apresentados na Figura 4.10.
Quando uma atividade peridica criada, seu estado Requisitos (Requirements), pois
possue apenas uma descrio geral e no possui perodos definidos (quando uma atividade
peridica criada, um perodo criado automaticamente, porm, este se encontra tambm no
estado de Requisitos). Quando ao menos um perodo da atividade peridica definido, mas
no instanciado, o estado da atividade peridica passa para Abstrata (Abstract). Quando h
84
perodos instanciados, o estado passa a ser Instanciada (Instantiated). Caso algum perodo
inicie sua execuo, a atividade passa para o estado Executando (Enacting), onde permanece
at que todos os perodos sejam concludos, quando ela passa para o estado Concluda
(Finished), ou quando a atividade falhada, passando para o estado Falhada (Failed). O
estado Mista (Mixed) existe para distinguir as atividades peridicas que no satisfaam os
requisitos para estarem nos demais estados.
A Falha ou Cancelamento de uma atividade ou perodo ocorrem da seguinte forma:
um cancelamento s pode ser solicitado se a atividade ou perodo no tiver sido iniciado, j a
falha, pode ser solicitada durante a execuo. A Falha encerra a atividade ou perodos em
execuo e cria uma nova verso deste, que refeita. O mecanismo de execuo deve, em
caso de falha e ao criar uma nova verso, por padro, criar uma nova verso da atividade
peridica apenas com os perodos no estado Requisitos; e caso um perodo seja falhado devese verificar a existncia de marcos associados ao perodo, caso exista, estes devero ser
removidos. Qualquer alterao no processo definido que tenha como objetivo manter a
consistncia do sistema deve solicitar autorizao do usurio para que ela seja realizada.
Uma questo muito importante para que os perodos sejam gerenciados de forma
automtica que o mecanismo gerencie os prazos e outras dependncias para incio do
mesmo no tempo previsto, permitindo que eles sejam executados. O mecanismo deve tambm
fornecer flexibilidade para a definio desses prazos e seguir os requisitos para atividades
peridicas definidos na seo 4.3.3. Na Figura 4.11 apresentado um diagrama de atividades
que define como o mecanismo deve gerenciar esses prazos e dependncias entre perodos
definidos pelo gerente.
85
Inicialmente, para que o mecanismo gerencie os prazos definidos, necessrio que ele
saiba se o perodo possui atividades instanciadas, ou seja, que podem ser executadas, mas
esto esperando que o prazo de incio seja alcanado. Neste momento o estado do perodo
Esperando (Waiting). Se o mecanismo verificar que para um dado perodo existem atividades
instanciadas, ele ento verifica se o prazo foi alcanado. O prazo pode ser definido como uma
data ou relacionado a um marco. Se o prazo no foi alcanado, o mecanismo verifica se
permitido que perodos sejam adiantados (cumprindo um dos requisito apresentados na seo
4.4.3). Se no, ele retorna a verificar quando o prazo alcanado. Se sim, ele verifica se o
perodo precedente est executando. A partir da, caso o perodo precedente no esteja
executando no h nenhum impedimento para que o perodo possa ser executado,
disponibilizando-se as atividades instanciadas na TaskAgenda dos desenvolvedores
86
responsveis por elas, aguardando a execuo no estado Pronto (Ready). Caso o erodo
precedente ainda esteja executando verifica-se se permitida a execuo concorrente de
perodos, se sim, o mecanismo, da mesma forma permite que o perodo inicie,
disponibilizando as atividades instanciadas na TaskAgenda dos desenvolvedores. Caso no
seja permitida a execuo de perodos concorrentes, o mecanismo volta a verificar quando o
prazo de incio alcanado.
A partir do momento em que um perodo tem sua execuo permitida e suas atividades
so iniciadas pelos desenvolvedores, o mecanismo fica apenas recebendo feedback dos
desenvolvedores at que o perodo seja concludo, mediante o cancelamento, falha ou
finalizao das atividades.
4.7.
87
Na Figura 4.12, o sistema recebe uma solicitao de insero de uma atividade peridica
em um ponto especfico do modelo de processo, sendo passados como parmetros o
identificador do processo no qual se pretende adicionar a atividade e o identificador que deve
ser utilizado por esta atividade. Seguindo o formalismo utilizado, para que a solicitao tenha
efeito, um estado do processo esquerda deve ser reconhecido e a transformao ou passo de
derivao estabelece que o estado posterior aplicao da regra encontra-se direita. Para
que a atividade seja criada necessrio que no exista previamente associada ao Processo, de
identificador process_id, uma atividade peridica de identificador new_id. Respeitadas as
condies, uma atividade peridica de identificador new_id criada, tendo um perodo
associado que definido por um Modelo de Processo no estado Requisitos.
O conjunto de regras modeladas para as atividades peridicas pode ser consultado no
Apndice B. Apesar da proposta inicialmente criar um escopo mais reduzido para a criao de
regras, no foi possvel alcanar o objetivo de se definir todas as regras para a mquina de
execuo, pois, alm de sua complexidade, estas precisam de um tempo de maturao que
ocorre a partir de muitos processos iterativos de definio, reviso, checagem de consistncia
e alteraes para que estejam integradas umas com as outras de forma a no haver
inconsistncias. Portanto uma extenso dessas regras e maior maturao so relacionados
como trabalhos futuros.
88
4.8.
Modelo de Dados
4.9.
89
Periodic
90
91
92
93
o (
94
elementos de processo, permitindo ainda a definio geral de elementos do processo sem que
seja necessrio instanci-los imediatamente.
O meta-modelo SPEM 2.0 permite que uma atividade ou qualquer elemento que compe
uma atividade possa ser reutilizado por outra atividade ou processo dinamicamente,
permitindo-se herdar uma subestrutura completa ou parcial; instncias de atividades podem
herdar, mesclar algumas propriedade ou substituir todas as suas propriedades pelas
propriedades de outra atividade. Outro elemento do processo definido pelo meta-modelo a
Iterao (Iteration), que agrupa um conjunto de atividades que so repetidas mais de uma vez;
de forma geral, a definio do processo pode incluir informaes que indicam que as
definies do trabalho modelado devem ser repetidas vrias vezes em um projeto (modelagem
de iteraes) ou que devem haver mltiplas ocorrncias, uma atividade, por exemplo, pode ser
repetida. No prprio meta-modelo SPEM ressaltado o fato de que, este o conceito de
iterao utilizado no modelo, mas o conceito de iterao pode ser associado com diferentes
regras em diferentes mtodos. permitida, ainda, a execuo paralela e sequencial de
atividades e processos. Muitas das facilidades e flexibilidades fornecidas pela atual
arquitetura do meta-modelo poderiam ser utilizadas para definir atividades peridicas, mas
estas ainda no so previstas explicitamente.
Com relao a automao, no foram encontradas ferramentas que implementem as
atividades peridicas tal como esto sendo expostas neste trabalho. As ferramentas
pesquisadas, no implementam um facilitador especfico para estas atividades. Apenas uma
ferramenta encontrada diferencia essas atividades em especfico, dando-lhes um tratamento
especial, mas no atende a maioria dos requisitos para atividades peridicas apresentados na
seo 4.4.3 e apresentam flexibilidade limitada durante a definio e execuo dessas
atividades em modelos de processo. Muitas das ferramentas encontradas apoiam no mximo a
repetio de atividades e na maioria dos casos apenas a modelagem de processos e no a
execuo.
A maioria das ferramentas encontradas no apoia a definio e execuo de atividades
peridicas diretamente. As principais limitaes das ferramentas encontradas, com relao ao
apoio fornecido para facilitar a definio, execuo e acompanhamento de atividades
peridicas, foram:
95
96
97
98
99
100
101
102
103
5. CONCLUSES
5.1.
Contribuies
5.2.
Limitaes do Trabalho
104
frequente, como em vrios projetos de software, foram um dos motivos de no se ter chegado
ao resultado final esperado de alguns objetivos traados.
5.3.
Trabalhos Futuros
Como no foi uma proposta do trabalho a visualizao grfica dos perodos das
atividades peridicas em cada ponto do processo onde eles acontecem, pelos
motivos expostos no captulo 4, pode ser objetivo de um trabalho futuro verificar
essa possibilidade;
105
5.4.
Consideraes Finais
Desde o incio o trabalho mostrou-se ambicioso, pois buscava a insero de uma nova
funcionalidade em um ambiente real de apoio ao processo de desenvolvimento de software,
funcionalidade esta pouco explorada na prtica por outros ambientes. O WebAPSEE um
ambiente muito grande e complexo, resultado de anos de desenvolvimento e melhorias,
porm, j apresenta muitas vantagens prontas que podem beneficiar os desenvolvedores do
sistema na melhoria do mesmo e os usurios em um processo real de desenvolvimento.
As atividades peridicas de forma geral no so tratadas por outras ferramentas da forma
como previstas nesse trabalho. Apenas uma soluo foi encontrada em outro trabalho neste
sentido, portanto, este trabalho, mais do que conclusivo, uma oportunidade para um trabalho
mais profundo no intuito de inserir as atividades peridicas como abordagem claramente
necessria em outros PSEEs.
O trabalho no pde abarcar todos os fatores relacionados com a implementao de
atividades peridicas no ambiente WebAPSEE. Entretanto, pretende-se dar continuidade ao
que se comeou aqui, provavelmente como tema de uma ps-graduao, procurar mais fatores
que podem ser tratados pelas atividades peridicas, melhorar o mecanismo proposto e
implementar de fato estas atividades no ambiente WebAPSEE.
106
REFERNCIAS BIBLIOGRFICAS
107
CONRADI, R.; RAGASETH, M.; LARSEN, J.; NGUYN, M. N.; MUNCH, B. P.;
WESTBY, P. H.; ZHU, W.; JACCHERI, M. L.; LIU, C. EPOS: Object-Oriented Cooperative
Process Modelling. In: FINKELSTEIN, A. et al. (Ed.). Software Process Modeling and
Technology. Taunton: Research Studies Press, 1994. p. 33-70.
CONRADI, R.; FERNSTRM, C.; FUGGETTA, A. Concepts for Evolving Software
Processes. In: FINKELSTEIN, A. et al. (Ed.). Software Process Modeling and Technology.
Taunton: Research Studies Press, 1994. p. 9-31.
CONRADI, R.; JACCHERI, M. L. Process Modelling Languages. In: DERNIAME, J.;
KABA, B.; WASTEL, D. (Eds.) Software Process: Principles, Methodology, and
Technology. London: Springer-Verlag, 1999. p. 27-52. (Lecture Notes In Computer Science,
v. 1500).
CONRADI, R.; LIU, C. Revised PMLs and PSEEs for Industrial SPI. In: BOSCH, J.;
MITCHELL, S. (Eds.) Object-Oriented Technology, ECOOP97 Workshop Reader:
ECOOP97 Workshops, Jyvskyl, Finland, June 1997, Proceedings. London: SpringerVerlag, 1998. p. 289-294. (Lecture Notes In Computer Science, v. 1357).
COSTA, A. J. S.; SALES, E. O. Uma Proposta para Reutilizao de Processos de
Software para o Ambiente WebAPSEE. 2007, 85 f. Trabalho de Concluso de Curso
(Graduao em Cincia da Computao) Curso de Bacharelado em Cincia da Computao.
Universidade Federal do Par, Belm, PA, fev. 2007.
COSTA, A. J. S. Um Mecanismo de Adaptao de Processos de Software. 2010, 103 f.
Dissertao (Mestrado em Cincia da Computao) Programa de Ps Graduao em Cincia
da Computao, Universidade Federal do Par, Belm, PA, 2010.
CUSUMANO, M.; MACCORMACK, A.; KEMERER, C. F.; CRANDALL, W. Software
Development Worldwide: The State of the Practice. In: IEEE Software, Volume 20, Issue 6,
November 2003. Journals... [S.l.]: IEEE Computer Society Press, 2003. p. 28-34.
EHRIG, H.; TAENTZER, G. Graphical Represenation and Graph Transformation. ACM
Computing Surveys (CSUR), New York, NY, Volume 31 Issue 3es, Sept. 1999.
ELLMER, E. Improving Software Processes. In: SOFTWARE ENGINEERING
ENVIRONMENT CONFERENCES, SSE95, 1995. Proceedings... Washington: IEEE
Computer Society, 1995. p. 74-83.
ENDRES, A.; ROMBACH, H. D. A Handbook of Software and Systems Engineering:
Empirical Observations, Laws and Theories. New York: Addison Wesley, 2003. 327 p.
(Fraunhofer IESE series on software engineering).
FANTINATO, M. Tutorial: Implementando um Processo de Negcio com BPEL. So Paulo:
USP, 201?. Disponvel em: <http://www.wsbpel.hd1.com.br/> Acesso em: 24 nov. 2011.
(trabalho vinculado ao projeto do programa Ensinar com Pesquisa da Universidade de So
Paulo, sob orientao do professor Doutor Marcelo Fantinato, do curso de Sistemas de
Informao).
FERREIRA, Aurlio Buarque de Holanda. Novo dicionrio Aurlio da lngua portuguesa.
4. ed. Curitiba: Ed. Positivo, 2009. 2120 p. ISBN 978-85-385-2825-8.
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134