Capítulos 6-9 TMS

Prévia do material em texto

49 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
Capítulo 6 - MODELAGEM DA VISTA DE INFORMAÇÃO COM CIMOSA 
 
 
CIMOSA define dois principais construtores para a modelagem de informação: objeto de empresa e vista 
de objetos. Objetos de empresa representam entidades do mundo real da empresa, possuindo uma identidade e 
existência própria. Eles são caracterizados por seu ciclo de vida e são descritos por um conjunto de propriedades 
intrínsecas. Dois tipos de propriedades são definidos: elementos de informação e mecanismos de abstração. 
Elementos de informação são dados ou grupo de dados representados e contidos nos objetos de empresa. Um 
elemento de informação pode ser: 
• um atributo definido por seu tipo de dado (são usados todos os tipos de dados básicos da linguagem EXPRESS *); 
• uma agregação de dados (LIST, ARRAY, SET e BAG, como definidos na linguagem EXPRESS); ou 
• uma referência a um outro objeto de empresa, considerada como um atributo. 
 
 Os mecanismos de abstração são: 
• a generalização, usada para definir uma classe de objeto como uma especialização de uma ou várias classes de 
objetos mais genéricas; 
• a agregação, utilizada para definir um objeto de empresa como composto de outras classes de objetos. 
 
* Exemplos de Tipos de dados ou domínios : 
 
- integer 
- real 
- boolean (true or false) 
- character 
- character string (palavras com número de letras limitas ou não) 
- text (para formatos de textos) 
- date (data no format, por exemplo: dd.mm.aa:hh.mn.ss) 
- money (Dolar, Real,…) 
- etc. 
 
Vistas de objetos são manifestações ou estados de objetos de empresa e podem ser classificadas em dois tipos: 
vistas de objetos de informação e vistas de objetos físicos. Vistas de objetos de informação referem-se a entidades 
de informação, isto é, representação de dados de objetos do mundo real (natureza de informação). Vistas de objetos 
físicos referem-se a entidades físicas, isto é, fazem referência a um objeto concreto (natureza física). Esta distinção 
diferencia o fluxo de informação e o fluxo de material em um modelo. No modelo, as vistas de objetos são 
constituídas de elementos de informação extraídos de objetos da empresa ou atributos derivados, ou seja, atributos 
calculados. Em outras palavras, uma vista de objetos é uma imagem ou aparência do estado de um ou mais objetos 
de empresa em um dado instante. 
 Exemplos de vistas de objetos são documentos (ver exemplos de documentos no capítulo 5), formulários, 
telas de computador, e arquivos de dados, utilizadas por usuários e atividades nas operações do dia-a-dia da empresa. 
Em termos matemáticos, uma vista de objeto (VO) pode ser definida como a projeção de um ou mais elementos de 
informações de objetos de empresa (OE). Na figura 6.1, OE1, OE2 e OE3 são objetos de empresa definidos por seus 
elementos de informação (simbolizados por ‘x’) e VO1, VO2, VO3 e VO4 são vistas de objetos definidos em função 
dos objetos de empresa anteriores. Note que neste exemplo OV3=OE3. 
 50 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
x
x
x
x
x
x
x
x
x
x
x x 
x
OE1
VO4
OE2
OE3
VO2
VO1
VO3
Objeto de Empresa Vista de Objetos
x
x
x
x
x
x
x
x
x
VOx
OEw
OEy
Projeção de elementos de 
informação de Objetos de 
Empresa sobre uma Vista
 de Objetos
 
Figura 6.1 - Objetos de empresa e vistas de objeto. 
 
Construtores da Vista de Informação: 
 
