Академический Документы
Профессиональный Документы
Культура Документы
MANUAIS TCNICOS
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
I N T R O D U O
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:
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
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.
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
I N T R O D U O
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.
I N T R O D U O
Pessoal Info
Modelo Essencial Conhecimento do Assunto do Sistema Desenvolver Sistemas Modelo de Implementao Pessoal Info
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
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
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
Modelo de Ambiente Diagrama de Conrtexto Lista de Eventos Externos Especificao de Estmulos e Sadas
Objetivos 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
DFD Preliminar
Objetivos do Sistema
MER Preliminar Objetivos do Sistema MER Preliminar DFD (Atividades Essenciais) DFD (Atividades Essenciais)
Modelo de Comportamento Modelo Entidades e Relacionamentos Modelo de Objetos de Negcio Modelo de Atividades Essenciais Especificaes Textuais
Especificaes Textuais
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
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
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
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.
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
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
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
Sistema
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.
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.
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:
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:
ESTMULO
Entidade-X.atributo + w
RESPOSTA
Entidade-Z.atributo + w
X Z
Com o Modelo de Ambiente e o Modelo de Dados mo, faa os seguintes passos, para cada evento e respectivos desenhos em folha nica.
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
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
2.2 Figura 2
3.3 Figura 3
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.
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
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
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:
23
M O D E L O
D E
O B J E T O S
D E
N E G C I O
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
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.
JOS DA SILVA
LISTAR NOME
AR RM E FO IN IDAD
Nome Nome
Data DataNascimento Nascimento
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:
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
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:
Objetivo
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
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
30
E S P E C I F I C A E S
T E X T U A I S
Objetivos
31
E S P E C I F I C A E S
T E X T U A I S
Objetivo
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
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:
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 := 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:
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:
remova fatura.
Encontrando uma Ocorrncia do Objeto
Use a construo encontre (find) para encontrar uma ocorrncia particular de um objeto. Por exemplo:
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:
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
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