Volume

MANUAIS TCNICOS

Cursos de Formao Profissional

Anlise Essencial de Sistemas com Orientao a Objetos

PLENA CONSULTORIA E PLANEJAMENTO EM INFORMTICA LTDA

Anlise Essencial de Sistemas com Orientao a Objetos

Plena Consultoria Rua da Consolao, 2697 - 5 andar - So Paulo - SP - 01416-001 Telefone (011) 852-1333 Fax (011) 852-0013 e-mail plena@ibm.net

I N T R O D U O

ndice analtico
V olume 2 Captulo 1 Sistemas A Captao da Essncia A Formao do Pessoal de Sistemas A Cultura do Usurio A Comunicao Analista X Usurio A Documentao Modelos Ferramentas de Modelagem Ferramentas de Modelagem Tradicionais Fases do Desenvolvimento de Sistemas Tabela de Produtos Captulo 2 Modelagem de Eventos Algoritmo para Modelagem de Eventos Eventos Relacionados Determinando o Contexto do Sistema Eventos Externos e Eventos Internos Fluxos de Dados e Eventos Documentando o Modelo Ambiental Captulo 3 Produzindo o MER a partir da Lista de Eventos Eventos Custodiais Anatomia do Processo Essencial 15 15 16 0 0 3 3 3 3 4 4 4 5 5 5 6 6 11 12 12 12 12 12 13 13 13 13 15 15 Derivando o Modelo de Processos Nivelando o Modelo de Processos O Conceito de Nivelamento Balanceando o Modelo Balanceando entre Projees Balanceamento entre Nveis Captulo 4 Orientao a Objetos Estrutura em camadas Conceitos bsicos Objetos Compostos. Polimorfismo 16 17 17 18 19 19 23 23 23 23 23 26 27

Critrios para encontrar objetos de negcio27 Objetos de Negcio a partir do MER Captulo 5 28 29 29

Especificao de Composio de Dados 29 Especificao de Elemento de Dados Especificao de Entidade Especificao de Relacionamento Especificao de Objetos Especificao de Processo Consideraes sobre Especificao de Processo Expresses e Operadores Funes 34 34 35 30 30 31 32 32

Recebendo e Enviando Fluxos de Dados 35 Criando e Removendo Ocorrncias de Objeto 35

I N T R O D U O

Encontrando uma Ocorrncia do Objeto Seleo Construes de Repetio Captulo 5 Bibliografia

36 36 37 39 39 39

I N T R O D U O

Captulo

Sistemas

Os sistemas com os quais ns trabalhamos podem ser classificados como Sistemas de Resposta Planejada e possuem as seguintes caractersticas:

H uma necessidade ou oportunidade de negcio que precisa ser atendida

no mundo real; o sistema surge como resposta a essa necessidade ou oportunidade.

Todo sistema tem uma finalidade especfica: o que o sistema faz, e

armazena, est diretamente relacionado com essa finalidade.

Os sistemas tm de fornecer respostas previsveis: 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 so transferveis: 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 sadas/destinos das informaes; a determinao da fronteira de um sistema uma boa ferramenta para caracteriz-lo.

O interior do sistema consiste de atividades e de dados armazenados, que

so as engrenagens que respondem a eventos externos, de acordo com as finalidades do sistema.

A essncia do sistema independe da tecnologia utilizada para implementlo. Por exemplo: o sistema de contas correntes do Banco do Brasil o mesmo desde sua fundao h mais de um sculo. O que tem mudado, muito rapidamente, a tecnologia de implementao do sistema.
A Captao da Essncia

O trabalho de anlise de um sistema consiste em conseguir captar a sua essncia: os fatos que ocorrem fora do sistema que causaro uma ao do sistema como resposta. Esse trabalho deve procurar filtrar todas as condies e caractersticas de implementao, em busca da sua essncia. Essencial aquilo que o sistema deve ter. Se no tiver, o sistema no conseguir atingir seus objetivos.

I N T R O D U O

A Formao do Pessoal de Sistemas

Em geral, os profissionais de informtica so formados em Economia, Administrao de Empresas, Engenharia, etc.. Em seus cursos de graduao tiveram contato com a informtica em temas como Clculo Numrico. A formao efetiva desses profissionais d-se por osmose dentro das empresas, por troca de experincias com profissionais mais tarimbados. Quando h treinamento, este executado pelo fabricante do equipamento utilizado e em ferramentas de software existentes e utilizadas na instalao. Dessa forma, depois de alguns anos, o profissional promovido categoria senior e possui vasto conhecimento em softwares bsico, habitualmente denominados por trs ou quatro letras. As tcnicas de anlise de sistemas, de levantamento de dados, de projeto de sistemas, de codificao e de testes praticadas so aquelas que os outros j praticavam. Aliado a esse fato, existe outro: o profissional de informtica, em geral, fortemente reacionrio e resistente a novas tcnicas que causem qualquer mudana em sua rotina diria e em seu comportamento pessoal. No podemos esquecer que a informtica uma cincia nova, que est em constante e rpida evoluo. Como promotor da entrada da tecnologia na empresa, o profissional de informtica no deve ser ele prprio reativo s novas tecnologias.

A Cultura do Usurio

