mapeando processos de negócios com zackman framework e sbvr

Apresentação Equipe #3

André Rocha Agostinho, 40.820

Herez Moise Kattan, 40.800

Nery Signorini Neto, 35.681

09 de abril de 2013

Temas Abordados na Apresentação

1) Quadros de referência para a Engenharia de Software

• Fornecer modelos apropriados para as colunas 1 (O quê?), 2 (Como?) e 3 (Onde?)das linhas 2 e 3 do Arcabouço de Zackman;

• Fornecer e justificar uma proposta de mapeamento dos elementos das células das colunas data funções da linha 2 para as células correspondentes da linha 3;

• Propor uma sugestão de como migrar RN da linha 2 para a linha 3.

Temas Abordados na Apresentação

2) Regras de negócio e requisitos de software.

• De acordo com o artigo discutido na aula 9, apresentar um conjunto de Regras de Negócio para o exemplo da disciplina assumindo premissas razoáveis.

• Definir parte dos conceitos do domínio do problema segundo o vocabulário SBVR e suplementar alguns deles, quando necessário, com regras de negócio estruturais.

• Definir algumas regras de processos de negócio segundo o SBVR.

• Definir algumas restrições.

• Dar exemplos de como as regras de negócio definidas acima podem afetar o modelo da coluna “dados” e linha 3 da primeira parte.

Exemplo da Disciplina

Objeto do Trabalho:

Sistema de Monitoração de Acúmulo de Águas Pluviais nas Estradas (Sigla: SMAAPE)

Domínio do Problema

• Quando e onde haverá possibilidade de haver acúmulo de água decorrente das chuvas?

• Qual é o nível pluviométrico que represente perigo para a circulação de veículos?

• As equipes de recuperação e sinalização devem ser acionadas quando o nível pluviométrico ultrapassar o considerado “perigoso”;

• O que é considerado perigoso?

• Quais outros valores qualitativos e quantitativos existem?

• O produto de software deverá melhorar a assertividade das previsões futuras de chuvas e de alagamentos;

Domínio do Problema

• Auxiliar no gerenciamento das equipes e frota de manutenção e sinalização nas bases operacionais instaladas nos pontos estratégicos;

• Objetivo é tornar as estradas “mais seguras”;

• O que é ser “mais seguro?”;

• Conexão (troca de dados) permanente com o Centro de Pesquisas Meteorológicos de Sãp Paulo (CMSP);

• Coleta das condições meteorológicas e do nível pluviométrico nas estradas em tempo real;

• Dispositivos/sensores instalados ao longo das estradas;

• Central de Gestão e Monitoração das estradas, evitar acidentes, aumentar proatividade das equipes.

Domínio do Problema – Cont.

Nome Representa Papel

#1 Secretário do Transporte

Governo do Estado, representado pela secretaria de transportePatrocina o projeto

É responsável pelo edital e pelo conteúdo da licitação

É sponsor do projeto, possui decisão final para aprovação do fornecedor

#2 Diretor DER Depto Estradas e Rodagem, responsável pelas estradas do estado

É responsável em analisar o conteúdo da proposta técnica para o produto de software

Stakeholders Identificados


#3 Diretoria Comercial CMSP (Centro de Meteorologia de SP)

Centro Meteorológico de São Paulo, responsável pelas previsões meteorológicas do estado

Definirá os métodos de acesso aos dados

Disponibilizarão informações sobre previsão do tempo para o sistema

#4 Superintendente regional para conservação das estadas

Secretaria responsável pela conservação das estradas

É responsável pela administração do contrato de monitoração das estradas do vencedor da licitação

Stakeholders Identificados – Cont.


#5 Diretor Centro de Manutenção (Base Central – Gestão e Coordenação)

Responsável pelos centros de manutenção espalhados estrategicamente pela rodovia

Definirá requisitos para o gerenciamento e agendamento das equipes de manutenção e sinalização

Faz a gestão da frota e das equipes

#6 Coordenador Centro de Manutenção (Bases Instaladas – Operacionais)

Responsável pelo centro de manutenção específico

