Aula 6 14042011 sii

Sistemas de Informação para Indústria© António Grilo 2011Departamento de Engenharia Mecânica e Industrial

1

Aula 6Aula 6

MODELAÇÃO DE PROCESSOS E MODELAÇÃO DE PROCESSOS E ESTRUTURA DE INFORMAÇÃO ESTRUTURA DE INFORMAÇÃO

Ano 2011Ano 2011

Sistemas InformaçãoSistemas Informaçãopara a Indústriapara a Indústria

Prof. António GriloProf. António Grilo


2

Processos são uma sequência de factos que conduzem a certo resultado, sendo que esta sequência de actos deverá ser ordenada e orientada para a realização de determinada finalidade. Os processos transformam inputs em outputs, através de mecanismos como sejam pessoas, equipamentos, operações, etc.

Um modelo de processo é um esquema que organiza, ordena e relaciona a forma como as várias fases e tarefas devem ser prosseguidas ao longo do ciclo de vida do sistema. A função principal dum modelo de processo é determinar a ordem das fases envolvidas no desenvolvimento de sistemas e estabelecer os critérios de transição para progredir entre fases

Esta área é designada como Business Process Management

MODELAÇÃO DE PROCESSOS MODELAÇÃO DE PROCESSOS


3

O Business Process Management Initiative (BPMI) desenvolveu 3 módulos para facilitar a standardização de actividade nos sistemas de Business Process Management

• Business Process Modeling Notation (BPMN), que serve como padrão para modelar processos de negócio

• Business Process Modeling Language (BPML), que serve como padrão de linguagem de desenvolvimento

• Business Process Query Language (BPQL), que serve como uma interface padrão de manutenção para a distribuição e execução de processos e-Business.

BUSINESS PROCESS MANAGEMENT BUSINESS PROCESS MANAGEMENT


4

PRINCIPAIS REGRAS DO BPMNPRINCIPAIS REGRAS DO BPMN

-Objectos de Fluxo;

-Conexão de Objectos;

-Swimlanes;

-Artefactos

Quatro categorias básicas de elementos:

Um dos objectivos do BPMN é criar um mecanismo simples para o desenvolvimento dos modelos de processos de negócio e ao mesmo tempo poder garantir a complexidade inerente aos processos.


5

PRINCIPAIS REGRAS DO BPMNPRINCIPAIS REGRAS DO BPMN

-Objectos de Fluxo;

-Conexão de Objectos;

-Swimlanes;

-Artefactos

Quatro categorias básicas de elementos:

Um dos objectivos do BPMN é criar um mecanismo simples para o desenvolvimento dos modelos de processos de negócio e ao mesmo tempo poder garantir a complexidade inerente aos processos.


66

Objecto Descrição Figura

Evento É algo que acontece durante umprocesso do negócio. Estes eventosafectam o fluxo do processo e têmgeralmente uma causa ou um impacto.Há três tipos de eventos, baseados sobrequando afectam o fluxo: Start,Intermediate e End.

Actividade É um termo genérico para um trabalhoexecutado. Os tipos de actividades são:Tarefas e sub-processos. O subprocesso é distinguido por uma pequenacruz no centro inferior da figura.

Gateway É usado para controlar a divergência e aconvergência da sequência de um fluxo.Assim, determinará decisões tradicionais,como juntar ou dividir trajectos.

OBJECTOS DE FLUXOOBJECTOS DE FLUXO


77


Fluxo desequência

É usado para mostrar a ordem(sequência) com que as actividadesserão executadas num processo.

Fluxo demensagem

É usado para mostrar o fluxo dasmensagens entre dois participantesdiferentes que os emitem e recebem.

Associação

É usada para associar dados, texto eoutros artefactos com os objectos defluxo. As associações são usadas paramostrar as entradas e as saídas dasactividades.

CONEXÃO DE OBJECTOSCONEXÃO DE OBJECTOS


88


Pool

Uma pool representa umparticipante num processo. Eleactua como um containergráfico para dividir um conjuntode actividades de outras pools,geralmente no contexto desituações de B2B.

Lane

Uma lane é uma subdivisãodentro de uma pool usada paraorganizar e categorizar asactividades.

SWIMLANESSWIMLANES


99


Objectos dedados