Os usurios tm a formao de acordo com sua rea de atuao. Assim, claro que o Departamento Jurdico est repleto de advogados, a Contabilidade formada por contadores e o Departamento Financeiro comandado por economistas. Os usurios, ao longo dos anos, tm tido algumas ms experincias com a informtica. Sistemas desenvolvidos para eles que no funcionaram adequadamente, sistemas que nunca ficaram prontos, sistemas que no se adaptam s mudanas em sua rea, sistemas que acabam acrescentando trabalho ao seu dia-a-dia. Apesar disso, ele ainda acredita na informtica e quer, cada vez mais, apoio de sistemas em suas atividades. O difcil conseguir que o pessoal l da informtica o atenda. Por isso vemos, com tanta freqncia, usurios montando verdadeiros CPDs paralelos para terem um mnimo de apoio informatizado em seus negcios.

A Comunicao Analista X Usurio

Os usurios conhecem o problema, os negcios, muito melhor que os analistas. Os analistas conhecem tcnicas para resolver os problemas. O trabalho de anlise deve produzir uma soluo para o problema. Geralmente a linguagem do usurio impregnada de termos do vocabulrio tcnico do assunto do problema que os analistas no entendem completamente. Por outro lado, ao expor a soluo, os analistas utilizam uma linguagem tcnica derivada do informatiqus que o usurio desconhece. A qualidade da soluo fortemente influenciada pela qualidade de sua validao pelos usurios. Ser que ns entendemos corretamente o problema? Ser que a soluo vivel?

I N T R O D U O

importante que o trabalho seja feito em conjunto e que se utilize de vocabulrio prprio, comum a todos os participantes. Analistas e usurios trabalhando no mesmo time, em busca da melhor soluo. Trabalhar junto leva ao entendimento, melhor comunicao e sinergia.

A Documentao

Para possibilitar essa comunicao h a necessidade de documentarmos o entendimento obtido. Essa documentao servir de base, num momento posterior, ao trabalho de manuteno do sistema j instalado. Para que a documentao seja til, importante que ela seja produzida durante o trabalho, que seja completa e que esteja atualizada. Uma documentao desatualizada no serve para nada. Sistemas com documentao incompleta ou desatualizada precisam de arquelogos, especialistas que vasculham fragmentos de cdigo, arquivos e dumps com o objetivo de construir hipteses a respeito de pra que serve isso? no sistema. Alm dos arquelogos, o sistema precisar ser atendido por pediatras, profissionais que so chamados a qualquer hora, principalmente de madrugada ou aos fins de semana, toda vez que o sistema passa mal.

Modelos

Um modelo uma representao 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, prottipos. O uso de modelos torna o estudo mais barato e seguro: muito mais rpido e barato construir um modelo que construir a coisa real. O objetivo do modelo mostrar como ser o sistema, para permitir sua inspeo e verificao, de modo a poder receber alteraes e adaptaes antes de ficar pronto. Qualquer modelo reala 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 sero mostrados e quais ficaro escondidos.

Ferramentas de Modelagem

Para modelarmos sistemas, necessitamos de ferramentas com as seguintes caractersticas:

I N T R O D U O

Grficas, com apoio de textos, como um mapa: legveis, concisas e

padronizadas. A parte grfica particiona o sistema em componentes interrelacionados, sem as restries de um texto linear. A parte textual descreve os componentes e suas interconexes;

Particionveis, do geral para o especfico, como um atlas geogrfico,

tornando o modelo mais fcil de entender. Precisamos ser capazes de ter a viso geral do sistema sem nos preocuparmos com detalhes e, termos a viso do detalhe sem perdermos a noo do todo;

Rigorosas, como as escalas de uma planta. O modelo do sistema deve ser

preciso, sem erros, incompletudes e redundncias. Mas deve ser flexvel, fcil de mudar, pois o sistema est sempre em constante evoluo;

Capazes de predizer o comportamento do sistema, como um

prottipo. 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 crticos do sistema, como fotos de

vrios ngulos, com simplicidade. Cada modelo deve ser uma projeo do sistema em um espao simplificado.
Ferramentas de Modelagem Tradicionais

As ferramentas tradicionais de modelagem de sistemas levam a modelos redundantes, contraditrios e difceis de checar quanto sua completude e preciso. necessrio que utilizemos ferramentas de modelagem substancialmente diferentes daquelas anteriormente utilizadas pelos mtodos tradicionais. O Desenvolvimento de sistemas com Anlise Essencial se d sempre de maneira a se obter mais conhecimento e qualidade a cada passo, atravs 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 abrangncia do sistema pela especificao dos eventos que motivam a sua ao, das entradas e suas origens e das sadas e seus destinos. A partir da Lista de Eventos Externos, do Modelo do Ambiente, deve ser construdo o Modelo do Comportamento do sistema, que especifica de que forma o sistema estruturado em termos de dados e funes para atingir aos objetivos estabelecidos e para responder aos eventos do Modelo do Ambiente. A Figura SDS 1 - O desenvolvimento de sistemas com Anlise Essencial, mostra o contexto do desenvolvimento de sistemas visto, ele prprio, como um sistema.

Fases do Desenvolvimento de Sistemas

I N T R O D U O

Pessoal Info

Conhecimento da Tecnologia de Automao

Modelo Essencial Conhecimento do Assunto do Sistema Desenvolver Sistemas Modelo de Implementao Pessoal Info

Resties de Implementao Pessoal Info Objetivos do Sistema

Figura SDS 1 - O desenvolvimento de sistemas com Anlise Essencial

O desenvolvimento de sistemas interage com o pessoal de informtica, que detm o conhecimento da tecnologia de automao; com o usurio, responsvel pela definio dos objetivos e restries do sistema e profundo conhecedor do assunto e do ambiente do sistema. A empresa a beneficiria do trabalho, recebendo o produto do desenvolvimento: o sistema. A Figura 0 - Desenvolver Sistemas, mostra os dois principais processos do desenvolvimento de sistemas.
Objetivos do Sistema