Receberá os acionamentos e os boletins do centro de monitoração e enviará equipes aos locais determinados

Stakeholders Identificados – Cont.

Nome Descrição Stakeholder

Analista da Qualidade das Estradas

DER – Responsável por definir premissas e restrições da licitação

Representa o governo como contratante e principal sponsor.

Representa #1 e #2

Meteorologista CMSP

Responsável em disponibilizar informações meteorológicas e previsão pluviométrica para o sistema

Identificará os critérios para que os sistemas sejam integrados

Representa #3

Usuários Identificados

Nome Descrição Stakeholder

Usuário do sistema de monitoração (Gestão)

Responsável pela utilização do sistema e realiza acionamento às equipes de manutenção e sinalização

Central de monitoração e acionamento

Faz parte do ganhador da licitação

Representa #5

Unidade de atendimento (Execução)

Realiza os serviços de reparo, sinalização e ações preventivas.

Executas as ações após acionamento pela central

Representa #6

Usuários Identificados – Cont.

Estrutura do Sistema

IDEF0 do Sistema Nível 0

IDEF0 do Sistema Nível 1

Arcabouço de Zachman


Linha 2

What - Linha 2 – Coluna 1Semantic Model

What - Linha 2 – Coluna 2Business Process Model

What - Linha 2 – Coluna 3Business Logistic System

DB SAAMPE

SensoresEstradas

DB CeMet- SP

DB SAAMPEEstatísticos

Bases Operacionais

Instaladas

HUBSConexões

Central de MonitoramentoE Acionamento da Frota

Sistema SAAMPE

Alertas Boletins Met. Acionamentos

SensoresEstradas

SensoresEstradas

DB SAAMPEConfig. Oper.


Linha 3

What - Linha 3 – Coluna 1Logical Data Model

Rodovia-trecho

Trecho-sensor

UnidadeGestao-UnidadeApoio

What - Linha 3 – Coluna 2Application Architecture

What - Linha 3 – Coluna 3Distributed System Architecture

DB SAAMPE

SensoresEstradas

DB SAAMPE

Estatísticos

HUBSConexões

DB SAAMPEConfig. Oper.

SRVAPPL

1

SRVDB

SRVAPPL

2

SRVAPPL

n

STG

Centro Meteor.

SP

Mapeando Linhas 2 e 3

Mapeamento Proposto Para classificação de risco de alagamento

Risco Descrição Condições de transição

Alto Trechos que devem ser notificados as unidades de gestão

(NP >= 30mm ) ou (PC == 'Alta' e OA > 0)

Médio Trechos que devem ser supervisionados e necessitam atenção

(NP >= 10mm e NP < 30mm) ou (PC == 'Alta' e OA > 0)

Baixo Trechos que não necessitam de atenção

