Análise Essencial de Sistemas com Orientação a Objetos

Análise Essencial de Sistemas com Orientação a Objetos

(Parte 1 de 4)

Volume

2

manuais Técnicos

Cursos de Formação Profissional

Análise Essencial de Sistemas com Orientação a Objetos

Plena consultoria e planejamento em informática ltda

Análise Essencial de Sistemas com Orientação a Objetos

ã 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

Índice analítico

Volume 1

2 1

Capítulo 3

1 3

Sistemas 3

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

Capítulo 14

2 14

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

Capítulo 18

3 18

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

4 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

5 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

5 46

Bibliografia 46

Capítulo

1

Sistemas
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.

A Documentação
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”.

Modelos
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.

Ferramentas de Modelagem
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.

Fases do Desenvolvimento de Sistemas
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.

Tabela de Produtos
Usando o Modelo de Processos do Sistema de Desenvolvimento de Sistemas (SDS), representamos abaixo os produtos conseguidos com as técnicas.

Modelo

ModelodeAmbiente

. Lista de Eventos. Diagrama de Contexto. Especificação Estímulos/Saídas

Modelo

Essencial

Modelo deComportamento

. Modelo de Dados DER + DD . Mod. Atividades DFD + Minispecs

de

Modelo

Modelo de Processadores

. DFD de Processadores. Diálogos. Protótipos

Sistemas

de

Implementação

Modelode Tarefas

. Jobs. Procedures. Transações p/ Tarefas Automatizadas

Modelo de Arquitetura de Código

. Projeto de Objetos

Capítulo

2

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.

Eventos Relacionados
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.

(Parte 1 de 4)

Comentários