1. Criar o Modelo Essencial Restries de Implementao Modelo Essencial Conhecimento do Assunto do Sistema 2. Derivar o Modelo de Implementao Conhecimento da Tecnologia de Implementao Modelo de Implementao

Figura 0 - Desenvolver 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

I N T R O D U O

ao sistema; de onde vm esses dados; quais as informaes que o sistema deve produzir; quem so os usurios dessas informaes.
Objetivos do Sistema Modelo Essencial Modelo de Ambiente Modelo de Comportamento 1. Modelar o Ambiente do Sistema

Modelo do Ambiente Conhecimento do Assunto do Sistema 2. Derivar o Modelo de Implementao Conhecimento do Assunto do Sistema Modelo do Comportamento

Figura 1 - Criar o Modelo Essencial

A partir do Modelo do Ambiente derivado o Comportamento do Sistema: quais so as estruturas de dados, os objetos de negcio, quais so os processos internos do sistema necessrios para garantir que o sistema atinja seus objetivos, atravs da ativao dos mtodos dos objetos de negcio. A Figura 1.1 - Modelar o Ambiente do Sistema, mostra que essa tarefa feita pela determinao do Contexto do Sistema e pela identificao de Eventos Externos. Essas tarefas so executadas em conjunto, uma subsidiando a outra.

I N T R O D U O

Objetivos do Sistema Diagrama de Contexto

Modelo de Ambiente Diagrama de Conrtexto Lista de Eventos Externos Especificao de Estmulos e Sadas

1.1.1 Determinar o Contexto do Sistema Diagrama de Contexto Preliminar

Conhecimento do Assunto do Sistema

Lista de Eventos Lista de Eventos Preliminar 1.1.2 Identificar os Eventos Essenciais

Conhecimento do Assunto do Sistema

Objetivos do Sistema

Figura 1.1 - Modelar o Ambiente do Sistema

A figura 1.2 - Derivar o Comportamento do Sistema - ilustra que essa tarefa constituda de quatro partes: A modelagem dos dados, a modelagem das atividades essenciais, a modelagem dos objetos de negcio e a especificao dos detalhes em um dicionrio de dados.
Conhecimento do Assunto do Sistema Modelo de Ambiente Conhecimento do Assunto do Sistema

1.2.2 Modelar os Dados Armazenados

DFD Preliminar

1.2.1 Modelar as Atividades Essenciais

Objetivos do Sistema

MER Preliminar Objetivos do Sistema MER Preliminar DFD (Atividades Essenciais) DFD (Atividades Essenciais)

1.2.3 Modelar Objetos de Negcio Objetos de Negcio

Modelo de Comportamento Modelo Entidades e Relacionamentos Modelo de Objetos de Negcio Modelo de Atividades Essenciais Especificaes Textuais

1.2.4 Especcificar Detalhes

Especificaes Textuais

Figura 1.2 - Derivar o Comportamento do Sistema

I N T R O D U O

A Figura 2 - Derivar o Modelo de Implementao, consiste, em primeiro lugar, na determinao do Modelo de Processadores, onde as atividades essenciais so alocadas a processadores, que so os agentes que executaro cada uma das atividades implementadas, fisicamente(entenda-se, aqui, por exemplo, computadores e pessoas); na derivao do Modelo de Tarefas, onde as atividades so organizadas, por processador, em seqncias ou grupos de operao que fazem trabalho til para o usurio (tarefas), e na derivao do Modelo de Arquitetura de Cdigo, onde as mesmas atividades so divididas em objetos ou mdulos funcionais (dependendo do ambiente de hardware), com o mximo de coeso interna e o mnimo de interdependncia entre mdulos.
Modelo Essencial Conhecimento da Tecnologia de Automao

Conhecimento da Tecnologia de Automao

2.1 Derivar o Modelo de Processadores Restries de Implementao Moelo de Processadores

2.2 Derivar o Modelo de Tarefas

Restries de Implementao

Modelo de Tarefas Conhecimento da Tecnologia de Automao 2.3 Derivar o Modelo de Arquitetura de Cdigo Modelo de Arquitetura de Cdigo Restries de Implementao

Modelo de Implementao Modelo de Processadores Modelo de Tarefas Modelo de Arquitetura de Cdigo

Figura 2 - Derivar o Modelo de Implementao

10

I N T R O D U O

Tabela de Produtos

Usando o Modelo de Processos do Sistema de Desenvolvimento de Sistemas (SDS), representamos abaixo os produtos conseguidos com as tcnicas.
. Lista de Eventos . Diagrama de Contexto . Especificao Estmulos/Sadas . Modelo de Dados DER + DD . Mod. Atividades DFD + Minispecs

Modelo

Modelo de Ambiente

Modelo Essencial Modelo de Comportamento

de Modelo Sistemas de Modelo de Tarefas Implementao Modelo de Arquitetura de Cdigo . Jobs . Procedures . Transaes p/ Tarefas Automatizadas . Projeto de Objetos Modelo de Processadores . DFD de Processadores . Dilogos . Prottipos

11

C O N S T R U I N D O

M O D E L O

A M B I E N T A L

Captulo

Modelagem de Eventos

A construo do Modelo Ambiental se d atravs da Definio 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 conseqncia. 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 informao ou a produo de um resultado.

Algoritmo para Modelagem de Eventos

Analise o ambiente do sistema e ponha no papel todo fato que, a princpio, parea determinar uma ao do sistema. Cada evento deve ser escrito em uma orao. Lembre-se que uma orao uma construo gramatical que expressa uma idia completa. Deve possuir um sujeito, um verbo e um objeto. Para cada evento identificado, responda as perguntas abaixo. A resposta a essas perguntas levar identificao de outros eventos. Para cada um desses novos eventos, responda novamente as perguntas. Repita esse processo exaustivamente, at que o ciclo se feche.