O objecto de dado é um mecanismopara mostrar como os dados sãorequeridos ou produzidos poractividades. São conectados àsactividades com as associações.

Grupo

Um grupo é representado por umrectângulo e pode ser usado parafinalidades de documentação ou deanálise.

Anotações

As anotações são mecanismos parafornecer informações adicionais paraa leitura de um diagrama BPMN.

ARTEFACTOSARTEFACTOS


10

EXEMPLO DE MODELAÇÃO DE PROCESSOSEXEMPLO DE MODELAÇÃO DE PROCESSOSMacro-processo de gestão de incidentes Macro-processo de gestão de incidentes (fonte: trabalho SII, grupo 4, 2007)(fonte: trabalho SII, grupo 4, 2007)


11

EXEMPLO DE MODELAÇÃO DE PROCESSOSEXEMPLO DE MODELAÇÃO DE PROCESSOSMicro-processo de Analisar e Diagnosticar Micro-processo de Analisar e Diagnosticar (fonte: trabalho SII, grupo 4, 2007)(fonte: trabalho SII, grupo 4, 2007)


12

Os indicadores de desempenho têm como principal objectivo quantificar a performance/desempenho de um determinado processo ou modelo de negócio. Estes servem para avaliar o que está bem e o que está mal, de modo a ser mais fácil uma posterior actuação e reengenharia do processo.

Exemplos de indicadores:

• Tempos médios (das actividades)

• Nº de falhas por prazo ou quantidade de tarefas realizadas

• Custos médio do processo

• Nº de pessoas envolvidas

• Nº de casos de excepção

• Nº de Incidentes

INDICADORES CHAVE DE DESEMPENHOINDICADORES CHAVE DE DESEMPENHO(Key Performance Indicators – KPI) (Key Performance Indicators – KPI)


13

A Unified Modelling Language (UML) é uma linguagem para especificação de sistemas. É uma linguagem diagramática, sendo que as especificações podem ser representadas através de diagramas e símbolos gráficos.

A abrangência e relativa facilidade de utilização e integração fez da UML um standard na área de desenvolvimento de sistemas. O suporte documental e de ferramentas de desenvolviemento é vasto e pode ser consultado no site da Object Management Group (OMG), em www.uml.org.

ESTRUTURAÇÃO DE INFORMAÇÃO ESTRUTURAÇÃO DE INFORMAÇÃO


14

O Diagrama de Classes (Class Diagram) da UML está essencialmente vocacionado para representar a componente estrutural de informação de um SI.

O Diagrama de Classes modelam não só a estrutura da informação mas também as operações que manipulam essa mesma informação.

O Diagrama de Classes possibilita desenhar uma base de dados relacional recorrendo a conceitos com um grau de abstração mais elevado e por isso mais próximo do profissional não informático.

Existem algumas ferramentas comerciais e “open source” que suportam esta forma de desenhar base de dados.

DIAGRAMA DE CLASSESDIAGRAMA DE CLASSES


15

Um Objecto (Object) é qualquer coisa relevante, distinta das outras, caracterizada por um conjunto de atributos e sobre os quais podem ser executadas operações.

Exemplo: uma mesa é algo que contém um conjunto de atributos (peso, cor, material, etc.) e sobre a qual podem ser executadas operações / acções (comprar, vender, reparar,etc.)

Os objectos não têm que representar necessariamente coisas com existência física. Os departamentos de uma organização podem ser relevantes para um sistema de informação.

OBJECTOOBJECTO


16

A mesma coisa pode por vezes, numa mesma organização, corresponder a dois objectos diferentes (relativos a 2 sistemas de informação). Um produto num sistema de produção industrial pode ser caracterizado por um conjunto de propriedades físicas, modos de produção e matérias constitutivas. O mesmo objecto físico, num sistema de gestão administrativo pode ser caracterizado por outro tipo de atributos, como por exemplo, o preço, campanhas promocionais, IVA aplicável, etc.

A possibilidade de se poder distiguir um objecto dos restantes é importante. Genericamente todos os objectos são diferentes, nomeadamente através do valor dos atributos.

Exemplo: o cliente João Silva é um objecto caracterizado pelos atributos: nome, morada, NIF, etc. Sobre ele podem ser executadas operações como: facturas, alterar dados, aceitar encomendas, etc.