(NP < 10mm) ou (PC != 'Alta‘ e OA == 0)

Neutro Trechos secos Otherwise

NP: Nível pluviométricoOA: Ocorrências anteriores, acidentesPC: Previsão de chuva

Atividades de negócios no diagrama BPMN levam a casos de uso.

Ator Caso de uso Atividades de negócio

Sensor Coletar dados do trecho

- Coletar Informações do Sensor - Verificar sinal com o centro de metrologia - Coletar dados meteorológicos - Armazenar dados coletados

Sistema de monitoramento

Analisar dados do trecho

- Analisar informações coletadas - Classificar risco do trecho

Operador Notificar trecho com risco

- Notificar trechos com risco - Registrar trechos com risco de alagamento

Gestor Notificar unidades de apoio

- Acionar unidades próximas - Registrar trechos com risco de alagamento

Mapeamento Proposto: DadosLinha 2 Coluna 1 para Linha 3 Coluna 1

1 Substantivos são transformados em objetos de negócios como classes;

2. Tipos de valor (como números) são transformados em tipos básicos (boolean, número, texto, etc.);

3. Relações de posse “Tem” são transformados em associações de composição e agregação;

4. Relações de definição “É” são transformadas em herança;

5. Relações como “Envia”, “Mantém” e “Monitora” são transformadas em associações entre classes;

6. A cardinalidade das associações seguem o vocabulário SBVR.

ID Association Name Description

R1

Rodovia-trecho É necessário que uma rodovia tenha ao menos um trecho

R2

Trecho-sensor É necessário que um trecho tenha ao menos um sensor

R3

UnidadeGestao-UnidadeApoio

É necessário que uma unidade de gestão e conservação tenha ao menos uma unidade de apoio

Mapeamento Proposto FunçõesLinha 2 Coluna 2 para Linha 3 Coluna 2

SVBR - Semantics Of Business Vocabulary And Rules

Definição:

É uma especificação da OMG

(www.omg.org/spec/SBVR/1.0)

Usada na definição de regras de negócio (RN) a partir da perspectiva de negócio. A base para se definir RN são as próprias regras do negócio.

Semantics Of Business Vocabulary And Rules(SBVR)

http://www.omg.org/spec/SBVR/1.0

Significado:

•Ontologia terminológica (terminologia formal,vocabulário SBVR): um conjunto de conceitos interconectados para escrever regras de negocio;

•Guia comportamental (políticas, regras, etc.): dirigem as ações dos sujeitos da ontologia terminológica;

•Fornece um meio para possibilitar o processamento da semântica do negócio.

Semantics Of Business Vocabulary And Rules(SBVR)

Regras de Negócio:

• Os dados metereológicos devem ser coletados do Centro de Metereologia do Estado;

• Os dados sobre condições das estradas são coletados de dispositivos situados ao longo das estradas, sobretudo nos trechos em que historicamente ocorrem mais alagamentos;

• Os dispositivos informam, em tempo real, as condições atmosféricas locais, incluindo a temperatura e a umidade.

SBVR – Coletar Dados Meteorológicos

O sistema de monitoração deve coletar do Centro de Metereologia do Estado em tempo real as condições atmosféricas locais, incluindo a temperatura e a umidade.

sistema de monitoraçãoDescription: Sistema de software SMAAPECentro de Metereologia do EstadoConcept Type: implicitly-understood conceptCondições atmosféricas locaisConcept Type: implicitly-understood conceptTemperatura Concept Type: implicitly-understood conceptDefinition: Medido em Grau CelciusUmidadeConcept Type: implicitly-understood concept

SBVR – Coletar Dados Meteorológicos

O sistema de monitoração deve coletar dos dispositivos situados em trechos da estrada em tempo real as condições atmosféricas locais, incluindo a temperatura e a umidade.

Sistema de monitoraçãoDescription: Sistema de software SMAAPEDispositivosSynonym: sensorTrechos da estradaConcept Type: implicitly-understood conceptCondições atmosféricas locaisConcept Type: implicitly-understood conceptTemperatura Concept Type: implicitly-understood conceptDefinition: Medido em Grau CelciusUmidade Concept Type: implicitly-understood concept

SVBR - Coletar Dados das Condições Meteorológicas das Estradas

Regras de Negócio:

• Os dispositivos informam, em tempo real, as condições atmosféricas locais, incluindo a temperatura e a umidade;

• Acionar a central de monitoração;

• Emitir alertas no sistema.

Coletar Dados das Condições Meteorológicas das Estradas

O sistema de monitoração necessita que um trecho da estrada tenha ao menos um dispositivo monitor.

Sistema de monitoraçãoDescription: Sistema de software SMAAPE

Dispositivo monitorSynonym: sensor

Trechos da estradaConcept Type: implicitly-understood concept

SVBR - Trecho Potencialmente PerigosoPremissa

O sistema de monitoração deve considerar um trecho da estrada como potencialmente perigoso se nível pluviométrico maior ou igual a 30 milimetros ou neste trecho da estrada há histórico de alagamento e há previsão de chuva.


Condições atmosféricas locaisConcept Type: implicitly-understood concept

potencialmente perigosoSynonym: alto riscoDescription: (NP >= 30mm ) ou (PC == 'Alta' e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriores

SVBR - Trecho Potencialmente PerigosoPremissa

O sistema de monitoração deve considerar um trecho da estrada como necessita atenção se nível pluviométrico entre 10 e 30 milimetros ou se neste trecho da estrada há histórico de alagamento e há previsão de chuva.


Condições atmosféricas locaisConcept Type: implicitly-understood concept

necessita atenção Synonym: alto riscoDescription: (NP >= 10mm e NP< 30mm) ou (PC == 'Alta' e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriores

SVBR – Trecho necessita atençãoPremissa

O sistema de monitoração deve avisar o coordenador do centro de monitoramento se há trechos da estrada potencialmente perigosos ou se há trechos da estrada que necessitam de atenção.Coordenador do centro de monitoramento

Concept Type: implicitly-understood concept-stakeholdertrecho da estrada potencialmente perigosoSynonym: alto riscoDescription: (NP >= 30mm ) ou (PC == 'Alta' e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriorestrecho da estrada necessita atençãoDescription: (NP >= 10mm e NP< 30mm) ou (PC == 'Alta' e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriores

SVBR -Alertar Centro de MonitoramentoRestrição

O sistema de monitoração deve avisar o coordenador do centro de monitoramento se há falhas.

Sistema de monitoração Description: Sistema de software SMAAPE

Coordenador do centro de monitoramentoConcept Type: implicitly-understood concept-stakeholder

FalhasSynonym:irregularidade, insucesso, imperfeição, erroDefinition: qualquer, toda falha tanto de software quanto de hardwareDescription: SMAAPE deve ser capaz de detectar falhas de software e hardwareNote: SMAAPE deve ter uma interface humano computador que permita ao usuário do SMAAPE identificar falhas no sistema

SVBR – Alertar sobre FalhasRestrição

implicitly-understood concept

Definition: concept that has a designation that is implicitly understood

Description: O significado compreendido é o mesmo da linguagem corrente do termo que representa.

implicitly-understood concept -stakeholder

• Definition: concept that has a definition at PMBOK(2008):

• Description: São pessoas e organizações, como clientes, patrocinadores, organizações executoras e o público, que estejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela execução ou término do projeto. Elas podem também exercer influência sobre o projeto e suas entregas.

SVBR Extensão

Movendo da linha 2 para a linha 3 do Arcabouço de Zachman

Proposta: Movendo da linha 2 para a linha 3

Regra de Negócio – perspectiva de Negócio

• Segundo BRG1, é um guia que possui uma obrigação a respeito da conduta, execução, práticas ou procedimentos de uma particular atividade ou esfera (processo específico) [2]. O objetivo principal é determinar processos desempenhados por humanos e automatizados por sistemas.

• Pela perspectiva do Negócio, as RN possuem a motivação e podem ser foco no processo de automação por TI.

1 Business Rule Group


Regra de Negócio – perspectiva de Negócio

• Podem ser RN Estruturuais (Structural Bus. Rules - verdadeiras em si) e;

• RN Operacionais (Operative Bus. Rules – definição ou restrições).



Regra de Negócio – perspectiva de TI

• Segundo BRG1, RN Persp. TI é uma declaração que limita, que restringe aspectos do negócio.

• Podem ser regras Derivadas (Derivation Rules) definem como a informação será utilizada (ie. Desconto);

• Processos (Process Rules) regras que afetam o processo, gatilhos (ie. Mal pagador) e;

• Restrições (Constrains) regras, restrições – premissas (ie. Respeitar limite de crédito);



Heurística abaixo pode ser aplicada para facilitar o processo de identificação [2]:

• Regras de negócio Estruturais (Business), serão transformadas em regras Derivadas (TI);

• Regras de negócio Operacionais (Bususiness), serão transformadas em regras Processos (TI) ou Restrições (TI)


Exemplo de RN:

RN Estruturais:

1) Os sensores instalados coletam dados em realtime; 2) Bases operacionais estão conectadas online com a

central de monitoração;

RN Operacionais:

3) Mapa de riscos é resultado da estatística + histórico de acidentes no Km, acúmulo de água + previsão meteorológicas daquela região;

4) Alertas do sistema são analisados pela central, que publica boletins, alertas e acionamentos.


RN Estruturais:

1) Os sensores instalados coletam dados em realtime;