Eventos Relacionados

Existe algum evento que seja uma variao 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 (antnimos).

H algum evento negativo do evento identificado? Consiste na negao do

evento. Negativo de pagar no pagar.

Existe algum evento que deve preceder o evento identificado?

Normalmente esses eventos so pr-requisitos do evento em questo. Por exemplo, para que seja feito um pagamento, necessrio que tenha sido feita uma compra.

H algum evento que seja conseqncia do evento identificado? Estes

eventos devem acontecer, como conseqncia, aps o evento em questo .

12

C O N S T R U I N D O

M O D E L O

A M B I E N T A L

Determinando o Contexto do Sistema

O Diagrama de Contexto a representao grfica do Ambiente do Sistema. Nele, o sistema como um todo representado por um crculo, com o seu nome. Os usurios (fornecedores e receptores de informaes) so representados por retngulos, rotulados pelo nome do agente externo e as informaes trocadas so as setas identificadas pelo nome do pacote de informaes que fluem entre o sistema e seus usurios. Na modelagem do ambiente, preocupamo-nos apenas com os eventos externos, isto , aqueles que ocorrem fora do sistema. Eventos internos so representados por oraes onde o sujeito o sistema ou por respostas do sistema a eventos externos.
Manutencao Dados de Filme

Eventos Externos e Eventos Internos

Sistema

Bye Bye Brazil

Fluxos de Dados e Eventos

Nem todo evento sinalizado por um fluxo de dados. Os eventos temporais, por exemplo, no possuem um fluxo de dados de entrada como estmulo. Nem todo evento possui um fluxo de sada correspondente. Um evento pode causar, apenas, que algum dado seja armazenado. Eventos diferentes podem estar associados a um mesmo fluxo de dados.

Documentando o Modelo Ambiental

O Modelo Ambiental deve ser documentado atravs das seguintes especificaes:

Objetivos do Sistema. uma lista de objetivos que o sistema deve

atender. Essa lista ser a baliza que nortear o conceito de essencial ou no, onde essencial tudo aquilo que necessrio para atingir um determinado objetivo.

Lista de Problemas. Essa lista ajudar na construo da Lista de

Objetivos. Os objetivos de um sistema podem ser de duas categorias: os que so ligados s necessidades futuras do usurio e os que so ligados soluo de problemas que o usurio enfrenta atualmente.

Lista de Eventos Externos. Constar da especificao, para cada evento,

do fluxo de estmulo e sua origem, da resposta que o sistema deve dar ao evento e do fluxo de sada produzido pelo sistema, com seu destino.

Diagrama de Contexto. Consiste na representao grfica dos elementos

identificados na Lista de Eventos Externos, representando as origens e

13

C O N S T R U I N D O

M O D E L O

A M B I E N T A L

seus estmulos, aos destinos e suas sadas, alm do sistema que os recebe / produz, sem nenhuma especificao de detalhes.

Dicionrio de Dados. Uma entrada para cada dado identificado como

fluxo de estmulo ou de sada do sistema (Ver Captulo Especificaes Textuais).

14

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

Captulo

Aps a determinao do Modelo de Ambiente, deve ser derivado o Modelo de Dados do Sistema, atravs da tcnica de Modelagem de Entidades e Relacionamentos (ver manual especfico). A modelagem dos dados determina os depsitos de dados, que o sistema utilizar para custodiar as informaes que lhe so essenciais. Os dados sero derivados do Modelo de Ambiente e, portanto, para passar ao prximo item, tenha-o mo.
Produzindo o MER a partir da Lista de Eventos

Para cada evento do Modelo de Ambiente, produza o MER conforme a seqncia abaixo:

Evento = o sujeito e o objeto do evento so candidatos a entidades e o

verbo, candidato a relacionamento.

Estmulo = verificar se os dados devem ser armazenados e onde (sujeito,

objeto ou outra entidade).

Ao / Resposta = conhecimento do sistema (regras); quais Entidades

ou Relacionamento so criados, usados, modificados ou removidos

Sada = verificar onde (Entidade ou Relacionameto) os dados devem ser

obtidos. Obs.: Lembrar que Eventos Temporais no tm estmulo e nem sempre so escritos com sujeito, verbo e objeto.
Eventos Custodiais

Os Eventos Essenciais so divididos em dois tipos:

Fundamentais - tm a ver com o negcio do sistema, o dia-a-dia comum

do(s) usurio(s);

Custodiais - tomam conta da base de informaes da organizao,

garantindo o funcionamento das respostas planejadas para os Eventos Fundamentais.

15

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

O Modelo de Dados foi derivado do Modelo Ambiental mais o conhecimento do assunto, porm, o Modelo Ambiental no atende totalmente o Modelo de Dados. Para que esse problema seja resolvido, ns precisamos refinar o Modelo Ambiental, isto , adicionar novos eventos lista, usando a seguinte regra: Verificar se existem e so significativos, eventos que:

criam; modificam; removem e usam

cada objeto do Modelo de Dados, isto , entidade, relacionamento e atributo significativo (atributo que muda o estado da entidade). Obs.: Lembre-se que refinar o Modelo Ambiental , alm de adicionar os eventos, complet-lo com os estmulos e sadas na Lista de Eventos e no Diagrama de Contexto e com a resposta planejada para cada evento.

Anatomia do Processo Essencial

ESTMULO