OBJECTOOBJECTO


17

A Classe (Class) é uma descrição de um conjunto de objectos semelhantes, ou seja, objectos que partilham os mesmos atributos (Attributes), sobre os quais podem ser executadas as mesmas operações/comportamento (Behaviour) e que representam a mesma realidade (semântica).

Não é necessário que todos os objectos possam ser descritos por todos os atributos. No entanto, é necessário que o mecanismo que permite identificar um objecto de uma classe seja válido para todos os objectos dessa classe.

Exemplo: A Classe Cliente representa todos os clientes do SI que partilham o mesmos Atributos (nome, morada, NIF, etc.), o mesmo mecanismo de identificação (o NIF), e sobre os quais podem ser executadas as mesmas Operações (emitir facturas, aceitar encomendas, etc.)

CLASSECLASSE


18

Os objectos não vivem isolados, têm relacionamentos (Relationships) com outros objectos, incluindo de outras classes. Por exemplo, um cliente relaciona-se com as facturas que lhe são emitidas (a classe cliente relaciona-se com a classe facturas).

A UML prevê vários tipos de relacionamentos específicos para captar diferentes realidades. Por exemplo, o tipo de relacionamento entre um cliente e uma factura é diferente do relacionamento entre uma organização e os seus departamentos (um organização é composta por departamentos, mas um cliente não é composto por facturas…)

A UML contempla dois tipos de relações:

- Associações, que podem ser Agregações e Composições

- Generalizações

RELAÇÃORELAÇÃO


19

As Associações (Associations) são a forma privilegiada de representar o relacionamento entre objectos. Elas representam as ligações existentes entre os objectos das classes, impondo algum tipo de restrições.

ASSOCIAÇÃOASSOCIAÇÃO

Cliente

NomeMoradaNIF

Factura

DataValorNº Factura

Facturação Cliente

1..1 0..*

A linha que une as duas classes representa todas as ligações existentes entre os objectos das 2 classes. Os intervalos de valores nos extremos das associações representam a cardinalidade (limite superior e inferior) das ligações entre objectos. Os valores variam entre “ 0 ” (zero) e “ * “ (infinito).


20

Uma Associação, para além de uma leitura semântica – “uma factura tem que estar associada a um cliente” – tem também implícito um aspecto funcional importante: “dado uma factura é possível determinar qual o cliente a quem ela foi facturada”

Normalmente o limite inferior assume o valor 0 (opcional, um cliente pode não ter facturas) ou o valor 1 (obrigatório, uma factura tem que ser de um cliente). Também é normal que o limite superior assuma o valor 1 ( a factura apenas pode ser de um cliente) ou o valor * ( o cliente pode ter muitas facturas).

ASSOCIAÇÃOASSOCIAÇÃO


21

1. “UM para MUITOS” – exemplo: um funcionário só pode trabalhar em um departamento e em um departamento podem trabalhar muitos funcionários.

CARDINALIDADE DAS ASSOCIAÇÕESCARDINALIDADE DAS ASSOCIAÇÕES

Departamento

SiglaDesignação

Funcionário

NomeMoradaTrabalha

1..1 1..*


22

1. “MUITOS para MUITOS” – exemplo: uma pessoa pode ser sócia de muitos clubes, e um clube pode ter muitos sócios


Clube

SiglaDesignaçãoMorada

Sócio

Numero SócioNomeData Admissão

Sócio

0..* 0..*


23

1. “UM para UM” – exemplo: uma factura só pode dizer respeito a uma encomenda e uma encomenda não pode dar origem a mais de uma factura.


Encomenda

DataValorNº EncomendaData Entrega

Factura

DataValorNº Factura

Factura Encomenda

1..1 0..1


24

Decidir se uma determinada entidade deverá ser representada através de um atributo ou de uma classe nem sempre é uma decisão simples.

ATRIBUTOS vs CLASSESATRIBUTOS vs CLASSES

Disciplina

SiglaDesignaçãoSemestre

Docente

NomeLecciona

1..1 0..1

Disciplina

SiglaDesignaçãoSemestreDocente

ou

Quando é necessário armazenar mais informação sobre o docente, e essa informação for utilizada por outra associação, então não poderá ser criado apenas um atributo “Docente” na classe Disciplina.

