Modelagem de Processos com IDEF0

Documentos relacionados
IDEF0 - Método de Representação de Processos em Forma de Fluxo

Ciência da Computação. Análise e Projeto Orientado a Objetos UML. Anderson Belgamo

MODELAGEM DE SISTEMAS

Introdução à Programação. João Manuel R. S. Tavares

S15 - Engenharia de Requisitos continuação cap.6

Introdução à Programação

UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos

UML (Unified Modelling Language)

Aula 4B. Lógica e Algoritmos. Profª. Fabiany

Algoritmos e Programação

Introdução ao Conceito de Algoritmo e Programação Estruturada

SISTEMAS DE INFORMAÇÕES DIAGRAMA DE FLUXO DE DADOS

Diagrama de Atividades

TÉCNICAS DE RACIONALIZAÇÃO DE PROCESSOS

Professor Emiliano S. Monteiro

Panorama da notação UML

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

UML Relacionamentos. Relacionamento é uma conexão entre itens A maioria dos itens relacionam-se entre si. Quatro tipos de relacionamentos:

Capítulo 5 Modelação do Sistema 1

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

2. Criação de Algoritmos

TerraLAB Laboratório para Modelagem e Simulação de Sistemas Terrestres Departamento de Computação - UFOP

Diagramas. Abordaremos agora cada um destes tipos de diagrama: 1. Diagrama Use-Case. 2. Diagrama de Colaboração. 3. Diagrama de Sequência

MODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro

27/08/2013. Aula 05 Análise Estruturada de Sistemas

UML e seus diagramas

Introdução à Programação

DMS - DOCUMENTO DE MODELAGEM DE SISTEMA VERSÃO: [NOME DO SISTEMA] [SIGLA] [AUTORES]

Introdução. Diagramas de Interação. Introdução. Introdução. Introdução. Introdução. Os modelos de análise não respondem a algumas perguntas:

UML. Modelando um sistema

Rational Unified Process (RUP)

Curso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML

UM CATÁLOGO DE BOAS PRÁTICAS, ERROS SINTÁTICOS E SEMÂNTICOS EM MODELOS BPMN

Desenho Técnico. Aula 03. Normalização, Normas Técnicas ABNT

Engenharia de Software

Modelagem de Sistemas Web. Modelagem de BD

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução a UML (Unified Modeling Language)

(ADMINISTRAÇÃO GERAL. Organização, Sistemas e Métodos. Gestão de Processos Parte 4. Prof.ª Karen Estefan Dutra

Prof. M.e Livaldo dos Santos. Unidade II PLANEJAMENTO OPERACIONAL: RECURSOS HUMANOS E FINANÇAS

Princípios de Análise e Projeto Orientados a Objetos com UML

INTRODUÇÃO. Principais diferenças entre processos, atividades e tarefas

Prática interdisciplinar em desenvolvimento de software I

Sintática: como é escrito cada elemento da linguagem de programação.

Organização e Arquitetura de Computadores I

INFORMÁTICA APLICADA AULA 02 ALGORITMOS

6 IMPLEMENTAÇÃO DO MODELO DE REFERÊNCIA

Padrões. Arquitetura de Software Thaís Batista

4) Defina o que vem a ser um algoritmo, e porque, o mesmo depende do processo.

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos

OS&M Unidade 05 Fluxograma

Diagrama de Classes. Régis Patrick Silva Simão. Régis Simão Diagrama de Classes 1/42

Prof. Jorge Cavalcanti

UFU-FACOM Documento de Requisitos <Nome do Sistema>

Apresentação do Capítulo 4 MDA (Model-Driven Archtecture) ALUNO: DOMENICO SCHETTINI FILHO NÚMERO USP:

3 Arquitetura MVC baseada em modelos

Resumo parcial da Tese de Doutorado. Um modelo de Sistema de Gestão do Conhecimento para grupos de pesquisa e desenvolvimento.

09/10/2013. Conteúdo dessa aula

SOCIEDADE PARANAENSE DE ENSINO E TECNOLOGIA SPET PROGRAMA DE EVOLUÇÃO CONTÍNUA DE QUALIDADE. ES 60 DISCIPLINA: Engenharia de Software II

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

A Anatomia de um Programa SAS

Processo nº. 1 Análise do fluxograma FLUXOGRAMA

1 Introdução. 1.1.Motivação

Visões Arquiteturais. Visões Arquiteturais

Modelagem de Processos. Rômulo César

Universidade Federal de Uberlândia Faculdade de Computação. Conceitos básicos de algoritmos Prof. Renato Pimentel. Computação