Entidade-X.atributo + w

RESPOSTA

k=w*2 Entidade-Y.atributo = k /2**3 SADA

Entidade-Z.atributo + w

X Z

Derivando o Modelo de Processos

Com o Modelo de Ambiente e o Modelo de Dados mo, faa os seguintes passos, para cada evento e respectivos desenhos em folha nica.

Passo 1: Identifique os Processos = para cada evento, crie um

Processo (representado por uma bolha no DFD) rotulado com o nome da resposta que o sistema d ao evento.

16

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

Passo 2: Adicione os Fluxos de Dados = adicione o Fluxo de

Estmulo, representando-o como uma seta entrando no Processo e adicione o(s) Fluxo(s) de Sada(s), representando-o(s) como seta(s) saindo do Processo.

Passo 3: Adicione os Depsitos de Dados = considere a lgica do

Processo e adicione os Depsitos de Dados criados, removidos ou atualizados pelo processo, representando-os por duas linhas horizontais, com o seu nome tirado do Modelo de Dados e por uma seta saindo do processo e entrando no referido depsito. Adicione os Depsitos de Dados lidos pelo processo, representando-os por duas linhas horizontais com o seu nome tirado do Modelo de Dados e por uma seta saindo do depsito e entrando no processo. O modelo produzido ter tantos processos quantos forem os eventos. bvio que esse modelo no bom para apresentao, validao e compreenso do sistema. Por isso, ele dever ser nivelado.
Nivelando o Modelo de Processos

Nivelar o Modelo de Processos consiste em organiz-lo em vrios DFD's, onde cada um deles apresenta um determinado nvel de detalhe. Assim, como num atlas, haver um modelo que representa o sistema e outro que representa os subsistemas. Cada processo do DFD nvel 1 (aquele que representa os subsistemas) pode ser detalhado em outro DFD que o considera como se aquele processo fosse o sistema. Este nivelamento deve ser feito at que todos os processos sejam representados em seu mais baixo nvel, ou seja, seu detalhamento feito atravs de especificao de lgica de processo, ao invs de por outro DFD. Um DFD, que representa um conjunto de transformaes graficamente conectadas, pode ser desenhado atravs de uma nica transformao, com o mesmo conjunto de entradas e sadas.

O Conceito de Nivelamento

17

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

Vrias transformaes podem ser juntadas em uma nica, num nvel mais alto. Da mesma maneira, uma transformao pode ser dividida em um grupo de transformaes, num nvel mais baixo.

Contexto

1.1

2.1

3 1.2 2 1.3 Figura 0 Figura 1

2.2 Figura 2

3.1.1 3.1 3.2 1.3.1

3.3 Figura 3

3.1.2 3.1.3 Figura 3.1 Figura 1.3 1.3.2

O menor nvel de transformaes determina o modelo completo do sistema. As transformaes de mais alto nvel servem apenas como abreviaes e nos ajudam a lidar com a complexidade dos diagramas de mais baixo nvel. Desde que a nica diferena entre um nvel e outro o grau de detalhe mostrado, s escrevemos especificaes textuais para as transformaes de mais baixo nvel: as primitivas funcionais.
Balanceando o Modelo

A organizao do modelo grfico muito mais do que uma questo de convivncia. Um DFD ou DER complexo pode sobrecarregar o leitor pela apresentao de mais detalhes do que sua mente pode absorver. Desde que a correo do modelo depende de sua compreensibilidade, o processo de balanceamento e reviso essencial para assegurar a qualidade do processo de desenvolvimento de sistemas. Pesquisas sobre a memria e percepo humanas sugerem que um diagrama que contenha 7 elementos, com uma variao de mais ou menos 2, ir sobrecarregar a maioria dos leitores.

18

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

Uma regra objetiva : um DFD inteligvel um DFD com poucos fluxos de dados, que no deve ter mais que meia dzia de transformaes.

Balanceando entre Projees

O modelo de processos e o modelo de dados esto balanceados quando:

cada elemento de dados, de cada entidade no DER, usado por uma ou

mais transformaes ou requerido por consultas ad-hoc;

cada relacionamento no DER usado por uma ou mais transformaes

ou requerido por consultas ad-hoc;

cada elemento de dados, de cada entidade ou entidade associativa no

DER, carregado por uma ou mais transformaes e

cada relacionamento do DER criado por uma ou mais transformaes.

Balanceamento entre Nveis

Os modelos de dados e de processos devem fornecer um modelo nico e consistente do sistema. Precisamos assegurar que cada nvel do modelo exatamente eqivalente aos demais nveis. Regra de balanceamento

19

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

Cada processo pai deve ter exatamente as mesmas entradas e sadas que o diagrama filho, que est no nvel imediatamente abaixo. Balanceamento visual de fluxos
a 2. c

d d's

Se ns no nivelarmos os fluxos, o balanceamento ser fcil: a bolha pai e o diagrama filho tero exatamente os mesmos nomes de fluxos.

b c 2.1 2.3 x

2.2 d's b

Balanceamento via especificaes textuais

c a 2.

Quando nivelamos fluxos, usamos as especificaes textuais (Dicionrio de Dados) para estabelecer a equivalncia dos fluxos pai e fluxos filhos.

d d's b

x z w 2.1 2.3 j y y k

2.2 d's b

Balanceando Depsitos de Dados

1.1

a=x+y+z c=K+w

1.2 x

Um depsito de dados aparece pela primeira vez, no nvel em que ele compartilhado entre dois processos. Abaixo desse nvel, o depsito aparece sempre que for referenciado.

1.1.1

1.2.1 x

1.1.2 y z

