Modelagem de Sistemas de Informações
242 pág.

Modelagem de Sistemas de Informações


DisciplinaEngenharia de Software I7.113 materiais70.605 seguidores
Pré-visualização50 páginas
que 
descreve detalhadamente as características de cada evento. 
Cada entrada no Dicionário de Eventos é composta de: 
\u2022 Identificador do evento, um número único identificar do evento. Esse número é obrigatório. 
\u2022 Número de seqüência do evento no tempo, se existe. Novamente um número, porém 
indicando a ordem do evento no tempo, se existir. O número é opcional. Vários eventos podem 
possuir a mesma ordem (pois aconteceriam no mesmo intervalo de tempo). 
\u2022 Nome do evento, uma sentença que identifica o evento, de acordo com as regras análise 
essencial. 
\u2022 Descrição do evento, uma descrição mais longa do evento, possivelmente contendo 
informações não essenciais (como a motivação do agente externo), porém que aumentam a 
compreensão do evento. É um resumo do que é o evento. 
\u2022 Classificação do evento (externo (E/NE), temporal (R/A), Não-evento. 
\u2022 Iniciador, o agente externo que envia o estímulo. 
\u2022 Transportador, i.e., quem inserirá os dados no sistema 
\u2022 Dados presentes no estímulo, descritos segundo alguma linguagem de dicionário de dados, 
como a descrita nesse texto. 
\u2022 Atividade, descrição sucinta da atividade, por meio de alguma linguagem. Possivelmente 
uma descrição algorítmica em português estruturado ou como uma seqüência de passos. Uma 
solução interessante e descrever a atividade de acordo com suas pré-condições e pós-condições, 
possivelmente em uma linguagem formal como VDM ou Z. 
\u2022 Informação emitida na atividade, efeito da atividade no ambiente, descrição de cada saída 
do sistema de acordo com uma linguagem de dicionário de dados ou equivalente. 
\u2022 Efeito da atividade no sistema, descrição em linguagem natural ou em outra linguagem das 
modificações que ocorrem no estado global do sistema, ou com entidades específicas, com a 
execução da atividade. Efeitos colaterais das atividades são descritos aqui. Por exemplo: a 
atividade pode cadastrar um cliente na lista de clientes inadimplentes, um efeito seria \u201co cliente 
está proibido de realizar outros gastos na empresa\u201d. 
\u2022 Tempo, limites de tempo do evento, ligado aos eventos esperados, quando devem acontecer. 
\u2022 Lista de entidades utilizadas (tiradas do modelo conceitual de dados), ou Matriz CRUD. 
Esse texto é acompanhado de um software que permite a criação de um dicionário de 
eventos. Na figura a seguir apresentamos a tela para o dicionário. 
 166 
 
Figura 84. Tela de um dicionário de eventos 
 
Figura 85. Tela complementar, indicando as entidades (memórias) 
envolvidas em cada evento. 
VIII.13 Especificando Processos 
O nome de cada processo, incluindo as atividades essenciais, é formado de um verbo 
no infinitivo e de um objeto direto, que indicam como o sistema responde ao evento. 
Exemplos: 
 167 
Evento Atividade 
Gerente solicita relatório de Vendas Emitir Relatório de Vendas 
Aluno solicita boletim Emitir Boletim 
Fornecedor entrega mercadoria Receber mercadoria 
Tabela 24. Nomes de atividades para alguns eventos 
VIII.13.1 Especificação do Tipo Caixa Preta 
A primeira especificação que devemos fazer de um processo ou atividade essencial 
deve enxergar esse processo ou atividade como uma caixa preta. Dessa forma, a descrição 
deve discutir apenas seus efeitos nas memórias e as entradas e saídas dos agentes externos. 
Esta especificação inicial deve ser feita utilizando a linguagem do cliente. 
Por exemplo: 
\u2022 Especificação do Processo \u201cCadastrar Cliente\u201d: 
Após conferir se o CGC é válido, deve registrar as informações passadas pelo cliente na 
memória \u201cCLIENTE\u201d. 
VIII.13.2 Especificação do Tipo Caixa Branca 
A especificação de processo, na modelagem essencial, é chamada de mini-
especificação. Cada processo, e nisso se incluem as atividades essenciais, deve ser 
especificados por meio de uma mini-especificação ou refinado por meio de outro DFD. 
Uma mini-especificação pode ser escrita em português estruturado, usando tabelas ou 
árvores de decisão. Qualquer que seja a linguagem escolhida, deve permitir o entendimento 
claro do que deve ser feito durante aquele processo. 
Por exemplo: 
Especificação do Processo \u201cCadastrar Cliente\u201d: 
o Se CGC é Válido Então 
o Salvar Cliente. 
VIII.13.3 Mini-especificações 
Uma especificação de um processo (mini-especificação) tem como objetivo 
especificar \u201co que\u201d o processo deve fazer (e não como). Uma especificação em português 
estruturado deve ser clara. Em geral, cada empresa ou projeto deve determinar como escrever 
sua mini-especificação. 
Português Estruturado 
Algumas regras básicas: 
\u2022 Toda a lógica deve ser expressa na forma de estruturas seqüenciais, estruturas de decisão, 
estruturas de case, ou iterações. 
\u2022 As palavras chaves devem ser destacadas (negrito ou letras maiúsculas). 
\u2022 Identar claramente os blocos de comando, mostrando sua hierarquia. 
\u2022 Destaque as palavras ou frases definidas no dicionário de dados, para indicar que têm um 
significado específico (sublinhe ou itálico). 
\u2022 Seja atento no uso das condições \u201cou\u201d, \u201ce\u201d, \u201cmaior\u201d, \u201cmaior ou igual". 
 168 
\u2022 Sintaticamente falando: 
\u2022 Uma mini-especificação é composta de uma seqüência de comandos. 
\u2022 Um comando pode ser um comando estruturado ou um comando simples 
\u2022 Um comando estruturado pode ser 
\ufffd Um bloco 
\ufffd Um comando se - então 
\ufffd Um comando se - então - senão 
\ufffd Um comando faça - caso 
\ufffd Um comando faça - enquanto 
\ufffd Um comando repita - até 
\ufffd Um comando para_cada - faça 
\ufffd Outro comando acertado entre o grupo 
\u2022 Um comando simples pode ser 
\ufffd Um comando de atribuição 
\ufffd Um comando de busca em memória 
\ufffd Um comando de escrita em memória 
\ufffd Um comando de leitura na interface 
\ufffd Um comando de escrita na interface 
\ufffd Outro comando acertado entre o grupo 
O importante é manter a consistência. Veja o exemplo a seguir: 
PROCESSO Preparar_Segunda_Via 
INÍCIO 
 LER tipo_pessoa 
 SE tipo_pessoa=\u201dFISICA\u201d ENTÃO 
 INÍCIO 
 LER cpf_pessoa 
 BUSCAR quem EM Contribuinte COM quem.cpf=cpf_pessoa 
 codigo_cont := quem.codigo 
 FIM 
 SENÃO 
 INÍCIO 
 LER cgc_empresa 
 BUSCAR empresa EM Contribuinte COM empresa.cgc=cgc_empresa 
 codigo_cont := empresa.codigo 
 FIM 
 FIM_DO_SE 
 LER ano 
 BUSCAR iptu EM impostos COM iptu.ano=ano E iptu.codigo=codigo_cont 
 169 
 IMPRIMIR iptu 
FIM 
VIII.13.4 O Diagrama de Transição de Estados 
Um diagrama de transição de estados, ou simplesmente diagrama de estados, ou ainda 
DTE, é uma das abstrações mais gerais que temos para um sistema ou objeto. O objetivo de 
um DTE é descrever como um sistema ou objeto muda de estado em função de eventos que 
ocorrem no ambiente, e que respostas estão associadas a cada mudança de estado. 
Diagramas de estados são compostos de dois símbolos básicos: estados (círculos ou 
caixas) e transições (setas). Os estados têm um nome ou um número, enquanto as transições 
são indicadas com um evento, que ativa a transição, e uma saída, provocada pela transição. 
Apesar de sua simplicidade, DTEs são ferramentas muito poderosas para modelagem. 
Podem ser usados de diferentes formas na modelagem essencial: para descrever o 
funcionamento do sistema como um todo ou de parte dele, para descrever os estados 
possíveis de uma entidade. Mesmo uma mini-especificação pode, em alguns casos, ser mais 
bem representada por um diagrama de estados. 
Yourdon [B43] sugere que as seguintes perguntas devem ser feitas para verificar um 
DTE: 
Todos os estados foram definidos? 
Todos os estados podem ser atingidos? 
Todos os estados têm uma saída? 
Em cada estado o sistema reage adequadamente a todos os eventos? 
Existem no mercado diferentes ferramentas, gratuitas ou comerciais, de desenho e 
verificação de DTEs. Existem também outras formas similares de modelagem, como Redes 
de Petri e StateCharts. 
Estado 1
Início
Fim
Estado2
Evento a
Saída 1