ADMINISTRAÇÃO GERAL. Abordagem Neoclássica da Administração Decorrências da Teoria Neoclássica Processo Administrativo - Organização - Parte 2

Modelagem de Tarefas

Análise e projeto de sistemas

UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO CURSO: CIÊNCIA DA COMPUTAÇÃO. Prof.ª Danielle Casillo

Analista de Sistemas S. J. Rio Preto

SISTEMA DE GESTÃO ERP

Engenharia de Requisitos

INF1013 MODELAGEM DE SOFTWARE

Aula 01 Conceito de Banco de Dados e SGBD

ESTRUTURA DE DADOS. Arvore Binária Jose. Arvore Ternaria Direção

Modelagem de Casos de Uso

INF1013 MODELAGEM DE SOFTWARE

Análise de Sistemas 4º Bimestre (material 3)

Fluxogramas de processo

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Engenharia de Software. UML Unified Modeling Language

Laboratório de Programação 1 Algoritmos e a Lógica de Programação

2 Fundamentação Teórica

Requisitos de Software e UML Básico. Janaína Horácio

Análise de Requisitos

Modelo Conceitual Parte 1 Banco de Dados I Prof. Luiz Antônio Vivacqua C. Meyer

Engenharia de Software

Generalização das técnicas de Piloto Automático para VANTs. Aluno: Raphael da Silva Teixeira (ED 14205) Professor: Cel R/R Cícero Garcez

Sistemas de PROFA. LILLIAN ALVARES FACULDADE DE CIÊNCIA DA INFORMAÇÃO

SSC Engenharia de Software. Prof. Paulo C. Masiero

Tópicos da Aula. Alguns Diagramas UML. Diagramas Principais. Diagramas de Interação: Sequência e Colaboração. Tipos de Diagramas de Interação

O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do Processo Unificado.

Banco de Dados. Aula 3 - Prof. Bruno Moreno 26/08/2011