1.2.2

20

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

x=a+b

Depsitos de dados podem ser nivelados da mesma forma que processos e fluxos.
1.1.1

1.1 x

1.2

1.2.1 b

1.1.2 a a

1.2.2

Nivelando o Modelo Essencial A derivao das projees grficas, a partir da lista de eventos, produz um modelo que no bem particionado.

Para reorganizar o modelo, junte os processos de acordo com os depsitos de dados referenciados por eles.

21

D E R I V A N D O

M O D E L O

C O M P O R T A M E N T A L

Nivelando para cima Represente cada grupo como uma transformao em um DFD de mais alto nvel e junte os detalhes em diagramas filho. Particione de forma a minimizar interfaces.

3 5

Figura 0

1.1

3.1 1.2

3.2

1.3 3.3

Figura 1 Figura 3

22

M O D E L O

D E

O B J E T O S

D E

N E G C I O

Captulo

Orientao a Objetos

Objetos so estruturas conceituais que juntam dados e processos. A organizao do modelo do sistema em torno dos objetos simplifica sua implementao e viabiliza a reutilizao de cdigo, tornando possvel o conceito de fbrica de software. A implementao do sistema ser organizada em camadas de objetos com a finalidade de isolar a tecnologia da essncia do sistema.

Estrutura em camadas

Aplicao

Objeto Visual

Objeto Funcional

Objeto de Negcio

Objeto Persistente

Durante a modelagem essencial do sistema, temos condies de projetar os objetos que so independentes de tecnologia, que so os objetos funcionais (que contm a lgica da resposta dos eventos) e os objetos de negcio, onde os dados e mtodos so distribudos. Os objetos visuais e os objetos persistentes sero projetados depois de definida a tecnologia, durante a modelagem de implementao.
Conceitos bsicos

relacionados. Na maioria dos casos correspondem aos objetos de negcio do mundo real tais como: pedidos, faturas, produtos, mquinas, departamentos, pessoas. Alguns princpios so fundamentais para se compreender os objetos:

Objetos so empacotamentos que contm os procedimentos e os dados

Abstrao: um tipo de objeto representa um conjunto de caractersticas

compartilhadas por outros

23

M O D E L O

D E

O B J E T O S

D E

N E G C I O

Encapsulamento: empacotamento das operaes e dados em um tipo de

objeto s acessveis atravs da interface do objeto. Disponibiliza publica e globalmente os acesso aos dados e operaes: protocolo do objeto

Reusabilidade: utilizao de tipos de objetos j definidos no projeto e

classes de objetos na implementao

Especializao: herda operaes, tipos de atributos e relacionamentos de

um ou mais supertipos. Generalizao de supertipos a partir de coisas comuns

Comunicao: solicitaes a outros objetos atravs de mensagens ou

requisies (ou chamadas) de operaes

Polimorfismo: quando uma mesma operao pode ser aplicada a diversos

tipos de objetos diferentes

Mensagens so os meios de comunicao entre objetos. Na essncia, objetos solicitam servios a outros objetos, para que juntos realizem uma operao essencial de negcio. Classes so como gabaritos para definio de tipos de objetos. Por exemplo, todo objeto Nota Fiscal poderia ser descrito como uma nica classe de Notas Fiscais, onde estariam especificados todas as propriedades ou os atributos de todas as notas, assim como os procedimentos ou servios possveis de serem oferecidos por essas notas.

A idia bsica da tecnologia a de replicar a forma como so construdos os equipamentos de hardware. Nesta analogia, o objeto se comporta como uma caixa preta, equivalente aos circuitos integrados utilizados na construo dos referidos equipamentos.

24

M O D E L O

D E

O B J E T O S

D E

N E G C I O

Objeto Mensagem

Classe

Ocultao da informao: Apenas o prprio objeto capaz de ver,

manipular e atualizar seus atributos;

Hereditariedade: As caractersticas e comportamentos do objeto so

determinados pela herana adquirida de suas classes ancestrais.

Mtodos

Variveis

Procedimentos ou Servios so codificados em Mtodos do objeto. Dados so armazenados em variveis, atributos, propriedades ou caractersticas. Somente os mtodos acessam as variveis do objeto. Um objeto solicita a execuo de um mtodo

25

M O D E L O

D E

O B J E T O S

D E

N E G C I O

do outro objeto via mensagem, eventualmente, com parmetros. O objeto solicitado responde com o dado contido na varivel acessada pelo mtodo.

Objetos Compostos.

LISTAR NOME - ID1234

JOS DA SILVA

LISTAR NOME
AR RM E FO IN IDAD

Nome Nome
Data DataNascimento Nascimento

Endereo Endereo LISTAR ENDEREO

Os objetos podem conter outros objetos. Normalmente, a composio implementada fazendo referncia aos objetos contidos usando os identificadores dos objetos. Um identificador ou handle do objeto o torna nico, mesmo que os valores de seus atributos sejam idnticos. Desta forma:

Os objetos contidos podem mudar de tamanho e composio sem

afetar o objeto que os contm. A manuteno de sistemas complexos fica muito mais simples do que de outra forma.

Os objetos contidos podem participar de quaisquer objetos compostos

permitindo uma forma vital de capturar informaes do mundo real. Uma mensagem uma solicitao feita a partir de um objeto (transmissor) a outro

objeto (receptor) para que ele execute algum de seus mtodos. Uma mensagem composta de trs partes:

26

M O D E L O

D E

O B J E T O S

D E

N E G C I O

A identificao do receptor da mensagem O mtodo que est sendo solicitado ao receptor Informaes adicionais que o receptor eventualmente necessite para a
execuo do mtodo solicitado
Polimorfismo

