1. O documento discute modelagem de processos e estruturação de informação, incluindo Business Process Management e a linguagem BPMN para modelagem de processos de negócio. 2. Apresenta os principais elementos do BPMN como objetos de fluxo, conexões, swimlanes e artefatos. 3. Discutem indicadores-chave de desempenho para avaliar processos e a linguagem UML para modelagem de estrutura de informação, incluindo diagramas de classes.

1. Aula 6 MODELAÇÃO DE PROCESSOS E ESTRUTURA DE INFORMAÇÃO Ano 2011 Sistemas Informação para a Indústria Prof. 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

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

4. PRINCIPAIS 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 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.

6. OBJECTOS DE FLUXO Objecto Descrição Figura Evento É algo que acontece durante um processo do negócio. Estes eventos afectam o fluxo do processo e têm geralmente uma causa ou um impacto. Há três tipos de eventos, baseados sobre quando afectam o fluxo: Start, Intermediate e End. Actividade É um termo genérico para um trabalho executado. Os tipos de actividades são: Tarefas e sub-processos. O sub processo é distinguido por uma pequena cruz no centro inferior da figura. Gateway É usado para controlar a divergência e a convergência da sequência de um fluxo. Assim, determinará decisões tradicionais, como juntar ou dividir trajectos.

7. CONEXÃO DE OBJECTOS Objecto Descrição Figura Fluxo de sequência É usado para mostrar a ordem (sequência) com que as actividades serão executadas num processo. Fluxo de mensagem É usado para mostrar o fluxo das mensagens entre dois participantes diferentes que os emitem e recebem. Associação É usada para associar dados, texto e outros artefactos com os objectos de fluxo. As associações são usadas para mostrar as entradas e as saídas das actividades.

8. SWIMLANES Objecto Descrição Figura Pool Uma pool representa um participante num processo. Ele actua como um container gráfico para dividir um conjunto de actividades de outras pools , geralmente no contexto de situações de B2B. Lane Uma lane é uma subdivisão dentro de uma pool usada para organizar e categorizar as actividades.

9. ARTEFACTOS Objecto Descrição Figura Objectos de dados O objecto de dado é um mecanismo para mostrar como os dados são requeridos ou produzidos por actividades. São conectados às actividades com as associações. Grupo Um grupo é representado por um rectângulo e pode ser usado para finalidades de documentação ou de análise. Anotações As anotações são mecanismos para fornecer informações adicionais para a leitura de um diagrama BPMN.

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

11. EXEMPLO DE MODELAÇÃO DE PROCESSOS Micro-processo de Analisar e Diagnosticar (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 DESEMPENHO (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

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 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. OBJECTO

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. OBJECTO

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.) CLASSE

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ÇÃ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ÇÃO Cliente Nome Morada NIF Factura Data Valor Nº 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ÇÃ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ÇÕES Departamento Sigla Designação Funcionário Nome Morada Trabalha 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 CARDINALIDADE DAS ASSOCIAÇÕES Clube Sigla Designação Morada Sócio Numero Sócio Nome Data 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. CARDINALIDADE DAS ASSOCIAÇÕES Encomenda Data Valor Nº Encomenda Data Entrega Factura Data Valor Nº 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 CLASSES Disciplina Sigla Designação Semestre Docente Nome Lecciona 1..1 0..1 Disciplina Sigla Designação Semestre Docente 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 ASSOCIATIVAS Encomenda Data Valor Nº Encomenda Data Entrega Factura Código Designação Preç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 N -ÁRIA Espectáculo Data Descrição Tipo Espectáculo Duração Tipo Lugar Tipo Lugar Descrição 0..* 0..* Tipo Bilhete Tipo Bilhete Descriçã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ÇÕES Sócio Nº Sócio Nome Data Admissão Morada Organização Ramo Actividade Capital Social Nº Funcionários Individual Data Nascimento Sexo Estado 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 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Á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Á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ÇÃO Tabela Escolas Tabela Eventos Nº Escola Nome Morada Telefone 1 Escola A+B R. Tomás, 34 21212121 2 Escola A + C R. Luís, 54 212334456 Nº Evento Descrição Data Hora 12 Leitura 8-Dez-05 11:00 24 Comemoração 25-Abr-06 15:00 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 ESTRANGEIRA Tabela Eventos Chave Estrangeira Nº Evento Descrição Data Hora 12 Leitura 8-Dez-05 11:00 24 Comemoração 25-Abr-06 15:00 Nº Escola 1 2

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 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 RELACIONAL

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 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 REGRAS DE MAPEAMENTO

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 REGRAS DE MAPEAMENTO