Construtor: VISTA DE OBJETO 
Tipo: [categoria relevante – selecionada de uma lista] 
Identificador: [VO -<identificador único>] 
Nome: [nome da classe Vista de Objeto] 
Autoridade de Projeto: [nome da pessoa e departamento com autoridade para projetar e/ou 
manter (ou modificar) esta classe particular] 
DESCRIÇÃO: [descrição textual curta; opcional] 
NATUREZA: [‘Física’ OU ‘Informação’] 
OBJETO PRINCIPAL: [<OE-identificador> / <nome> do Objeto de Empresa do qual as 
propriedades da Vista de Objeto são predominantemente derivadas] 
OBJETOS RELACIONADOS: [ lista [0:n] de <OE-identificador> / <nome> de outros Objetos de 
Empresa as quais a Vista de Objeto retira propriedades] 
PROPRIEDADES: [ lista [1:n] de Elementos de Informação da Vista de Objeto, definido 
como: 
<identificador> “:” <nome do tipo de dado>, OU 
<identificador> “:” <nome da Vista de Objeto>, OU 
<identificador> “:Setof” <cardinalidade> <unicidade> seguido por 
<nome de tipo de dado> ou um <nome da Vista de Objeto>, OU 
<identificador> “:Listof” <cardinalidade> <unicidade> seguido por 
<nome de tipo de dado> ou um <nome da Vista de Objeto>. 
<identificador> é o nome do Elemento de Informação definido pelo 
usuário 
<cardinalidade> :: = “[“<card1> “:” <card2> “]”. 
<card1> é a cardinalidade mínima do conjunto ou da lista (0,1,2, ...), 
<card2> é a cardinalidade máxima (1,2, ...). 
Se <card2> não é conhecido e pode ser grande, ela é representado 
por # 
<unicidade> :: = “EXCLUSIVO” ou NIL indicando se duplicatas foram 
permitidas no conjunto ou lista. Esta é uma cláusula opcional] 
CLÁUSULA DE SELEÇÃO: [ opcional; a cláusula de seleção começa com uma palavra reservada 
“WHERE” e é formada de uma lista de predicados semelhante a 
linguagem SQL (Sequencial Query Language ] 
 
 51 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
 
Construtor: OBJETO DE EMPRESA 
Tipo: [categoria relevante – selecionada de uma lista] 
Identificador: [OE-<identificador único>] 
Nome: [nome da classe Objeto de Empresa] 
Autoridade de Projeto: [nome da pessoa e departamento com autoridade para projetar 
e/ou manter (ou modificar) esta classe particular] 
DESCRIÇÃO: [descrição textual curta; opcional] 
ABSTRAÇÃO DE 
RELACIONAMENTOS : 
[lista de relacionamentos de objetos semânticos na forma: 
 Isa: [lista [0:n] de <OE-identificador> / <nome> de classes de Objeto de 
Empresa que são generalizações desta classe particular. A classe 
Objeto de Empresa sendo definida não pode ser usada] 
 Partof: [lista [0:n] de <OE-identificador> / <nome> de classes de Objeto de 
Empresa do qual esta classe particular é um componente de 
agregação. A classe Objeto de Empresa sendo definida não pode 
ser usada] 
PROPRIEDADES: [obrigatório; lista [1:n] de Elementos de Informação do Objeto de 
Empresa, cada um sendo: 
<identificador> “:” <tipo de dado>, OU 
<identificador> “:” <nome do Objeto de Empresa>, OU 
<identificador> “:Setof” <cardinalidade> <unicidade> seguido por 
<nome de tipo de dado> ou um <nome de Objeto de Empresa>, 
OU 
<identificador> “:Listof” <cardinalidade> <unicidade> seguido por 
<nome de tipo de dado> ou um <nome de Objeto de Empresa>. 
<identificador> é o nome do Elemento de Informação definido pelo 
usuário 
<cardinalidade> :: = “[“<card1> “:” <card2> “]”. 
<card1> é a cardinalidade mínima do conjunto ou da lista (0,1,2, 
...), 
<card2> é a cardinalidade máxima (1,2, ...). 
Se <card2> não é conhecido e pode ser grande, ele é 
representado por # (ilimitado) 
<unicidade> :: = “EXCLUSIVO” ou NIL indicando se duplicatas 
foram permitidas no conjunto ou lista. Esta é uma cláusula 
opcional] 
 
RESTRIÇÕES DE INTEGRIDADE: [ lista [0:n] de <RI-identificador> / <nome> de Restrições de 
Integridade aplicáveis a alguns Elemento de Informação do Objeto 
de Empresa] 
 
 
 
 
 
 52 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
Construtor: RELACIONAMENTO DE OBJETOS 
Tipo: [categoria relevante – selecionada de uma lista] 
Identificador: [RO -<identificador único>] 
Nome: [nome da classe Relacionamento de Objeto] 
Autoridade de Projeto: [nome da pessoa e departamento com autoridade para projetar 
e/ou manter (ou modificar) esta classe particular] 
DESCRIÇÃO: [descrição textual curta;opcional] 
GERADOR: [<OE-identificador> / <nome> da primeira classe de Objeto de 
Empresa] 
RELACIONADO A: [<OE-identificador> / <nome> da segunda classe de Objeto de 
Empresa] 
FUNCIONALIDADE: [ um de: ‘1:1’ OU ‘1:n’ OU ‘n:1’ OU ‘n:n’] 
OBJETO PRINCIPAL: [<OE-identificador> / <nome> do Objeto de Empresa do qual as 
propriedades da Vista de Objeto são primeiramente derivadas] 
 
Construtor: RESTRIÇÃO DE INTEGRIDADE 
Tipo: [categoria relevante – selecionada de uma lista] 
Identificador: [IC -<identificador único>] 
Nome: [nome da classe Restrição de Integridade] 
Autoridade de Projeto: [nome da pessoa e departamento com autoridade para projetar 
e/ou manter (ou modificar) esta classe particular] 
DESCRIÇÃO: [descrição textual curta; opcional] 
OBJETOS DE EMPRESA: [ lista [1:n] de <OE-identificador> / <nome> de Objetos de 
Empresa relacionado pela Restrição de Integridade] 
ELEMENTOS DE INFORMAÇÃO: [ lista [1:n] do <nome> dos Elementos de Informação 
relacionados pela Restrição de Integridade] 
RESTRIÇÃO: [ <predicado> definindo a restrição; texto no nível RDM] 
 
 
Exemplos de Objetos de Empresas e Vistas de Objetos: 
 
VISTA DE OBJETO 
 Identificador: OV-1 
 Nome: Pedido de Cliente Regular 
 Natureza: Informação 
 Objeto Principal: EO-1/Pedido de Cliente Regular 
 Objetos Relacionados: EO-5/Cliente, EO-10/Produto 
 Propriedades: 
 Data do Pedido: Data 
 Elaborado por: String [15] 
 Endereço de Cobrança: Endereço 
 Endereço de Entrega: Endereço 
 Itens: Lista de [1:15] OV-3/Itens Pedidos 
 Comentários: Texto 
 
VISTA DE OBJETO 
 Identificador: OV-3 
 Nome: Itens Pedidos 
 Natureza: Informação 
 Objeto Principal: EO-10/Produto 
 Objetos Relacionados: 
 Propriedades: 
 Item de Referência: String [8] 
 Requisitos Especiais: String [30] 
 Quantidade: Inteiro 
 
 
 
 
 53 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
VISTA DE OBJETO 
 Identificador: OV-10 
 Nome: Lista de Peças 
 Natureza: Informação 
 Objeto Principal: EO-25/Lista de Peças 
 Objetos Relacionados: EO-10/Produto, EO-20/Peça 
 Propriedades: 
 Lista de Peças no.: Inteiro 
 Designação: String [25] 
 Produto no.: String [8] 
 Peças: Lista de [1:#] OV-16/Parte de Item 
 
VISTA DE OBJETO 
 Identificador: OV-40 
 Nome: Plano de Processo 
 Natureza: Informação 
 Objeto Principal: EO-25/Plano de Processo 
 Objetos Relacionados: EO-20/Parte 
 Propriedades: 
 Peça no.: String [8] 
 Designação: String [15] 
 No. da Seção: Inteiro 
 Criado por: String [15] 
 Início do Período: Data 
 Fim do Período: Data 
 Material: String [8] 
 Peso Bruto: Real 
 Peso Líquido: Real 
 Operações. Lista de [1:30] Operação 
 
OBJETO DE EMPRESA 
 Identificador: EO-3 
 Nome: Pedido do Cliente 
 Isa: 
 Parte de: 
 Propriedades: 
 Ref. do Cliente: EO-5 Cliente 
 Data do Pedido: Data 
 Endereço de Cobrança: Endereço 
 Endereço de Entrega: Endereço 
 Elaborado por: String [15] 
 Data de Entrega: Data 
 Situação: (Aberto, Pendente, Atrasado, Aceito, Arquivado) 
 
 
OBJETO DE EMPRESA 
 Identificador: EO-1 
 Nome: Pedido de Cliente Regular 
 Isa: EO-3/Pedido do Cliente 
 Parte de: 
 Propriedades: 
 Itens: Lista de [1:15] EO-200/Itens Pedidos 
 Comentários: Texto 
 
 
OBJETO DE EMPRES 
 Identificador: EO-200 
 Nome: Itens Pedidos 
 Isa: 
 Parte de: EO-1/Pedidos de Cliente Regular 
 Propriedades: 
 Itens de Referência: String[8] 
 Requisitos Especiais: String [30] 
 Quantidade: Integer 
 
 
 54 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
Capítulo 7 - MODELAGEM DE ASPECTOS DE RECURSOS 
 
O objetivo deste capítulo é discutir o papel, características, e tipos de recursos, como encontrado em 
empresas de manufatura e mostrar como eles podem ser modelados para suportar a especificação e execução de 
atividades de empresas. 
 
7.1 PROPÓSITO E ESCOPO 
 
Em um sentido geral, um recurso é qualquer coisa que é requerida para executar algo. Então recursos são 
classificados como: 
• Itens de entrada (peças, produtos, matéria prima, documentos, etc.); 
• Recursos humanos; 
• Recursos tecnológicos (ferramentas máquinas, equipamentos, pacotes de softwares, etc.); 
• Recursos de informação (conhecimento e dados); 
• Recursos financeiros; 
• Recursos de energia; e 
• Tempo. 
 
Neste contexto, não se considera recursos financeiros e energia. Restringi-se o termo ‘recursos’ a mecanismos. Isto 
é, objetos de empresa contribuindo para a realização da funcionalidade de atividades de processos de negócio 
(recursos transformadores, e não recursos transformados, como definidos em entradas e saídas de função de 
atividades em CIMOSA). Então, entrada de sistemas, no sentido de objetos processados, não são considerados como 
recursos mas como entradas de função. Tempo é considerado como um tipo separado de recurso mas não é modelado 
como um objeto de recurso. 
 
Processos de Negócios define ‘o que’ deve ser feito e ‘como’ deve ser feito. Recursos são agentes ou atores 
atualmente fazendo o trabalho. Uma clara separação entre processos e recursos é então necessária no contexto de 
modelagem de empresa porque estes são tipos separados de entidades da empresa. Estes são gerenciados 
diferentemente, e possuem ciclos de vida separados. 
 
As pessoas certas com as adequadas habilidades e competências devem ser alocadas aos trabalhos/operações. A 
seleção de recursos físicos os quais melhor satisfazem ambos critérios econômicos (minimizando custos de compra, 
operação e manutenção) e critérios tecnológicos (exemplo: fornecendo um conjunto ótimo de funcionalidades), deve 
ser cuidadosamente planejado para toda duração da utilização do recurso devido ao investimento de capital 
empregado. 
 
Processos são executados por recursos ativos ou entidades funcionais. A relação entre processos e entidades 
funcionais materializa-se durante um intervalo de tempo através de operações funcionais. A alocação de recursos 
para processar durante o tempo e espaço é um problema de gerenciamento crítico para empresas de manufatura, 
conhecido como problema de programação (scheduling), e é uma questão central no controle de prazos. 
 
Ambas, a seleção de recursos e o desenvolvimento de programas de produção são tarefas extremamente importantes 
na maioria dos tipos de indústria porque eles podem impactar seriamente a produtividade e os custos da empresa. 
 
Por estas razões, modelagem de recursos, ambos em termos de políticas de gerenciamento e capabilidades 
(habilidades) de recursos, é uma questão crucial para a engenharia e gerenciamento da empresa. 
 
Em capítulos anteriores, foram feitas em várias ocasiões uma distinção entre tipos fundamentais de entidades 
funcionais ou recursos ativos de empresas de manufatura: 
• Recursos humanos; 
• Equipamentos e máquinas (incluindo serviços de TI, equipamentos de tecnologia de manufatura, ou outro tipo de 
equipamentos de tecnologia); e 
• Aplicativos (isto é, pacotes de software). 
 
 
Pode parecer irracional para algumas pessoas considerar recursos humanos no mesmo nível de recursos tecnológicos 
ou de software porque gerenciamento de recursos humanos é diferente de gerenciamento de recursostecnológicos. 
Isto é, porém, aceitável do ponto de vista de modelagem de empresa porque durante a fase de definição de requisitos 
da engenharia de empresa, recursos (sejam eles humanos ou máquinas) não são definidos até que a fase de 
especificação de projeto detalhada se inicia. Neste estágio (Definição de Requisitos), recursos são caracterizados 
 55 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
apenas por um conjunto de capabilidades requeridas e por um conjunto de operações funcionais a serem fornecidas. 
Eles são totalmente especificados apenas na fase de descrição de implementação quando seu tipo é definido, sua 
seleção é feita, e seu layout físico ou local é decidido. 
 
Ainda, no nível de definição de requisitos, não são feitas decisões com relação a quais atividades serão 
automatizadas e quais atividades permanecerão manuais. Apenas um papel (o que um recurso pode/deve fazer) em 
termos de é definido em termos de capabilidades necessárias definindo o perfil funcional do recurso. 
 
7.2 – TAXONOMIA DE RECURSOS 
 
7.2.1 – DEFINIÇÕES 
 
Um recurso é uma entidade (humana ou técnica) a qual pode realizar um papel importante na realização de uma certa 
classe de tarefas, quando ele está disponível. 
 
Disponibilidade de um recurso é um mapeamento de intervalos de tempo para o conjunto {disponível, não 
disponível} o qual indica “partes” de tempo quando o recurso pode ser usado. 
 
Capacidade de um recurso é uma medida do número de unidades que o recurso pode processar no tempo. 
 
O papel de um recurso define um subconjunto de ações que um recurso pode oferecer para um dado propósito entre o 
conjunto total de ações possíveis. Um recurso pode ter papéis diferentes durante seu ciclo de vida. 
 
Uma capabilidade é uma habilidade (requerida ou fornecida) para fazer certas tarefas. 
 
7.2.2 – TAXONOMIA GERAL DE RECURSOS 
 
Esta seção tem o objetivo de ilustração. Seu propósito é mostrar que recursos podem ser organizados em 
classes de acordo com sua natureza. Classes genéricas podem ser definidas. Especialização de modelos genéricos 
(parciais ou de referência) pode ser feita. 
 
Exemplo de classes de recursos: 
� Humanos: 
• gerentes 
• engenheiros 
• administradores 
• operadores 
• trabalhadores 
• secretários 
• outros tipos de empregados 
 
� Equipamentos: 
• equipamentos de TI 
• equipamentos de Manufatura 
• equipamentos logísticos 
• outros tipos de equipamentos 
 
� Aplicativos 
• Sistemas de suporte a decisão 
• Pacotes de automação de escritório 
• Pacotes de engenharia 
• CAD 
• CAM 
• CAE 
• CAPP 
• Pacotes de Planejamento da Produção 
• Outros 
 
 
 56 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
Em geral temos: 
Capabilidades humanas: habilidades e competências possuídas, responsabilidades as quais podem ser assumidas, e 
autoridades, as quais podem ser exercidas por seres humanos. 
Capabilidades de máquinas: defini características técnicas, tipos de operações funcionais oferecidas, autonomia de 
máquina, linguagem técnica usada, etc.. 
Capabilidade de Aplicativos: indica o tipo de sistema de operação usado, o número de transações processadas por 
unidade de tempo, o tamanho máximo de documento de dados tratado, etc.. 
 
Por exemplo, habilidades humanas podem ser especializadas em: 
- Capabilidades ou competências intelectuais (Exemplo é ser um engenheiro certificado, ou falar inglês ou francês); 
- Capabilidades físicas (pode jogar futebol); 
- Capabilidades funcionais (possui licença para dirigir caminhões). 
 
7.2.3 - TAXONOMIA DE RECURSOS DE MANUFATURA 
 
Exemplos: 
 
Operadores 
Gerentes/supervisores/administradores 
Qualificados 
Não qualificados 
Máquinas 
Equipamentos de transporte 
Equipamentos de armazenagem 
Equipamentos de teste e controle 
Equipamentos de processamento 
 Equipamentos de Conformação 
 Equipamentos de Material de Corte (Usinagem, Torneamento, ...) 
Equipamentos de Montagem 
Equipamentos de Revestimento/Pintura 
 Outros 
Ferramentas 
 Consumíveis 
 Não Consumíveis 
 
 
 
 
Operadores gerentes Operadores não-qualificados
Operadores qualificados
Operadores
Dispositivos de transporte
Conformação Corte
Revestimento Montagem
Dispositivos de processamento
Dispositivos de armazenamento Dispositivos de controle/teste
Máquinas
Ferramentas consumíveis Ferramentas não-consumíveis
Ferramentas
Recursos de Manufatura
 57 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
7.3 - QUESTÕES SOBRE GERENCIAMENTO DE RECURSOS 
 
Tipos de problemas: 
• Seleção de recursos; 
• Projeto de layout de recursos; 
• Alocação de operações a recursos (minimizar custos); 
• Programação (scheduling) de recursos; 
• Manutenção preventiva e análise de confiabilidade; e 
• Controle de recursos. 
 
Gerenciamento de recursos está sujeito a vários tipos de restrições: 
• Interdependência de recursos; 
• Conflito de prioridades de recursos; 
• Exclusividade de recursos; 
• Limitações na disponibilidade de recursos; 
• Níveis variáveis de disponibilidade de recursos; 
• Limitações na alocação de recursos parciais. 
 
7.4 – CARACTERIZAÇÃO DE RECURSOS 
 
Podemos caracterizar recursos de várias maneiras: 
1. Consumo do recurso: consumível (pode ser renovável) e não-consumível; 
2. Compartilhamento do recurso (uso por diferente usuários e processos), ou não; 
3. Mobilidade do recurso (pode ser fixo, ou pode móvel, ou pode ser transportado); 
4. Autonomia: autônomo, não autônomo, semi-autônomo (poder de decisão) 
5. Pre-emption: capacidade do recurso interromper alguma tarefa, fazer outra e voltar a fazer a tarefa anterior 
(exemplo: pessoas). 
 
 
Conjunto de características que devem ser consideradas por uma técnica de modelagem de empresa para modelar 
aspectos de recursos: 
• Sua identificação 
• Seu tipo 
• Sua natureza (consumível ou não) 
• Sua capacidade 
• Sua disponibilidade (definido como um calendário em dado horizonte de tempo) 
• Seus papéis (cada papel é definido como um conjunto de capabilidades) 
• Sua funcionalidade (definido como um conjunto de operações funcionais) 
• Sua localização 
• Seu compartilhamento (é ou não) 
• Sua mobilidade (fixo, móvel, movível) 
• Pre-emptiness (é ou não) 
• Seu MTBF, MTTR, e sua confiabilidade 
• Seu custo por unidade (de tempo, de distância,..) 
• Seu custo analítico (compra, manutenção e operação). 
 
MTBF – Tempo Médio Entre Falhas 
MTTR – Tempo Médio Para Reparos 
 
Características adicionais podem ser propostas conforme necessidade. 
 
 58 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
Capítulo 8 - MODELAGEM DA VISTA DE RECURSOS COM CIMOSA 
 
Nesta vista, CIMOSA vê a empresa como um conjunto de entidades funcionais interconectadas, as quais 
podem enviar requisições e executar operações funcionais. CIMOSA fornece dois construtores essenciais para 
modelar necessidades em recursos e objetos de recursos de uma empresa: conjunto de capabilidades e recurso. Um 
conjunto de capabilidades é constituído de elementos de capabilidade. Elementos de capabilidade podem referir-
se à funcionalidade de uma atividade de empresa ou de um recurso. Elementos de capabilidade são definidos por um 
nome, um valor e possivelmente uma unidade. As unidades são aquelas do sistema internacional. O conjunto de 
capabilidades é um construtor essencial em CIMOSA para suporte ao princípio de desacoplamento de processos e 
recursos. Este princípio é baseado no fato de que atividades, e portanto processos, requerem capabilidades para sua 
execução enquanto recursos fornecem capabilidades para executar operações funcionais de atividades, com a devida 
capacidade. 
 Em CIMOSA, os recursos são classificados em entidadesfuncionais (EF) e componentes. Componentes 
são recursos passivos (objetos que não proporcionam funcionalidades por si só). Eles precisam ser usados ou 
manipulados por entidades funcionais tornando-se parte de uma entidade funcional agregada. Exemplos típicos são 
ferramentas, equipamentos de medição e veículos dirigidos manualmente. 
Entidades funcionais em CIMOSA são todos recursos ativos capazes de executar operações funcionais de 
uma atividade e fazer algum papel no curso do processo. Um termo similar usado em inteligência artificial é agente 
ou ator. Assim, uma entidade funcional é um recurso ativo dentro ou fora de uma empresa capaz de mandar, receber, 
processar mensagens (requisições ou dados), ou ainda armazenar informações. Ela possui algum grau de autonomia e 
inteligência. Em outras palavras, a entidade funcional tem capacidade de processamento para ser capaz de reagir a 
estímulos enviados para ela na forma de mensagens. Ela precisa ser acessada por meio de algum protocolo externo 
(linguagem). Entidades funcionais são capazes de fornecer capabilidades através de suas operações funcionais. 
Operações funcionais são equivalentes à métodos de um objeto ou agente ativado por mensagens. CIMOSA define 
três tipos fundamentais de entidades funcionais dentro de uma empresa: 
• máquinas, incluindo equipamentos de manufatura (máquinas a controle numérico, robôs, veículos auto-guiados, 
ou equipamentos de armazenagem automatizados) e equipamentos de informação (por exemplo: computadores, 
servidores de banco de dados ou impressoras compartilhadas); 
• aplicativos, isto é, pacotes de software tais como sistemas CAD, sistemas MRP, sistemas de pagamentos, ou 
sistemas de supervisão de célula; e 
• recursos humanos, sendo este o mais importante e mais difícil tipo de entidade funcional a se considerar no 
modelo da empresa. Ele introduz indeterminismo no modelo, porém possui a propriedade de ser capaz de resolver 
problemas no caso de eventos inesperados (não modelados). 
 
 Ainda, alguma combinação de entidades ou uma combinação de um recurso passivo (como uma ferramenta, 
um caminhão transportador, uma máquina de escrever, etc.) com uma entidade funcional, também é uma entidade 
funcional. Por exemplo, uma máquina operada manualmente com seu operador forma uma entidade funcional. Um 
pacote de software instalado em um computador é uma entidade funcional. 
 Assim, entidades funcionais podem se unir para formar entidades funcionais maiores e mais complexas as 
quais podem ser consideradas como um todo. Neste caso, faz-se necessário um equipamento de controle para acessar 
as funcionalidades da entidade funcional agregada. Pode-se distinguir entre agregação temporária, formando um 
 59 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
conjunto de recursos (sendo exemplo, a união entre um motorista e um caminhão) e agregação permanente 
formando uma célula de recursos (sendo exemplo, uma célula de manufatura). 
 Sendo que as entidades funcionais podem ser acessadas por um protocolo externo e são componentes ativos, 
os quais podem receber e/ou mandar mensagens, elas podem interagir. Isto é ilustrado pela figura 8.1, que mostra o 
princípio de transação no modelo cliente/servidor como o mecanismo básico para comunicação entre entidades 
funcionais. 
Envio
Processo
Armazenagem
Recebimento
Canal de 
Comunicação
Requisição 
Resposta
Recebimento
Processo
Armazenagem
Envio
Transações
suportadas pela
Infraestrutura de Integração
Entidade Funcional 1 Entidade Funcional 2
 
Figura 8.1 - Interações entre Entidades Funcionais. 
 
 Unidades de recurso representam recursos particulares, isto é, ocorrências de recursos existentes na 
implementação particular de um sistema. Unidades de recursos podem ser definidos como parte do modelo e 
utilizados como entradas de recurso de algumas classes de atividades de empresa. Neste caso, significa que todas 
ocorrências da classe de atividade serão executadas por esta unidade de recurso. A estrutura do construtor de uma 
unidade de recurso é herdada da estrutura do construtor de recurso, e são adicionadas informações relevantes como: 
localização, capacidade, disponibilidade na forma de um calendário, modo de alocação (FIFO, LIFO, etc.) e outras 
informações dependendo do tipo de recurso. 
 
Construtores da Vista de Recursos: 
 
Construtor: CONJUNTO DE CAPABILIDADES 
Tipo: [categoria relevante – selecionada de uma lista] 
Identificador: [CS -<identificador único>] 
Nome: [nome do Conjunto de Capabilidades] 
Autoridade de Projeto: [nome da pessoa e departamento com autoridade para 
projetar e/ou manter este Conjunto de Capabilidades] 
DESCRIÇÃO: [descrição textual; opcional] 
 
CAPABILIDADES: 
 
[<EO-identificador> / <nome> da primeira classe de Objeto 
de Empresa] 
 
 Relacionadas à Função: [lista [1:n] de Elementos de Capabilidade separados por ‘:’] 
 
 Relacionadas a Objetos: [lista [1:n] de Elementos de Capabilidade separados por ‘:’] 
 
 Relacionadas à Performance: [lista [1:n] de Elementos de Capabilidade separados por ‘:’] 
 
 Relacionadas à Operação: [lista [1:n] de Elementos de Capabilidade separados por ‘:’] 
 
 60 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
Construtor: RECURSO 
Tipo: [categoria relevante – selecionada de uma lista] 
Identificador: [RE -<identificador único> para o componente recurso ou 
FE-<identificador único> para Entidades Funcionais] 
Nome: [nome do Recurso] 
Autoridade de Projeto: [nome da pessoa e departamento com autoridade para 
projetar e/ou manter esta instância particular] 
DESCRIÇÃO: [descrição textual curta; opcional] 
CONJUNTO DE CAPABILIDADES: [ <CS-identificador> / <nome> do Conjunto de 
Capabilidades definindo as capabilidades deste Recurso] 
CLASSE: [ “Entidade Funcional” ou “Célula Organizacional” ou 
“Conjunto de Recursos” ou “Componente de Recurso”] 
CONJUNTO DE OPERAÇÕES: [ lista [0:n] de Operações Funcionais válida para este 
Recurso usando a sintaxe AID. Cada Operação Funcional 
é definida por seu nome FO-nome e seus argumentos de 
entrada e saída como: 
<FO-nome> “(“ “IN” <lista de parâmetros> “,” “OUT” <lista 
de parâmetros> “,” “INOUT” <lista de parâmetros> “)”. Não 
se aplica a Componentes de Recurso] 
VISTA DE OBJETO: [<OV-identificador> / <nome> da Vista de Objeto definindo 
as características (capacidade, disponibilidade, 
localização, etc.) deste Recurso] 
ESTRUTURA 
 PARTE DE: [ lista [0:n] de <FE-identificador> / <nome> de Entidades 
Funcionais das quais este Recurso é um componente ] 
 CONSISTE DE: [ lista [0:n] de <RE-identificador> ou <FE-identificador>/ 
<nome> de instâncias de Recursos que são parte deste 
Recurso ] 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CONJUNTO CAPABILIDADE 
 
Tipo: Programação de Capacidades Humanas 
Identificador: Cs –5 
Nome: Programação-Modif-Capacidades 
Autoridade do projeto: B. Dupont /Engenheiro 
 
CAPABILIDA DES: 
 
Função Relatada: Funções: (avaliar programações, modificar 
programações) 
 
 
Objeto Relatado: Tamanho – Programação: [ - ,100] / * programação 
tem menos que 100 operações* / 
 
Desempenho Relatado: Programação-avaliação- tempo: [- ,10] mn 
 /* estar apto a modificar a programação em menos que 
10 mn */ 
 
 
Operação Relatada: Regras de Prioridade: (SPT, SLACK, RDM, FIFO, 
EDD) 
 61 
Partes de textos traduzidos principalmente do livro Enterprise Modeling and Integration, Principles and Applications (François B. Vernadat) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CONJUNTO CAPABILIDADE 
 
Tipo: Capacidades do Sistema de Chão de Fábrica 
Identificador: CS-6 
Nome: Capacidades de operação do chão de fábrica 
Autoridadedo projeto: B. Dupont / Engenheiro 
 
CAPABILIDA DES: 
 
Função Relatada: Funções: (programar, indicar programação, 
modficar programação, controlar a execução da 
programação) 
 
Objeto Relatado: Tamanho – Programação: [ - ,100] / * programação 
tem menos que 100 operações* / 
 
Desempenho Relatado: Tempo de geração da programação: [- ,3] mn / * ser 
hábil para modificar uma programação em menos 
de 10 mn * / 
 
Operação Relatada: Regras de programadas : (SPT, SLACK, RDM, 
FIFO, EDD) 
RECURSO 
 
Tipo: Célula de Manufatura 
Identificador: FE-200 
Nome: CélulaManufPerfuração 
Autoridade do projeto: B. Dupont /Engenheiro 
 
DESCRIÇÃO: A célula de manufatura é feita por máquinas de 
usinagem e um robô. 
 
CAPABILIDADES: CS-200 / Usinagem-Manuf-Célula-Capabilidades 
 
CLASSE: Célula Recurso 
 
QUANTIDADE: 1 
 
CONJUNTO DE 
OPERA ÇÕES: /* Lista de operações funcionais executáveis pela 
 célula controladora – 
 Pode ser MMS-Like comandos */ 
 
VISTA DE OBJETO: OV-200 / Usinagem-Manuf-Célula 
 
ESTRUTURA 
 PARTE DE 
 CONSISTE DE: FE-300 / ASEA-RB-60,FE-401 / FANUC-RT50, 
 FE-410 / MILLACRON-P20