UML4SPM
(Software Process Modeling)
Davi Junio S. de Oliveira
[email protected]
Tópicos Avançados em Engenharia de Software 3
28/05/2008
AGENDA
• Motivação
• Processo de Software e Meta-Processo de Software
• Modelo de Processo de Software
– Conceito
– Objetivos
• Linguagem de Modelagem de Processo
• Linguagens de Modelagem de Processo baseadas em UML
–
–
–
–
–
Spem1.1
Spem2
Di Nitto
PROMENADE
Shih-Chien Chous
• UML4SPM
–
–
–
–
–
–
–
Metamodelo
Process Structure Package
Element Process Package
Foundation Package
Notação UML4SPM
Avaliação da UML4SPM
Avaliação da UML4SPM com ISPW-6
MOTIVAÇÃO
• Preocupação
em
administrar
a
complexidade gerada pelas atividades do
Ciclo de Vida de Desenvolvimento de
Software;
• Os modelos de CVDS (SDLC) tem um
granularidade grossa;
• Criar pequenas atividades com um nível
de detalhamento mais explícito e preciso;
PROCESSO E META-PROCESSO
• Processo de Desenvolvimento de Software: O
conjunto total de atividades de Engenharia de
Software necessárias para transformar requisitos
de usuário em software[Humphrey];
• Meta-Processo: Consiste em atividades de
modelagem do processo, administração do
processo,
suporte
para
execução
e
melhoramento deste;
MODELO DE PROCESSO
SOFTWARE - CONCEITO
• Um Modelo de Processo é uma descrição
abstrata de um processo proposto que
representa elementos do processo selecionado
que são considerados importantes para a
finalidade do modelo e podem ser executados
por um humano ou por uma máquina [Curtis 92];
• Representa uma sequência de atividades, objetos
e transformações que compõe a estratégia para a
execução do desenvolvimento do software
[Scacchi];
MODELO DE PROCESSO SOFTWARE OBJETIVOS
• Facilitar e Suportar o desenvolvimento de
software de alta qualidade e baixo custo;
• Facilidade de Comunicação e Entendimento
humano;
• Facilidade de reuso do processo;
• Suporte a melhorias no processo;
• Suporte a administração do processo;
• Automatização do andamento do processo;
LINGUAGUEM DE MODELAGEM DE
PROCESSO - CONCEITO
• É uma linguagem usada para expressar modelos de
processos [Zamli];
• Uma LMP pode ser vista como uma linguagem de
modelagem ou como uma linguagem de programação;
• A abrangência da linguagem depende dos seus objetivos e
metas do modelo resultante;
• O nível de entendimento, precisão e usabilidade de um
modelo de processo dependem diretamente da LMP usada
para descrevé-lo;
LINGUAGUEM DE MODELAGEM DE
PROCESSO
• Semântica Rica
– Elementos do Processo: Agentes, Regras, Atividades
(Passos) , Artefatos e Ferramentas;
– Coordenação das Ações e Atividades:
• Controles Proativos : Control Flow e Object Flow;
• Controles Reativos: Exception, Event Handling;
– Tratadores de Exceção;
• Isso é modelagem de processo
ou desenvolvimento de software?
LINGUAGUEM DE MODELAGEM DE
PROCESSO
• Semântica Rica
– Construções Avançadas:
• Entendível
– Código ou Notação Visual?
LINGUAGUEM DE MODELAGEM DE
PROCESSO
• Precisão;
– Depende da Granulidade
• Executável;
• Modularização;
– Capacidade de combinar diferentes
pedaços de processos para formar
um novo processo.
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• SPEM 1.1 (Software Process Engineering
Metamodel - OMG)
– UML 1.4 Profile;
– MOF 1.3 Compliant;
– SPEM_FOUNDATION E SPEM_EXTENSIONS
– Process Structure Package;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Semântica Rica
– Elementos do Processo
•
•
•
•
Activity;
Work Product ;
Process Role;
Human, Agent, Tool???
– Coordenação de Atividades e Ações;
• Controles Proativos: start-start, finish-start, finish-finish;
• Controles Reativos???
– Tratadores de Exceções???;
– Construtores Avançados;
• Loops e Condicionais???
• Phase e iteration;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Entendível
• Precisão
– Phase, Lifecycle, Iteration, WorkDefinition, Step;
• Executabilidade
– O conceito de passo é impreciso…
• Modularização
– ProcessComponent
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Ferramentas
– Rational Process WorkBench;
– Iris Suite;
– SPEM Profile;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• SPEM 2 (Software Process Engineering
Metamodel - OMG)
– UML 2 Superstructure Profile ;
– MOF 2 Compliant extendendo UML Infrastructure;
– Não defini restrições OCL;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Semântica Rica
– Elementos do Processo
• Role Uses, Activities, Work Product Uses, etc;
• Agent e Tool;
– Coordenação de Atividades e Ações;
• Controles Proativos;
• Contoles Reativos: WorkSequenceKind;
– Tratadores de Exceções????;
– Construtores Avançados;
• Extensible Element;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Entendível
– Muito complexo;
• Precisão
• Executabilidade
– O padrão não especifica uma forma;
– Process Behavior Package;
• Modularização
– Activity Use Kind;
– Process Component;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Ferramentas
– Eclipse Process Framework;
– Rational Method Composer;
– PRO3;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Di Nitto (International Conference of Software
Engineering 2002)
– Subconjunto de UML 1.3 como uma LMP
executável;
– Duas fases, primeira fase é realizada através da
descrição do processo usando diagramas UML, na
segunda fase os diagramas são traduzidos em
código;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Semântica Rica
– Elementos do Processo
• Tool, Role????
– Coordenação de Atividades e Ações;
• Active Controls;
• Reactive Controls???;
– Tratadores de Exceções???;
– Construtores Avançados???;
• Entendível
– Não existem mecanismos de ligação de dois diagramas;
– Não existe o conceito de composição no diagrama de atividades;
– O uso de diagramas de estados dificultam a leitura de pessoas que não
estão acostumadas a eles;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Precisão
• Executabilidade
– Todos os diagramas podem ser traduzidos para
código desde que contenham informações
suficientes;
• Modularização???
• Ferramentas
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• PROMENADE (PROcess-oriented Modelling
and Enactement of Software DEvelopment)
– ComProLab Project;
– UML 1.3;
– Duas partes, primeira fase é estática, realiza a
descrição do processo usando diagramas UML, a
segunda fase é dinânmica, estabelece a sequência
das atividades a serem executadas (Gráfico de
Precendência);
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Semântica Rica
– Elementos do Processo
– Coordenação de Atividades e Ações;
• Strong;
• Weak;
• Synchronizing;
– Tratadores de Exceções;
• CompleteUnsucc (Diagrama de Estados);
– Construtores Avançados???;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Entendível
– Processo simples, usa o diagrama de classe para
representar os elementos do processo e o diagrama
de precedência para representar a ordem de execução
das tarefas;
– Como integrar???
• Precisão
– Única unidade de trabalho, Task;
• Executabilidade???
• Modularização
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Shih-Chien Chous
– National Science Council of Taiwan;
– UML 1.4;
– Duas partes, representar a descrição do processo
usando diagramas UML, mapear a descrição para
um linguagem em formato legível por máquina;
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Semântica Rica
– Elementos do Processo
• Activity, Role, Tool;
• Agent???
– Coordenação de Atividades e Ações;
• Active Controls;
• Reactive Controls???
– Tratadores de Exceções;
• Representado no P-activity como uma atividade;
– Construtores Avançados???;
• Branch e Loop (Gramática BNF);
LINGUAGUENS DE MODELAGEM DE
PROCESSO BASEADAS EM UML
• Entendível
– Não existe ligação entre os dois diagramas
propostos;
• Precisão
– Activity
• Executabilidade
– Não existe ferramenta para geração automática de
um programa do processo;
• Modularização???
UML4SPM
• Baseada em UML2;
• Linguagem de Modelagem e
Execução de processos de software;
• MOF Compliant Metamodel
extendendo UML Superstructure;
UML4SPM
• Aumentar o nível de abstração, e por
consequência elevar o nível de entendimento da
linguagem, possibilitando assim a compreensão
deste por profissionais que não são de ciência da
computação;
• Usar um formalismo bem conhecido e padrão;
• Modelo de Processo Executável;
UML4SPM - Metamodel
• UML4SPM_FOUNDATION;
• UML4SPM_EXTENSIONS;
UML4SPM – Process Structure Package
Process Element
• Descrição: Metaclasse para Software
Responsible Role e Work Products;
• Generalização:
Activities,
– UML Superstructure::Kernel::Classifier;
• Atributos:
– description: String;
– name: String (herdado de Classifier);
• Associações:
– Kind: Process Element Kind [0..1]
• Restrições: Um process element kind não pode ser
reusado por diferentes subclasses de process element;
UML4SPM – Process Element
Process Element Kind
• Descrição: Metaclasse para definição de tipos
de elementos de processos específicos;
• Generalização:
• Atributos:
– name: String;
• Associações:
• Restrições:
Software Activity Kind
• Descrição: Metaclasse para definição de tipos
de atividades de software específicos;
• Generalização: Process Element Kind;
• Atributos:
– name: String (Process Element Kind);
• Associações:
• Restrições:
Work Product Kind
• Descrição: Metaclasse para definição de tipos
de produtos de trabalho específicos;
• Generalização: Process Element Kind;
• Atributos:
– name: String (Process Element Kind);
• Associações:
• Restrições:
Responsible Role Kind
• Descrição: Metaclasse para definição de tipos
de responsabilidades específicos;
• Generalização: Process Element Kind;
• Atributos:
– name: String (Process Element Kind);
• Associações:
• Restrições:
Software Activity
• Descrição: Descreve o esforço ou pedaço de trabalho que deve ser
executado durante o processo de desenvolvimento de software;
• Generalização:
– Process Element
– UML Superstructure::Activities::Activity;
• Atributos:
–
–
–
–
–
–
–
name: String (Classifier);
description: String (Process Element);
executionKind: ActivityExecutionKind;
priority: PriorityKind;
complexity: ComplexityKind;
isInitial: Boolean;
duration: String;
• Associações:
– responsibleRoles: ResponsibleRole [1..N];
– softwareActivityKind: SoftwareActivityKind [0..1]
Software Activity
• Associações:
– requires: Guidance [0..N];
– startAt: TimeLimit [0..1]
– endAt: TimeLimit [0..1]
• Restrições: Somente uma Software Activity
pode ser isInitial=true
context Model inv:
self.allOwnedElement()->select(oclIsKindOf(SoftwareActivity))>select(sa | sa.isInitial)->size()=1
Software Activity
Activity Execution Kind
• Descrição: Enumeração que define os tipos de
execução de uma Software Activity
– machineExecution;
– humanExecution;
•
•
•
•
Generalização:
Atributos:
Associações:
Restrições:
Priority Kind
• Descrição: Enumeração que define a prioridade
da Software Activity dentro do processo;
– Low;
– Medium;
– High;
•
•
•
•
Generalização:
Atributos:
Associações:
Restrições:
Complexity Kind
• Descrição:
Enumeração
que
define
a
complexidade da Software Activity dentro do
processo;
– Easy;
– Medium;
– Difficult;
•
•
•
•
Generalização:
Atributos:
Associações:
Restrições:
Responsible Role
• Descrição: Define responsabilidades e habilidades
necessárias para executar uma Software Activity.
Também é responsável pela realização do Work
Product;
• Generalização:
– Process Element;
• Atributos:
–
–
–
–
–
name: String (Classifier);
description: String (Process Element);
responsibility: String;
qualification: String;
rights: String;
Responsible Role
• Associações:
– activities: SoftwareActivity [0..N];
– workproducts: WorkProduct [0..N];
– responsibleRoleKind: ResponsibleRoleKind [0..1];
– rolePerformer: RolePerformer [1..N]
• Restrições:
Work Product
• Descrição: Representa qualquer pedaço físico de informação consumido,
produzido ou modificado durante o processo de desenvolvimento. Pode
ser composto por outros WorkProducts. Pode também ser usado como
input/output de SoftwareActivities;
• Generalização:
– Process Element ;
– UML Superstructure::Deployments::Artifacts::Artifact;
• Atributos:
–
–
–
–
–
–
–
–
name: String (Classifier);
description: String (Process Element);
idWorkProduct: String;
isDeliverable: Boolean;
created: String;
lastTimeModified: String;
version: String;
uriLocalisation: String;
Work Product
• Associações:
– performer: ResponsibleRole [0..N];
– workProductKind: WorkProductKind[0..1];
– Impact: WorkProduct[0..N];
• Restrições:
Role Performer
• Descrição: Representa a entidade que irá
realizar a Responsible Role afim de executar a
Software Activity;
• Generalização:
• Atributos:
– name: String;
• Associações:
• Restrições:
Tool
• Descrição: Representa a entidade que irá realizar a
Responsible Role afim de executar a Software Activity;
• Generalização:
– Role Performer;
• Atributos:
–
–
–
–
name: String (Role Performer);
description: String;
isBatch: Boolean;
version: String;
• Associações:
• Restrições:
Team
• Descrição: Representa a entidade que irá realizar a Responsible Role
afim de executar a Software Activity. Pode ser composto por
Agents ou outros Teams;
• Generalização:
– Role Performer;
• Atributos:
– name: String (Role Performer);
• Associações:
– performers: RolePerformer [1..N]
• Restrições:Um Team só pode ser composto por Agents ou outros
Teams, não pode ser composto por Tools;
context Team inv:
self.performers->forAll (roleperformer |roleperformer.isKindOf (Team) or
roleperformer.isKindOf(Agent)
Agent
• Descrição: Representa a entidade que irá realizar a
Responsible Role afim de executar a Software Activity;
• Generalização:
– Role Performer;
• Atributos:
–
–
–
–
name: String (Role Performer);
skill: String;
isAvailable: Boolean;
version: String;
• Associações:
• Restrições:
Guidance
• Descrição: Linhas gerais afim de indicar meios
para a execução de atividades do processo;
• Generalização:
– WorkProduct;
• Atributos: Mesmos de WorkProduct;
• Associações:
• Restrições:
TimeLimit
• Descrição: Representa o tempo que um
SoftwareActivity inicia ou termina;
• Generalização:
• Atributos:
– milestone: string;
• Associações:
• Restrições:
FOUNDATION PACKAGE
Activity
• Descrição: Sequência coordenada de Actions.
Usa o modelo de Object e Control Flow.
Podem incluir Control Nodes, Objects Nodes e
Actions;
• Generalização:
– Behavior;
• Atributos:
– isReadOnly: boolean;
– isSingleExecution: boolean;
Artifact
• Descrição: Representam uma entidade física. Pode ter
assossiações com outros artefatos. Como WorkProduct
deriva de Artifact pode ser definido como Activity
Parameter Nodes em termos de Software Activity e
InputPin ou OutputPin em termos de Action. Pode ter
associado um diagrama de estados;
• Generalização:
– Classifier;
– DeployedArtifact e;
– NamedElement;
• Atributos:
– fileName: String;
Action
• Descrição: Unidade fundamental de especificação de comportamento;
• Ações Reusadas:
– CallBehaviorAction;
• Sincrona;
• Assincrona;
– CallOperationAction;
• Síncrona;
• Assíncrona;
– SendSignalAction;
• Controle Reativo;
– AcceptEventAction;
• Time Event;
• Change Event;
• Message Event;
– BroadcastSignalAction;
– RaiseExceptionAction;
– OpaqueAction;
Action
Notação UML4SPM
Avaliação da UML4SPM
• Semântica Rica
– Elementos do Processo:
•
•
•
•
•
Noção de Atividade é dada pela Software Activity;
Noção de Regras é dada pela Responsible Role;
Noção de Artefato é dada pela Work Product;
Noção de Humano é dada pela Team e Agent;
Noção de Tool é dada pela Tool;
Avaliação da UML4SPM
• Semântica Rica
– Coordenação e Sequência de Ações:
Avaliação da UML4SPM
• Semântica Rica
– Coordenação e Sequência de Atividades:
• Message Event;
– AcceptEventAction
•
•
•
•
Time Event;
Change Event;
CallBehaviorAction;
ActivityParameterNode;
Avaliação da UML4SPM
• Semântica Rica
– Tratadores de Evento:
• RaiseExceptionAction;
• ExceptionHandler;
– Construtores Avançados:
•
•
•
•
Decision Nodes;
Loop Nodes;
Conditional Nodes;
DataStoreNode;
Avaliação da UML4SPM
• Entendível
– Diagrama de Atividades: Modela a sequência de
Software Activities e Work Products trocados entre
Actions;
– Diagrama de Estados: Modela os possíveis estados e
operações de Software Activities, Work Products ou
Agents;
– Diagrama de Sequência: Especifica as chamadas de
operações entre Software Activities;
– Diagrama de Classes: Especificar a relação entre
diferentes elementos do modelo de processo;
Avaliação da UML4SPM
• Precisão
– É possível representar uma hierarquia de processo
definidos por uma metodologia específica através
do Software Activity e Software Activity Kind;
– Dois níveis de abstração: Process e Activity;
Avaliação da UML4SPM
• Executável
– Basic Actions: CallBehaviorAction,
SendSignalAction, etc;
– Intermediate Actions: CreateObjectAction,
DestroyObjectAction, etc;
– Complete Actions: AcceptEventAction,
AcceptCallAction;
– Structured Actions: Structured Nodes;
Avaliação da UML4SPM
• Modularização
– Software Activity pode conter outras unidades;
– Pode-se compor novas Softwares Activity através
de outras;
– CallBehaviorActions liga Software Activities como
se fosse um chamada de método;
Avaliação da UML4SPM
• Modularização
Avaliação da UML4SPM com ISPW-6
• ISPW-6
– Six International Software Process Workshop;
– Visando comparar e entender as diversas
linguagens de modelagem de processo de
software foi criado um exemplo de problema de
modelagem de processo;
– Avalia pontos fortes e pontos fracos das
abordagens de modelagem de processo
examinadas;
Avaliação da UML4SPM com ISPW-6
• ISPW-6
– O problema foca no projeto, codificação, teste
unitário e administração de uma mudança localizada
para um software. É apresenta uma mudança nos
requisitos que pode ocorrer depois da fase de
desenvolvimento ou durante a fase de suporte;
– O problema inicia com o gerente do projeto
agendando mudanças e atribuindo funções, o
exemplo termina quando a nova versão do código é
passado com sucesso pelo novo teste de unidade;
Avaliação da UML4SPM com ISPW-6
• ISPW-6
– Agendamento e Atribuição de tarefas;
– Modificação do Projeto;
– Revisão do Projeto;
– Modificação do Código;
– Modificação dos Planos de Teste;
– Modificação do Pacote de Teste Unitário;
– Teste de unidade;
– Monitorar o Progresso;
Avaliação da UML4SPM com ISPW-6
• Modificação do Projeto:
– Descrição: modificação da unidade de código afetada pela
mudança dos requisitos. O projeto modificado deve ser
revisto e se aprovado implementado em código;
– Entradas:
• Projeto Atual;
• Projeto Revisto;
– Saídas:
• Projeto Revisto;
– Responsabilidade: Atribuído ao Engenheiro de Projeto
– Restrições:
• O passo deve ser iniciado tão logo a tarefa seja atribuída pelo
Gerente do Projeto;
• Subsequentes iterações devem iniciar tão logo a revisão do projeto
tenha sido completada;
• O passo termina quando a saída é fornecida;
Avaliação da UML4SPM com ISPW-6
• Modificação do Projeto:
Avaliação da UML4SPM com ISPW-6
• Revisão do Projeto:
– Descrição: Revisão formal do projeto modificado. Os revisores
anotarão o número de defeitos encontrados para medir o
esforço empregado na revisão;
• Aprovação incondicional;
• Recomendadas poucas mudanças;
• Recomendadas grandes mudanças;
– Entradas:
• Projeto Modificado;
– Saídas:
• Feedback do Projeto Revisto;
• Aprovação do Projeto Modificado;
• Relatório de resultados, erros encontrados e esforço empregado;
– Responsabilidade: Atribuído a uma equipe de revisores
– Restrições:
• O passo deve ocorrer no tempo programado;
• O passo termina quando todas as saídas são fornecidas;
Avaliação da UML4SPM com ISPW-6
• Revisão do Projeto: