Capítulos 1-5 TMS
48 pág.

Capítulos 1-5 TMS


DisciplinaModelagem de Sistemas3.038 materiais78.033 seguidores
Pré-visualização16 páginas
(fim do processo) 
pode ser alcançado a partir de todos STARTs (inícios do processo), e (2) todas as funções da empresa usadas nas 
regras pertencem ao menos a um procedimento do START ao FINISH. 
 
Regras temporais são opcionais e são somente usadas se uma regra para conjunto não ordenado é usada 
(ver exemplo a seguir). 
Regras de tratamento de exceção (opcional) são definidas para detectar situações incomuns e reagir a elas. 
Dois mecanismos podem ser usados, chamados intervalos e supervisões: 
- Intervalos (Time-outs) definem uma duração máxima para o processo. Se esta duração é excedida, o 
processo é abortado e um procedimento de tratamento de exceção é chamado (que pode ser definido como 
um processo de domínio). 
- Supervisões são mecanismos nos quais uma condição é definida. Se a condição se torna verdadeira, 
então a cláusula ação da regra de supervisão é ativada. Esta cláusula de ação pode ser um simples 
procedimento ou novamente uma chamada para um processo de tratamento de exceção. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A figura 4.2 fornece um exemplo fictício ilustrando as várias possibilidades de regras de comportamento de 
um processo de especificação CIMOSA. O exemplo é auto-explicativo e é dado em linguagem formal e formas 
gráficas. Retângulos representam funções da empresa, paralelogramos representam eventos, setas representam o 
fluxo de controle, e BP1 e BP2 são dois processos de negócios comunicantes (trocando mensagens pelas suas 
atividades) iniciados em paralelo exatamente ao mesmo tempo (regra síncrona simbolizada pelo ponto). 
Atividades EA2 e EA3 podem gerar eventos (e2 e e3). 
 
 
e3 
e1 
EA3 
EA1 
e2 
EA2 EA4 
BP1 
BP2 
EA5 EA6 
EA1 
B 
FIM 
INÍCIO 
Figura 4.2 \u2013 Exemplos de regras de comportamento de um processo CIMOSA. 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 25
PROCESSO Exemplo 
EVENTOS ACIONADORES : e1 
ESTADOS FINAIS: s5 
COMPORTAMENTO DE PROCESSO : 
WHEN(START WITH e1) DO EA1 
WHEN(ES(EA1) = s1) DO EA2 
WHEN(ES(EA2) = s21) DO EA3 
WHEN(ES(EA2) = s22) DO EA4 
WHEN(ES(EA3) = s3) DO EA1 
WHEN(ES(EA4) = s41) DO EA3 
WHEN(ES(EA4) = s42) DO SYNC (BP1 & BP2) 
WHEN(ES(BP1) = s51 AND ES(BP2) = s52 ) DO B = {EA5, EA6, EA7} 
WHEN(ES(B) = s5) DO FINISH 
DEPENDE DE EA6 ANTES DE EA7 
TRATAMENTO DE EXCEÇÃO intervalo (10000) : Evento Criado (e10) 
FIM DO PROCESSO 
 
 
4.3 ESPECIFICAÇÃO DA FUNCIONALIDADE DA EMPRESA 
 
Atividades de empresa definem a funcionalidade da empresa (isto é, coisas a serem feitas). Uma atividade de 
empresa é definida em CIMOSA como um conjunto de ações elementares a ser considerado como um todo, isto é 
requerendo recursos e tempo para sua completa execução. Qualquer atividade de empresa (execução ou tomada de 
decisão) é caracterizada por: 
\u2022 seu identificador e seu nome; 
\u2022 seus objetivos, restrições, e regras declarativas; 
\u2022 uma descrição de sua função de transformação; 
\u2022 sua função de entrada (FI), isto é, o conjunto ou fluxo de vistas de objetos a serem processados ou transformados (vistas 
de objetos físicos ou de informação); 
\u2022 sua saída de função (FO), isto é , o conjunto ou fluxo de vistas de objetos produzidos ou transformados pela atividade 
(vistas de objetos físicos ou de informação); 
\u2022 sua entrada de controle (CI), isto é, o conjunto de vistas de objeto usado como controle ou restrições mas não 
modificado pela atividade (deve ser uma vista de objeto de informação); 
\u2022 sua saída de controle (CO), isto é, os estados finais devolvidos no fim da ocorrência da atividade ou a lista de eventos 
gerada pela atividade; 
\u2022 sua entrada de recurso (RI), isto é , o conjunto de entidades funcionais usadas como recursos requeridos para executar a 
atividade; 
\u2022 sua saída de recurso (RO), isto é, vista(s) de objetos de informação sobre objeto(s) de recurso usado(s) como entrada de 
recurso para descrever/gerar relatórios sobre a utilização do recurso (opcional); 
\u2022 sua duração máxima e mínima, isto é, o tempo para executar uma ocorrência de atividade. Uma duração média com 
desvio padrão poderia também ser especificada; 
\u2022 seu comportamento de atividade especificando sua função de transformação/procedimento de operação; 
\u2022 seu conjunto de habilidades requeridas; 
\u2022 sua lista exata de estados finais. 
 
 
Condições de acionamento devem ser também especificadas. Elas podem depender de combinações de relações 
causais (isto é, quais atividades foram terminadas com que estados finais), estados de sistemas (definido pelos 
estados das vistas de objetos), e tempos de sincronização (por exemplo, tempos cronometrados e tempos de espera). 
Elas são definidas como parte do comportamento do processo (cláusula de condição das regras WHEN DO). A 
entrada de controle é em muitos casos a vista de objeto anexada ao evento acionando o processo ao qual a atividade 
pertence. A figura 4.3 ilustra este mecanismo no qual a informação sobre pedido de cliente tem que ser processada. 
O pedido do cliente é usado como entrada de controle fornecendo o número do cliente (Cliente#) e 
referências/identificação de peças (Peças #). Baseado nesta informação, a atividade pode obter os registros de dados 
corretos de duas vistas de objeto de sua entrada de função: base de dados de cliente e base de dados de peças. 
A saída de controle retorna o estado final depois da execução da atividade. Na fase de especificação de projeto, 
ela é usada para definir o tipo de eventos que podem ser gerados pela atividade durante sua execução, se algum. 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 26
O conjunto de habilidades e entrada de recursos especifica os requisitos de recurso da atividade e as entidades 
funcionais a serem usadas para sua execução. Estes são construtores da vista de recurso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.3 \u2013 Mecanismo de Entrada de Controle por meio de eventos e vistas de objetos. 
 
 
A função de transformação é especificada em CIMOSA como o comportamento da atividade. Ela é definida 
como um algoritmo (ou um script em pseudocódigo), semelhante ao comportamento de processo, conforme pode ser 
ilustrado na página 30 (a linguagem para definição do comportamento da atividade não será foco de estudo). Ela faz 
uso de operações funcionais fornecidos por entidades funcionais especificadas na entrada de recurso. 
 
A definição do comportamento de atividades definidas com a linguagem proposta por CIMOSA visa a 
automação de atividades. Porém se o comportamento de atividades pode ser descrito em linguagem natural através 
de um procedimento de operação. 
 
4.4 - DERIVAÇÃO DE MODELOS NA VISTA DE FUNÇÃO 
 
 Um dos princípios da estrutura de modelagem CIMOSA é o princípio de Derivação, onde os modelos vão se 
modificando, dependendo da fase de modelagem do sistema (ver figura 2.8). A seguir são ilustrados construtores de 
modelagem para cada uma das fases: Definição de Requisitos; Especificação de Projeto; e Descrição de 
Implementação. 
 
Evento: 
Pedido de Clientes 
Vista de Objeto: 
Pedido-Cliente 
Custo # 
Listof Pedido # 
Data de Entrega 
 
Atividade Empresa: 
Obter Detalhes do Pedido 
Vista Objeto: 
Pedido Completo 
Custo # 
Endereço # 
Listof (Pedido#,Preço) 
Feito 
Processo de Domínio: 
Entrada de Pedido de Clientes 
Início 
Vista de Objeto: 
Basede Dados de Peças 
Peça # 
Preço 
Vista Objeto: 
Base de Dados de Cliente 
Cliente # 
Endereço 
 
Vista de Objetos 
Operador de Pedidos 
Sistema de Gerenciamento 
de Pedidos 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 27
4.4.1 - NÍVEL DE MODELAGEM DEFINIÇÃO DE REQUISITOS 
 Neste nível de modelagem, o usuário primeiro estabelece os domínios