(ADMINISTRAÇÃO GERAL. Organização, Sistemas e Métodos. Gestão de Processos Parte 1. Prof.ª Karen Estefan Dutra

Universidade Veiga de Almeida Algoritmos e Linguagem I

APÊNDICE D Unified Model Language (UML)

Transcrição:

Modelagem de Processos com IDEF0 Luiz Lourenço de Mello Filho Mestre em Economia Empresarial pela Universidade Candido Mendes e em Computação Aplicada e Automação pela Universidade Federal Fluminense, Professor do CASI Curso de Pós-graduação em Gestão Empresarial e Sistemas de Informação da Universidade Federal Fluminense e dos Curós de Graduação e Pós-graduação da Escola de Direito da Fundação Getulio Vargas RJ. A Metodologia IDEF0 1 INTRODUÇÃO Um fluxograma, é uma representação gráfica de um processo, mostrando a seqüência de passos, tarefas ou atividades, em termos de alguns símbolos ou ícones padrões de um fluxograma. É um desenho de como uma equipe faz determinado trabalho. O padrão mais utilizado para uma representação de um fluxograma durante a modelagem conceitual é o IDEF0. Esta "linguagem" foi desenvolvida a partir de uma necessidade da força aérea americana, que trabalhava com diversas indústrias aeroespaciais. Como cada uma destas indústrias trabalhava de sua maneira, era difícil controlar e documentar todos esses processos. Estudos foram feitos para que se tivesse uma linguagem que compreendesse vários critérios e atendesse todas estas indústrias. Em 1972, foi desenvolvido o SADT (Structered Analysis and Design Technique) por Douglas T. Ross, da SoftTech, que foi escolhido para uso no projeto AFCAM (Air Force Computer Aided Manufacturing). Em seguida foram desolvidos o ICAM I e o ICAM 2. O ICAM 2 foi documentado e renomeado como IDEF0. 2 IDEF0 IDEF (Integration Definition for Function Modeling) é uma família integrada de métodos para modelagem baseada em representações de diagramas, incluindo uma larga variedade de técnicas. Todas estas técnicas estão formalizadas no FIPS (Federal Information Processing Standarts). O IDEF0, que é o primeiro conjunto de padrões do IDEF, processa uma coleção de atividades e outras ações utilizando-se de ICOMs (Input Control Output Mechanism). Cada processo representado no modelo possui "terminais" para que possa ser alimentado ou alimentar outros processos. Esses "terminais" recebem o nome de entrada, controle, saída e mecanismo. A entrada recebe o dado a ser convertido pelo processo, o controle significa a restrição de como e quando a entrada deve ser processada e executada, a saída apresenta o resultado de como a entrada foi processada e o mecanismo representa os recursos utilizados para executar esta atividade (pode ser uma pessoa, equipamento, máquina ou outras organizações). O modelo funcional IDEF0 é composto por um conjunto de setas e caixas. Cada processo, atividade ou função é conceitualmente representada por uma caixa retangular. Cada atividade pode ser decomposta em vários níveis. Estes subníveis seguem as mesmas convenções. Portanto um modelo completo de IDEF0 é uma representação hierárquica do processo composta por atividades ou funções em quantos níveis forem necessários. 1

2.1 Sintaxe e Semântica Os componentes estruturais e características de uma linguagem e os regulamentos que definem as relações entre eles são chamados da sintaxe da linguagem. Os elementos básicos que constituem um diagrama IDEF0 são simples construções gráficas, tais como caixas, linhas e setas. Caixas representam funções, atividades e processos. Setas representam objetos ou dados relacionados com as caixas. E temos também algumas regras de como esses componentes são utilizados. As caixas são retangulares, desenhadas com linhas sólidas. É incluído um nome ou uma frase para a caixa e também é dado um número único para a mesma. Desta maneira, caixas são simples representações gráficas que formam os elementos básicos do diagrama. Eles podem representar a atividades, ações ou tarefas. Estas caixas informam o que acontece em determinada função. Uma caixa básica é mostrada na figura 2. As linhas são sólidas e curvadas nos cantos, apenas possuem orientação vertical ou horizontal, são conectadas aos lados de cada caixa e são nomeadas por substantivos. As linhas (com setas) são usadas para conectar as caixas. No diagrama elas representam objetos ou dados do sistema. Estes objetos ou dados serão usados ou produzidos por atividades nas caixas. As linhas com setas não representam fluxo ou seqüência como num modelo de fluxo tradicional. Elas indicam objetos ou dados que são utilizados pelas funções. Alguns exemplos mais comuns são mostrados na figura 3. As caixas devem ser descritas com verbos ou frases e são divididas ou agrupadas em diagramas. As linhas podem ser agrupadas em feixes, mas as setas deverão ser nomeadas, a fim de indicar qual a sua utilidade. Cada lado de uma caixa tem um padrão de significado em termos da relação entre caixas e setas. Setas entrando no lado esquerdo são entradas. As entradas são utilizadas pela função para produzirem determinada saída. Setas entrando no lado de cima, indicam controle. Controles especificam as condições de como a função deve gerar a saída correta. Setas deixando a caixa pelo lado direito indicam saídas. Saídas são dados ou objetos produzidos pela função. Setas conectadas na parte inferior da caixa representam mecanismos. Setas entrando indicam quem é o responsável pela execução desta função. Setas saindo indicam chamadas. As chamadas são utilizadas para que haja o compartilhamento de detalhes entre caixas. 2.2 Diagramas IDEF0 O modelo IDEF0 é composto por três tipos de informação: diagramas, texto e glossário. Estes tipos de diagrama são referenciados entre si. O diagrama gráfico é o mais extenso componente do modelo de IDEF0, contendo os elementos básicos: caixas e linhas com setas. Caixas representam cada função macro de um sistema. Estas funções são quebradas ou decompostas em outras caixas para haver um maior detalhamento do diagrama, até que a tarefa seja descrita num nível suficiente que suporte as metas de um projeto. O nível superior do diagrama no modelo provém a mais geral ou resumida descrição da tarefa representada por este modelo, como visto na figura 4. 2

Este diagrama é seguido por uma série de diagramas filhos provendo maiores detalhes sobre determinada tarefa. Cada modelo possui um nível superior, no qual cada tarefa do modelo é representada por uma simples caixa com suas linhas e setas. Isto é chamado de diagrama A- 0. As setas neste diagrama indicam a interface entre o mundo externo e este diagrama. Desde que uma simples caixa representa o assunto completo, o nome escrito nesta caixa deve ser geral. O mesmo é verdadeiro para a interface entre as setas utilizadas, desde que elas representem um conjunto completo de agentes externos. As características deste nível expressam a razão pela qual o modelo é criado e atualmente determinam a estrutura do modelo. A mais importante característica que vem primeiro na hierarquia é o nível superior. Este é decomposto em sub-funções que as compõem. Estas partes são decompostas em outras sub-funções até todos os detalhes relevantes do projeto como um todo sejam adequadamente expostos. Cada sub-função é modelada individualmente por uma caixa, com caixas pai detalhadas por diagramas filho no mais baixo nível. A função representada no nível superior pode ser decomposta em outras sub-funcões pela criação de diagramas filho. Por outro lado, estas sub-funções podem ser novamente decompostas em outras sub-funções. Cada Diagrama filho contém caixas e setas que fornecem detalhes adicionais a respeito da função que as originou. Na figura 5 é apresentado um exemplo de como esses diagramas de nível superior e diagramas pai e filho são utilizados. Um diagrama pode ser associado por um texto estruturado, que é usado para fornecer uma visão resumida do diagrama. Este texto dever ser usado para destacar certas caraterísticas, fluxo e conexões entre caixas a fim de esclarecer o intuito destes itens. O texto não deve ser usado para simplesmente descrever, redundantemente, as caixas e setas. Um glossário deve ser usado para definir significados de expressões ou palavras-chave que foram usadas nos diagramas gráficos. O glossário define palavras no modelo e deve conter uma explicação conveniente para que haja a correta interpretação do conteúdo do modelo. 2.3 Conceitos Fundamentais A metodologia original IDEF0 incorpora conceitos básicos listados a seguir. 2.3.1 Representação gráfica As "caixas" e "setas" de um diagrama IDEF0 mostram atividades como caixas, e as interfaces entrando ou saindo das caixas, como sendo "setas". Para que se tenha uma real visualização de um conjunto de atividades, as caixas podem ser interpretadas como sendo operadas juntamente com outras, com as interfaces (setas) indicando quando e como são disparadas e controladas. 2.3.2 Consistência A documentação de uma arquitetura de modelagem de fluxo deve ter consistência suficiente para permitir descrever todo o processo. Utilizar um texto escrito em linguagem ordinária é claramente insuficiente. 3

2.3.3 Comunicação Há diversos conceitos IDEF0 que são designados para melhorar a comunicação. Os diagramas IDEF0 são simples arranjos de caixas e setas. Deste modo qualquer pessoa que não tenha conhecimento profundo dos conceitos de IDEF0, pode ler e entender um diagrama IDEF0. Outra característica que facilita o entendimento de um diagrama é a exposição gradual de detalhes, caracterizando uma hierarquia com as funções principais no nível superior e os demais sub-níveis revelando todos os detalhes inerentes a tal diagrama. O detalhamento em cada nível não deve conter mais do que 6 atividades (caixas) e não menos do que 3. Isso se deve ao fato que se um diagrama contém mais do que 6 caixas, estará apresentando um detalhamento excessivo neste nível. Para uma rápida visualização, este diagrama fica incompreensível. Então algumas caixas deverão ser reunidas em uma, e o detalhamento do que esta única caixa irá fazer, deverá ser apresentado num nível inferior. E a respeito de um diagrama conter menos que 3 caixas, deve-se ao fato de que há poucos detalhes a serem descritos, então podemos reunir essas caixas em apenas uma. Essa última regra só é quebrada, quando estamos falando no primeiro diagrama principal, que deve conter somente uma caixa, generalizando todo o processo. Para que se tenha um perfeito entendimento de um diagrama, o mesmo deve conter texto e glossário escritos no diagrama no qual eles são utilizados. Isto permite que tal diagrama não tenha uma interpretação errada ou dúbia. 4

2.4 Exemplo de Diagrama IDEF0 Supondo que seja desejado que se faça uma descrição de como fazer um sanduíche com bacon, alface e tomate, para se descrever todo o sistema é necessário começarmos pelo nível superior do mesmo. Este é apresentado na figura 6. Neste diagrama, o controle é o desejo por um sanduíche. Tem-se entradas para os ingredientes básicos. E os mecanismos aqui são os utensílios domésticos. Este primeiro diagrama é bom para um bom entendimento do sistema por completo, mas não apresenta muitos detalhes sobre o sistema. A codificação A0 que está representada abaixo da caixa, diz a nós que existe um diagrama "filho". A entrada que representa os ingredientes no nível superior é quebrada em três diferentes ingredientes: pão, alface e tomate. A outra entrada, dos condimentos, agora é vista como maionese. A seqüência é óbvia no diagrama, mas está implícito que o bacon frito é necessário para se completar o sanduíche, com isso é necessário que seja frito e checado se ele está pronto antes de usá-lo. Desta maneira a presença de bacon controla a caixa 2 e o bacon já frito controla a caixa 4. As ferramentas são vistas como uma frigideira e uma faca. A figura 7 traz ingredientes que são adicionados ao pão. O diagrama "filho" é mostrado na figura 8. Na figura 8 é detalhado o processo de união de todos os ingredientes para termos o sanduíche acabado. Este diagrama é composto do diagrama do nível superior mais dois digramas para prover maior detalhamento. =-=-=-=-=-=-=-= 5