Por outro lado, caso seja necessário validar a informação de entrada na classe Disciplina então deveremos sempre associar uma classe


25

À semelhança das classes, as associações também podem ser caracterizadas por atributos. As Classes Associativas são associações que assumem algumas características das classes (i.e. serem caracterizadas por atributos ou associarem-se a classes), mas que se mantêm associações, nomeadamente em termos do mecanismo de identificação das suas instâncias (ligações).

CLASSES ASSOCIATIVASCLASSES ASSOCIATIVAS

Encomenda

DataValorNº EncomendaData Entrega

Factura

CódigoDesignaçãoPreço

Produtos Encomendados

0..* 0..*

Encomenda

Quantidade


26

Apesar de a maioria das associações serem binárias (associam 2 classes), por vezes na representação de um determinado domínio de aplicação pode ser necessário recorrer a associações n-árias. No entanto, estas tendem a ser substítuidas por duas associações binárias.

ASSOCIAÇÕES ASSOCIAÇÕES NN-ÁRIA-ÁRIA

Espectáculo

DataDescriçãoTipo EspectáculoDuração

Tipo Lugar

Tipo LugarDescrição

0..* 0..*

Tipo Bilhete

Tipo BilheteDescrição

Tarifário

Preço


27

A Generalização é uma relação que permite representar a noção de pertença ou especificidade de objectos. As classes representam conjuntos de objectos que partilham informação e comportamentos. No entanto, nesse conjunto dos objectos poderão existir subconjuntos que partilhem informação específica, não relevante para os restantes objectos.

GENERALIZAÇÕESGENERALIZAÇÕES

Sócio

Nº SócioNomeData AdmissãoMorada

Organização

Ramo ActividadeCapital SocialNº Funcionários

Individual

Data NascimentoSexoEstado Civil


28

Uma Base de Dados (Database) consiste em informação armazenada de um forma estruturada. No Modelo Relacional a informação é estruturada em relações, também designadas por Tabelas.

Uma Tabela é um conjunto de linhas (registos) e colunas (campos) em que as colunas correspondem aos atributos sobre os quais pretendemos armazenar valores, e as linhas são os valores que neles armazenamos.

MODELO RELACIONALMODELO RELACIONAL

Nº Cliente Nome Morada Telef. Móvel

1 João Alves R. Ernesto Cardoso, nº 25 938665985

2 Ana Lopes Av. Roma, 65, 3ªEsq 966689311

3 Luís Nuno

4 David Barbosa Travessa Midaros, 10, R/c 919020900


29

Todas as Tabelas têm associadas uma propriedade fundamental – uma Chave Primária (Primary Key) – que consiste num forma única de identificar uma linha da tabela. Normalmente essa forma implica designar um atributo cuja função é a identificação (atributo chave). No entanto, a Chave Primária pode ser composta por mais que um atributo chave.

As Base de Dados relacionais são mantidas por programas informáticos designados Sistemas de Gestão de Base de Dados – SGBD (Database Management System – DBMS). Para além dos mecanismos de facilitação de consultas e manutenção dos dados, têm um conjunto de funcionalidades para garantir a integridade dos dados. Nomeadamente, a manutenção da Chave Primária permite evitar que sejam introduzidos numa tabela dois registos com o mesmo valor no(s) atributo(s) chave.

CHAVE PRIMÁRIACHAVE PRIMÁRIA


30

A escolha dos atributos que vão ser utilizados como chave primária por vezes não é imediata, nomeadamente quando existem várias possibilidades (ex. BI, NIF, Nº Cliente). Como critérios gerais de escolha da Chave Primária:

- Atributos de Preenchimento obrigatório (se um registo não poder ser preenchido então atributo não poderá ser chave primária)

- Atributos familiares ao utilizadores (facilidade de preenchimento)

- Domínio numérico (rapidez e evitar confusão)

- Apenas um atributo (eficiência da SGBD)

CHAVE PRIMÁRIACHAVE PRIMÁRIA


31

No modelo relacional considera-se que as tabelas estão devidamente estruturadas quando é possível cruzar a informação considerada relevante.

CRUZAMENTO DE INFORMAÇÃOCRUZAMENTO DE INFORMAÇÃO

Nº Escola Nome Morada Telefone