• O sistema possui threshold de Nms para garantir que os dados dos sensores estejam sendo coletados, alarme em caso de falha (envio de equipe no local, manutenções);

• Nms é configurado pelo Adm do Sistema.

2) Bases operacionais (clientes) estão conectados online com a central de monitoração;

• O sistema possui controle dos links de comunicação entre as bases e a central, onde é identificado quais bases estão offline, para contingências operacionais (telefone, rádio),


RN Operacionais:

1) Mapa de riscos é resultado da estatística acidentes histórico, acúmulo de água + previsão meteor.;

• Deriva em Processo: O cálculo para estabelecer riscos é oriundo da análise de 3 fatores (% histórico de acidentes no Km; % Vol. Água, Histórico de Alagamentos e Previsão (análise barométrica, volume estiamdo, probabilidade, impacto);

2) Alertas do sistema são analisados pela central, que publica boletins, alertas e acionamentos;

• Deriva em restrição: Após calculado o risco, o sistema emite um alerta e recomendações, Este, para ser válido deverá ser aprovado pelo Coordenador em serviço obrigatoriamente;


Associação:

Estrutural: Os sensores instalados coletam dados em realtime

Estrutural: Bases operacionais (clientes) estão conectados online com a central de monitoração

Funções primárias, automatizadas e monitoradas