Como os objetos so definidos independentes dos outros, um mesmo nome pode ser utilizado para solicitar a execuo de vrios mtodos diferentes de objetos diferentes. Nenhum parmetro de mensagem pode ser usado como argumento de controle. O polimorfismo elimina o uso de CASE ( caso ) ou IFs ( se) encadeados. Novos casos so criados pela construo de novos mtodos de novos objetos.

Solicitao de Compra Incluir Acrescenta um item na solicitao de compra Departamento Incluir Admite um novo funcionrio no departamento
Critrios para encontrar objetos de negcio

Objetos podem ser identificados a partir do Modelo Essencial do Sistema e so validados com os seguintes critrios:

Podem ser vistos como coisas ( substantivos ), mesmo que descritos por
verbos

Contm informao de alguma espcie Possuem procedimentos associados a eles Tm casos especiais ou podero t-los no futuro Compartilham propriedades com outros objetos em potencial

27

M O D E L O

D E

O B J E T O S

D E

N E G C I O

Contm coisas j definidas como objetos

Objetos de Negcio a partir do MER

Anlise dos assuntos contidos no diagrama entidade relacionamento do evento. Consideram-se:

as cardinalidades as totalidades a obteno de uma nica instncia do objeto

Veculos N
posse 1

Modelos
N

Veculo

custo

Modelo

Categorias de Preos

Categoria

O modelo hierrquico do objeto de negcio mostra que Veculo composto pelo objeto Modelo, que por sua vez constitudo pelo objeto Categoria. O objeto funcional (lgica do evento) que lida com o objeto de negcio veculo deve fazer referncia apenas ao Veculo. Modelo por sua vez invocado por um mtodo de Veculo e Categoria instanciada por algum mtodo de Modelo. Desta forma, a complexidade do objeto de negcio escondida atravs de sua estrutura de composio, o que tornar a especificao muito mais simples para se especificar e entender.

28

E S P E C I F I C A E S

T E X T U A I S

Captulo

Nossa inteno escrever o mnimo de texto, para especificarmos o sistema de maneira formal e rigorosa. Para isso, vamos, em um Dicionrio de Dados, especificar:

Composio de Dados (Grupos de Dados); Elementos de Dados; Entidades; Relacionamentos e Processos.

Especificao de Composio de Dados

Objetivo

Definir sintaticamente a composio de dados no elementares.

Ocorrncias

Uma para cada depsito de dados e fluxo no elementar em um DFD e

uma para cada entidade em um DER. Exemplo

Scios = nmero_scio + endereo_scio + (fone_scio) +

(fone_comercial) + CPF_scio + RG_scio

Dados_artsticos = nome_ator + {/participaes/ nome_filme +

gnero_filme + nome_personagem + ano_produo}

Preferncia = [cod_filme |ator | gnero | ttulo] Dados_pessoais_alterados = <endereo_scio | fone_scio |

fone_comercial>

29

E S P E C I F I C A E S

T E X T U A I S

Sintaxe Smbolo
= + {} [] <> | // () ** @

Significado
composto de e vrias ocorrncias de apenas um dentre qualquer conjunto dentre ou nome (rtulo) de grupo repetitivo opcional comentrio identificador

Especificao de Elemento de Dados

Objetivos

documentar o significado de cada elemento; especificar o significado do item; especificar o domnio do elemento pela enumerao ou especificao de
seus limites;

especificar se o elemento discreto ou contnuo e especificar a implementao fsica adotada em tempo de implementao.
Ocorrncias

uma para cada fluxo elementar no DFD, e uma para cada elemento em uma especificao de composio de dados.
Especificao de Entidade

Objetivos

definir o significado da entidade atravs da descrio de seu papel no

sistema;

30

E S P E C I F I C A E S

T E X T U A I S

a especificao deve explicitar o critrio de incluso, ou seja, qual a regra

ou conceito que faz com que um determinado objeto seja considerado como pertinente a este conjunto;

deve especificar, tambm, o critrio de excluso: o que faz com que um

objeto deixe de pertencer a este conjunto e

adicionalmente, se adequado, definir tambm os estados que uma

ocorrncia da entidade pode assumir, atravs dos eventos que a colocam nesses estados. Ocorrncias

uma por entidade no DER.

Especificao de Relacionamento

Objetivos

descrever o significado do relacionamento e especificar a cardinalidade e a totalidade do relacionamento.

Ocorrncias

uma por relacionamento no DER.

31

E S P E C I F I C A E S

T E X T U A I S

Especificao de Objetos Especificao de Processo

Objetivo

documentar a a composio dos objetos

Ocorrncias

uma para cada objeto.

Gabarito
Nome do Objeto

Atributos atributo1: tipo atributo2: tipo . . . .

Servios nomeDoMtodo1(argumento1: tipo,...) : tipo minispec do mtodo nomeDoMtodo2(argumento1: tipo,...) : tipo minispec do mtodo

32

E S P E C I F I C A E S

T E X T U A I S

Exemplo
Categoria

Atributos
categoria: Id valorHora: Valor valorMes: Valor cancelar: Booleano

Servios
encontrar(categoria: Id) : Booleano SE ENCONTRAR Categorias. COM .categoria=categoria RETORNE Verdadeiro SENAO RETORNE Falso criar( categoria: Id, valorHora: Valor, valorMes: Valor) : Nulo CRIE Categorias .codigo := categoria .valorHora := valorHora .valorMes := valorMes excluir(categoria: Id) : Nulo REMOVA Categorias

33

E S P E C I F I C A E S