1 Escola A+B R. Tomás, 34 21212121

2 Escola A + C R. Luís, 54 212334456

Tabela Escolas

Nº Evento Descrição Data Hora

12 Leitura 8-Dez-05 11:00

24 Comemoração 25-Abr-06 15:00

Tabela Eventos

Nº Escola

1

2


32

Uma chave estrangeira é um conjunto de atributos cujo domínio consiste nos valores de atributos de outra tabela (normalmente nos atributos que compõem a chave primária da outra tabela).

O facto de um atributo fazer parte de uma chave estrangeira não significa que ele seja de preenchimento obrigatório. Apenas se tiver um valor diferente de NULL (em BD NULL significa a ausência de valor num atributo) é que o valor vai ser confrontado com os valores existentes na outra tabela.

CHAVE ESTRANGEIRACHAVE ESTRANGEIRA

Nº Evento Descrição Data Hora

12 Leitura 8-Dez-05 11:00

24 Comemoração 25-Abr-06 15:00

Tabela Eventos

Nº Escola

1

2

Chave Estrangeira


33

Sempre que existe uma chave estrangeira é necessário indicar ao SGBD o que fazer quando é anulado, ou alterado um registo na tabela que contém os atributos que são chave estrangeira noutra tabela.

No modelo relacional, para além da indicação das chaves primárias e estrangeiras, relativamente aos atributos é possível indicar outras propriedades para além do nome e do tipo de dados, nomeadamente:

- Indicar se o atributo admite ou não o valor NULL

- Indicar se o valor do atributo é único ou admite duplicados

- Restringir o domínio de valores válidos através de regras simples com operadores lógicos

- Valor por omissão (default)

- Comentários

MANUTENÇÃO DE INTEGRIDADE DA CHAVE ESTRANGEIRAMANUTENÇÃO DE INTEGRIDADE DA CHAVE ESTRANGEIRA


34

A grande maioria das aplicações informáticas é suportada por linguagens com capacidade para manipular informação armazenada no modelo relacional, nomeadamente através da linguagem Structured Query Language – SQL.

A linguagem SQL não manipula classes nem reconhece os conceitos de classes da UML. Assim, é necessário transpor o diagrama de classes para uma base de dados relacional. Algumas ferramentas permitem fazer essa transposição automáticamente.

As regras transposição do modelo de classes para o modelo relacional asseguram que i) não ocorre pedra da informação, i.e. é possível aceder a toda a informação; ii) não existe informação redundante no modelo relacional

MAPEAMENTO ENTRE O DIAGRAMA DE CLASSES E O MODELO MAPEAMENTO ENTRE O DIAGRAMA DE CLASSES E O MODELO RELACIONALRELACIONAL


35

Pressuposto:

Todas as tabelas deverão ter uma chave primária. No caso de não existirem na tabela atributos que satisfaçam esta condição dever-se-á criar um identificador único

Regra 1 – Classes

Todas as classes e associações do tipo “muitos para muitos” dão origem a tabelas, e nada mais dá origem a tabelas. As tabelas não têm de ter a mesma designação das classes ou associações que lhes deram origem

Regra 2 – Atributos das Classes

Todos os atributos de uma classe são atributos da tabela que implementa a classe

REGRAS DE MAPEAMENTOREGRAS DE MAPEAMENTO


36

Regra 3 – Atributos de Associações

Todos os atributos de uma associação são atributos da tabela que ou

i) implementa a associação ou

ii) herda as chaves primárias das restantes tabelas que implementam as classes envolvidas na associação

Regra 4 – Associações do tipo “Um para Um”

As tabelas que implementam os argumentos da associação herdam a chave primária da(s) outra(s) tabela(s) como chave estrangeira



37

Regra 5 – Associações do tipo “Um para Muitos”

A tabela cujos registos são susceptíveis de serem relacionados com apenas um registo da outra tabela (lado muitos) herda como chave estrangeira da(s) tabela(s) cuja correspondência é unitária (lado um)

Regra 6 – Associações do tipo “Muitos para Muitos”

A associação dá origem a uma nova tabela representativa da associação e a chave primária é composta pelos atributos chave das tabelas que implementam as classes associadas


Aula 6 14042011 sii

Documents

Transcript of Aula 6 14042011 sii