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
Nome Representa Papel
#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.
Nome Representa Papel
#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
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.
Arcabouço de Zachman
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)
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.
Sistema de monitoraçãoDescription: Sistema de software SMAAPE
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.
Sistema de monitoraçãoDescription: Sistema de software SMAAPE
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
Proposta: Movendo da linha 2 para a linha 3
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).
1 Business Rule Group
Proposta: Movendo da linha 2 para a linha 3
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);
1 Business Rule Group
Proposta: Movendo da linha 2 para a linha 3
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)
Proposta: Movendo da linha 2 para a linha 3
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.
Proposta: Movendo da linha 2 para a linha 3
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),
Proposta: Movendo da linha 2 para a linha 3
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;
Proposta: Movendo da linha 2 para a linha 3
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).
Proposta: Movendo da linha 2 para a linha 3Aplicando so Conceitos
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”.
Proposta: Movendo da linha 2 para a linha 3Aplicando so Conceitos
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
Top Related