T E X T U A I S

Consideraes sobre Especificao de Processo

Fonte : Rpida e Limpa, FG&A

Cada processo deve ser completamente especificado pela ao executada para:

manipular os fluxos de dados de entrada; produzir os fluxos de dados de sada e atualizar a memria do sistema. Para produzir especificaes consistentes e sem ambigidades, voc pode
usar NRDE's (elementos de dados no armazenados) e atributos. Por exemplo:

cliente.nome, .endereo fornecedor_cdigo

Sempre que voc usar um elemento de dados dentro de uma especificao de processo, ele ser considerado importado pelo processo. Um atributo tambm considerado importado se fizer parte do dicionrio de dados. De qualquer maneira, existem casos em que um elemento de dados usado para manter algum resultado intermedirio exclusivamente dentro do processo. Tais elementos de dados so chamados de elementos de dados locais. Como sugesto, inicie o nome de todos os elementos de dados locais com uma arroba (@). Por exemplo:

@@e:= produto.valor * .quantidade produto.valor = @preco_por_unidade * pedido.quantidade

Expresses e Operadores

As expresses so escritas usando a notao pr-fixada convencional de linguagem de programao. Por exemplo:

x+=y

x := x + y

34

E S P E C I F I C A E S

T E X T U A I S

x-=y x*=y x/=y

x := x - y x := x * y x := x / y

Sempre que voc atribuir um valor a um elemento de dados, ele considerado exportado pelo processo. Um atributo tambm exportado se ele fizer parte de algum fluxo de dados recebido pelo processo. Para comparar valores pode-se usar os operadores =, >>, <<, >>=, <<= e <<>>, e, para as operaes lgicas, os operadores and, or e not. Voc pode (e deve) usar parnteses para agrupar sub-expresses.
Funes

Voc pode usar funes usando um nome seguido por parnteses. Se houver argumentos, estes devem estar entre parnteses e separados por vrgula. Por exemplo:

novo_saldo:=ajuste(saldo_anterior, fator_classificador)
No existe pr-definio de funes. Quando se determina uma nova funo, esta deve ser, necessariamente, definida como um processo.
Recebendo e Enviando Fluxos de Dados

A construo receba (receive) usada para receber um fluxo de dados. Por exemplo:

receba pedido_usurio
Voc pode tambm receber parte de um fluxo de dados. Por exemplo:

receba item de pedido

Neste caso, item deve ser rtulo de um grupo de dados. A construo produza (produce) usada para enviar fluxos de dados de sada ou parte deles. Por exemplo:

produza nota_de_autorizao e produza item de fatura

Criando e Removendo Ocorrncias de Objeto

A construo crie (create) cria novas ocorrncias de um objeto. Por exemplo:

crie cliente.

35

E S P E C I F I C A E S

T E X T U A I S

Como os objetos so inter-relacionados, existe uma forma especial de utilizar a construo crie, que, da mesma maneira, especifica os atributos apontadores para alguns seletores de ocorrncia. Por exemplo: crie fatura. de cliente., vendedor. exatamente igual a:

crie fatura. fatura.cliente := cliente. fatura.vendedor:= vendedor.

A construo remova (remove) usada para remover a ocorrncia do objeto corrente. Por exemplo:

remova fatura.
Encontrando uma Ocorrncia do Objeto

Use a construo encontre (find) para encontrar uma ocorrncia particular de um objeto. Por exemplo:

encontre cliente. com .nome = nome_pedido

Voc pode usar uma forma especial da construo encontre, para encontrar a ocorrncia do objeto apontada por um outro:

encontre cliente. com cliente. = fatura.cliente

Seleo

A construo se (if) permite especificar uma seleo entre alternativas:

se cliente.saldo >> 100000

crdito:=aprovado f_se

se cliente.saldo <<100000
crdito := rejeitado se_no crdito := aprovado f_se

se cliente.tipo = especial
crdito := aprovado se_no_se cliente.saldo >> 5000

36

E S P E C I F I C A E S

T E X T U A I S

crdito := aprovado se_no_se cliente.saldo >> 1000 crdito := reviso se_no crdito:=rejeitado f_se
Construes de Repetio

A nica construo de iterao permitida a para_cada (for_each), que pode ser aplicada em diversas situaes. O uso mais comum do para_cada para especificar um grupo de aes, que deve ser executado para cada tipo do objeto:

para_cada cliente.
classificao := cliente.classe produza item do relatrio f_para Podemos especificar um critrio de classificao:

para_cada cliente. com .tipo = revendedor

ou .tipo = distribuidor em_ordem_de cliente.cep ascendente, .nome descendente classificao:= cliente.classe produza item do relatorio f_para Existe ainda uma forma de classificao manual para objetos inter-relacionados. Por exemplo:

para_cada fatura. de cliente.

........ f_para

para_cada fatura. de cliente. com fatura.estado = pendente

............ f_para

Finalmente, existe uma forma de manipular itens repetitivos em fluxos de dados de entrada:

37

E S P E C I F I C A E S

T E X T U A I S

para_cada item em fornecedor_pedido

............ f_para Neste caso, item deve ser um rtulo de um grupo de dados.

38

R E F E R N C I A S

D E

A P O I O

Captulo

Bibliografia

1. Anlise Essencial de Sistemas Stephen M. McMenamim / J. Palmer 2. Anlise Estruturada Moderna Edward Yourdon 3. Anlise Estruturada e Especificao de Sistemas Tom de Marco 4. Desenvolvendo Sistemas sem Complicao Paul T. Ward 5. Anlise Estruturada de Sistemas Chris Gane / Trish Sarson

39