Análise Essencial de Sistemas com Orientação a Objetos
Plena consultoria e planejamento em informática ltda
ã Plena Consultoria
Rua da Consolação, 2697 - 5° andar - São Paulo - SP - 01416-001
Telefone (011) 852-1333 • Fax (011) 852-0013
e-mail plena@ibm.net
A Captação da Essência	4
A Formação do Pessoal de Sistemas	4
A Cultura do Usuário	5
A Comunicação Analista X Usuário	5
A Documentação	6
Modelos	6
Ferramentas de Modelagem	7
Ferramentas de Modelagem Tradicionais	7
Fases do Desenvolvimento de Sistemas	8
Tabela de Produtos	13
Modelagem de Eventos	14
Algoritmo para Modelagem de Eventos	14
Eventos Relacionados	14
Determinando o Contexto do Sistema	15
Eventos Externos e Eventos Internos	15
Fluxos de Dados e Eventos	16
Documentando o Modelo Ambiental	16
Produzindo o MER a partir da Lista de Eventos	18
Eventos Custodiais	19
Anatomia do Processo Essencial	20
Derivando o Modelo de Processos	20
Nivelando o Modelo de Processos	21
O Conceito de Nivelamento	21
Balanceando o Modelo	22
Balanceando entre Projeções	23
Balanceamento entre Níveis	24
Capítulo	28
Orientação a Objetos	28
Estrutura em camadas	28
Conceitos básicos	29
Objetos Compostos. 31
Polimorfismo	32
Critérios para encontrar objetos de negócio	33
Objetos de Negócio a partir do MER	33
Capítulo	35
Especificação de Composição de Dados	35
Especificação de Elemento de Dados	36
Especificação de Entidade	37
Especificação de Relacionamento	37
Especificação de Objetos	39
Especificação de Processo	39
Considerações sobre Especificação de Processo	41
Expressões e Operadores	42
Funções	42
Recebendo e Enviando Fluxos de Dados	42
Criando e Removendo Ocorrências de Objeto	43
Encontrando uma Ocorrência do Objeto	44
Seleção	44
Construções de Repetição	44
Capítulo	46
Os sistemas com os quais nós trabalhamos podem ser classificados como "Sistemas de Resposta Planejada" e possuem as seguintes características:
Há uma necessidade ou oportunidade de negócio que precisa ser atendida no mundo real; o sistema surge como resposta a essa necessidade ou oportunidade.
Todo sistema tem uma finalidade específica: o que o sistema faz, e armazena, está diretamente relacionado com essa finalidade.
Os sistemas têm de fornecer respostas previsíveis: há um conjunto de regras que o sistema deve obedecer, no sentido de responder a eventos externos ao sistema, de acordo com sua finalidade.
Os sistema são transferíveis: as regras que os regem precisam ser escritas de modo que os sistemas possam ser transferidos de um processador para outro, quer ele seja automatizado ou humano.
A fronteira do sistema é caracterizada pelas entradas/origens dos dados e pelas saídas/destinos das informações; a determinação da "fronteira" de um sistema é uma boa ferramenta para caracterizá-lo.
O interior do sistema consiste de atividades e de dados armazenados, que são as engrenagens que respondem a eventos externos, de acordo com as finalidades do sistema.
A essência do sistema independe da tecnologia utilizada para implementá-lo. Por exemplo: o sistema de contas correntes do Banco do Brasil é o mesmo desde sua fundação há mais de um século. O que tem mudado, muito rapidamente, é a tecnologia de implementação do sistema.
A Captação da Essência
O trabalho de análise de um sistema consiste em conseguir captar a sua essência: os fatos que ocorrem fora do sistema que causarão uma ação do sistema como resposta. Esse trabalho deve procurar filtrar todas as condições e características de implementação, em busca da sua essência. Essencial é aquilo que o sistema deve ter. Se não tiver, o sistema não conseguirá atingir seus objetivos.
A Formação do Pessoal de Sistemas
Em geral, os profissionais de informática são formados em Economia, Administração de Empresas, Engenharia, etc.. Em seus cursos de graduação tiveram contato com a informática em temas como Cálculo Numérico.
A formação efetiva desses profissionais dá-se por "osmose" dentro das empresas, por troca de "experiências" com profissionais mais tarimbados. Quando há treinamento, este é executado pelo fabricante do equipamento utilizado e em ferramentas de software existentes e utilizadas na instalação. Dessa forma, depois de alguns anos, o profissional é promovido à categoria "senior" e possui vasto conhecimento em softwares básico, habitualmente denominados por três ou quatro letras. As técnicas de análise de sistemas, de levantamento de dados, de projeto de sistemas, de codificação e de testes praticadas são aquelas que os outros já praticavam.
Aliado a esse fato, existe outro: o profissional de informática, em geral, é fortemente reacionário e resistente a novas técnicas que causem qualquer mudança em sua rotina diária e em seu comportamento pessoal.
Não podemos esquecer que a informática é uma ciência nova, que está em constante e rápida evolução.
Como promotor da entrada da tecnologia na empresa, o profissional de informática não deve ser ele próprio reativo às novas tecnologias.
A Cultura do Usuário
Os usuários têm a formação de acordo com sua área de atuação. Assim, é claro que o Departamento Jurídico está repleto de advogados, a Contabilidade é formada por contadores e o Departamento Financeiro é comandado por economistas.
Os usuários, ao longo dos anos, têm tido algumas más experiências com a informática. Sistemas desenvolvidos para eles que não funcionaram adequadamente, sistemas que nunca ficaram prontos, sistemas que não se adaptam às mudanças em sua área, sistemas que acabam acrescentando trabalho ao seu dia-a-dia. Apesar disso, ele ainda acredita na informática e quer, cada vez mais, apoio de sistemas em suas atividades. O difícil é conseguir que o pessoal lá da informática o atenda. Por isso vemos, com tanta freqüência, usuários montando verdadeiros "CPDs" paralelos para terem um mínimo de apoio informatizado em seus negócios.
A Comunicação Analista X Usuário
Os usuários conhecem o problema, os negócios, muito melhor que os analistas. Os analistas conhecem técnicas para resolver os problemas. O trabalho de análise deve produzir uma solução para o problema. Geralmente a linguagem do usuário é impregnada de termos do vocabulário técnico do assunto do problema que os analistas não entendem completamente. Por outro lado, ao expor a solução, os analistas utilizam uma linguagem técnica derivada do "informatiquês" que o usuário desconhece.
A qualidade da solução é fortemente influenciada pela qualidade de sua validação pelos usuários. Será que nós entendemos corretamente o problema? Será que a solução é viável?
É importante que o trabalho seja feito em conjunto e que se utilize de vocabulário próprio, comum a todos os participantes. Analistas e usuários trabalhando no mesmo time, em busca da melhor solução. Trabalhar junto leva ao entendimento, à melhor comunicação e à sinergia.
Para possibilitar essa comunicação há a necessidade de documentarmos o entendimento obtido. Essa documentação servirá de base, num momento posterior, ao trabalho de manutenção do sistema já instalado.
Para que a documentação seja útil, é importante que ela seja produzida durante o trabalho, que seja completa e que esteja atualizada. Uma documentação desatualizada não serve para nada.
Sistemas com documentação incompleta ou desatualizada precisam de "arqueólogos", especialistas que vasculham fragmentos de código, arquivos e "dumps" com o objetivo de construir hipóteses a respeito de "pra que serve isso?" no sistema. Além dos "arqueólogos", o sistema precisará ser atendido por "pediatras", profissionais que são chamados a qualquer hora, principalmente de madrugada ou aos fins de semana, toda vez que o sistema "passa mal".
Um modelo é uma representação abstrata de algo real. O modelo tem o objetivo de imitar a realidade para possibilitar que esta seja estudada quanto ao seu comportamento.
Tradicionalmente, a engenharia tem empregado modelos em escala, plantas, desenhos de circuitos, protótipos.
O uso de modelos torna o estudo mais barato e seguro: é muito mais rápido e barato construir um modelo que construir a "coisa real".
O objetivo do modelo é mostrar como será o sistema, para permitir sua inspeção e verificação, de modo a poder receber alterações e adaptações antes de ficar pronto.
Qualquer modelo realça certos aspectos do que está sendo modelado em detrimento de outros.
A ferramenta que usamos para modelar influi diretamente na forma como pensamos sobre a realidade e determina quais aspectos serão mostrados e quais ficarão escondidos.
Para modelarmos sistemas, necessitamos de ferramentas com as seguintes características:
Gráficas, com apoio de textos, como um mapa: legíveis, concisas e padronizadas. A parte gráfica particiona o sistema em componentes interrelacionados, sem as restrições de um texto linear. A parte textual descreve os componentes e suas interconexões;
Particionáveis, do geral para o específico, como um atlas geográfico, tornando o modelo mais fácil de entender. Precisamos ser capazes de ter a visão geral do sistema sem nos preocuparmos com detalhes e, termos a visão do detalhe sem perdermos a noção do todo;
Rigorosas, como as escalas de uma planta. O modelo do sistema deve ser preciso, sem erros, incompletudes e redundâncias. Mas deve ser flexível, fácil de mudar, pois o sistema está sempre em constante evolução;
Capazes de predizer o comportamento do sistema, como um protótipo. O modelo deve ser capaz de nos dizer o que é bom e o que é ruim no sistema, em termos objetivos, antes que o sistema seja implementado. O modelo deve nos permitir simular o comportamento do sistema.
Capazes de mostrar os aspectos críticos do sistema, como fotos de vários ângulos, com simplicidade. Cada modelo deve ser uma projeção do sistema em um espaço simplificado.
Ferramentas de Modelagem Tradicionais
As ferramentas tradicionais de modelagem de sistemas levam a modelos redundantes, contraditórios e difíceis de checar quanto à sua completude e precisão. É necessário que utilizemos ferramentas de modelagem substancialmente diferentes daquelas anteriormente utilizadas pelos métodos tradicionais.
O Desenvolvimento de sistemas com Análise Essencial se dá sempre de maneira a se obter mais conhecimento e qualidade a cada passo, através de refinamentos sucessivos. O primeiro passo é construir o Modelo do Ambiente do sistema, composto pelo Diagrama de Contexto e pela Lista de Eventos Externos. A finalidade desse modelo é determinar a abrangência do sistema pela especificação dos eventos que motivam a sua ação, das entradas e suas origens e das saídas e seus destinos.
A partir da Lista de Eventos Externos, do Modelo do Ambiente, deve ser construído o Modelo do Comportamento do sistema, que especifica de que forma o sistema é estruturado em termos de dados e funções para atingir aos objetivos estabelecidos e para responder aos eventos do Modelo do Ambiente. A Figura SDS 1 - O desenvolvimento de sistemas com Análise Essencial, mostra o contexto do desenvolvimento de sistemas visto, ele próprio, como um sistema.
O desenvolvimento de sistemas interage com o pessoal de informática, que detém o conhecimento da tecnologia de automação; com o usuário, responsável pela definição dos objetivos e restrições do sistema e profundo conhecedor do assunto e do ambiente do sistema. A empresa é a beneficiária do trabalho, recebendo o produto do desenvolvimento: o sistema.
A Figura 0 - Desenvolver Sistemas, mostra os dois principais processos do desenvolvimento de sistemas.
A Figura 1 - Criar o Modelo Essencial detalha o processo de modelagem essencial. Em primeiro lugar fazemos a modelagem do Ambiente do Sistema: a quais eventos externos o sistema deve responder; quais os fluxos de dados fornecidos pelo ambiente ao sistema; de onde vêm esses dados; quais as informações que o sistema deve produzir; quem são os usuários dessas informações.
A partir do Modelo do Ambiente é derivado o Comportamento do Sistema: quais são as estruturas de dados, os objetos de negócio, quais são os processos internos do sistema necessários para garantir que o sistema atinja seus objetivos, através da ativação dos métodos dos objetos de negócio.
A Figura 1.1 - Modelar o Ambiente do Sistema, mostra que essa tarefa é feita pela determinação do Contexto do Sistema e pela identificação de Eventos Externos. Essas tarefas são executadas em conjunto, uma subsidiando a outra.
A figura 1.2 - Derivar o Comportamento do Sistema - ilustra que essa tarefa é constituída de quatro partes: A modelagem dos dados, a modelagem das atividades essenciais, a modelagem dos objetos de negócio e a especificação dos detalhes em um dicionário de dados.
A Figura 2 - Derivar o Modelo de Implementação, consiste, em primeiro lugar, na determinação do Modelo de Processadores, onde as atividades essenciais são alocadas a processadores, que são os agentes que executarão cada uma das atividades implementadas, fisicamente(entenda-se, aqui, por exemplo, computadores e pessoas); na derivação do Modelo de Tarefas, onde as atividades são organizadas, por processador, em seqüências ou grupos de operação que fazem trabalho útil para o usuário (tarefas), e na derivação do Modelo de Arquitetura de Código, onde as mesmas atividades são divididas em objetos ou módulos funcionais (dependendo do ambiente de hardware), com o máximo de coesão interna e o mínimo de interdependência entre módulos.
Usando o Modelo de Processos do Sistema de Desenvolvimento de Sistemas (SDS), representamos abaixo os produtos conseguidos com as técnicas.
ModelodeAmbiente
. Lista de Eventos. Diagrama de Contexto. Especificação Estímulos/Saídas
Modelo deComportamento
. Modelo de Dados DER + DD . Mod. Atividades DFD + Minispecs
Modelo de Processadores
. DFD de Processadores. Diálogos. Protótipos
Modelode Tarefas
. Jobs. Procedures. Transações p/ Tarefas Automatizadas
Modelo de Arquitetura de Código
. Projeto de Objetos
Modelagem de Eventos
A construção do Modelo Ambiental se dá através da Definição do Contexto do Sistema e da Modelagem da Lista de Eventos Externos.
Um evento externo é algo que ocorre no ambiente (fora dos limites do sistema) e que provoca uma resposta do sistema, como conseqüência. Um evento pode ser sinalizado por um fluxo de dados ou ser localizado em um determinado instante no tempo.
Analisar eventos é, basicamente, identificar fatos que ocorrem no meio ambiente que interage com o sistema e que exigem uma resposta do mesmo. Esta resposta pode ser, por exemplo, o armazenamento de uma informação ou a produção de um resultado.
Algoritmo para Modelagem de Eventos
Analise o ambiente do sistema e ponha no papel todo fato que, a princípio, pareça determinar uma ação do sistema. Cada evento deve ser escrito em uma oração. Lembre-se que uma oração é uma construção gramatical que expressa uma idéia completa. Deve possuir um sujeito, um verbo e um objeto.
Para cada evento identificado, responda as perguntas abaixo. A resposta a essas perguntas levará à identificação de outros eventos. Para cada um desses novos eventos, responda novamente as perguntas. Repita esse processo exaustivamente, até que o ciclo se feche.
Existe algum evento que seja uma variação significativa do evento identificado? Normalmente esses eventos podem ser escritos com as mesmas palavras do evento original, trocando-se apenas o verbo.
Existe algum evento oposto ao evento identificado? Por exemplo: oposto a vender é comprar; oposto a pagar é receber (antônimos).
Há algum evento negativo do evento identificado? Consiste na negação do evento. Negativo de pagar é não pagar.
Existe algum evento que deve preceder o evento identificado? Normalmente esses eventos são pré-requisitos do evento em questão. Por exemplo, para que seja feito um pagamento, é necessário que tenha sido feita uma compra.
Há algum evento que seja conseqüência do evento identificado? Estes eventos devem acontecer, como conseqüência, após o evento em questão .
Determinando o Contexto do Sistema
O Diagrama de Contexto é a representação gráfica do Ambiente do Sistema. Nele, o sistema como um todo é representado por um círculo, com o seu nome. Os usuários (fornecedores e receptores de informações) são representados por retângulos, rotulados pelo nome do agente externo e as informações trocadas são as setas identificadas pelo nome do pacote de informações que fluem entre o sistema e seus usuários.
Eventos Externos e Eventos Internos
Na modelagem do ambiente, preocupamo-nos apenas com os eventos externos, isto é, aqueles que ocorrem fora do sistema. Eventos internos são representados por orações onde o sujeito é o sistema ou por respostas do sistema a eventos externos.
Fluxos de Dados e Eventos
Nem todo evento é sinalizado por um fluxo de dados. Os eventos temporais, por exemplo, não possuem um fluxo de dados de entrada como estímulo.