Este documento apresenta os detalhes de uma apresentação sobre engenharia de software realizada por três estudantes. Apresenta os temas abordados, incluindo quadros de referência para engenharia de software e regras de negócio e requisitos de software. Fornece exemplos de um sistema de monitoramento de acúmulo de águas pluviais em estradas para ilustrar os conceitos, incluindo stakeholders, estrutura do sistema, modelo de dados e regras de negócio definidas usando SBVR.
1. Apresentação Equipe #3
André Rocha Agostinho, 40.820
Herez Moise Kattan, 40.800
Nery Signorini Neto, 35.681
09 de abril de 2013
2. 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.
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.
4. Exemplo da Disciplina
Objeto do Trabalho:
Sistema de Monitoração de Acúmulo de
Águas Pluviais nas Estradas (Sigla: SMAAPE)
6. 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;
7. Domínio do Problema – Cont.
• 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.
8. Stakeholders Identificados
Nome Representa Papel
#1 Secretário do Governo do Estado, É responsável pelo edital
Transporte representado pela e pelo conteúdo da
secretaria de transporte licitação
Patrocina o projeto
É sponsor do projeto,
possui decisão final para
aprovação do
fornecedor
#2 Diretor DER Depto Estradas e É responsável em analisar
Rodagem, responsável o conteúdo da proposta
pelas estradas do estado técnica para o produto
de software
9. Stakeholders Identificados – Cont.
Nome Representa Papel
#3 Diretoria Comercial Centro Meteorológico de Definirá os métodos de
CMSP (Centro de São Paulo, responsável acesso aos dados
Meteorologia de SP) pelas previsões
meteorológicas do Disponibilizarão
estado informações sobre
previsão do tempo para
o sistema
#4 Superintendente Secretaria responsável É responsável pela
regional para pela conservação das administração do
conservação das estradas contrato de monitoração
estadas das estradas do
vencedor da licitação
10. Stakeholders Identificados – Cont.
Nome Representa Papel
#5 Diretor Centro de Responsável pelos Definirá requisitos para o
Manutenção (Base centros de manutenção gerenciamento e
Central – Gestão e espalhados agendamento das
Coordenação) estrategicamente pela equipes de manutenção
rodovia e sinalização
Faz a gestão da frota e
das equipes
#6 Coordenador Centro Responsável pelo centro Receberá os
de Manutenção (Bases de manutenção acionamentos e os
Instaladas – específico boletins do centro de
Operacionais) monitoração e enviará
equipes aos locais
determinados
11. Usuários Identificados
Nome Descrição Stakeholder
Analista da Qualidade DER – Responsável por Representa o governo
das Estradas definir premissas e como contratante e
restrições da licitação principal sponsor.
Representa #1 e #2
Meteorologista CMSP Identificará os critérios
para que os sistemas
Responsável em sejam integrados
disponibilizar informações
meteorológicas e Representa #3
previsão pluviométrica
para o sistema
12. Usuários Identificados – Cont.
Nome Descrição Stakeholder
Usuário do sistema de Responsável pela Faz parte do ganhador
monitoração (Gestão) utilização do sistema e da licitação
realiza acionamento às
equipes de manutenção Representa #5
e sinalização
Central de monitoração
e acionamento
Unidade de atendimento Realiza os serviços de Executas as ações após
(Execução) reparo, sinalização e acionamento pela
ações preventivas. central
Representa #6
26. Mapeamento Proposto
Para classificação de risco de alagamento
Risco Descrição Condições de transição
Alto Trechos que devem ser (NP >= 30mm ) ou (PC == 'Alta' e OA > 0)
notificados as unidades de
gestão
Médio Trechos que devem ser (NP >= 10mm e NP < 30mm) ou (PC == 'Alta'
supervisionados e necessitam e OA > 0)
atenção
Baixo Trechos que não necessitam de (NP < 10mm) ou (PC != 'Alta„ e OA == 0)
atenção
Neutro Trechos secos Otherwise
NP: Nível pluviométrico
OA: Ocorrências anteriores, acidentes
PC: Previsão de chuva
27. Mapeamento Proposto: Dados
Linha 2 Coluna 1 para Linha 3 Coluna 1
Ator Caso de uso Atividades de negócio
Sensor Coletar dados do - Coletar Informações do Sensor
trecho - Verificar sinal com o centro de metrologia
- Coletar dados meteorológicos
- Armazenar dados coletados
Sistema de Analisar dados do - Analisar informações coletadas
trecho - Classificar risco do trecho
monitoramento
Operador Notificar trecho com - Notificar trechos com risco
risco - Registrar trechos com risco de alagamento
Gestor Notificar unidades de - Acionar unidades próximas
apoio - Registrar trechos com risco de alagamento
Atividades de negócios no diagrama BPMN levam a casos de uso.
28. Mapeamento Proposto Funções
Linha 2 Coluna 2 para Linha 3 Coluna 2
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- É necessário que uma unidade de gestão e
UnidadeApoio conservação tenha ao menos uma unidade de apoio
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.
30. Semantics Of Business Vocabulary And Rules
(SBVR)
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.
31. 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.
32. SBVR – Coletar Dados Meteorológicos
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.
33. 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ção
Description: Sistema de software SMAAPE
Centro de Metereologia do Estado
Concept Type: implicitly-understood concept
Condições atmosféricas locais
Concept Type: implicitly-understood concept
Temperatura
Concept Type: implicitly-understood concept
Definition: Medido em Grau Celcius
Umidade
Concept Type: implicitly-understood concept
34. SVBR - Coletar Dados das Condições Meteorológicas
das Estradas
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ção
Description: Sistema de software SMAAPE
Dispositivos
Synonym: sensor
Trechos da estrada
Concept Type: implicitly-understood concept
Condições atmosféricas locais
Concept Type: implicitly-understood concept
Temperatura
Concept Type: implicitly-understood concept
Definition: Medido em Grau Celcius
Umidade
Concept Type: implicitly-understood concept
35. 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.
36. SVBR - Trecho Potencialmente Perigoso
Premissa
O sistema de monitoração necessita que um trecho
da estrada tenha ao menos um dispositivo monitor.
Sistema de monitoração
Description: Sistema de software SMAAPE
Dispositivo monitor
Synonym: sensor
Trechos da estrada
Concept Type: implicitly-understood concept
37. SVBR - Trecho Potencialmente Perigoso
Premissa
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ção
Description: Sistema de software SMAAPE
Condições atmosféricas locais
Concept Type: implicitly-understood concept
potencialmente perigoso
Synonym: alto risco
Description: (NP >= 30mm ) ou (PC == 'Alta' e OA > 0)
Note: NP = nível pluviométrico
PC = previsão de chuva
OA = ocorrências anteriores
38. SVBR – Trecho necessita atenção
Premissa
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ção
Description: Sistema de software SMAAPE
Condições atmosféricas locais
Concept Type: implicitly-understood concept
necessita atenção
Synonym: alto risco
Description: (NP >= 10mm e NP< 30mm) ou (PC == 'Alta' e OA > 0)
Note: NP = nível pluviométrico
PC = previsão de chuva
OA = ocorrências anteriores
39. SVBR -Alertar Centro de Monitoramento
Restrição
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-stakeholder
trecho da estrada potencialmente perigoso
Synonym: alto risco
Description: (NP >= 30mm ) ou (PC == 'Alta' e OA > 0)
Note: NP = nível pluviométrico
PC = previsão de chuva
OA = ocorrências anteriores
trecho da estrada necessita atenção
Description: (NP >= 10mm e NP< 30mm) ou (PC == 'Alta' e OA > 0)
Note: NP = nível pluviométrico
PC = previsão de chuva
OA = ocorrências anteriores
40. SVBR – Alertar sobre Falhas
Restriçã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 monitoramento
Concept Type: implicitly-understood concept-stakeholder
Falhas
Synonym:irregularidade, insucesso, imperfeição, erro
Definition: qualquer, toda falha tanto de software quanto de
hardware
Description: SMAAPE deve ser capaz de detectar falhas de
software e hardware
Note: SMAAPE deve ter uma interface humano computador que
permita ao usuário do SMAAPE identificar falhas no sistema
41. SVBR Extensã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.
43. 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
44. 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
45. 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
46. 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)
47. 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:
1) Mapa de riscos é resultado da estatística + histórico
de acidentes no Km, acúmulo de água + previsão
meteorológicas daquela região;
2) Alertas do sistema são analisados pela central, que
publica boletins, alertas e acionamentos.
48. 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),
49. 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;
50. Proposta: Movendo da linha 2 para a linha 3
Associação:
Estrutural: Os sensores instalados
coletam dados em realtime
Funções primárias,
automatizadas e
Estrutural: Bases operacionais (clientes) monitoradas
estão conectados online com a
central de monitoração
Operacional: Mapa de riscos é
resultado da estatística acidentes
histórico, acúmulo de água + previsão Procedimentos/processos
meteor. traduzidos em funções no
sistema;
Operacional: Alertas do sistema são
analisados pela central, que publica Operação automatizada;
boletins, alertas e acionamentos;
51. Proposta: Movendo da linha 2 para a linha 3
Aplicando 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).
52. Proposta: Movendo da linha 2 para a linha 3
Aplicando 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”.
53. Proposta: Movendo da linha 2 para a linha 3
Aplicando 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.
54. 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