Operacional: Mapa de riscos é resultado da estatística acidentes histórico, acúmulo de água + previsão meteor.

Procedimentos/processos traduzidos em funções no sistema;

Operação automatizada;Operacional: Alertas do sistema são analisados pela central, que publica boletins, alertas e acionamentos;

Proposta: Movendo da linha 2 para a linha 3Aplicando so Conceitos

Passos para Aplicação

1) Classificar os RN Negócio (Business Owner Row 2) em: Estruturais ou Operacionais:

2) Aplicar a Heurística Sugerida pelo artigo;

3) As RN Estruturais, são transferidos como funções, programas específicos, ou equipamento que desempenham determinadas funções (de subsistência do sistema) que permite o negócio operar com segurança e integridade;

4) Se faz a relação entre Requisito e Especificação (base para implementação).


Passos para Aplicação

5) Respeitar especificações dos componentes (sensores) utilizados na solução (são restrições de operação e uso);

6) RN Operacionais; são transferidas com base em processos operacionais descritos, comportamentos adotados pelos operadores, cálculos, estatísticas que serão automatizados para auxiliar na tomada de decisão pelos operadores;

7) Buscar processos operacionais, regras, códigos de conduta e outras “diretrizes”.


RN Definidas Afetam o Modelo Dados – Col. 3

1. Regras Estruturais podem adicionar o modelo de dados com restrições e premissas de operação;

2. Criação de funções específicas para subsistência do sistema;

3. Regras Operacional, direcionam a implementação dos processos que se complementam com as ações da operação diária (a primeira reflete a segunda);

4. O modelo de dados é acrescido de mecanismos para suportar ambas as regras;

5. Atenção especial à rastreabilidade dos RN e RS.

Bibliografia

[1] Evaluation of Current Architecture Frameworks, Susanne Leist, Gregor Zellner;

[2] Moving from Zachman Row 2 to Zachman Row 3, Markus Schacher; [2]

http://www.omg.org/mda/mda_files/SanJose.pdf

The Zachman Framework and the OMG’s Model Driven Architecture;

http://www.omg.org/mda/mda_files/09-03-WP_Mapping_MDA_to_Zachman_Framework1.pdf

http://www.ibm.com/developerworks/rational/library/nov06/temnenco/

http://www.hfgilbert.com/rc/Whitepapers/UMLRUPandZachmanBetterTogether.temnenko.pdf

http://heaveniscupcake.blogspot.com.br/2006/10/practical-use-of-zachman-framework-for.html



Dúvidas?

Obrigado!

André, Herez e Nery

mapeando processos de negócios com zackman framework e sbvr

Technology