Apostila ProjetoOO

UFES - Universidade Federal do Esprito Santo
Projeto de Sistemas
Notas de Aula
Ricardo de Almeida Falbo

E-mail: falbo@inf.ufes.br
2003/1
ndice
Captulo 1 - Introduo 1.1 A Fase de Projeto 1.2 Conceitos Bsicos de Projeto 1.3 Princpios de Projeto 1.4 Qualidade do Projeto 1.5 Tecnologia Imperfeita e Requisitos Tecnolgicos Captulo 2 Projeto Arquitetural 2.1 Objetivos do Projeto Arquitetural 2.2 A Arquitetura Cliente-Servidor 2.3 Coletando Estatsticas e Restries 2.4 Estratgias de Acesso Oportuno a Dados 2.5 Sumrio da Determinao da Distribuio Geogrfica 2.6 Segurana 2.7 Modelo de Tarefas 2.8 Atividades Tecnolgicas Captulo 3 Projeto de Interface com o Usurio 3.1 Aspectos Gerais de Interface com o Usurio Captulo 4 Projeto de Bancos de Dados Relacionais 4.1 O Modelo Relacional 4.2 Diagrama Relacional Captulo 5 - Projeto Orientado a Objetos 5.1 Projeto da Arquitetura do Sistema 5.2 Projeto da Componente do Domnio do Problema 5.3 Projeto da Componente de Interface com o Usurio 5.4 Projeto da Componente de Gerncia de Tarefas 5.5 Projeto da Componente de Gerncia de Dados 5.6 Projeto de Objetos 5.7 Critrios de Qualidade de Projeto OO 5.8 Reviso do Documento de Projeto 5.9 Padres de Projeto (Design Patterns) Captulo 6 Projeto Estruturado de Sistemas 6.1 Projeto de Dados 6.2 Projeto Modular de Programas 1 1 2 3 3 6 8 8 9 13 18 20 20 21 22 23 24 27 27 30 32 33 36 36 37 39 42 43 44 45 62 62 69
UFES Departamento de Informtica
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo
1. Introduo
Referncias: Cap. 13 (Pressman, 2002), Caps. 2 e 3 (Xavier et al., 1995) O projeto de software encontra-se no ncleo tcnico do processo de desenvolvimento de software e aplicado independentemente do modelo de ciclo de vida e paradigma adotados. iniciado assim que os requisitos do software tiverem sido modelados e especificados, correspondendo primeira dentre as trs atividades tcnicas projeto, implementao e testes requeridas para se construir e verificar um sistema de software. Enquanto a fase de anlise pressupe que dispomos de tecnologia perfeita (capacidade ilimitada de processamento com velocidade instantnea, capacidade ilimitada de armazenamento, custo zero e no passvel de falha), a fase de projeto envolve a modelagem de como o sistema ser implementado com a adio dos requisitos tecnolgicos ou no funcionais.
Domnio do Problema
Mundo Real
Anlise e Especificao de Requisitos (o que)
Projeto (como)
Domnio da Soluo
Mundo Computacional
Implementao
1.1 A Fase de Projeto

O objetivo desta fase incorporar a tecnologia aos requisitos essenciais do usurio, projetando o que ser construdo na implementao. Sendo assim, necessrio conhecer a tecnologia disponvel e as facilidades do ambiente de software onde o sistema ser desenvolvido e/ou implantado.
Independentemente do paradigma adotado, o projeto deve produzir: Projeto da Arquitetura do Software: definir os grandes componentes estruturais do software e seus relacionamentos. Projeto de Dados: projetar a estrutura dos dados necessria para implementar o software. Projeto de Interfaces: descrever como o software dever se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces externas) e com pessoas que o utilizam (interface com o usurio). Projeto Procedimental: refinar e detalhar a descrio procedimental dos componentes estruturais da arquitetura do software.
O projeto de software um processo iterativo. Inicialmente, o projeto representado em um nvel alto de abstrao. medida que iteraes ocorrem, os refinamentos conduzem a representaes de menores nveis de abstrao. Uma especificao de projeto deve: Contemplar todos os requisitos explcitos contidos no modelo de anlise e todos os requisitos implcitos desejados pelo cliente; Ser um guia legvel e compreensvel para aqueles que iro codificar, testar e manter o software. Prover um quadro completo do software, tratando aspectos funcionais, comportamentais e de dados, segundo uma perspectiva de implementao.
1.2 Conceitos Bsicos de Projeto

Nveis de Abstrao: o projeto deve considerar vrios nveis de abstrao, comeando com em um nvel mais alto, prximo da fase de anlise. medida que avanamos no processo de projeto, o nvel de abstrao deve ser reduzido. Refinamento: processo de elaborao, no qual o projeto vai sendo conduzido de nveis mais altos para nveis mais baixos de abstrao. Modularidade: um projeto deve estruturar mdulos/componentes coesos e fracamente acoplados. um sistema como
Ocultao de informaes: mdulos / componentes so caracterizados pelas decises de projeto que cada um deles esconde dos demais. Mdulos devem ser projetados e especificados de modo que as informaes neles contidas (dados e alguns procedimentos) sejam inacessveis a outros mdulos. Interface Contratual.
Independncia Funcional: mdulos devem cumprir uma funo bem estabelecida, minimizando interaes com outros mdulos. Esta caracterstica resultado direto da soma das demais caractersticas e pode ser medida usando dois critrios de qualidade: coeso e acoplamento.
1.3 Princpios de Projeto

Em geral, um modelo de projeto (por exemplo, uma planta arquitetnica de uma casa) deve: comear representando a totalidade da coisa a ser construda; refinar para prover orientao para a construo de cada detalhe; prover diferentes vises da coisa. considerar abordagens alternativas com base nos requisitos do problema, recursos disponveis e conceitos de projeto; ser rastrevel ao modelo de anlise; no reinventar a roda, isto , reutilizar componentes; minimizar a distncia conceitual e semntica entre o software e o mundo real; exibir uniformidade (estilo) e integrao (interfaces entre componentes); ser estruturado para acomodar mudanas (alterabilidade); acomodar circunstncias no usuais e, se necessrio abortar o processamento, faz-lo de modo elegante; apresentar nvel de abstrao superior ao cdigo fonte. Projeto no codificao; Ser passvel de avaliao da qualidade; Ser revisado para minimizar erros semnticos.
Mais especificamente, o projeto de software deve:
1.4 Qualidade do Projeto

Conforme citado anteriormente, a fase de projeto responsvel por incorporar requisitos tecnolgicos aos requisitos essenciais. Assim, o projetista dever estar atento aos critrios de qualidade que o sistema ter que atender. O modelo de qualidade definido na norma ISO/IEC 9126-1, utilizado como referncia para a avaliao de produtos de software, define seis caractersticas de qualidade, desdobradas em sub-caractersticas (Rocha et al., 2001):
Funcionalidade: refere-se existncia de um conjunto de funes que satisfaz s necessidades explcitas e implcitas e suas propriedades especficas. Tem como sub-caractersticas: adequao, acurcia, interoperabilidade, segurana de acesso e conformidade. Confiabilidade: diz respeito capacidade do software manter seu nvel de desempenho, sob condies estabelecidas, por um perodo de tempo. Tem como sub-caractersticas: maturidade, tolerncia a falhas, recuperabilidade e conformidade. Usabilidade: refere-se ao esforo necessrio para se utilizar um produto de software, bem como o julgamento individual de tal uso por um conjunto de usurios. Tem como sub-caractersticas: inteligibilidade, apreensibilidade, operacionalidade, atratividade e conformidade. Eficincia: diz respeito ao relacionamento entre o nvel de desempenho do software e a quantidade de recursos utilizados sob condies estabelecidas. Tem como sub-caractersticas: comportamento em relao ao tempo, comportamento em relao aos recursos e conformidade. Manutenibilidade: concerne ao esforo necessrio para se fazer modificaes no software. Tem como sub-caractersticas: analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade. Portabilidade: refere-se capacidade do software ser transferido de um ambiente para outro. Tem como sub-caractersticas: adaptabilidade, capacidade para ser instalado, coexistncia, capacidade para substituir e conformidade. Xavier et al. (1995) utilizam outra classificao, indicando os seguintes aspectos a serem considerados: Completeza: diz respeito ao atendimento dos requisitos do cliente. Desempenho: refere-se ao uso otimizado dos recursos computacionais disponveis (hardware, software e peopleware). Fatores que afetam o desempenho incluem: Projeto fsico de arquivos: deve minimizar o tempo de acesso a disco; Reorganizao de arquivos Reorganizao de ndices Limpeza de arquivos Utilizao da computao cliente-servidor: front-end local no servidor (interface com o usurio) e back-end no servidor (processamento e acesso a dados).
Segurana contra acessos indevidos: importante projetar: Procedimentos de segurana, tais como controle de acesso (matriz classe de usurio x operaes), criptografia e vises em bancos de dados; Mecanismos de deteco de violaes, tal como monitorao e arquivos de log.
Facilidade de uso: diz respeito ao projeto de interface com o usurio; Confiabilidade: refere-se preservao da disponibilidade do sistema e da integridade das informaes armazenadas. No tocante a este critrio de qualidade, deve-se ficar atento a: Restries de integridade: informaes a serem armazenadas devem ser filtradas a partir das regras estabelecidas. Este filtro pode se dar via programa ou Sistema Gerenciador de Banco de Dados (SGBD). Controle de Concorrncia: bloqueio. Recuperao de Falhas: prever possveis falhas e definir sua forma de recuperao. Por exemplo, restaurar um banco de dados a um estado reconhecidamente correto aps a ocorrncia de uma falha. Tipos de falhas: Humana: digitao ou operao do sistema; Transao: overflow, erro em tempo de execuo, diviso por zero, ... de Sistema: problemas no hardware, falta de energia, ... de Comunicao: queda de linha, ... de Software: erros de desenvolvimento Preveno de falhas: em Arquivos: registros de cabealho (header) e de final (trailler); Cpias de Segurana (backup); Arquivos de Log para desfazer ou refazer transaes; Espelhamento (gravao simultnea em dois discos). Deteco de falhas: Auditoria: varredura inconsistncias. Recuperao de falhas: Desfazer ou refazer operaes realizadas. de arquivos, apontando possveis
Manutenibilidade: diz respeito facilidade de alterao. Alteraes podem ter origem em: erros de especificao e/ou projeto; novas necessidades do usurio; alteraes no ambiente tecnolgico do usurio. Aes para aumentar a manutenibilidade: Definir normas e padres para interfaces com o usurio, relatrios, mensagens, codificao e nomenclatura de arquivos, mdulos e programas. Documentar Modularizar
Economia: o custo deve ser adequado ao escopo do software. Fatores que podem aumentar a economia incluem: Reutilizao: parcial de programa (cpia e alterao), de mdulos, de mdulos de biblioteca, de projeto. Ferramentas CASE Documentao
1.5 Tecnologia Imperfeita e Requisitos Tecnolgicos

Em funo das limitaes da tecnologia, devemos tomar decises que adicionam os requisitos tecnolgicos essncia do sistema. Limitaes da tecnologia: Custo Capacidade de armazenamento Velocidade de processamento Aptido dos processadores: processador matemtico, para comunicao entre processadores, etc. A tecnologia passvel de falha. Uso de processadores diferentes / Distribuio / Comunicao Redundncia: repetio de atividades e dados; incluso de dados derivados (por exemplo, totalizadores) Novas atividades e funes acrescidas em funo da imperfeio da tecnologia.
Impactos da tecnologia imperfeita:
Levantamento dos Requisitos Tecnolgicos junto aos Usurios: Localizao geogrfica de usurios / Transporte de dados Problemas operacionais nas atividades dos usurios Definio do ambiente de hardware e software de produo: Freqncia de disparo das atividades Volume de dados (inicial, estimativa de crescimento, poltica de esvaziamento) Tempo de resposta Restries tcnicas (novo ambiente?) Restries ambientais (temperatura, etc.) Requisitos de confiabilidade (tempo mnimo entre falhas) Restries de segurana (classes de usurios e acesso) Interface com o usurio
Referncias (Pressman, 2002) (Rocha et al., 2001) Engenharia de Software. Roger S. Pressman, traduo da 5a edio, Mc Graw Hill, 2002. Qualidade de Software: Teoria e Prtica. Ana Regina C. da Rocha, Jos Carlos Maldonado, Kival Chaves Weber, So Paulo: Prentice Hall, 2001.
(Xavier et al., 1995) Projetando com Qualidade a Tecnologia de Sistemas de Informao. Carlos Magno da S. Xavier, Carla Portilho, Livros Tcnicos e Cientficos Editora, 1995.
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
2. Projeto Arquitetural
Referncias: Cap.8 (Ruble, 1997), Caps. 2 e 3 (Xavier et al., 1995) O modelo de arquitetura mapeia os requisitos essenciais da fase de anlise em uma arquitetura tcnica. Uma vez que muitas arquiteturas diferentes so possveis, o propsito do projeto arquitetural escolher a melhor configurao (ou talvez a menos pior). O processo de projetar a arquitetura inclui: a coleta de estatsticas de volumes de dados, freqncia de disparo de eventos e expectativas de tempos de resposta para o modelo essencial, a documentao da topologia geogrfica do negcio, a determinao da distribuio geogrfica dos locais de computao, a definio do particionamento de dados e processos entre os locais de computao, a determinao do trfego em rede e tamanho das bases de dados para vrias configuraes, e a validao do modelo de arquitetura contra o modelo essencial.
2.1 Objetivos do Projeto Arquitetural

At o projeto arquitetural, a questo do hardware ainda no foi tratada, j que na fase de anlise pressupe-se tecnologia perfeita. Este o momento para resolver como este modelo ideal ir executar em uma plataforma restrita. importante realar que no existe a soluo perfeita. O projeto da arquitetura uma tarefa de negociao, onde se faz compromissos entre solues sub-timas. Em suma, o projeto arquitetural consiste na alocao do modelo essencial de requisitos em uma tecnologia especfica, determinando que processos rodaro em quais processadores, onde os dados sero armazenados e quanta comunicao entre processadores ser necessria. Ao trmino do projeto arquitetural, a equipe de desenvolvimento deve ter determinado: a distribuio geogrfica dos requisitos computacionais, os componentes de hardware para as mquinas clientes, os componentes de hardware para as mquinas servidoras, a configurao e o nmero de camadas de hardware cliente-servidor, a plataforma de software de implementao, incluindo linguagens de codificao e apresentao (interface com o usurio), sistemas operacionais, os mecanismos e linguagens de comunicao em rede e sistema gerenciador de banco de dados,
8
a localizao ou localizaes dos processos, a localizao ou localizaes dos dados fsicos e as estratgias de sincronizao para dados distribudos geograficamente.
Muitas dessas decises j tero sido tomadas previamente, seja por uma ordem da gerncia, seja pelo fato da organizao j possuir uma plataforma de hardware e software para implementao. Assim, o projeto de arquitetura a busca por um meio menos objetvel de atingir os requisitos do negcio, reconhecendo as limitaes da plataforma a ser utilizada.
2.2 A Arquitetura Cliente-Servidor

A computao cliente-servidor um processamento cooperativo de informaes de negcio por um conjunto de processadores, no qual mltiplos clientes geograficamente distribudos iniciam requisies que so realizadas por um ou mais servidores centrais. Primordialmente, o termo cliente-servidor usado para descrever software que executa em mais de um hardware de modo a realizar uma tarefa do negcio. A separao de hardware a norma em aplicaes cliente-servidor, embora algumas pessoas utilizem o termo para descrever diferentes componentes de software se comunicando uns com os outros, ainda que rodando em uma mesma mquina. A distncia entre processadores remotos varia desde computadores localizados na mesma sala ou prdio, at aqueles localizados em diferentes prdios, cidades ou mesmo espalhados pelo planeta. Atualmente, h muitos tipos diferentes de processadores, que podem ser melhor utilizados para serem clientes ou servidores. Mquinas de grande porte (mainframes), por exemplo, so poderosas, mas requerem grande habilidade para oper-las e so subutilizadas para uma ampla variedade de requisies comuns. Computadores pessoais (PCs), por sua vez, so bem melhores para gerenciar de apresentaes (interface com o usurio), necessitam de menos habilidades do usurio para oper-los e provem processamento eficiente e barato para muitas das tarefas de uma organizao.
Figura 2.1 Onde fazer uma torrada? Em uma torradeira ou em um fogo industrial?
2.2.1 - Camadas de Hardware Cliente-Servidor O uso mais comum para arquiteturas cliente-servidor explorar o poder dos PCs para gerenciar interfaces grficas com o usurio, mantendo a integridade dos dados do negcio em uma mquina hospedeira central. Em sua forma mais simples, a arquitetura clienteservidor envolve mltiplos clientes fazendo requisies para um nico servidor, como mostra a figura 2.2. Este modelo mostra uma arquitetura de hardware em duas camadas (two-tier). fcil imaginar que, nesta arquitetura de hardware, a poro software de interface ficar no cliente, enquanto o armazenamento de dados dever ser feito em um ou mais servidores centrais. Mas e o restante da aplicao? No h respostas fceis. Antes de explorar as possibilidades, vamos complicar um pouco mais a questo, introduzindo mais camadas na arquitetura cliente-servidor.
Clientes
Servidor Central
Figura 2.2 Uma arquitetura de hardware cliente-servidor em duas camadas. A figura 2.3 mostra uma arquitetura cliente-servidor em trs camadas, na qual mquinas-cliente esto conectadas via uma rede local a um servidor local de aplicao que, por sua vez, se comunica com um servidor de dados central.
Clientes
Servidor Central
Servidor Local de Aplicao
Figura 2.3 Uma arquitetura de hardware cliente-servidor em trs camadas.

10
Em uma arquitetura de trs camadas, a noo de cliente e servidor comea a se tornar nebulosa. Um PC que hospeda uma aplicao de interface certamente um cliente e a mquina hospedeira da base de dados certamente um servidor. Mas e o servidor local de aplicao? Ele algumas vezes um cliente e outras um servidor, dependendo da direo de comunicao. Esta arquitetura pode ser estendida para n camadas (n-tier), como mostra a figura 2.4. Nestes casos, a distino entre cliente estrito e servidor estrito destruda, tornando o termo um padro conceitual.
Servidor Locais de Arquivo
Clientes
Servidor Central
Figura 2.4 Uma arquitetura de hardware cliente-servidor em n camadas. 2.2.2 - Camadas de Software Cliente-Servidor Para discutir o desenvolvimento de software em uma arquitetura multi-camada de hardware, necessrio primeiro dissecar a aplicao de software em camadas. Os componentes de uma aplicao de negcio podem ser agrupados em pelo menos trs categorias principais, como mostra a figura 2.5: Camada de Apresentao: a camada mais externa do sistema de software. Sua funo capturar estmulos de eventos externos e realizar alguma edio dos dados de entrada. encarregada tambm de apresentar respostas aos
11
eventos para o mundo exterior. Geralmente, localizada em uma mquina cliente, tal como um PC, entretanto, esta no uma regra rigorosa. Camada de Lgica do Negcio: contm o cdigo que executa e impe a poltica do negcio. Regras, regulamentos e clculos so encontrados nesta camada. a camada mais mvel, podendo ser localizada em clientes remotos, no servidor central ou em qualquer outro local intermedirio. Camada de Gerncia de Dados: prov acesso a dados corporativos. Gerencia requisies concorrentes de acesso s bases de dados, assim como a sincronizao de elementos de dados distribudos. Muito desta camada estar no mesmo local fsico que os dados.
If .... Then .... Else .... If .... Then .... Else ....
Camada de Apresentao Camada de Lgica do Negcio
Camada de Gerncia de Dados
Figura 2.5 Camadas de Software 2.2.3 - Cliente Pesado x Servidor Pesado Uma classificao, relativamente incorreta, tem sido para utilizada para designar a filosofia adotada em um projeto no que se refere localizao da maior parte da camada de lgica do negcio. O termo cliente pesado indica que a camada de lgica do negcio colocada principalmente na mquina cliente e o servidor dedicado ao acesso, distribuio e armazenamento de dados, respondendo a requisies de clientes. O termo servidor pesado descreve uma alocao de responsabilidades na qual o cliente limitado apresentao da interface e edio mnima, enquanto a maior parte da lgica de negcio e a imposio de regras so executadas no servidor central. claro que esta uma viso muito simplificada, j que arquiteturas cliente-servidor em n-camadas podem suportar uma gama de complexa de camadas de software.
12
A primeira gerao de ferramentas populares de desenvolvimento de aplicaes cliente-servidor com interfaces grficas assumia uma arquitetura de hardware de duas camadas e encorajava uma abordagem de projeto arquitetural de software do tipo cliente pesado, onde a lgica do negcio era totalmente amarrada camada de apresentao da aplicao. Estas mesmas ferramentas tm sido utilizadas, em um segundo momento, com uma filosofia do tipo servidor pesado, onde a lgica de negcio fortemente mapeada no servidor de dados, na forma de stored-procedures e triggers em bancos de dados. Respondendo s demandas por linguagens mais flexveis de desenvolvimento, a segunda gerao de ferramentas desta natureza reconhece a necessidade de separar a camada de lgica do negcio. Esta separao traz vrias vantagens, como reusabilidade, portabilidade e manutenibilidade. A reusabilidade tem sido apontada como a principal razo para a separao. Classes de apresentao so extremamente fceis de reutilizar dada sua natureza altamente mecnica. Classes de negcio, por outro lado, so altamente complexas e podem desempenhar diferentes papis dentro dos sistemas corporativos. A meta criar classes que garantam todas as regras de negcio para uma particular classe de negcio e reutiliz-la em todos os contextos que lidem com a mesma. Esta abordagem possvel em uma filosofia de servidor pesado, mas impossvel em uma de cliente pesado. A portabilidade a segunda razo para se efetuar a separao. A habilidade de mover a lgica de negcio ao longo da arquitetura cliente-servidor permite que se tire proveito de diferentes plataformas de hardware e software, sem ter que reescrever grandes pores do cdigo. Finalmente, a separao favorece a manuteno, j que concentra a lgica de negcio em uma camada nica da arquitetura de software, facilitando a localizao das alteraes e evolues a serem feitas no sistema.
2.3 Coletando Estatsticas e Restries

Determinar a arquitetura mais apropriada para um sistema envolve a quantificao da capacidade de computao necessria para o problema. O modelo de anlise prov uma infra-estrutura confivel para a realizao de estimativas dos requisitos de computao do sistema final. Assim, a primeira atividade do projeto arquitetural consiste em completar esta infra-estrutura, coletando informaes estatsticas importantes. 2.3.1 Coletando Estatsticas sobre o Modelo de Informao A coleta de estatsticas sobre um modelo de informao um modelo que descreve o sistema sob a tica das informaes que o mesmo precisa manipular, tal como um modelo de Entidades e Relacionamentos ou um Diagrama de Classes extremamente importante para a definio da arquitetura do software. A meta principal deste passo estimar o tamanho de uma base de dados. Para o projeto de um banco de dados relacional, duas informaes so essenciais: o tamanho das
13
colunas e o nmero estimado de linhas que podero acumular ao longo do tempo. Estes nmeros so relativamente simples de serem obtidos. Para determinar o tamanho das colunas, deve-se definir o tipo de dados para cada atributo da entidade/classe. Para estimar com certa preciso o nmero de bytes de uma nica linha, basta somar o nmero de bytes para cada atributo da entidade/classe e adicionar o nmero de bytes da chave primria (se ela no for um atributo da entidade/classe) e das chaves estrangeiras, ou transpostas, que mapeiam os relacionamentos. A estimativa do nmero de linhas esperadas para cada tabela no to simples. Algumas entidades/classes resultaro na criao de tabelas de controle, tais como Estado Civil e Pas. O nmero de instncias nestas entidades/classes relativamente fixo e, portanto, fcil de ser estimado. Contudo, mais importante estimar o volume de dados para tabelas de transaes, tais como Pedido e Itens de Pedido. Para estes casos, um modelo de eventos (por exemplo, modelo de casos de uso) pode nos dizer quais eventos criam instncias destes tipos. Para estimar o tamanho dessas tabelas, necessrio saber quo freqentemente o caso de uso ocorre. Esta estimativa deve ser obtida junto aos usurios. Alm disso, necessrio determinar o perodo de reteno da informao sobre uma instncia. Em suma, colete as seguintes informaes para cada entidade/classe do modelo de informao: tamanho estimado, em bytes, de uma instncia, calculado pelo somatrio dos tipos de dados de cada atributo, adicionado da estimativa para as chaves primria e estrangeiras, taxa de ocorrncia dos casos de uso que criam novas instncias da entidade/classe, perodo de reteno.
Estas estatsticas so usadas para estimar os recursos necessrios para alojar adequadamente a base de dados. Mesmo se espao em disco no for um problema para o projeto, elas so teis para outros aspectos. Este problema torna-se mais complicado quando o repositrio fsico dos dados est geograficamente remoto do evento que necessita de seus dados. Uma vez que importante saber que tipo de operao um caso de uso pode realizar em uma entidade/classe, til produzir uma matriz CERA (Criar, Eliminar, Recuperar, Atualizar) Caso de Uso/Classe (ou Caso de Uso/Entidade), mostrando se, por ocasio da ocorrncia do caso de uso, o sistema necessitar criar, atualizar, recuperar ou eliminar instncias da entidade/classe.
14
Caso de Uso\Classe Efetuar pedido Cancelar pedido Alterar pedido
Cliente R R R
Pedido C RE RA
Item de Pedido C RE CERA
Figura 2.6 Exemplo de uma Matriz CERA Caso de Uso/Classe. 2.3.2 Coletando Estatsticas sobre o Modelo de Eventos Um modelo de eventos aquele que captura as funcionalidades de um sistema segundo uma perspectiva exterior, isto , dos usurios. A lista de eventos da Anlise Essencial ou o modelo de casos de uso na Orientao a Objetos so exemplos de modelos de eventos. Alguns casos de uso so bem mais crticos do que outros no que diz respeito importncia do sistema ser hbil para responder rapidamente. Pode-se fazer anotaes com estatsticas sobre o modelo de eventos para capturar a freqncia de ocorrncia (ou disparo) e o tempo de resposta desejado para um evento. O objetivo identificar os eventos crticos, j que eles sero objeto de exame minucioso. Para esses, deve-se levantar a freqncia mdia de ocorrncia, a taxa de pico e o perodo de tempo do pico. A freqncia mdia de disparo nos diz apenas o nvel normal de ocorrncia para um evento. Esta informao suficiente para eventos uniformes, isto , aqueles cuja freqncia de disparo tende a ser mesma ao longo do todo tempo. Para eventos irregulares, contudo, necessrio conhecer as taxas de pico e o perodo em que estes picos ocorrem. A principal questo a ser colocada sobre este assunto : o sistema tem que ser dimensionado para tratar picos, de modo a sempre atender satisfatoriamente s necessidades dos usurios? Se o sistema for dimensionado pela capacidade de pico, provavelmente ele ficar ocioso grande parte do tempo. Por outro lado, se for dimensionado pela mdia, nos momentos de pico no atender totalmente s necessidades dos usurios. Esta no uma deciso fcil e no deve ser tomada apenas pelo pessoal de desenvolvimento. Ao contrrio, esta deciso cabe, principalmente, ao cliente. De maneira geral, a menos que o custo seja proibitivo, a maioria das organizaes prefere gastar mais dimensionando o sistema pelo pico, evitando inconvenientes para os usurios. Uma alternativa criativa, mas nem sempre possvel, consiste em tentar suavizar o pico de alguns eventos, oferecendo incentivos para os usurios utilizarem o sistema fora do perodo de pico. No necessrio analisar todos os eventos de um modelo de eventos, coletando estatsticas para todo o sistema. Devemos nos concentrar nos principais casos de uso do negcio, aqueles com os maiores impactos sobre o cliente, com os maiores volumes de dados e com as localizaes mais remotas geograficamente.
15
Outro aspecto muito importante sobre casos de uso diz respeito aos requisitos de desempenho. Uma caracterstica de qualidade recorrente para sistemas de informao o tempo de resposta. O tempo de resposta mximo aceitvel deve ser definido para cada evento/caso de uso. Novamente, uma boa dose de bom senso necessria. A equipe do projeto deve concentrar seus esforos sobre os eventos de negcio mais importantes, ou seja, aqueles que ocorrem com maior freqncia e tm mais impactos para os clientes e usurios. O tempo de resposta pode ser medido tanto no nvel de evento do negcio quanto no nvel de dilogo. No nvel de evento do negcio, a mtrica de tempo de resposta mede o tempo entre a recepo do estmulo inicial do evento at a emisso da resposta final. No nvel de dilogo, a mtrica de tempo de resposta mede o tempo que o sistema leva para responder a um dilogo/consulta, que pode ser apenas uma poro do caso de uso total. Obviamente, quando o tempo de resposta expresso no nvel de dilogo, o projetista se depara com uma situao bem mais restrita. 2.3.3 Determinando Requisitos de Distribuio Geogrfica O prximo passo do projeto arquitetural consiste em examinar a distribuio geogrfica dos casos de uso, o que conduz naturalmente distribuio necessria ao acesso dos dados. Juntos, a freqncia de disparo dos casos de uso, volume de dados, restries de tempo de resposta e a distribuio geogrfica do negcio formaro a base para se determinar uma arquitetura aceitvel para o sistema em questo. Algumas matrizes podem ser usadas para mapear o modelo de anlise na topologia de localizaes do negcio. Uma matriz Caso de Uso/Localizao do Negcio, como a mostrada na figura 2.7, juntamente com uma matriz Caso de Uso/Classe (ou Evento/Entidade), como a mostrada na figura 2.6, permitem mapear as necessidades de distribuio geogrfica da computao de uma organizao. Caso de Uso /Localizao Efetuar pedido Cancelar pedido Alterar pedido X X Internet Vitria X X X Linhares X Cachoeiro X
Figura 2.7 Exemplo de uma Matriz Caso de Uso/Localizao do Negcio. A partir dessas duas matrizes, uma terceira pode ser derivada. Uma vez que se conhece a distribuio geogrfica dos eventos e os requisitos de acesso a dados de cada evento, possvel derivar a distribuio geogrfica dos requisitos de acesso a dados, a matriz CERA Localizao do Negcio/Classe (Entidade), como mostra o exemplo da figura 2.8. Esta matriz mostra exatamente que localizaes do negcio precisam criar, recuperar, atualizar ou eliminar instncia de cada uma das entidades/classes do sistema. Com esta informao possvel comear a avaliar potenciais solues arquiteturais.
16
Localizao/Classe Internet Vitria Linhares Cachoeiro
Cliente R R R R
Pedido ERA CERA C C
Item de Pedido CERA CERA C C
Figura 2.8 Exemplo de uma Matriz CERA Localizao/Classe. Uma variao til da matriz CERA Caso de Uso/Classe (Evento/Entidade) a matriz de Aceitao Caso de Uso/Classe (ou Evento/Entidade), mostrada na figura 2.9. Ela mostra quo atualizada uma base de dados deve estar para atender um determinado caso de uso. O valor zero indica que a base de dados deve refletir instantaneamente a atualizao feita mais recentemente. Caso de Uso/Classe Efetuar pedido Cancelar pedido Alterar pedido Cliente 48 48 48 Pedido 0 0 0 Item de Pedido 0 0 0
Figura 2.9 Exemplo de uma Matriz de Aceitao Caso de Uso/Classe (em horas). Da mesma forma que as matrizes Caso de Uso/Localizao e CERA Caso de Uso/Classe foram combinadas para derivar uma matriz CERA Localizao/Classe, as matrizes Caso de Uso/Localizao e de Aceitao Caso de Uso/Classe podem ser combinadas para derivar uma matriz de Aceitao Localizao/Classe para mostrar a necessidade de acesso a dados remotos, como mostra a figura 2.10. Localizao/Classe Internet Vitria Linhares Cachoeiro Cliente Pedido 0 0 0 0 Item de Pedido 0 0 0 0
Figura 2.10 Exemplo de uma Matriz de Aceitao Localizao/Classe. Esta matriz mostra uma viso muito geral, j que no revela o fato de apenas certos atributos serem acessados em certas localizaes. Esta viso pode ser refinada, construindo matrizes para cada entidade/classe, mostrando que atributos so usados em que localizaes. A anlise da distribuio de dados no nvel de atributo necessria apenas quando os problemas forem muito complexos e distribudos.
17
2.4 Estratgias de Acesso Oportuno a Dados

Uma vez levantadas as necessidades de acesso a dados de cada localizao do negcio, pode-se avaliar qual a melhor estratgia para a distribuio dos mesmos. A seguir, as principais estratgias so discutidas. 2.4.1 Uma nica Base de Dados Centralizada A primeira opo de soluo a ser considerada para a distribuio de dados consiste em, contraditoriamente, no distribu-los de fato. Uma nica cpia dos dados mantida em uma localizao central e todas as aplicaes que necessitem acess-los devem fazer suas consultas e atualizaes no servidor central. Os benefcios so numerosos: fcil fazer cpias de segurana dos dados quando uma nica cpia existe. O projeto do sistema total menos complicado, por exemplo, a segurana mantida centralmente e nenhuma rotina de sincronizao requerida. Os dados so sempre atuais. No h dados redundantes ao longo das localizaes do negcio.
Entretanto, as desvantagens podem ser significativas no desenvolvimento de uma aplicao geograficamente remota: At os dias atuais, muitas tecnologias de comunicao de dados no so ainda rpidas o suficiente ou so muito caras para aplicaes de grande escala. As estatsticas coletadas de volume de dados e freqncia de disparo de eventos quando comparadas com a capacidade de comunicao da rede podem dizer se o acesso remoto a dados vivel. Tem-se um grande problema se o servidor central ou as linhas de comunicao carem. Neste caso, os locais remotos ficaram efetivamente sem processamento.
Desempenho inaceitvel e risco de queda so os dois fatores que fazem com que negcios muitas vezes descartem bases de dados centralizadas. 2.4.2 Dados Descentralizados e Replicados De um lado diretamente oposto, a base de dados pode ser completamente replicada em todos os locais que dela necessitem. Atualizaes em um local podem ser irradiadas (broadcast) para outros locais em tempo real. Com esta estratgia, h vrios benefcios bvios: O projeto das aplicaes locais simplificado por ter acesso a dados locais. O tempo de resposta para cada transao no onerado pelo alto trfego em rede. Incentiva proprietrios locais de dados e prov acesso local rpido.
18
As desvantagens, contudo, envolvem muitas complicaes: O trfego global na rede aumenta devido replicao de dados em todos os locais. Rotinas complexas de sincronizao so necessrias para manter as vrias cpias da base de dados atualizadas. Podem surgir problemas se o mesmo registro for atualizado em dois locais. Se um dos servidores cair ou o software de replicao falhar, pode ser difcil reconstruir o conjunto dos dados e reaplicar atualizaes na ordem correta. Qual base de dados a principal? Procedimentos de back-up tornam-se mais complexos. Dados completamente replicados podem conduzir a redundncia desnecessria de dados.
Fragmentao Um compromisso freqentemente sugerido entre a centralizao e a replicao totais. A distribuio dos dados otimizada de modo que apenas os dados necessrios por cada local so mantidos locais. Esta estratgia chamada fragmentao e pode ser vertical ou horizontal. A fragmentao vertical ocorre quando apenas certas tabelas ou colunas so fisicamente distribudas a locais remotos. Cada localizao possui apenas aquelas tabelas ou colunas que so requeridas pelos eventos que ocorrem no mesmo. Isto reduz trfego em rede, pois apenas os elementos de dados necessrios precisam ser sincronizados com outros locais. Entretanto, esta estratgia pode ser bastante complexa para gerenciar. Os procedimentos de replicao devem ser capazes de sincronizar atualizaes coluna-porcoluna em diferentes locais. A fragmentao horizontal ocorre quando apenas certas linhas em uma tabela so fisicamente distribudas a locais remotos. Esta estratgia empregada tipicamente quando localizaes tm seus prprios dados que no so manipulados em outras localizaes. Cada localizao tem sua cpia completa do esquema de banco de dados. As estruturas das tabelas em cada localizao so idnticas, mas as linhas de dados que povoam estas tabelas podem ser diferentes. Geralmente, h uma base de dados principal que contm todos os registros. Assim como a fragmentao vertical, a horizontal diminui o trfego na rede, eliminando transferncias de dados desnecessrias. Contudo, o processo de sincronizao tambm de alguma forma complicado, principalmente quando diferentes locais compartilham alguns registros. Uma combinao dos dois tipos de fragmentao apresentados anteriormente pode ser utilizada. Bases de dados distribudas compartilham os mesmos tipos de entidades lgicas, mas possuem diferentes colunas e linhas. Cada local possui apenas as colunas e linhas que so realmente necessrias para os eventos que ocorrem ali. fcil perceber que tal estratgia quando levada ao extremo pode ser muito difcil de gerenciar.
19
2.5 Sumrio da Determinao da Distribuio Geogrfica

Os modelos criados durante a fase de anlise provem uma riqueza de informao para a determinao dos requisitos de distribuio geogrfica de um sistema. Podemos comear coletando estatsticas para determinar o tamanho total da base de dados. Esta informao crtica, no s para a determinao da necessidade de espao em disco, mas tambm para situaes onde os dados so fisicamente distribudos. Neste caso, o tamanho dos registros e a freqncia de disparo dos eventos permitiro estimar o trfego em rede. Estatsticas capturadas do modelo de eventos incluem a freqncia mdia de disparo dos eventos, taxas de pico para eventos irregulares e expectativas de tempo de resposta. De posse destas estatsticas, o prximo passo consiste em aplic-las topologia de localizao do negcio. Vrias matrizes tm se mostrado teis para modelar este aspecto do sistema, tais como matrizes Casos de Uso/Localizao Geogrfica, matrizes CERA Caso de Uso/Classe e matrizes CERA Localizao do Negcio/Classe. Uma vez que os requisitos de acesso a dados foram determinados, informao adicional pode ajudar a equipe de projeto a efetuar escolhas arquiteturais slidas. Matrizes de aceitao, por exemplo, mostram quo antiga uma entidade pode ser para um dado evento ocorrendo em uma localizao. Isto pode ajudar a decidir se uma rotina de sincronizao em tempo real necessria ou se uma rotina de atualizao batch suficiente. Conhecidos o tamanho dos registros, a taxa dos eventos que criam, lem, atualizam e eliminam estes registros e a distncia entre os locais do negcio, a equipe pode, enfim, explorar suas opes arquiteturais. Estratgias de distribuio de dados variam desde completamente centralizada a completamente distribuda. Qualquer que seja a escolha feita, ela deve respeitar, acima de tudo, as necessidades dos usurios.
2.6 Segurana
A segurana contra acessos indevidos tem como objetivo no permitir que pessoas no autorizadas tenham acesso a eventos ou aos dados. Para controlar o acesso, necessrio identificar, autenticar e autorizar usurios. A identificao se d atravs de um cdigo unvoco capaz de identificar apenas um usurio. A autenticao consiste em comprovar que o usurio mesmo quem ele diz ser na identificao, sendo feita, normalmente, por uma senha. Finalmente, a autorizao dada ao usurio, ou a uma classe de usurios, dando acesso a determinados eventos, dados para leitura/escrita e tipos de transaes. Um caso de uso de cunho tecnolgico tem de ser adicionado lista de eventos/ modelo de casos de uso, para permitir definir classes de usurios e seus perfis, incluir, excluir ou alterar usurios, alm, claro, das atividades de identificao, autenticao e autorizao de usurios. Uma matriz Caso de Uso / Classe de Usurio pode ser utilizada para documentar o nvel de autorizao adotado no projeto, como mostra a figura 2.11.
20
Caso de Uso/Classe Usurio Efetuar pedido Cancelar pedido Alterar pedido Solicitar relatrio de pedidos
Cliente X X
Gerente X X X X
Funcionrio X X X
Figura 2.11 Exemplo de uma Matriz de Caso de Uso/Classe de Usurio. Outra atividade que deve ser adicionada ao projeto a deteco da ocorrncia de violaes. Muitas vezes s percebemos que um sistema foi violado aps o ocorrido. Quando for necessrio maior nvel de segurana, importante criar um procedimento de monitorao que registre os usurios que acessaram o sistema e os casos de uso por eles realizados. O arquivo que guarda essas informaes chamado de histrico (log). Para consulta a esse arquivo, necessrio criar mais um caso de uso de cunho tecnolgico, a auditoria.
2.7 Modelo de Tarefas

Mesmo quando um sistema no ser distribudo geograficamente, til definir tarefas ou unidades de execuo, isto , conjunto de casos de uso essenciais e tecnolgicos agrupados em uma unidade, do ponto de vista de execuo pelo sistema operacional. O padro para empacotamento em tarefas o agrupamento de casos de uso por tipo de processador, isto , todos os casos de uso que devam rodar em um mesmo tipo de mquina so agrupados em uma tarefa. Porm, em alguns casos, podem ser necessrias mais tarefas, tal como: Quando existir uma classe de usurios especfica, cujos casos de uso autorizados sejam de seu nico acesso e interesse. Quando usurios esto dispersos geograficamente, como discutido anteriormente. No h memria disponvel suficiente para que a tarefa rode eficientemente. Casos de uso so realizados uma nica vez (ou muito poucas vezes), tais como converso de dados e instalao do sistema.
A principal estratgia para agrupar casos de uso em tarefas consiste em fazer um levantamento sobre o modo de utilizao do sistema, o tempo de resposta esperado, o tamanho e nmero de casos de uso, aspectos de segurana e facilidade de uso, como discutido para o caso da distribuio geogrfica.
21
2.8 Atividades Tecnolgicas

Em decorrncia das imperfeies e limitaes da tecnologia (requisitos tecnolgicos), novos casos de uso podem ser adicionados ao modelo de eventos, tais como, as atividades de segurana anteriormente relacionadas, limpeza, reorganizao, cpia e restaurao de arquivos e facilidades de ajuda (help). bom lembrar que todo caso de uso tecnolgico projetado decorrente de um requisito tecnolgico acrescido ao sistema, mas nem todo requisito tecnolgico necessariamente implica na criao de um caso de uso tecnolgico. Algumas destas funcionalidades podem ser melhor caracterizadas como procedimentos tecnolgicos, constando no interior da especificao de um ou mais casos de uso (essenciais ou tecnolgicos) do sistema.
Referncias: (Ruble, 1997) Practical Analysis and Design for Client/Server and GUI Systems. David A. Ruble, Yourdon Press Computing Series, 1997.
(Xavier et al., 1995) Projetando com Qualidade a Tecnologia de Sistemas de Informao. Carlos Magno da S. Xavier, Carla Portilho, Livros Tcnicos e Cientficos Editora, 1995.
22
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 3 Projeto de Interface com o Usurio
3 - Projeto de Interface com o Usurio

A maioria dos sistemas atuais desenvolvida para ser utilizada por pessoas. Assim, um aspecto fundamental no projeto de sistemas a interface com o usurio (IU). Nesta etapa do projeto, so definidos os formatos de janelas e relatrios, entre outros, sendo a prototipagem bastante utilizada, buscando auxiliar o desenvolvimento e a seleo dos mecanismos reais de interao. A IU capta como um usurio comandar o sistema e como o sistema apresentar as informaes a ele. O princpio bsico para o projeto de interfaces com o usurio, em geral, o seguinte: Conhea o usurio e as tarefas. O projeto de interface com o usurio envolve no apenas aspectos de tecnologia (facilidades para interfaces grficas, multimdia, etc), mas principalmente o estudo das pessoas. Quem o usurio? Como ele aprende a interagir com um novo sistema? Como ele interpreta uma informao produzida pelo sistema? O que ele espera do sistema? Estas so apenas algumas das muitas questes que devem ser levantadas durante o projeto da interface com o usurio (Pressman, 2002). De maneira geral, o projeto de interfaces com o usurio segue o seguinte processo global, como mostra a figura 3.1: 1. Delinear as tarefas necessrias para obter a funcionalidade do sistema: este passo visa capturar as tarefas que as pessoas fazem normalmente no contexto do sistema e mape-las em um conjunto similar (mas no necessariamente idntico) de tarefas a serem implementadas no contexto da interface homem-mquina. 2. Estabelecer o perfil dos usurios: A interface do sistema deve ser adequada ao nvel de habilidade dos seus futuros usurios. Assim, necessrio estabelecer o perfil destes potenciais usurios e classific-los segundo aspectos como nvel de habilidade, nvel na organizao e membros em diferentes grupos. Uma classificao possvel considera os seguintes grupos: Usurio Novato: no conhece os mecanismos de interao requeridos para utilizar a interface eficientemente (conhecimento sinttico) e conhece pouco a aplicao em si, isto , entende pouco as funes e objetivos do sistema (semntica da aplicao); Instrudo, mas intermitente: possui um conhecimento razovel da semntica da aplicao, mas tem relativamente pouca lembrana das informaes sintticas necessrias para utilizar a interface; Instrudo e freqente: possui bom conhecimento tanto sinttico quanto semntico e buscam atalhos e modos abreviados de interao. 3. Considerar aspectos gerais de projeto de interface, tais como tempo de resposta, facilidades de ajuda, mensagens de erro, tipos de comandos, entre outros. 4. Construir prottipos e, em ltima instncia, implementar as interfaces do sistema, usando ferramentas apropriadas. A prototipao abre espao para uma abordagem iterativa de projeto de interface com o usurio, como mostra abaixo. Entretanto, para tal imprescindvel o suporte de ferramentas para a construo
23
de interfaces, provendo facilidades para manipulao de janelas, menus, botes, comandos, etc... 5. Avaliar o resultado: Coletar dados qualitativos e quantitativos (questionrios distribudos aos usurios do prottipo).
Projeto Preliminar
Construo do 1o Prottipo
Construo do no Prottipo
Avaliao do Usurio
Modificaes do Projeto de Interface
Estudo da Avaliao pelo Projetista
Projeto de Interface Completo
Figura 3.1 - Abordagem Iterativa para o Projeto de Interface com o Usurio.
3.1 Aspectos Gerais de Interface com o Usurio

Com relao aos aspectos gerais de um projeto de interface, citados no item 3, devemos considerar, pelo menos, o seguinte conjunto: Tempo de Resposta: importante mostrar o progresso do processamento para os usurios, principalmente para eventos com tempo de resposta longo ou com grande variao de tempos de resposta. Facilidade de Ajuda (Help): Definir: quando estar disponvel e para que funes do sistema; como ativar (boto, tecla de funo, menu); como representar (janela separada, local fixo da tela); como retornar interao normal (boto, tecla de funo); como estruturar a informao (estrutura plana, hierrquica, hipertexto).
24
Mensagens de Erro e Avisos: Devem: descrever o problema com um vocabulrio passvel de entendimento pelo usurio; prover assistncia para recuperar o erro; indicar quaiquer conseqncias negativas do erro; ser acompanhadas de uma dica visual ou sonora; ser sem censura ao usurio. Tipos de Comandos: Em muitas situaes deve-se prover ao usurio a opo de utilizao de comandos. Nestes casos, definir e avaliar: se toda opo de menu ter um comando correspondente; a forma do comando (controle de seqncia (^Q), teclas de funo (F1), palavra); quo difcil aprender e lembrar o comando; possibilidade de customizao de comandos (macros); padres para todo sistema e conformidade com outros padres. Algumas orientaes adicionais devem ser consideradas e so listadas na seqncia. Diretrizes Gerais: Seja consistente (formato consistente para seleo de menus, entrada de comandos, apresentao de dados, ...); Oferea retorno significativo ao usurio (comunicao com o usurio); Pea confirmao para aes destrutivas (deletar arquivo, sobrepor informao, terminar a aplicao,...); Permita reverso fcil da maioria das aes (funo UNDO); Reduza a quantidade de informao que precisa ser memorizada entre aes; Busque eficincia no dilogo (movimentao, teclas a serem apertadas); Trate possveis erros do usurio (o sistema deve se proteger de erros, casuais ou no, provocados pelo usurio); Classifique atividades por funo e organize geograficamente a tela de acordo (menus pull-down); Proveja facilidades de ajuda sensveis ao contexto; Use verbos de ao simples ou frases verbais curtas para nomear funes e comandos.
25
Diretrizes para Apresentao de Informao Mostre apenas informaes relevantes ao contexto corrente; Use formatos de apresentao que permitam assimilao rpida da informao (grficos, figuras, etc.); Use rtulos consistentes, abreviaturas padro e cores previsveis; Produza mensagens de erro significativas; Projete adequadamente o layout de informaes textuais (letras maisculas e minsculas, identao, agrupamento de texto, etc.); Use janelas para separar diferentes tipos de informao; Use formas de representao anlogas s do mundo real para facilitar a assimilao da informao (figuras, cores, etc.). Diretrizes para a Entrada de Dados: Minimize o nmero de aes de entrada requeridas (seleo de dados a partir de um conjunto pr-definido de valores de entrada, macros, etc.); Mantenha consistncia entre apresentao e entrada de dados (caractersticas visuais: tamanho do texto, cor, localizao, etc.); Permita ao usurio customizar a entrada (comandos customizados, dispensar algumas mensagens de aviso e verificaes de aes, etc.); Flexibilize a interao, permitindo afin-la ao modo de entrada preferido do usurio (comandos, botes, plug-and-play, digitao, etc.); Desative comandos inapropriados para o contexto das aes correntes; Proveja ajuda para assistir todas as aes de entrada de dados; Proveja valores default, sempre que possvel; Nunca requeira que o usurio entre com uma informao que possa ser adquirida automaticamente pelo sistema ou computada por ele. Referncias (Pressman, 2002) Engenharia de Software. Roger S. Pressman, traduo da 5a edio, Mc Graw Hill, 2002.
26
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 4 Projeto de Bancos de Dados Relacionais
4. Projeto de Bancos de Dados Relacionais

Um aspecto fundamental da fase de projeto consiste em estabelecer de que forma sero armazenados os dados do sistema. Em funo da plataforma de implementao, diferentes solues de projeto devem ser adotadas. Isto , se o software tiver de ser implementado em um banco de dados hierrquico, por exemplo, um modelo hierrquico deve ser produzido, adequando a modelagem conceitual de dados (ER ou diagrama de classes) a esta plataforma de implementao. Atualmente, a plataforma de implementao para armazenamento de dados mais difundida a dos Bancos de Dados Relacionais e, portanto, neste texto, discutiremos apenas o modelo relacional.
4.1 - O Modelo Relacional

Em um modelo de dados relacional, os conjuntos de dados so representados por tabelas de valores. Cada tabela, denominada de relao, bidimensional, sendo organizada em linhas e colunas. Este modelo est fortemente baseado na teoria matemtica sobre relaes, da o nome relacional. Ex: Modelo E/R cursaram Alunos (0,N (0,N Disciplinas
Registros de Modelo Relacional Alunos Matrcula Nome 96100199 Jos 96100187 Maria 95100140 Luiza ... ... Registros de Histrico Matrcula Cdigo Perodo 96100199 INF2814 98/1 96100199 INF2777 97/2 95100140 INF2777 98/1 ... ... ... Nota 7.0 8.5 9.0 ... Disciplinas Cdigo Nome INF2814 Projeto INF2777 Anlise MAT1918 Clculo I ... ...
Figura 4.1 - Exemplo de um Modelo Relacional derivado a partir de um Modelo E/R.
27
Conceitos Bsicos Relao: Tabela de valores bidimensional organizada em linhas e colunas. Representa um conjunto de entidades do Modelo E/R ou uma classe em um Diagrama de Classes. Ex: Relao Funcionrios. Matrcula 0111 0208 0789 1589 ... Nome Marcos Rita Mnica Mrcia ... CPF 17345687691 56935101129 81176628911 91125769120 ... Endereo Vila Velha Vila Velha Vitria Serra ... Dt-Nasc 11/04/66 21/02/64 01/11/70 20/10/80 ... Dt-Adm 20/08/86 18/03/90 15/07/92 01/02/98 ...
Grau da Relao: Nmero de colunas da tabela. Ex: 6 Linha (Tupla): Representa uma entidade do conjunto de entidades, ou um objeto de uma classe. Ex: Funcionrio 0789 do conjunto de Funcionrios. Colunas: Representam os vrios atributos do conjunto de entidades ou classe. Ex: Matrcula, Nome, CPF, Endereo, Dt-Nasc, Dt-Adm. Clula: Item de dado elementar da linha i, coluna j. Ex: Vitria (linha 3, coluna 4) 01/02/98 (linha 4, coluna 6) Chave Primria: Atributo ou combinao de atributos que possuem a propriedade de identificar de forma nica uma linha da tabela. Corresponde a um atributo determinante do Modelo Conceitual. Ex: Matrcula Chaves Candidatas: Ocorrem quando em uma relao existe mais de uma combinao de atributos possuindo a propriedade de identificao nica. Ex: Matrcula, CPF Chave Estrangeira: Ocorre quando um atributo de uma relao for chave primria em outra relao. Ligaes: Representam os relacionamentos do Modelo E/R ou as associaes em um Diagrama de Classes. A ligao entre duas relaes feita, em geral, transportando-se a chave de uma relao para outra (item transposto), como ilustra a figura 4.2. Neste exemplo, a chave da tabela Departamentos foi transposta para a tabela Funcionrios. Assim, Departamentos denominada relao origem e Funcionrios relao destino. No caso de relacionamentos muitos-para-muitos, necessrio criar uma nova tabela, dita Tabela Associativa, que dever ter as chaves das duas tabelas relacionadas.
28
Modelo E/R (1,1) Departamentos lotam (1,N Funcionrios
Modelo Relacional Departamentos Cdigo Nome INF Informtica LET Letras MAT Matemtica ... ... Matrcula 0158 5295 7712 ... Funcionrios Nome Jos Ricardo Wilberth ... Cod-Depto MAT INF LET ...
Item Transposto Figura 4.2 - Exemplo de uma ligao entre tabelas, atravs da transposio de chaves. Propriedades do Modelo Relacional Nenhum campo componente de uma chave primria pode ser nulo; Cada clula de uma relao pode ser vazia (exceto de uma chave primria), ou ao contrrio, conter no mximo um nico valor; A ordem das linhas irrelevante; No h duas linhas iguais; Cada coluna tem um nome e colunas distintas devem ter nomes distintos; Usando-se os nomes para se fazer referncia s colunas, a ordem destas torna-se irrelevante; Cada relao recebe um nome prprio distinto do nome de qualquer outra relao da base de dados; Os valores de uma coluna so retirados todos de um mesmo conjunto, denominado domnio da coluna; Duas ou mais colunas distintas podem ser definidas sobre um mesmo domnio; Um campo que seja uma chave estrangeira ou um item transposto s pode assumir valor nulo ou um valor para o qual exista um registro na tabela onde ela chave primria.
29
4.2 - Diagrama Relacional

Um Diagrama Relacional a representao grfica das ligaes entre tabelas de um modelo relacional. A figura 4.3 mostra um exemplo de um mapeamento de um diagrama ER para um Diagrama Relacional e suas tabelas correspondentes. Diagrama E/R Departamentos (0,1) chefiam (1,1) Funcionrios matrcula nome nome #Matrcul Funcionrios
cdigo
Diagrama Relacional #Cdigo #MatrculaDepartamentos Tabelas do Modelo Relacional Departamentos Cdigo Nome Matrcula-Chefe INF Informtica 00877 MAT Matemtica 06001 QUI Qumica 13888 ... ... ... Funcionrios Matrcula Nome 13888 Jorge 00877 Dede 06001 Pedro ... ...
Figura 4.3 - Exemplo de Diagrama Relacional e correspondentes Modelo E/R e Relacional. Neste exemplo a coluna Matrcula foi transposta para a relao Departamentos. O contrrio tambm poderia ser feito, isto , transpor Cdigo para Funcionrios. Escolhemos esta soluo porque h poucos funcionrios que so gerentes, enquanto todos os departamentos tm gerentes. Assim, a coluna Matrcula Chefe no ter valores vazios e dizemos que ela mais densa do que a coluna resultante da transposio de Cdigo.
30
No Diagrama Relacional so representados os seguintes elementos: a) As relaes (tabelas) provenientes de conjuntos de entidades e dos agregados do Modelo E/R. So representadas por retngulos, com uma referncia chave primria da tabela em cima. #Fun Funcionrios
b) As ligaes, que derivam dos relacionamentos, so representadas por linhas contnuas, associadas aos smbolos abaixo: Cardinalidade (0,1) (1,1) (0,N) (1,N) c) No caso de transposio de chave, se a chave transposta no fizer parte da chave primria da relao destino, iremos represent-la em cima do retngulo desta relao com um subscrito t. d) Atributos no so representados nos diagramas, mas sim em um dicionrio de tabelas do modelo relacional. Nos captulos que se seguem, sero discutidos os mapeamentos de um Modelo de Classes no paradigma Orientado a Objetos e de um Modelo de Entidades e Relacionamentos no paradigma Estruturado, para um Modelo Relacional. Ligao
31
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
5. Projeto Orientado a Objetos

A Anlise Orientada a Objetos identifica e define classes que refletem diretamente o domnio do problema e as responsabilidades do sistema dentro dele. O Projeto Orientado a Objetos (Object-Oriented Design - OOD) transforma o modelo de anlise em um modelo de projeto que serve de base para a construo do software. Ao contrrio dos mtodos de projeto de software convencionais, o projeto orientado a objetos resulta em um projeto que obtm um nmero de diferentes nveis de modularidade. Os componentes principais do sistema so organizados em mdulos de nvel de sistema, chamados subsistemas ou pacotes. Os dados e as operaes que os manipulam so encapsulados em classes. Alm disso, o OOD deve descrever a estrutura de dados especfica dos atributos e os detalhes procedurais de operaes individuais. A anlise geralmente transcorre com a suposio de que h uma tecnologia perfeita disponvel; j no projeto, sabe-se que o sistema ser implementado em uma plataforma de hardware, sob um sistema operacional, usando uma linguagem de programao. Em suma, a anlise interessa-se pelo o que o sistema deve fazer, enquanto o projeto diz respeito a como os requisitos sero implementados e, portanto, pressupe uma infra-estrutura de implementao e fortemente influenciado por ela. Assim, o projeto de um sistema orientado a objetos dependente de aspectos como: caractersticas da linguagem de programao a ser utilizada: Qual o tipo de linguagem a ser usada (orientada a objetos, baseada em objetos, convencional,...)? Se uma LPOO, qual o nvel de herana suportado (simples, mltipla)? Quais os mecanismos de acesso a atributos e operaes?, etc. modelo de persistncia de objetos: Que mecanismo de persistncia de objetos ser utilizado (banco de dados orientado a objetos, banco de dados relacional, arquivos, persistncia da prpria linguagem de programao)? caractersticas da plataforma de implementao: A plataforma de hardware multi-processada? O sistema distribudo? etc... caractersticas da interface com o usurio: Que tipo de interface com o usurio ser utilizada (interfaces grficas, orientadas a caracter, ...)? O Projeto Orientado a Objetos identifica e define classes adicionais, refletindo requisitos de implementao. Deste modo, as ferramentas de modelagem utilizadas na fase de anlise - Diagrama de Classes, Diagramas de Interao e Diagramas de Transio de Estados - so utilizadas tambm na fase de projeto, agora como o intuito de capturar os requisitos de implementao. Entretanto, a perspectiva de implementao existente no projeto, tipicamente, demanda extenses notao da anlise para permitir representar visibilidade, persistncia, concorrncia, excees e restries. Assim, ainda que a UML no especifique explicitamente que notaes destes diagramas devem ser utilizadas nas fases de anlise e de projeto, algumas de suas facilidades devem ser utilizadas apenas na fase de projeto, tais como as notaes de visibilidade de atributos e operaes e navegabilidade de relacionamentos.
32
Ainda que a terminologia e os passos do processo de projeto sejam diferentes para cada um dos mtodos de projeto orientado a objetos, os processos globais de projeto so razoavelmente consistentes (Pressman, 2002). De modo geral, dois grandes passos podem ser identificados: Projeto da Arquitetura do Sistema: descreve cada um dos subsistemas, de um modo passvel de implementao, e as comunicaes entre eles; Projeto de Objetos: descreve aspectos de implementao de cada uma das classes do sistema, incluindo, o projeto procedural de cada operao, a definio de classes internas e o projeto de estruturas de dados para os atributos das classes.
5.1 - Projeto da Arquitetura do Sistema

A primeira tarefa a ser realizada no OOD consiste em definir uma arquitetura para a aplicao. Ser sobre esta arquitetura que o projetista poder introduzir os aspectos de implementao em um modelo de anlise. Em sistemas complexos, a definio da arquitetura do software deve ser iniciada durante a fase de anlise para permitir uma melhor organizao dos modelos de anlise, evitando a complexidade. A arquitetura de um software deve indicar como o sistema ir funcionar em um ambiente operacional e fornecer os meios necessrios para a definio dos componentes do software, das interaes entre eles e dos padres necessrios para que todo esse ambiente coopere para produzir o software que est sendo projetado (Magela, 1998). Uma boa arquitetura de software pode ser obtida atravs da aplicao de duas idias fundamentais (Magela, 1998): Produo de software em camadas com nveis de abstrao definidos; e Separao entre interface e implementao. Desta forma, uma boa arquitetura de software deve ser elaborada em termos dos componentes que compem este software. Dificilmente possvel compreender o projeto de um software como um todo. Ao contrrio, melhor dividi-lo em componentes gerenciveis, de complexidade reduzida. Esta quebra deve ser refletida no projeto da arquitetura do sistema. Alm disso, a arquitetura deve levar em considerao requisitos tecnolgicos ou no-funcionais, tais como segurana, desempenho, manutenibilidade e economia (Magela, 1998). A organizao de classes em pacotes deve ser o ponto de partida para a definio da arquitetura, j que um meio de estabelecer nveis de abstrao para o modelo. Esses nveis de abstrao podem ser organizados em camadas e, assim, tratados separadamente durante a fase de projeto. A organizao de classes em pacotes til tambm para permitir a produo de componentes para reuso. Uma forma bastante utilizada para organizao em pacotes consiste em agrupar classes de acordo com o tipo de funo que exercem no sistema, isto , o seu esteretipo. Uma classe possui somente um esteretipo. No podemos ter uma classe com dois
33
esteretipos, uma vez que ela possuiria duas responsabilidades distintas, o que deveria levar a duas classes distintas (Magela, 1998). Alm da organizao por esteretipos, pode ser til agrupar classes em funo do domnio do problema. A organizao por domnio de problema conduz construo de pacotes verticais, levando produo de componentes de negcio (Magela, 1998). Contudo, esta abordagem isolada , normalmente, insuficiente. Assim, uma vez que um pacote pode conter outros pacotes, uma abordagem mais eficiente, sobretudo para sistemas complexos, consiste em realizar primeiramente uma organizao por domnio do problema e, posteriormente, fazer uma subdiviso dos pacotes do domnio em esteretipos. Quando esta abordagem baseada no domnio do problema for adotada, o primeiro passo a ser dado consiste em particionar o modelo de anlise para definir colees coesas de classes, relacionamentos e comportamento, empacotando-os em pacotes ou subsistemas. De fato, este passo uma reviso da identificao de subsistemas feita na fase de anlise, agora levando em conta requisitos de implementao. Subsistemas devem ser definidos e projetados em conformidade com os seguintes critrios (Pressman, 2002): Um subsistema deve possuir uma interface bem definida atravs da qual toda comunicao com o restante do sistema ocorre. Com exceo de um pequeno nmero de classes de comunicao, as classes dentro de um subsistema devem colaborar apenas com outras classes deste mesmo subsistema. O nmero de subsistemas deve ser mantido pequeno. Subsistemas podem ser particionados internamente para auxiliar a reduzir a complexidade. Esta subdiviso poder ser feita ainda segundo o critrio domnio do problema (para problemas muito complexos) ou usando o critrio de agrupamento por esteretipos. 5.1.1 Componentes de Projeto A comunidade de Smalltalk desenvolveu uma metfora simples, mas elegante, para uma arquitetura de projeto, conhecida como Modelo-Viso-Controlador (Model-ViewController) - MCV. Essencialmente, ela sugere que uma arquitetura tpica de projeto orientado a objetos possui trs componentes principais: um grupo de classes que modela a aplicao em si; um grupo de classes que prov uma viso da interface com os usurios; e um grupo de classes que controla, ou sincroniza, o comportamento dos demais. A arquitetura MCV um bom ponto de partida. Contudo, ela desconsidera um importante componente: a gerncia de dados. Isto se deve ao fato de, em Smalltalk, todos os objetos serem naturalmente persistentes. Assim, durante o projeto da arquitetura do sistema, um engenheiro de software deve considerar quatro (e no apenas trs) componentes bsicos, como mostra a figura 5.1 (Coad et al., 1993): Componente do Domnio do Problema: corresponde aos subsistemas responsveis por implementar diretamente os requisitos dos usurios;
34
Componente de Interao Humana: corresponde aos subsistemas que implementam as interfaces com o usurio; Componente de Gerncia de Tarefa: corresponde aos subsistemas responsveis por controlar e coordenar tarefas; Componente de Gerncia de Dados: corresponde aos subsistemas responsveis pelo armazenamento e recuperao de objetos (persistncia dos objetos).
Componente de Domnio do Problema (CDP)
Componente de Interao Humana (CIH)
Componente de Gerncia de Tarefa (CGT)
Componente de Gerncia de Dados (CGD)
Figura 5.1: Arquitetura Bsica de Projeto Orientado a Objetos (Coad et al., 1993). A idia bsica dessa arquitetura simples, mas crucial: ela vai buscar as mesmas classes que foram documentadas no modelo de anlise e, ento, as envolve com classes adicionais para tratar aspectos relacionados implementao de gerncia de tarefa, gerncia de dados e interao humana. Essa arquitetura no s preserva o modelo de anlise, como tambm o utiliza como o cerne do modelo de projeto. Deve-se notar que, por detrs dessa arquitetura, h uma filosofia de projeto que sugere que as classes centrais, orientadas aplicao na CDP, no devem estar cientes do mundo exterior e no tm de saber como interagir com tal mundo. Este um ponto fundamental, j que, sem uma ateno consciente a esta filosofia, podemos chegar a uma arquitetura na qual cada classe: (i) sabe como interagir com o usurio final e (ii) sabe como ler e escrever seus dados permanentes em arquivos de disco. Uma abordagem assim poderia funcionar (quem sabe at de maneira mais rpida), mas seria muito suscetvel a mudanas na interface com o usurio ou no modelo de persistncia. Alm disso, fatalmente tornaria a estrutura interna das classes mais complexa do que se tivessem de estar cientes apenas de seus detalhes essenciais, ligados ao domnio da aplicao. Assim, seguindo a arquitetura bsica proposta por Coad e Yourdon (Coad et al., 1993), temos quatro esteretipos: Domnio do Problema Interface com o Usurio Gerncia de Tarefas Gerncia de Dados
De fato, outros esteretipos podem ser usados para organizar classes, tais como Classes Limtrofes, Utilitrios, Classes de Excees, Controladores, etc.
35
5.2 Projeto da Componente do Domnio do Problema

No OOD, os resultados da OOA fazem parte da Componente de Domnio do Problema (CDP). Em muitos casos, o modelo de anlise desenvolvido pode ser transposto para dentro da CDP sem qualquer alterao adicional. Mas, algumas vezes, ele pode ser modificado ou estendido, de acordo com as necessidades do projeto. Alteraes podem advir da necessidade de: reutilizar projetos anteriores e classes j programadas: uma vez que uma das principais motivaes da orientao a objetos a reutilizao de software, importante que na fase de projeto seja levada em conta a existncia de bibliotecas de classes passveis de serem reusadas. Tipicamente, ajustes feitos para incorporar tais classes envolvem a alteraes nas hierarquias de generalizao-especializao do modelo, de modo a tratar as classes apropriadas da OOA como subclasses de classes de biblioteca pr-existentes, obtendo a vantagem total da habilidade de herdar atributos e mtodos de tais classes. ajustar o modelo ao nvel de herana suportado: em funo do nvel de herana suportado pela linguagem de programao a ser usada na implementao, o modelo da OOA pode ter de ser alterado. Se, por exemplo, o modelo da OOA envolve herana mltipla e a linguagem de implementao no oferece tal recurso, alteraes no modelo sero necessrias. ajustar o modelo para melhorar o desempenho: desempenho pode ser uma preocupao se h um alto trfico de mensagens entre objetos, se a linguagem de programao implementa herana ineficientemente, ou por vrias outras razes advindas da abordagem orientada a objetos. Nestes casos, o projetista pode alterar o modelo de anlise para melhor acomodar os ajustes necessrios. ajustar o modelo para facilitar o projeto de interfaces com o usurio amigveis: com o objetivo de incorporar a caracterstica de qualidade facilidade de uso, pode ser importante considerar novas classes que facilitem a apresentao de listas para seleo do usurio. A CDP pode ser alterado, ainda, para comportar outros requisitos tecnolgicos, tais como segurana, confiabilidade, etc.
5.3 Projeto da Componente de Interface com o Usurio

A premissa fundamental que justifica a existncia deste componente a seguinte: a poro do sistema que lida com a interface com o usurio deve ser mantida to independente e separada do resto da arquitetura do software quanto possvel. A razo para tal evidente: aspectos de interface com o usurio provavelmente sero alvo de alteraes ao longo de toda a vida produtiva do sistema, e essas alteraes devem ter um impacto mnimo (idealmente, nenhum impacto) nas partes especficas da aplicao do sistema. A Componente de Interface com o Usurio (CIU) adiciona detalhes sobre o projeto da interao humana, incluindo formato de janelas e relatrios, entre outros. Nesta etapa, a prototipao geralmente utilizada, buscando auxiliar o desenvolvimento e a seleo dos
36
mecanismos reais de interao. A CIU capta como um usurio comandar o sistema e como o sistema apresentar as informaes a ele. Como citado no Captulo 3, o princpio bsico para o projeto de interfaces com o usurio o seguinte: Conhea o usurio e as tarefas. Assim sendo, o modelo de casos de uso deve ser o guia para esta atividade, j que modela exatamente a interao entre atores (classes de usurios) e casos de uso (tarefas ou funcionalidades do sistema). No desenvolvimento orientado a objetos, o ponto de partida para o projeto da CIU o modelo de casos de uso e seus cenrios e descries de atores. Com base nos casos de uso, devemos projetar uma hierarquia de comandos, definindo barras de menu, menus pulldown, cones, etc., que levem a aes quando acionados pelo usurio. A hierarquia de comandos deve respeitar convenes e estilos existentes com os quais o usurio j esteja familiarizado. Note que a hierarquia de comandos , de fato, um meio de apresentar ao usurio as vrias funcionalidades disponveis no sistema, ou, olhando sob outro ponto de vista, as vrias mensagens que o usurio pode enviar para as classes dentro do sistema. A hierarquia de comandos deve ser refinada at que todos os casos de uso possam ser implementados, atravs da navegao nesta hierarquia. Uma vez definida a hierarquia de comandos, as interaes detalhadas entre o usurio e o sistema devem ser projetadas. Neste momento, observe o uso de termos, passos e aes consistentes. Observe, tambm, aspectos relacionados a desempenho, tempo de resposta e facilidade de uso e aprendizagem. No obrigue o usurio a ter de lembrar coisas. Fornea ajuda interativa. Normalmente, no necessrio projetar as classes bsicas de interfaces grficas com o usurio. Existem vrios ambientes de desenvolvimento de interfaces, oferecendo classes reutilizveis (janelas, cones, botes, ...) e, portanto, basta especializar as classes e instanciar os objetos que possuem as caractersticas apropriadas para o problema em questo. Em ambientes com interfaces grficas, a hierarquia de classes bsica para a CIU ter tipicamente uma superclasse janela e as janelas da aplicao sero construdas adicionando os outros objetos grficos necessrios, tais como botes, menus, cones.
5.4 Projeto da Componente de Gerncia de Tarefas

A Componente Gerncia de Tarefas (CGT) compreende a definio de tarefas e a comunicao e coordenao entre elas. O objetivo bsico desta etapa do projeto definir e classificar as tarefas. Algumas funcionalidades no so facilmente distribudas nas classes da CDP, principalmente aquelas que operam sobre vrios objetos. Uma possibilidade para resolver tal problema pulverizar esse comportamento ao longo de vrios objetos da CDP ou da CIU. Contudo, esta no uma boa soluo segundo uma perspectiva de alterabilidade. Uma alterao em tal funcionalidade poderia afetar diversos objetos, e assim ser difcil de ser incorporada. Uma abordagem mais interessante modelar as classes da CGT como gerenciadores ou coordenadores de tarefas, responsveis pela realizao de tarefas sobre um determinado
37
conjunto de objetos. Tipicamente, esses gerenciadores agem como aglutinadores, unindo outros objetos para dar forma a um caso de uso. Conseqentemente, gerenciadores de tarefa so normalmente encontrados diretamente a partir dos casos de uso. Os tipos de funcionalidade tipicamente atribudos a gerenciadores de tarefa incluem: comportamento relacionado a transaes, seqncias de controle especficas a um caso de uso, ou funcionalidades que separam objetos da CDP e da CIU. importante observar, ainda, que os aspectos dinmicos de um modelo de anlise mostram a existncia, ou no, de concorrncia entre objetos (ou subsistemas). Se objetos (ou subsistemas) no tm de estar ativos em um mesmo momento, ento no h necessidade de processamento concorrente e, portanto, o processamento do sistema pode ser atribudo a um nico processador. Caso contrrio, duas opes de alocao devem ser consideradas (Pressman, 2002): alocar cada subsistema a um processador independente: esta abordagem requer sistemas multi-processados ou distribudos; alocar os subsistemas para o mesmo processador e prover suporte a concorrncia atravs de caractersticas de sistemas operacionais: neste caso, sero necessrias novas classes de gerncia de tarefas, responsveis por este suporte. Em um esboo preliminar, pode-se atribuir um gerenciador de tarefa para cada caso de uso, sendo que os seus cenrios do origem a operaes da classe que representa o caso de uso. Nesta abordagem, a alterabilidade facilitada, uma vez que, detectado um problema em um caso de uso, fcil identificar a classe que trata do mesmo. Um possvel problema, contudo, o desempenho: para sistemas grandes, com muitos casos de uso, haver muitas classes de gerncia de tarefa e, para realizar uma tarefa, pode ser necessria muita comunicao entre essas classes. Uma soluo diametralmente oposta consiste em definir uma nica classe de aplicao para todo o sistema. Neste caso, os cenrios de todos os casos de uso do origem a operaes dessa classe. Fica evidente que, exceto para sistemas muito pequenos, a classe de aplicao ser extremamente complexa e, portanto, esta abordagem no seria prtica. Normalmente, uma soluo intermediria entre as duas anteriormente apresentadas conduz a melhores resultados. Nesta abordagem, casos de uso complexos so designados a classes de gerncia de tarefas especficas. Casos de uso mais simples e de alguma forma relacionados so tratados por uma mesma classe de aplicao. Uma coisa certa: pelo menos um gerenciador de tarefa ser sempre necessrio - a classe Aplicao, representando o sistema como um todo. Os objetos desta classe representam as vrias sesses (execues) do sistema. Obviamente, necessrio levar em conta, ainda, quantos executveis devem ser gerados para o sistema. Se mais do que um for necessrio, cada executvel ter de dar origem a uma classe de aplicao. Outros fatores que afetam esta deciso so aspectos de distribuio geogrfica e se o sistema ser um aplicativo ou um sistema rodado a partir de um navegador.
38
A hierarquia de tarefas a serem realizadas oferece um recurso bastante til para a definio das janelas, menus ou outros componentes de interao necessrios para cada uma dessas tarefas. Assim os projetos das componentes de interao humana e de gerncia de tarefa esto bastante relacionados, e devem ser realizados conjuntamente, uma vez que, muitas vezes, so as tarefas que determinam a necessidade de elementos de interface com o usurio para sua execuo.
5.5 Projeto da Componente de Gerncia de Dados

A Componente de Gerncia de Dados (CGD) prov a infra-estrutura bsica para o armazenamento e a recuperao de objetos no sistema. Sua finalidade isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura do software (Coad et al., 1993). A questo primordial neste momento do projeto : Como tornar persistentes os objetos do sistema? De modo geral, so quatro as opes atualmente disponveis para suportar a persistncia de objetos: uso de arquivos: Neste caso, necessrio estabelecer uma estratgia para escrita e leitura de uma srie de objetos em um arquivo simples. Um layout simples para um arquivo pode ser pensado em termos de um objeto por linha, com os atributos do objeto iniciando e terminando em posies especficas. As facilidades oferecidas pelas prprias linguagens de programao para manipular arquivos devem ser utilizadas. persistncia de objetos fornecida pela prpria linguagem de programao, como o caso de Smalltalk (arquivo IMAGE) e Eiffel (classe STORABLE). Em Smalltalk, todos os objetos so persistentes e, ao encerrar uma sesso, o estado de todo ambiente salvo em um arquivo. Neste caso, no h projeto da CGD. Eiffel, por sua vez, oferece a classe STORABLE, que oferece mecanismos para salvar e recuperar objetos persistentes. Neste caso, o projeto da CGD consiste em definir que classes devem ser definidas como sub-classes de STORABLE. bancos de dados de objetos: Em um ambiente orientado a objetos, a soluo ideal para essa questo seria usar um Sistema de Gerenciamento de Bancos de Dados Orientado a Objetos (SGBDOO), onde cada uma das classes persistentes na arquitetura de software corresponderia a exatamente uma base de dados gerenciada pelo SGBDOO. bancos de dados relacionais: Ainda que haja diferenas entre a abordagem relacional e o paradigma de objetos, os bancos de dados relacionais tem sido utilizados pela maioria dos desenvolvedores OO para armazenar objetos (Ambler, 1998). Alguns ambientes de programao, tais como certos ambientes C++ e o ambiente Delphi (Object Pascal), oferecem facilidades de interface com alguns bancos de dados relacionais. Neste caso, o projeto da CGD fortemente dependente do nvel de suporte oferecido. Caso o ambiente encapsule totalmente o banco de dados relacional, o projeto pode ser muito semelhante ao projeto
39
usando um banco de dados OO; caso contrrio, o projetista deve efetuar um projeto de bases de dados relacionais, definindo suas tabelas, para s ento poder utiliz-las no projeto OO da CGD. Utilizando SGBDs relacionais, geralmente, o processo de projeto comea pela traduo das classes no modelo orientado a objetos para a terceira forma normal padro. Para cada tabela em terceira forma normal, derivada deste processo de normalizao de objetos, uma tabela na base de dados definida. A despeito da opo de persistncia adotada, outra questo deve ser considerada: Que classes devem suportar a persistncia dos objetos? Uma alternativa seria tornar cada classe, ao longo de toda a arquitetura do software, responsvel por suas prprias atividades de leitura e escrita. Obviamente, nesta abordagem, a arquitetura torna-se completamente dependente da tecnologia de persistncia e, se, por exemplo, a organizao migra de um sistema de arquivo para um SGBD relacional, ou mesmo de um SGBD relacional para outro, essa migrao impactaria todas as classes ao longo do sistema. Uma abordagem mais elegante consiste em fazer com que apenas uma parte da arquitetura de software fique ciente da tecnologia de persistncia adotada. Essa parte, a CGD, serve como uma camada intermediria para as classes de objetos persistentes, tipicamente da CDP, estabelecendo um protocolo para a persistncia dos objetos. Via conexes de mensagem, a CGD l e escreve dados, estabelecendo uma comunicao entre a base de dados e os objetos do sistema. O preo a ser pago por este tipo de ocultamento de informao o desempenho: cada requisio para ler ou escrever um objeto envolve no apenas os comandos fsicos de leitura/gravao, mas tambm uma troca de dados (via parmetros de mensagem) entre a CGD e o objeto no sistema (Yourdon, 1994). Nesta abordagem, as operaes de armazenamento e recuperao de objetos no so colocadas nas classes da CDP, mas sim em uma ou mais classes salvadoras de objetos dentro da CGD. A abordagem mais direta para esta camada de persistncia consiste em prover uma classe sombra na CGD para cada classe persistente nos demais componentes da arquitetura. Tal classe salvadora de objetos encapsula a funcionalidade necessria para se implementar a persistncia dos objetos da classe correspondente. Uma abordagem mais elegante e complexa consiste em prover classes genricas que estabelecem protocolos para comunicao com os meios de armazenamento secundrios e utiliz-las para a persistncia dos objetos das classes correspondentes. Uma vez que os bancos de dados relacionais so os dispositivos de armazenamento mais confiveis e utilizados atualmente (Magela, 1998), a seguir detalhamos o projeto da CGD pressupondo o uso deste dispositivo de armazenamento. 5.5.1 - Persistncia em Bancos de Dados Relacionais Claramente, h uma diferena semntica significativa entre o modelo de classes de um projeto orientado a objetos e o modelo relacional. Assim, para que a persistncia de
40
objetos seja feita em um banco de dados relacional, necessrio proceder um mapeamento entre esses dois mundos. Deve-se realar que este mapeamento s deve ser visvel na camada de persistncia, isto , na CGD, isolando a CDP do impacto da tecnologia de bancos de dados. No mapeamento dos mundos de objetos e relacional, as seguintes questes devem ser abordadas: Mapeamento de Classes para Tabelas e de Objetos para Linhas; Mapeamento de Herana. Mapeamento de Associaes entre Objetos; Mapeando Classes em Tabelas e Objetos em Linhas Quando no h herana, cada classe deve ser mapeada em uma tabela e cada instncia da classe (objeto) em uma linha desta tabela. O modelo de classes deve ser normalizado previamente para a 3a forma normal, eliminando-se atributos multivalorados. Neste processo de normalizao das classes, surge uma importante questo. No modelo relacional, toda tabela tem de ter uma chave primria, isto , uma ou mais colunas, cujos valores identificam univocamente um registro da mesma. Objetos, por sua vez, tm identidade prpria, independentemente dos valores de seus atributos. Assim, que identificador nico devemos designar aos nossos objetos no banco de dados relacional, para que possamos distingui-lo? Uma soluo possvel consiste em observar se h um atributo na classe com esta propriedade de identificao nica e utiliz-lo, ento, como chave primria. Caso no haja um atributo com tal caracterstica, dever ser criado um. Esta abordagem deve ser utilizada sempre que j houver uma base de dados legada, sendo utilizada por outros sistemas, no orientados a objetos. Uma maneira mais eficaz, sobretudo para permitir a construo de componentes mais genricos de persistncia, consiste em dar a cada objeto um atributo chamado de identificador de objeto (IDO). Os IDOs so tipicamente implementados como grandes nmeros inteiros, que so utilizados como chaves primrias nas tabelas do banco de dados relacional. Essa coluna na tabela do banco de dados relacional dever ser do tipo autoincremento, garantindo que a unicidade do objeto ser mapeada na tabela, e no deve possuir nenhum significado de negcio (Ambler, 1998) (Magela, 1998). Mapeando Herana A grande questo no mapeamento da herana diz respeito a como organizar os atributos herdados no banco de dados. Existem trs solues razoavelmente aplicveis para mapear a herana em um banco de dados relacional (Ambler, 1998): 1. Utilizar uma tabela para toda a hierarquia; 2. Utilizar uma tabela por classe concreta na hierarquia; 3. Utilizar uma tabela por classe na hierarquia. No primeiro caso, a tabela derivada contm os atributos de todas as classes na hierarquia. A vantagem desta soluo a simplicidade da implementao. Ela suporta bem
41
o polimorfismo e facilita a designao de IDOs, j que todos os objetos esto em uma nica tabela. O problema fundamental desta soluo que, se as subclasses tm muitos atributos diferentes, haver muitas colunas que no se aplicam aos objetos individualmente, provocando grande desperdcio de espao no banco de dados.Alm disso, sempre que um atributo for adicionado a qualquer classe na hierarquia, um novo atributo deve ser adicionado tabela. Isso aumenta o acoplamento na hierarquia, pois, se um erro for introduzido durante a adio do atributo, todas as classes na hierarquia podem ser afetadas e no apenas a classe que recebeu o novo atributo. No segundo caso, utiliza-se uma tabela para cada classe concreta na hierarquia. Cada tabela derivada para as classes concretas inclui tanto os atributos da classe quanto os de suas superclasses. A grande vantagem a facilidade de processamento sobre as subclasses concretas, j que todos os dados de uma classe concreta esto armazenados em uma nica tabela. Da mesma forma que o caso anterior, a designao de IDOs facilitada, com a vantagem de se eliminar o desperdcio de espao. Contudo, h ainda algumas desvantagens. Quando uma superclasse alterada, por exemplo, necessrio alterar as tabelas de todas as suas subclasses. Alm disso, quando h muito processamento envolvendo a superclasse, h uma tendncia de queda do desempenho da aplicao, j que passa a ser necessrio manipular vrias tabelas ao invs de uma. A terceira soluo a mais genrica: utiliza-se uma tabela por classe, no importando se concreta ou abstrata. Deve haver uma tabela para cada classe e vises para cada uma das classes derivadas (subclasses). De fato, esta abordagem a que est mais de acordo com os conceitos da orientao a objetos. muito mais fcil modificar uma superclasse e acrescentar subclasses, j que necessrio apenas alterar ou acrescentar uma tabela. Uma desvantagem o grande nmero de tabelas no banco de dados, uma para cada classe. Alm disso, pode levar mais tempo para acessar dados de uma classe, uma vez que pode ser necessrio acessar vrias tabelas. Mapeando Associaes Uma vez que a persistncia ser feita em um banco de dados relacional, necessrio transpor chaves entre tabelas para mapear associaes. As regras vlidas para o modelo relacional tm de ser aplicadas, tal como criar tabelas associativas para mapear associaes muitos-para-muitos. Para implementar associaes um-para-um ou um-para-muitos, basta transpor a chave primria de uma tabela para a outra.
5.6 - Projeto de Objetos

No contexto do Projeto Orientado a Objetos, devemos desenvolver um projeto detalhado dos atributos, das associaes e das operaes que compem cada classe, e uma especificao das mensagens que conectam as classes com seus colaboradores. Inicialmente, uma descrio de protocolo para cada classe deve ser provida, estabelecendo o conjunto de mensagens da classe (sua interface) e uma descrio da operao a ser executada quando um objeto da classe receber uma dessas mensagens. Neste momento, deve-se definir, portanto, que operaes e atributos devem ser pblicos ou
42
privados classe. A seguir, deve-se fazer uma descrio da implementao da classe, provendo detalhes internos necessrios para a implementao, mas no necessrios para a comunicao entre objetos. No que tange aos atributos, esta descrio deve conter uma especificao das estruturas de dados privadas da classe, com indicaes de itens de dados e tipos para os atributos. Deve-se definir, tambm, a navegabilidade das associaes. Esta deciso conduzir definio de novas variveis na classe, bem como do seu tipo e estrutura de dados. Para as operaes, deve-se definir os tipos e estruturas de dados para as interfaces, bem como uma especificao procedural de cada operao (projeto algortmico). No caso de operaes complexas, uma boa opo modulariz-las, criando sub-operaes, estas privadas classe. O projeto algortmico de uma operao pode revelar a necessidade de variveis locais aos mtodos ou de variveis globais classe para tratar detalhes internos.
5.7 - Critrios de Qualidade de Projeto OO

H vrios projetos possveis que podem implementar corretamente um conjunto de requisitos. Um bom projeto equilibra custo e benefcio de modo a minimizar o custo total do sistema ao longo de seu tempo de vida total. Coad e Yourdon propem alguns critrios baseados na observao e estudos de casos reais de desenvolvimento OO, entre eles (Coad et al., 1993): Acoplamento: diz respeito ao grau de interdependncia entre componentes de software. O objetivo minimizar o acoplamento, isto , tornar os componentes to independentes quanto possvel. No OOD, estamos preocupados principalmente com o acoplamento entre classes e entre subsistemas. A meta minimizar o nmero de mensagens trocadas e a complexidade e o volume de informao nas mensagens. Coeso: define como as atividades de diferentes componentes de software esto relacionadas umas com as outras. Vale a pena ressaltar que coeso e acoplamento so interdependentes e, portanto, uma boa coeso, geralmente, conduz a um pequeno acoplamento. No OOD, trs nveis de coeso devem ser verificados: coeso de mtodos individuais: um mtodo deve executar uma e somente uma funo; coeso de classes: atributos e servios encapsulados em uma classe devem ser altamente coesos, isto , devem estar estreitamente relacionados; e coeso de uma hierarquia de classes: a coeso de uma hierarquia pode ser avaliada examinando-se at que extenso uma subclasse redefine ou cancela atributos e mtodos herdados da superclasse. Clareza: um projeto deve ser passvel de entendimento por outros projetistas. Reutilizao: bons projetos devem ser fceis de serem reutilizados.
43
Efetivo Uso da Herana: para sistemas mdios, com aproximadamente 100 classes, as hierarquias devem ter de 2 a 7 nveis de generalizao-especializao. Projetos com uso intensivo de herana mltipla devem ser evitados, pois so mais difceis de serem entendidos e, conseqentemente, de serem reutilizados e mantidos. Protocolo de Mensagens Simples: protocolos de mensagem complexos so uma indicao comum de acoplamento excessivo entre classes. Assim, a passagem de muitos parmetros deve ser evitada. Operaes Simples: os mtodos que implementam as operaes de uma classe devem ser bastante pequenos. Se um mtodo envolve muito cdigo, uma forte indicao de que as operaes da classe foram pobremente modularizadas. Habilidade de avaliar por cenrio: importante que um projeto possa ser avaliado a partir de um cenrio particular escolhido. Revisores devem poder representar o comportamento de classes e objetos individuais, e assim, verificar o comportamento dos objetos nas circunstncias desejadas.
5.8 Reviso do Documento de Projeto

Assim como os demais documentos, o documento de projeto deve ser revisado. Os seguintes aspectos devem ser observados: Aderncia a padres de documento de projeto; Aderncia a padres de nomenclatura, incluindo nomes de classes, atributos, operaes, mensagens, etc; Coerncia com os modelos de anlise e de especificao de requisitos.
Do ponto de vista de coerncia entre modelos, os seguintes aspectos devem ser observados: As classes da componente do domnio do problema devem ser necessrias e suficientes para cumprir as responsabilidades apontadas pelos casos de uso do documento de especificao de requisitos, agora j com uma perspectiva de implementao. As classes da componente de interao humana devem ser necessrias e suficientes para permitir o acesso e a realizao de todos os casos de uso do documento de especificao de requisitos e seus cenrios. As classes da componente de gerncia de tarefas devem controlar todos os casos de uso documentados na especificao de requisitos e seus cenrios; As classes da gerncia de dados devem ser necessrias e suficientes para tratar do armazenamento e recuperao de objetos de todas as classes persistentes do sistema (tipicamente, as classes da componente do domnio do problema);
44
Alteraes no decorrentes da tecnologia, mas da deteco de um erro de especificao de requisitos ou de anlise, devem ser atualizadas nos correspondentes modelos de especificao de requisitos ou anlise.
5.9 Padres de Projeto (Design Patterns)

Projetar software uma tarefa difcil. A maioria dos projetistas capaz de compreender conceitos como classes, objetos, interfaces e herana. O desafio reside em aplic-los para construir software flexvel e reutilizvel. Projetistas novatos tendem a se perder com as muitas opes disponveis e a recorrer a tcnicas no orientadas a objetos com as quais tm certa familiaridade. Projetistas experientes, por sua vez, tendem a fazer bons projetos. Eles sabem que no se deve resolver todo e qualquer problema partindo de princpios bsicos (classes, objetos, herana, relacionamentos, agregao,...). Ao contrrio, deve-se buscar reutilizar solues que funcionaram no passado. Esta a motivao para o estudo de padres de projeto, ou design patterns. Assim, um padro um par nomeado problema/soluo, que pode ser utilizado em novos contextos, com orientaes sobre com utiliz-lo em novas situaes [Larman00]. O objetivo de um design pattern registrar uma experincia no projeto de software OO, na forma de um padro passvel de ser efetivamente utilizado por projetistas. Cada padro sistematicamente nomeia, explica e avalia um importante projeto que ocorre repetidamente em sistemas OO (Gamma et al., 1995). Um projetista familiarizado com padres de projeto pode aplic-los diretamente a problemas de projeto sem ter que redescobrir abstraes e os objetos que as capturam. Uma vez que um padro aplicado, muitas decises de projeto decorrem automaticamente. Em geral, um padro tem quatro elementos essenciais: Nome: identificao de uma ou duas palavras, que se possa utilizar para descrever o problema de projeto, suas solues e conseqncias. Problema: descreve quando aplicar o padro. Explica o problema de projeto e seu contexto. Soluo: descreve os elementos que compem o projeto, seus relacionamentos, responsabilidades e colaboraes. No descreve um particular projeto concreto ou implementao. Um padro prov uma descrio abstrata de um problema de projeto e como uma organizao geral de classes e objetos resolve este problema. Conseqncias: so os resultados e os comprometimentos feitos ao se aplicar o padro, tais como, bibliotecas de classes necessrias, que problemas acarreta, etc.
45
5.9.1 O Catlogo proposto por (Gamma et al., 1995) Um dos principais catlogos de padres OO publicados at o momento o apresentado em (Gamma et al., 1995). A descrio dos padres neste catlogo mais detalhada e consiste de: Nome: nome dado ao padro neste catlogo. Classificao: feita segundo dois critrios: propsito e escopo. O propsito reflete o que o padro faz, isto , sua funcionalidade. Segundo este critrio, um padro pode ser: criativo, diz respeito ao processo de criao de objetos; estrutural, lida com a composio de classes ou objetos; ou comportamental, caracteriza os meios pelos quais classes ou objetos interagem e distribuem responsabilidades. O escopo, por sua vez, especifica se o padro est centrado em classes (e neste caso, faz intenso uso de herana) ou em objetos (e, portanto, mais apoiado em associaes). Inteno (Propsito): descreve sucintamente o que faz o padro, seu propsito e o problema endereado. Tambm conhecido como: apresenta outros nomes pelos quais o padro conhecido (se houver). Motivao: apresenta um cenrio que ilustra o problema endereado pelo padro e como a estrutura proposta pelo padro resolve este problema. Aplicabilidade: trata de situaes nas quais o padro pode ser aplicado e como reconhecer essas situaes. Estrutura: apresenta o modelo de classes do padro e, opcionalmente, diagramas de interao para ilustrar seqncias de requisies e colaboraes entre objetos. Participantes: fornece uma descrio das classes e/ou objetos que participam do padro e suas responsabilidades. Colaboraes: descreve como os participantes colaboram para realizar suas responsabilidades. Conseqncias: trata dos comprometimentos e resultados quando se aplica o padro, tanto positivos como negativos. Implementao: discute armadilhas e sugestes na implementao do padro, bem como tcnicas e questes especficas de linguagem. Cdigo-Exemplo: apresenta fragmentos de cdigo em C++ ou Smalltalk que ilustram como o padro pode ser implementado. Usos conhecidos: apresenta exemplos de uso do padro encontrados em sistemas reais.
46
Padres relacionados: faz referncia a outros padres proximamente relacionados com o padro em questo, discutindo diferenas. Relaciona, tambm, outros padres que devem ser utilizados juntamente com este.
Tendo em vista a classificao proposta por (Gamma et al., 1995), possvel apontar os objetivos gerais de cada grupo de padres. Quanto ao propsito, os seguintes objetivos so vlidos: Padro Criativo: abstrai o processo de instanciao (criao) de objetos, ajudando a tornar um sistema independente de como seus objetos so criados, compostos e representados. o o Padro Criativo de Classe: utiliza herana para variar a classe instanciada, adiando alguma parte da criao de objetos para subclasses. Padro Criativo de Objeto: delega a instanciao de um objeto para outro objeto ou adia alguma parte da criao de um objeto para outro objeto.
Padro Estrutural: diz respeito a como classes e objetos so compostos para formar estruturas maiores. o o Padro Estrutural de Classe: utiliza herana para compor classes. Padro Estrutural de Objeto: descreve meios de compor objetos a partir de outros objetos, visando obter nova funcionalidade. A flexibilidade adicional da composio de objetos advm da habilidade de alterar uma composio em tempo de execuo, o que impossvel com a composio esttica de classes.
Padro Comportamental: diz respeito a algoritmos e a atribuio de responsabilidades entre objetos. o Padro Comportamental de Classe: utiliza herana para distribuir comportamento entre classes, ou seja, para descrever algoritmos e fluxos de controle. o Padro Comportamental de Objeto: utiliza composio de objetos para distribuir o comportamento. Descreve como um grupo de objetos coopera para realizar uma tarefa que nenhum objeto poderia realizar sozinho.
A tabela 5.1 apresenta o catlogo de padres proposto por (Gamma et al., 1995). Na seqncia, apresentada uma breve descrio de cada um dos padres.
47
Propsito Escopo Classe Objeto Criativo Mtodo-Fbrica Construtor Fbrica Abstrata Prottipo Singular Estrutural Adaptador (classe) Adaptador (objeto) Composto Decorador Fachada Peso-Mosca Ponte Procurador Comportamental Interpretador Mtodo Modelo Cadeia de Responsabilidade Comando Iterador Mediador Memorial Observador Estado Estratgia Visitador Tabela 5.1 Catlogo de Padres proposto em (Gamma et al., 1995). Padres de Classe Mtodo-Fbrica: define uma interface para a criao de objetos, mas deixa que uma classe adie a instanciao para suas subclasses. Adaptador: converte a interface de uma classe em outra interface, permitindo que classes trabalhem em conjunto, quando isto no seria possvel por causa da incompatibilidade de interfaces. Mtodo Modelo: define o esqueleto de um algoritmo em uma operao, adiando alguns de seus passos para as subclasses, permitindo que as subclasses redefinam certos passos do algoritmo sem alterar sua estrutura. Interpretador: Dada uma linguagem, define uma representao para sua gramtica, junto com um interpretador que utiliza essa representao para interpretar sentenas na linguagem. Construtor: separa a construo de um objeto complexo de sua representao de modo que o mesmo processo de construo pode criar diferentes representaes. Fbrica Abstrata: prov uma interface para a criao de famlias de objetos relacionados ou dependentes, sem especificar suas classes concretas.
Padres de Objetos
48
Prottipo: especifica os tipos de objetos que podem ser criados a partir de uma instncia prototpica e cria novos objetos copiando este prottipo. Singular: garante que uma classe possui uma nica instncia e prov um ponteiro global para acess-la. Composto: compe objetos em estruturas de rvore para representar hierarquias todo-parte, permitindo que clientes tratem objetos individuais e compostos uniformemente. Decorador: anexa responsabilidades adicionais a um objeto dinamicamente, permitindo estender sua funcionalidade. Fachada: prov uma interface unificada para um conjunto de interfaces em um subsistema. Define uma interface de nvel mais alto para o subsistema, tornando-o mais fcil de ser usado. Peso-Mosca: utiliza compartilhamento para suportar eficientemente um grande nmero de objetos de granularidade muito fina. Ponte: desacopla uma abstrao de sua implementao, de modo que ambas possam variar independentemente. Procurador: prov um substituto/procurador (proxy) que tem autorizao para controlar o acesso a um objeto. Cadeia de Responsabilidades: evita o acoplamento entre o objeto emissor de uma mensagem e o receptor, dando chance para mais de um objeto tratar a solicitao. Encadeia os objetos receptores e passa a mensagem adiante na cadeia at que um objeto a trate. Comando: encapsula uma requisio como um objeto, permitindo, assim, parametrizar clientes com diferentes requisies e desfazer operaes (comando undo). Iterador: prov um meio de acessar seqencialmente os elementos de um objeto agregado sem expor sua representao bsica. Mediador: define um objeto que encapsula como um conjunto de objetos interage. Memorial: sem violar o encapsulamento, captura e externaliza o estado interno de um objeto de modo que se possa posteriormente restaurar o objeto para este estado. Observador: define uma dependncia um-para-muitos entre objetos de modo que quando um objeto muda de estado, todos os seus dependentes so notificados e atualizados automaticamente. Estado: permite que um objeto altere o seu comportamento quando seu estado interno muda, fazendo parecer que o objeto mudou de classe.
49
Estratgia: define uma famlia de algoritmos, encapsula cada um deles e os torna intercambiveis. Deste modo, o algoritmo varia independentemente dos clientes que o utlizam. Visitador: representa uma operao a ser executada sobre os elementos de uma estrutura de um objeto. Permite definir uma nova operao sem alterar as classes dos elementos sobre as quais ele opera.
Gamma et al. (1995) sugerem que, para se utilizar um padro do catlogo, os seguintes passos devem ser seguidos: 1. Leia o padro uma vez para obter uma viso geral, concentrando a ateno nas sees de Aplicabilidade e Conseqncias para garantir que este o padro certo para o seu problema. 2. Volte e estude as sees de Estrutura, Participantes e Colaboraes. Tenha a certeza de que compreendeu as classes e objetos no padro e como se relacionam entre si. 3. Olhe a seo Cdigo de Exemplo para ver um exemplo concreto do padro em cdigo. Isto ir ajud-lo a aprender a implementar o padro. 4. Escolha nomes para os participantes (classes e/ou objetos) do padro que sejam significativos no contexto da aplicao. Os nomes em um padro de projeto so geralmente muito abstratos para aparecerem diretamente em uma aplicao. Contudo, til incorporar o nome do participante do padro de projeto ao seu nome na aplicao, de modo a tornar o padro mais explcito na implementao. 5. Defina as classes. 6. Defina nomes especficos da aplicao para as operaes no padro. 7. Implemente as operaes para realizar as responsabilidades e colaboraes do padro. Padres de projeto no devem ser aplicados indiscriminadamente. Freqentemente, eles alcanam flexibilidade e variabilidade atravs da introduo de nveis adicionais de indireo que podem complicar um projeto e/ou resultar em queda de desempenho. Um padro de projeto s deve ser aplicado quando a flexibilidade que ele proporciona for realmente necessria. A seo de Conseqncias muito til para a avaliao dos benefcios e obrigaes de um padro. Padres de projeto so bastante teis para a criao de projetos robustos, aptos a suportar determinadas mudanas, garantindo que o sistema pode ser alterado de certas maneiras especficas. Cada padro permite que algum aspecto da estrutura do sistema varie de forma independente de outros aspectos, tornando o sistema mais robusto para um particular tipo de alterao. A seguir, so parcialmente apresentados alguns dos padres de projeto propostos em (Gamma et al., 1995).
50
Fbrica Abstrata Classificao: Padro Criativo de Objeto Propsito: Prover uma interface para criar famlias de objetos relacionados ou dependentes, sem especificar suas classes concretas. Tambm conhecido como: Kit. Motivao: Toolkit de Interface Grfica com o Usurio, suportando diferentes padres de apresentao (Motif, Presentation Manager,...). Cada padro de apresentao define diferentes comportamento e aparncia para objetos de interface, tais como janelas, botes, barras de scroll, etc. Para ser portvel ao longo de diferentes padres de apresentao, uma aplicao no pode se comprometer com um padro especfico. Aplicabilidade: Sistema deve ser independente de como seus produtos so criados, compostos e representados. Sistema deve ser configurado com uma dentre vrias famlias de produtos. Uma famlia de produtos relacionados foi projetada para ser usada em conjunto e esta restrio tem de ser garantida. Estrutura: FbricaAbstrata CriarProdutoA CriarProdutoB Cliente
ProdutoAbstratoA
ProdutoA2 FbricaConcreta1 CriarProdutoA CriarProdutoB FbricaConcreta2 CriarProdutoA CriarProdutoB
ProdutoA1
ProdutoAbstratoB
ProdutoB2
ProdutoB1
51
Participantes: Fbrica Abstrata: declara uma interface para operaes criam objetos-produto abstratos; Fbrica Concreta: implementa as operaes para criar objetos-produto concretos; Produto Abstrato: declara uma interface para um tipo de objeto produto. Produto Concreto: implementa a interface abstrata de Produto Abstrato e define um objeto-produto a ser criado pela Fbrica Concreta correspondente. Cliente: utiliza apenas as interfaces declaradas por Fbrica Abstrata e Produto Abstrato. Colaboraes: Fbrica Abstrata adia a criao de objetos-produto para suas subclasses Fbricas Concretas. Conseqncias: Isola classes concretas: uma vez que uma fbrica encapsula a responsabilidade e o processo de criao de objetos-produto, ela isola clientes das classes de implementao. Fica mais fcil a troca de uma famlia de produtos, bastando trocar a fbrica concreta usada pela aplicao. Promove consistncia entre produtos. Quando objetos-produto em uma famlia so projetados para trabalhar juntos, importante que uma aplicao utilize apenas objetos desta famlia. O suporte a novos tipos de produtos dificultado, j que a interface da Fbrica Abstrata fixa o conjunto de produtos que podem ser criados. Para suportar novos tipos de produtos, necessrio alterar a interface da fbrica, o que envolve alteraes na Fbrica Abstrata e em todas as suas subclasses. FbricaDeObjetos Grficos CriarJanela CriarBarraScroll JanelaPM FbricaMotif CriarJanela CriarBarraScroll FbricaPM CriarJanela CriarBarraScroll
52
Cliente Janela
JanelaMotif BarraScroll
BScrollPM
BScrollMotif
Mtodo Modelo Classificao: Padro Comportamental de Classe. Propsito: Definir o esqueleto de um algoritmo em uma operao, adiando alguns passos para as subclasses. Aplicabilidade: Para implementar partes invariantes de um algoritmo apenas uma vez e deixar a cargo das subclasses a implementao do comportamento varivel. Estrutura: Classe Abstrata MtodoModelo OperaoPrimitiva1 OperaoPrimitiva2 ... OperaoPrimitiva1 ... OperaoPrimitiva2
Classe Concreta OperaoPrimitiva1 OperaoPrimitiva2 Participantes: Classe Abstrata: implementa um mtodo modelo, definindo o esqueleto de um algoritmo e define operaes primitivas abstratas que as subclasses concretas tm de definir para implementar os passos do algoritmo; Classe Concreta: implementa as operaes primitivas para realizar passos do algoritmo que so especficos da subclasse. Colaboraes: A Classe Concreta conta com a Classe Abstrata que implementa os passos invariante do algoritmo. Padres Relacionados: Mtodo Fbrica: mtodos-fbrica normalmente so chamados por mtodosmodelo; Estratgia: enquanto os mtodos-modelo utilizam herana para variar partes de um algoritmo, as estratgias usam delegao para variar o algoritmo inteiro.
53
Procurador Classificao: Padro Estrutural de Objeto Propsito: prov um substituto/procurador que tem autorizao para controlar o acesso ao objeto. Tambm conhecido como: Substituto, Proxy. Motivao: Uma razo para se controlar o acesso a um objeto tentar adiar o alto custo de criao e inicializao deste objeto at o momento em que ele for ser realmente utilizado. Considere um editor de texto que pode embutir objetos grficos em um documento. Alguns desses objetos, como figuras complexas, podem ter um alto custo de criao. Contudo, a abertura de um documento deve ser rpida. Assim, desejvel evitar a criao de todos esses objetos no momento em que o documento aberto, at porque muitos deles no estaro visveis ao mesmo tempo. Esta restrio sugere a criao dos objetos complexos sob demanda, isto , o objeto s ser criado no momento em que sua imagem se tornar visvel. Mas o que colocar no documento no lugar da imagem? E como esconder essa abordagem sem complicar a implementao do editor? A soluo consiste em criar um outro objeto, o procurador (proxy) da imagem, que atuar como substituto para a imagem real. Este procurador agir exatamente como a imagem e cuidar de sua instanciao quando a mesma for requerida. O procurador da imagem criar a imagem real somente quando o editor de texto requisitar a ele que exiba a imagem, atravs da operao desenhar(). A partir da, o procurador passar adiante as requisies subseqentes diretamente para a imagem, como ilustra o diagrama de seqncia abaixo.
: E ditorTexto fi gur aS ubs ti tut a : FiguraS ubstituta des enhar( ) [figuraReal = = null] carregar( ) fi guraReal : FiguraReal
des enhar( )
54
Aplicabilidade: O padro Procurador aplicvel sempre que houver necessidade de uma referncia mais verstil ou sofisticada do que um simples ponteiro. A seguir so listadas algumas situaes nas quais este padro aplicvel: Um Procurador Remoto prov uma representao local para um objeto que se encontra em um outro espao de endereamento. Um Procurador Virtual cria objetos complexos sob demanda, como no caso do exemplo da motivao. Um Procurador de Proteo controla o acesso ao objeto original. Este tipo de procurador amplamente utilizado quando h diferentes direitos de acesso ao objeto original. Neste caso, o procurador serve como uma espcie de filtro. Um Procurador de Referncia Inteligente uma substituio para um ponteiro simples, que realiza operaes adicionais quando o objeto acessado. Isto pode ser til em muitas situaes, tais como: contar o nmero de referncias ao objeto real, de forma tal que ele possa ser liberado automaticamente quando no houver mais referncias a ele; carregar um objeto persistente para a memria quando ele for referenciado pela primeira vez; verificar se o objeto real no est bloqueado antes de permitir um acesso a ele, garantindo que nenhum outro objeto poder altera-lo. Estrutura:
As sunto
Cliente
req uisi o() cri ar ()
Procurador requisi o() criar() ... objetoReal.requisio(); ...
ObjetoReal requisi o() criar()
55
Participantes: Assunto: define uma interface comum para o ObjetoReal e para o Procurador, de modo que o procurador possa ser usado no lugar do objeto real; Procurador: representa um substituto para o objeto real. Para tal, mantm uma referncia ao objeto real, que o permite acessar este objeto. Sua interface deve ser idntica do objeto real, de modo que possa ser por ele substitudo. Alm disso, controla o acesso ao objeto real e pode ser responsvel pela criao e excluso do mesmo. Outras responsabilidades podem lhe ser atribudas em funo do tipo do procurador; ObjetoReal: define o objeto real que o procurador representa. Colaboraes: O procurador envia requisies para o objeto real, quando for apropriado, dependendo do tipo de Procurador. Conseqncias: O padro Procurador introduz um nvel de indireo quando se acessa o objeto. Esta indireo adicional tem muitos usos, dependendo do tipo de procurador. Um Procurador Remoto, por exemplo, pode esconder o fato de um objeto residir em um espao de endereamento diferente. Um Procurador Virtual pode realizar otimizaes, como criar um objeto sob demanda. Procuradores de Proteo e de Referncia Inteligente, por sua vez, permitem tarefas adicionais de gerenciamento quando um objeto acessado.
56
Figura des e nhar() c arreg ar()
0. .* 1
E ditorTe x to
Figu raS ubs t it uta des enhar() c arregar()
0. .* 0..1
Figura Rea l dese nhar() carregar()
des enhar() { if (figuraReal == null) figuraReal = carregar(); figuraReal.des enhar(); }
Padres Relacionados: Adaptador: um adaptador prov uma interface diferente para o objeto que ele adapta. O procurador prov a mesma interface. Decorador: Um decorador adiciona responsabilidades a um objeto, enquanto o procurador controla o acesso ao objeto.
57
Observador Classificao: Padro Comportamental de Objeto Propsito: define uma dependncia um-para-muitos entre objetos de modo que quando um objeto muda de estado, todos os seus dependentes so notificados e atualizados automaticamente. Tambm conhecido como: Dependentes. Motivao: uma boa opo para ferramentas de interfaces grficas com o usurio separar aspectos de apresentao dos respectivos dados da aplicao. As classes dos componentes de domnio do problema e de interface com o usurio podem ser reutilizadas independentemente, assim como podem trabalhar juntas. Por exemplo, os mesmos dados estatsticos podem ser apresentados em formato de grfico de barras ou planilha, usando apresentaes diferentes. O grfico de barras e a planilha devem ser independentes, de modo a permitir reuso. Contudo, eles tm de se comportar consistentemente, isto , quando um usurio altera a informao na planilha, o grfico de barras reflete a troca imediatamente e viceversa.
a X 50
b 30
c 20 a b c
X a = 50% b = 30% c = 20%
notificao de alterao pedido de alterao
Este comportamento implica que a planilha e o grfico de barras so dependentes do mesmo objeto de dados e, portanto, devem ser notificados quando ocorre alguma mudana no estado desse objeto. O padro Observador descreve como se estabelecem estes relacionamentos. Os objetos principais deste padro so Sujeito e Observador. O sujeito, no exemplo o objeto X, pode ter qualquer nmero de observadores, no caso a planilha e o grfico de barras. Todos os observadores so notificados sempre que ocorre uma mudana no estado do sujeito. Em resposta, cada observador ir consultar o sujeito para sincronizar seu estado com o estado do sujeito.
58
Aplicabilidade: O padro Procurador aplicvel em qualquer uma das seguintes situaes: Quando uma abstrao possui dois aspectos, um dependente do outro. Encapsular esses aspectos em objetos separados permite vari-los e reutilizalos independentemente. Quando uma alterao em um objeto requer alteraes em outros e no se sabe quantos objetos precisam ser alterados. Quando um objeto deveria ser capaz de notificar outros objetos sem fazer nenhuma suposio sobre como so esses objetos, ou seja, no se quer esses objetos fortemente acoplados. Estrutura:
S ujeito 1 adicionarObservador() rem overObs ervador() notific ar() 0 ..* Ob s ervador atualiz ar()
not ifi c ar() { p ara c ada observador observador.a tualiz ar }
S ujeitoConc reto estad o atribu irEs tado() 1 obter E stad o() 0..*
ObservadorConc reto estado atualiz ar()
atualiz ar() { es tado = s ujeitoConc reto.obterE s tado }
Participantes: Sujeito: conhece seus observadores e prov uma interface para adicionar e remover objetos observadores. Qualquer nmero de observadores pode observar um sujeito. Observador: define uma interface de atualizao para os objetos que devem ser notificados das mudanas no sujeito. SujeitoConcreto: armazena o estado de interesse para os observadores concretos e envia notificaes para eles quando o seu estado alterado.
59
ObservadorConcreto: mantm uma referncia para um objeto SujeitoConcreto, armazena o estado que deve ficar consistente com o estado do sujeito e implementa a interface de atualizao do Observador, de modo a manter seu estado consistente com o do sujeito. Colaboraes: O sujeito concreto notifica seus observadores sempre que ocorre uma alterao que pode tornar o estado de seus observadores inconsistente com o seu estado. Aps ser informado de uma mudana no sujeito concreto, um objeto ObservadorConcreto pode consultar o sujeito, usando esta informao para reconciliar seu estado com o estado do sujeito.
: Cli ente s ujeitoConc reto : S ujeitoConc reto ob servador 1 : ObservadorConc reto
. ..
observadorN : ObservadorConc reto
atribuirE stado( ) notific ar( )
atualiz ar( ) obterE s tado( )
...
atu aliz ar( ) obt erEs tado( )
60
Conseqncias: O padro Observador permite variar sujeitos e observadores independentemente. Deste modo possvel reutilizar sujeitos sem reutilizar observadores e vice-versa. Isso permite adicionar observadores sem modificar o sujeito ou outros observadores. Outros benefcios e obrigaes desse padro incluem: Acoplamento abstrato entre Sujeito e Observador: Tudo que um sujeito sabe que ele possui uma lista de observadores, todos em conformidade com a interface simples da classe abstrata Observador. O sujeito no conhece a classe concreta de nenhum observador. Assim, o acoplamento entre sujeitos e observadores abstrato e mnimo. Suporte para comunicao broadcast: Ao contrrio de uma notificao individual, a notificao que um sujeito envia no precisa especificar seus receptores. A notificao enviada automaticamente para todos os objetos interessados. Assim, a responsabilidade de um sujeito limitada apenas notificao de seus observadores. Isso oferece liberdade de adicionar e remover observadores a qualquer momento. Atualizaes inesperadas: Uma vez que os observadores no tm conhecimento da presena uns dos outros, eles podem no ser conscientes do custo de uma alterao no sujeito. Assim, uma operao aparentemente incua sobre o sujeito pode provocar uma atualizao em cascata para seus observadores e objetos dependentes. Alm disso, critrios de dependncia no bem definidos geralmente levam a atualizaes falsas que podem ser difceis de propagar. Referncias (Ambler, 1998) (Coad et al., 1993) (Gamma et al., 1995) Anlise e Projeto Orientados a Objetos. Scott Ambler, IBPI Press, 1998. Projeto Baseado em Objetos, P. Coad, E. Yourdon, Editora Campus, 1993. Design Patterns - Elements of Reusable Object-oriented Software. Gamma, E., Helm R., Johnson R., Vlissides, J. Addison-Wesley Professional Computing Series, 1995. Produzindo Software Orientado a Objetos - Projeto. Rogrio Magela, Fuzion Engenharia de Software, 1998. Engenharia de Software. Roger S. Pressman, traduo da 5a edio, Mc Graw Hill, 2002. Object-Oriented Systems Design: an Integrated Approach, E. Yourdon, Yourdon Press Computing Series, Prentice Hall, 1994.
(Magela, 1998) (Pressman, 2002) (Yourdon, 1994)
61
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
6. Projeto Estruturado de Sistemas

No projeto de sistemas segundo o paradigma estruturado, assim como no paradigma OO, um modelo de projeto gerado a partir do modelo de anlise, com o objetivo de representar o que dever ser codificado na fase de implementao. Uma vez que o paradigma estruturado trabalha com a clara distino entre dados e funes, o projeto estruturado tende a seguir o mesmo caminho. Sendo assim, o projeto estruturado de sistema pode ser dividido em duas grandes fases: projeto de dados e projeto de programas.
6.1 - Projeto de Dados

Um aspecto fundamental da fase de projeto consiste em estabelecer de que forma sero armazenados os dados do sistema. Em funo da plataforma de implementao, diferentes solues de projeto devem ser adotadas. Isto , se o software tiver de ser implementado em um banco de dados hierrquico, por exemplo, um modelo hierrquico deve ser produzido, adequando a modelagem de entidades e relacionamentos a esta plataforma de implementao. Atualmente, a plataforma de implementao para armazenamento de dados mais difundida a dos Bancos de Dados Relacionais e, portanto, neste texto, discutiremos apenas o projeto lgico de bancos de dados relacionais. Conforme discutido no captulo 4, em um modelo de dados relacional, os conjuntos de dados so representados por tabelas de valores. Cada tabela, denominada de relao, bidimensional, sendo organizada em linhas e colunas. Para se realizar o mapeamento de um modelo de entidades e relacionamentos em um modelo relacional, pode-se utilizar como ponto de partida as seguintes diretrizes: Conjuntos de entidades e agregados devem dar origem a tabelas; Uma instncia de um conjunto de entidades ou de um agregado deve ser representada como uma linha da tabela correspondente; Um atributo de um conjunto de entidades ou agregado deve ser tratado como uma coluna da tabela correspondente; Toda tabela tem de ter uma chave primria, que pode ser um atributo determinante do conjunto de entidades ou agregado correspondente, ou uma nova coluna criada exclusivamente para este fim; Relacionamentos devem ser mapeados atravs da transposio da chave primria de uma tabela para a outra. Ainda que este mapeamento seja amplamente aplicvel, sempre necessrio avaliar requisitos no funcionais para se chegar ao melhor projeto para uma dada situao. Alm disso, os relacionamentos requerem um cuidado maior e, por isso, so tratados a seguir com mais detalhes.
62
Relacionamentos 1 : 1 No exemplo da figura 6.1, ambas as solues so igualmente vlidas. Deve-se observar para cada caso, contudo, a melhor soluo, considerando os seguintes aspectos: Se A for total em R (todo A est associado a um B), melhor colocar a chave de B (#B) em A, como mostra o exemplo da figura 6.2. Se B for total em R (todo B est associado a um A), melhor colocar a chave de A (#A) em B. Se ambos forem totais, pode-se trabalhar com uma nica tabela escolhendo uma das chaves #A ou #B como chave primria, como mostra o exemplo da figura 6.3. Caso contrrio, melhor transpor a chave que dar origem a uma coluna mais densa, isto , que ter menos valores nulos. Diagrama E/R #A Diagrama Relacional A #A #Bt A ou #B B (0,1)
(0,1)
B #B #At B
Figura 6.1 - Traduo de Relacionamentos 1:1 do Diagrama E/R para o Relacional.
Diagrama E/R
Funcionrio
#Fun
(1,1)
gerencia
(0,1)
Departamento
#Dep #Fun t
Diagrama Relacional
Funcionrio
Departamento
Figura 6.2 Exemplo de Relacionamento 1:1.
63
Diagrama E/R
Mquina
(1,1)
utiliza
(1,1)
Mistura Combustvel
Uma mquina emprega necessariamente uma mistura combustvel e vice-versa.

#Maq ou #MCo
Diagrama Relacional
Mquina / Mistura Combustvel
Figura 6.3 - Exemplo de um relacionamento 1:1 total em ambos os lados. Relacionamentos 1 : N Neste caso, deve-se transpor a chave da tabela correspondente ao conjunto de entidades de cardinalidade mxima N para a tabela que representa o conjunto de entidades cuja cardinalidade mxima 1, como mostra a figura 6.4. Diagrama E/R #A Diagrama Relacional A (0,1)
(0,N)
B #B #At B
Figura 6.4 - Traduo de Relacionamentos 1:N do Diagrama E/R para o Relacional. Um A pode estar associado a vrios Bs, mas um B s pode estar associado a um A, logo deve-se transpor a chave primria de A para B. A figura 6.5 mostra um exemplo desta situao. Diagrama E/R (1,1) lota
Departamento
#Dep
(0,N)
Funcionrio
#Fun #Dep t
Diagrama Relacional
Departamento
Funcionrio
Figura 6.5 Exemplo de um relacionamento 1:N.
64
Relacionamentos N : N No caso de relacionamentos N:N (agregado), deve-se criar uma terceira tabela, transpondo as chaves primrias das duas tabelas que participam do relacionamento N:N, como mostra a figura 6.6. Se existirem atributos do relacionamento, estes devero ser colocados na nova tabela. Caso seja necessrio, algum desses atributos pode ser designado para compor a chave primria da tabela correspondendo ao agregado, como ilustra o exemplo da figura 6.7.
Diagrama E/R #A Diagrama Relacional
(0,N)
R #A #B
(0,N) #B
Figura 6.6 - Traduo de Relacionamentos N:N do Diagrama E/R para o Relacional.
Registro Histrico
Diagrama E/R
Aluno
(0,N)
cursou
(0,N)
Disciplina
Diagrama Relacional
#Al Aluno
# Al #Dis #Perodo
#Dis Disciplina
Registro Histrico
Figura 6.7 Exemplo de relacionamento N:N.
65
Auto-Relacionamentos Os auto-relacionamentos devem seguir as mesmas regras de traduo de relacionamentos, como mostram os exemplos das figuras 6.8 e 6.9.
(0,N) Diagrama E/R

est subordinada a
(0,1)
Unidade Organizacional
Diagrama Relacional
#UO #UO-Superior t
Unidade Organizacional
Figura 6.8 Exemplo de auto-relacionamento 1:N.
(0,N) Diagrama E/R PrRequisito (0,N) Disciplina #Dis Disciplina
Diagrama Relacional
# Dis #Dis-Pr-Req
Pr-Requisito
Figura 6.9 Exemplo de auto-relacionamentos N:N. Relacionamentos entre um Conjunto de Entidades e um Agregado J discutimos como fazer a traduo de um agregado para o modelo relacional. Um relacionamento entre uma entidade e um agregado ter o mesmo tratamento que um relacionamento entre entidades, considerando, agora, o agregado como uma entidade. Tomemos como exemplo um relacionamento 1:N entre uma entidade e um agregado, como mostra o exemplo da figura 6.10.
66
Registro Histrico
Diagrama E/R
Aluno
(0,N)
cursou
(0,N)
Disciplina
(0,N) (1,1) Situao #Al Diagrama Relacional Aluno

# Al #Dis #Perodo #Sit t
#Dis Disciplina
Registro Histrico #Sit Situao
Figura 6.10 Exemplo de relacionamento 1:N entre uma entidade e um agregado. Relacionamento Ternrio No caso de relacionamentos ternrios, deve-se criar uma nova tabela contendo as chaves das trs entidades envolvidas, como mostra a figura 6.11. Assim como no caso de agregados, se existirem atributos do relacionamento, estes devero ser colocados na nova tabela. Caso seja necessrio, algum desses atributos pode ser designado para compor a chave primria da nova tabela.
67
C Diagrama E/R A #A Diagrama Relacional A (0,N) (0,N) R

#A #B #C
(0,N)
B #B B
#C C Figura 6.11 - Traduo de Relacionamentos Ternrios. Particionamento No caso de particionamento de conjuntos de entidades, deve-se criar uma tabela para o super-tipo e tantas tabelas quantos forem os sub-tipos, todos com a mesma chave, como mostra a figura 6.12. Caso no haja no modelo conceitual um atributo determinante no super-tipo, uma chave primria deve ser criada para fazer a amarrao com os sub-tipos. #ST Super-tipo Super-tipo
#ST Sub-tipo1 Sub-tipoN Sub-tipo1
#ST Sub-tipoN
Figura 6.12 Traduo de Particionamento. Atributos Multivalorados Segundo a propriedade do modelo relacional que nos diz que cada clula de uma relao pode conter no mximo um nico valor, no podemos representar atributos multivalorados como uma nica coluna da tabela. H algumas solues possveis para este problema, tal como, criar tantas colunas quantas necessrias para representar o atributo. Esta soluo, contudo, pode, em muitos casos, no ser eficiente ou mesmo possvel. Uma soluo mais geral para este problema criar uma tabela em separado, como mostra a figura 6.13.
68
#Cli Cliente Cliente telefone
#Cli #Num Telefone
Figura 6.13 Mapeamento Geral de Atributos Multi-valorados.
6.2 - Projeto Modular de Programas

A tarefa de construo de sistemas computadorizados requer uma organizao das idias, de modo a se conseguir desenvolver produtos com qualidade. Programas escritos sem qualquer subdiviso so inviveis do ponto de vista administrativo e no permitem reaproveitamento de trabalhos anteriormente executados. O Projeto Modular de Programas oferece uma coleo de orientaes, tcnicas, estratgicas e heursticas capazes de conduzir a bons projetos de programas. O objetivo desenvolver programas com menor complexidade, usando o princpio dividir para simplificar. Como resultados de um bom projeto de programas, tem-se: Facilidade na leitura de programas (maior legibilidade); Maior rapidez na depurao de programas na fase de testes; Facilidade de modificao de programas na fase de manuteno (maior alterabilidade). O projeto estruturado de sistemas, em sua dimenso de funes, envolve duas grandes etapas: o projeto da arquitetura do sistema e o projeto detalhado dos mdulos. Paralelamente, devem ser feitos o projeto de dados e o projeto da interface com o usurio. Em ambos os casos do projeto funcional estruturado, tcnicas de Projeto Modular de Programas so empregadas. Apenas de se usar diferentes variaes, basicamente, dois conceitos so centrais para o projeto estruturado de sistemas: Mdulo: Conjunto de instrues que desempenha uma funo especfica dentro de um programa. definido por: entrada/sada, funo, lgica e dados internos. Conexo entre Mdulos: Forma como os mdulos interagem entre si. O bloco bsico de construo de um programa estruturado um mdulo. Os programas estruturados so organizados como uma hierarquia de mdulos. A idia bsica, ento, estruturar os programas em termos de mdulos e conexes entre estes mdulos. O Projeto Modular de Programas considera, ainda, cinco aspectos importantes para o projeto de programas:
69
Permite que a forma da soluo seja guiada pela forma do problema. Procura solucionar sistemas complexos atravs da segmentao deste sistema em caixas pretas e pela organizao destas caixas pretas em uma hierarquia conveniente para uma implementao computadorizada. Utiliza ferramentas, especialmente as grficas, que tornam os sistemas de fcil compreenso. Oferece um conjunto de estratgias para desenvolver o projeto de soluo a partir de uma declarao bem definida do problema. Oferece um conjunto de critrios para avaliao da qualidade de um determinado projeto-soluo com respeito ao problema a ser resolvido. So objetivos do Projeto Modular de Programas: Permitir a construo de programas mais simples; Obter mdulos independentes; Permitir testes por partes; Ter menos cdigo a analisar em uma manuteno; Servir de guia para a programao estruturada; Construir mdulos com uma nica funo; Permitir reutilizao.
6.2.1 - Simplificando um Sistema

O Projeto Modular procura simplificar um sistema complexo, particionando-o em mdulos e organizando esses hierarquicamente. O sistema subdividido em caixas-pretas, que so organizadas em uma hierarquia conveniente. A vantagem do uso da caixa-preta est no fato de que no precisamos conhecer como ela trabalha, mas apenas utiliz-la. As caractersticas de uma caixa-preta so: sabemos como devem ser os elementos de entrada, isto , as informaes necessrias para seu processamento; sabemos como devem ser os elementos de sada, isto , os resultados oriundos do seu processamento; conhecemos a sua funo, isto , que processamento ela faz sobre os dados de entrada para que sejam produzidos os resultados; no precisamos conhecer como ela realiza as operaes, nem to pouco seus procedimentos internos, para podermos utiliz-la. Sistemas compostos por caixas pretas so facilmente construdos, testados, corrigidos, entendidos e modificados. Deste modo, o primeiro passo no controle da
70
complexidade no projeto estruturado consiste em segmentar um sistema em caixas pretas de modo a atingir as seguintes metas: cada caixa preta deve resolver uma parte bem definida do problema; a funo de cada caixa preta deve ser facilmente compreendida; conexes entre caixas pretas devem refletir apenas conexes entre partes do problema; as conexes devem ser to simples e independentes quanto possvel. Organizando as Caixas Pretas Hierarquicamente Antes de iniciarmos uma discusso sobre Projeto Modular de Programas, passemos a observar os exemplos das figuras 6.14, 6.15 e 6.16, que mostram trs organogramas de empresas. Presidente
Z Figura 6.14 - Organograma da Empresa 1. Presidente
Funcionrio 1
Funcionrio 2
...
Funcionrio N
Figura 6.15 - Organograma da Empresa 2.
71
Presidente
A1
A2
A3
B1
B2
C1
C2
C3
Figura 6.16 - Organograma da Empresa 3. Como podemos notar, no organograma da empresa 1, o vice-presidente A e os gerentes X e Y, possuem tarefas triviais, pois cada um deles tem como responsabilidade gerenciar apenas um subordinado. Neste caso, todo servio seria realizado pelo funcionrio Z. Poderamos sugerir, ento, acabar com as gerncias. Por outro lado, o presidente da empresa 2 est sobrecarregado, uma vez que ele gerencia funcionrios demais. A empresa 3 parece apresentar um organograma mais equilibrado, no qual cada gerente gerencia um nmero apropriado de subordinados. As estruturas de um programa, ou de um sistema, podem ser discutidas de maneira anloga questo dos organogramas. Ou seja, os mdulos (caixas-pretas) devem ser dispostos em uma hierarquia de modo a, por um lado, no provocar sobrecarga de processamento e, de outro, no criar mdulos apenas intermedirios, sem desempenhar nenhuma funo. H vrios tipos de diagramas hierrquicos para o projeto de programas (Martin et al., 1991). Neste texto, sero explorados dois deles: o Diagrama Hierrquico de Funes (DHF), usado principalmente para o projeto arquitetural, e o Diagrama de Estrutura Modular (DEM), usado para o projeto detalhado de mdulos. A diferena bsica entre eles que o DHF no representa o fluxo de dados e controles entre mdulos, nem aspectos relacionados com detalhes lgicos de um mdulo, tais como estruturas de repetio (laos) e condio. Estas informaes so capturadas em um DEM e, por isso mesmo, o DEM empregado no projeto detalhado de mdulos, enquanto o DHF usado para o projeto da arquitetura do sistema.
6.2.2 - Diagrama Hierrquico de Funes

Um Diagrama Hierrquico de Funes (DHF) define a arquitetura global de um programa ou sistema, mostrando mdulos e suas inter-relaes (Martin et al., 1991). Cada mdulo pode representar um subsistema, programa ou mdulo de programa. Sua finalidade mostrar os componentes funcionais gerais (arquitetura do sistema) e fazer referncia a diagramas detalhados (tipicamente Diagramas de Estrutura Modular). Um DHF no mostra o fluxo de dados entre componentes funcionais ou qualquer informao de estruturas de controle, tais como laos (loops) ou condies.
72
A estrutura de um DHF tem como ponto de partida um mdulo inicial, localizado no topo da hierarquia, que detm o controle sobre os demais mdulos do diagrama, ditos seus mdulos-filhos. Um mdulo-filho, por sua vez, pode ser pai de outros mdulos, indicando que ele detm o controle sobre esses mdulos. A construo de um DHF pode ser bastante facilitada se existir um diagrama de casos de uso do sistema. De fato, consideraes anlogas s feitas no projeto da Componente de Gerncia de Tarefas podem ser aplicadas no projeto arquitetural usando DHFs. Cada executvel deve dar origem a um DHF. Os casos de uso controlados por esse executvel devem ser mdulos-filhos do mdulo inicial do diagrama. Cenrios de um caso de uso podem ser representados como mdulos-filhos do mdulo correspondente. Para sistemas de mdio a grande porte, contudo, representar todos os casos de uso e seus cenrios em um nico diagrama pode torn-lo muito complexo. Assim, novos DHFs poderiam ser elaborados para cada caso de uso, ou para alguns casos de uso. Tomemos como exemplo um sistema de entrega domiclio de refeies, cujo diagrama de casos de uso apresentado na figura 6.17.
Aes: - Efetuar Novo Pedido - Cancelar Pedido - Devolver Pedido - Alterar Dados Pedido Controlar Pedido - Registrar Atendimento Pedido - Definir Entregador Aes: - Incluir Novo Cliente - Alterar Dados Cliente - Excluir Cliente Cadastrar Cliente - Consultar Dados Cliente Aes: Consultar Itens Cardpio - Consultar Refeies - Consultar Sobremesas - Consultar Bebidas
Funcionrio
Figura 6.17 Diagrama de Casos de Uso de um Sistema de Entrega de Refeies Domiclio. Com base neste modelo, poderamos construir o DHF mostrado na figura 6.18. Neste diagrama, optou-se por no representar os cenrios do caso de uso Controlar Pedido, uma vez que este um caso de uso bastante complexo, com vrios cenrios, o que traria uma complexidade indesejada para o DHF. Assim, alm do diagrama da figura 6.18, um outro, cujo mdulo inicial seria Controlar Pedido, deveria ser elaborado. Vale ressaltar que, assim como a Componente de Gerncia de Tarefas, no projeto orientado a objetos, tem forte relao com a Componente de Interface com o Usurio, um DHF pode ser usado como um guia para o projeto das interfaces com o usurio, apoiando a definio de janelas, estruturas de menu, etc.
73
Aplicao Atendimento a Cliente Controlar Pedido Cadastrar Cliente
Incluir Novo Cliente Consultar Cardpio
Alterar Dados Cliente
Consultar Cliente
Excluir Cliente
Consultar Refeies
Consultar Sobremesas
Consultar Bebidas
Figura 6.18 Um Diagrama Hierrquico de Funes para o Sistema de Entrega de Refeies.
6.2.3 - Diagrama de Estrutura Modular

Em um Diagrama de Estrutura Modular (DEM), um programa representado como um conjunto de mdulos organizados hierarquicamente, de modo que os mdulos que executam tarefas de alto nvel no programa so colocados nos nveis superiores da hierarquia, enquanto os mdulos que executam tarefas detalhadas, de nvel mais baixo, aparecem nos nveis inferiores. Observando a hierarquia, os mdulos a cada nvel sucessivo contm tarefas que definem as tarefas realizadas no nvel precedente (Martin et al., 1991). Um mdulo definido como uma coleo de instrues de programa com quatro atributos bsicos: entradas e sadas, funo, lgica e dados internos. Entradas e sadas so, respectivamente, as informaes que um mdulo necessita e fornece. A funo de um mdulo o que ele faz para produzir, a partir da informao de entrada, os resultados da sada. Entradas, sadas e funo fornecem a viso externa do mdulo e, portanto, apenas estes aspectos so representados no diagrama de estrutura modular.
74
A lgica de um mdulo a descrio dos algoritmos que executam a funo. Dados internos so aqueles referenciados apenas dentro do mdulo. Lgica e dados internos representam a viso interna do mdulo e so descritos por uma tcnica de especificao de programas, tal como portugus estruturado, pseudocdigo, tabelas de deciso e rvores de deciso. Assim sendo, um DEM mostra: O particionamento de um programa em mdulos; A hierarquia e a organizao dos mdulos; As interfaces de comunicao entre mdulos (entrada/sada); As funes dos mdulos, dadas por seus nomes; Estruturas de controle entre mdulos, tais como condio de execuo de um mdulo, laos de repetio de mdulos (iterao), dentre outras. Um DEM no mostra a lgica e os dados internos dos mdulos e, por isso, deve ser acompanhado de uma descrio dos mdulos, mostrando os detalhes internos dos procedimentos das caixas pretas. Simbologia do DEM A seguir, so apresentadas as principais notaes utilizadas para elaborar Diagramas de Estrutura Modular (Xavier et al., 1995): Mdulo: Em um DEM, um mdulo representado por um retngulo, dentro do qual est contido seu nome, como mostra a figura 6.19. Um mdulo pr-definido aquele que j existe em uma biblioteca de mdulos e, portanto, no precisa ser descrito ou detalhado. Nome do Mdulo Mdulo Pr-definido
verbo + objeto + {qualificador}
Figura 6.19 Simbologia para Mdulos em um DEM. Conexo entre mdulos: Um sistema um conjunto de mdulos organizados dentro de uma hierarquia, cooperando e se comunicando para realizar um trabalho. A hierarquia mostra quem chama quem. Portanto, mdulos devem estar conectados. No exemplo da figura 6.20, o mdulo A chama o mdulo B passando, como parmetros, os dados X e Y. O mdulo B executa, ento, sua funo e retorna o controle para A, no ponto imediatamente aps chamada de B, passando como resultado o dado Z. A ordem de chamada sempre de cima para baixo, da esquerda para a direita.
75
A
(Parmetros)
Mdulo Chamador
X, Y Z B
Mdulo Chamado (Resultado)
Figura 6.20 Conexo entre mdulos. Comunicao entre mdulos: Mdulos conectados esto se comunicando, logo existem informaes trafegando entre eles. Estas informaes podem ser dados ou controles (descrevem uma situao ocorrida durante a execuo do mdulo). A figura 6.21 mostra a conveno utilizada para se determinar se a informao que est sendo passada entre mdulos um dado ou um controle, juntamente com um exemplo.
Obter dados cliente
cpf
Ligao de Dados
dados-cliente cliente inexistente Ligao de Controle
Pesquisar cliente por cpf
Figura 6.21 Comunicao entre mdulos. Chamadas Condicionais: Em muitos casos, um mdulo s ser ativado se uma condio for satisfeita. Nestes casos, temos chamadas condicionais, cuja notao mostrada na figura 6.22. No exemplo esquerda, o mdulo A pode ou no chamar o mdulo B. No exemplo direita, o mdulo A pode chamar um dos mdulos B ou C. A A
Figura 6.22 Chamada Condicional.
76
Chamadas Iterativas: Algumas vezes, nos deparamos com situaes nas quais um mdulo (ou um conjunto de mdulos) chamado vrias vezes, caracterizando chamadas iterativas ou repetidas, cuja notao mostrada na figura 6.23. No exemplo, os mdulos B e C so chamados repetidas vezes pelo mdulo A. A
Figura 6.23 Chamada Iterativa. Conectores: Algumas vezes, um mesmo mdulo chamado por mais de um mdulo, s vezes em diagramas diferentes. Outras, o diagrama est complexo demais e deseja-se continu-lo em outra pgina. Nestas situaes, conectores podem ser utilizados, como ilustra a figura 6.24.
Cadastrar cliente
v cpf
cpf vlido
cpf cpf vlido v Figura 6.24 Conectores. Tcnicas de Desenho
Validar cpf
Para elaborar um diagrama de estrutura modular, devemos observar as seguintes orientaes: Os mdulos devem ser desenhados na ordem de execuo, da esquerda para a direita. Cada mdulo s deve aparecer uma nica vez no diagrama. Para se evitar cruzamento de linhas, deve-se usar conectores. No segmentar demais. Alm dessas orientaes, o projeto estruturado fornece duas estratgias de projeto para guiar a elaborao de DEMs: a anlise de transformao e a anlise de transao.
77
Essas duas estratgias fornecem dois modelos de estrutura que podem ser usados isoladamente ou em combinao para derivar um projeto estruturado (Martin et al., 1991). A anlise de transformao um modelo de fluxo de informaes centrado na filosofia entrada-processamento-sada. Assim, o DEM correspondente tende a espelhar esta mesma estrutura, podendo ser decomposto em trs grandes ramos, como mostra a figura 6.25.
Ramo de Entrada
entrada vlida
Mdulo Principal
sada entrada vlida sada
Ramo de Sada
Obter Entrada
entrada entrada
Processar Dados
sada
Obter Entrada
sada formatada sada formatada
Ok/NOk
Ler Entrada
Validar Entrada
Ramo de Processamento
Formatar Sada
Emitir / Gravar Sada
Figura 6.25 Anlise de Transformao. O ramo de entrada contm os mdulos que tratam da leitura e validao dos dados de entrada, bem como de uma eventual transformao para um formato adequado para o processamento. O ramo de processamento contm o processamento essencial e deve ser independente de consideraes fsicas de entrada e sada. Finalmente, o ramo de sada trata da transformao dos dados de sada de um formato interno para um formato adequado para o seu registro (p.ex., uma interface com o usurio ou um registro em bancos de dados). A anlise de transao uma estratgia de projeto alternativa para a anlise de transformao. Ela til no projeto de programas de processamento de transaes. O DEM geral para a anlise de transao mostrado na figura 6.26. No topo do diagrama est um mdulo centro de transao, que responsvel pela determinao do tipo de transao e pela chamada do mdulo de transao apropriado. Abaixo dele, esto os vrios mdulos de transao. H um mdulo de transao para cada tipo de transao (Martin et al., 1991).
78
Mdulo Centro de Transao
dados transao
dados transao Transao Tipo 2
dados transao
Transao Tipo 1
Transao Tipo n
Figura 6.26 Anlise de Transao.
6.2.4 - Critrios de Qualidade de Projetos de Programa

O objetivo maior do projeto modular de programas permitir que um sistema complexo seja particionado em mdulos simples. No entanto, vital que essa partio seja feita de tal forma que os mdulos sejam to independentes quanto possvel e que cada um deles execute uma nica funo. Critrios que tratam estes aspectos so, respectivamente, acoplamento e coeso. Acoplamento diz respeito ao grau de interdependncia entre dois mdulos. O objetivo minimizar o acoplamento, isto , tornar os mdulos to independentes quanto possvel. Um baixo acoplamento pode ser obtido: eliminando relaes desnecessrias; enfraquecendo a dependncia das relaes necessrias. Podemos citar como razes para se minimizar o acoplamento: Quanto menos conexes houver entre dois mdulos, menor ser a chance de um problema ocorrido em um deles se refletir em outros. Uma alterao do usurio deve afetar o menor nmero de mdulos possvel, isto , uma alterao em um mdulo no deve implicar em alteraes em outros mdulos. Ao dar manuteno em um mdulo, no devemos nos preocupar com detalhes de codificao de outros mdulos. O acoplamento envolve trs aspectos principais: tipo da conexo, tamanho da conexo e o que comunicado atravs da conexo. O tipo da conexo diz respeito forma como uma conexo estabelecida. O ideal que a comunicao se d atravs de chamadas a subrotinas, cada uma delas fazendo uso apenas de variveis locais. Qualquer informao externa necessria deve ser passada como parmetro. Assim, cada mdulo deve possuir seu escopo prprio de variveis, evitando-se utilizar uma varivel definida em outro mdulo.
79
Com relao ao tamanho da conexo, quanto menor o nmero de informaes trafegando de um mdulo para outro, menor ser o acoplamento. Entretanto, vale a pena ressaltar que importante manter-se a clareza da conexo. No devemos mascarar as informaes que fluem. Finalmente, no que tange ao que comunicado entre mdulos, o ideal que se busque acoplamento apenas de dados. Entretanto, quando se fizer necessria a comunicao de controles, devemos faz-la sem mscaras. Seja o exemplo da figura 6.27. Obter dados registro EOF Ler Registro de Arquivo Figura 6.27 Clareza na comunicao. Neste caso, no indicado mover brancos para o registro e se o registro estiver em branco porque acabou o arquivo (EOF). Com este artifcio, estar-se-ia mascarando o controle. De maneira geral, no adianta melhorar dois destes aspectos se estivermos piorando o terceiro. Muitas vezes, o acoplamento resultante poder ser maior. S devemos fazer alteraes que melhorem um dos aspectos sem afetar os demais. As seguintes orientaes podem servir para apoiar a tomada de deciso: O mdulo chamador no deve nunca enviar um controle ao mdulo chamado. Isto significa que o mdulo chamador est dizendo o que o mdulo chamado deve fazer, caracterizando, portanto, que o mdulo chamado no trata de uma nica funo. S utilizar controles de baixo para cima. O mdulo chamado avisa que no conseguiu executar sua funo, mas no deve dizer ao chamador o que fazer. Evitar o uso de dados globais. Sempre que possvel, utilizar variveis locais. inadimissvel que um mdulo se refira a uma parte interna de outro. Em suma, para minimizar o acoplamento, devemos: Passar o menor nmero possvel de parmetros e, de preferncia, apenas dados. Quando for necessrio passar controles, faz-lo apenas de baixo para cima. Ter pontos nicos de entrada e sada em um mdulo. Sempre que possvel, utilizar programas compilados separadamente.
80
Coeso define como as atividades de um mdulo esto relacionadas umas com as outras. Vale a pena ressaltar que coeso e acoplamento so interdependentes e, portanto, uma boa coeso deve nos levar a um pequeno acoplamento. A figura 6.28 procura mostrar este fato. No projeto modular de programas, os mdulos devem ter alta coeso, isto , seus elementos internos devem estar fortemente relacionados uns com os outros. O grau de coeso de um mdulo tem um impacto direto na qualidade do software produzido, sobretudo no que tange alterabilidade, manutenibilidade, legibilidade e capacidade de reutilizao. O ideal que tenhamos apenas coeso funcional, isto , que todos os elementos de um mdulo estejam contribuindo para a execuo de uma e somente uma funo do sistema. Baixa Coeso
Fbrica de Refrigerantes Iate
Baixa Coeso
Alto Acoplamento
CST Serra
Vila Velha
Conjunto Habitacional da CST Trfego Intenso
Fbrica de Garrafas Plsticas
Alta Coeso
Fbrica de Refrigerantes Iate
Alta Coeso
Baixo Acoplamento
CST Serra
Vila Velha Fbrica de Garrafas Plsticas Pouco Trfego
Conjunto Habitacional da CST
Figura 6.28 Coeso e Acomplamento.
81
Referncias (Martin et al., 1991) J. Martin, C. McClure. Tcnicas Estruturadas e CASE. Makron Books, So Paulo, 1991. (Xavier et al., 1995) C.M.S. Xavier, C. Portilho. Projetando com Qualidade a Tecnologia de Sistemas de Informao. Livros Tcnicos e Cientficos Editora, 1995.
82

Apostila ProjetoOO

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostila ProjetoOO

Загружено:

Авторское право:

Доступные форматы

UFES - Universidade Federal do Esprito Santo

Ricardo de Almeida Falbo

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

Anlise e Especificao de Requisitos (o que)

1.1 A Fase de Projeto

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

1.2 Conceitos Bsicos de Projeto

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

1.3 Princpios de Projeto

Mais especificamente, o projeto de software deve:

1.4 Qualidade do Projeto

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

1.5 Tecnologia Imperfeita e Requisitos Tecnolgicos

Impactos da tecnologia imperfeita:

UFES Departamento de Informtica

Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 1 - Introduo

UFES Departamento de Informtica

2.1 Objetivos do Projeto Arquitetural

UFES Departamento de Informtica

2.2 A Arquitetura Cliente-Servidor

UFES Departamento de Informtica

Servidor Local de Aplicao

Figura 2.3 Uma arquitetura de hardware cliente-servidor em trs camadas.

UFES Departamento de Informtica

Servidor Locais de Arquivo

UFES Departamento de Informtica

Camada de Gerncia de Dados

UFES Departamento de Informtica

2.3 Coletando Estatsticas e Restries

UFES Departamento de Informtica

UFES Departamento de Informtica

Caso de Uso\Classe Efetuar pedido Cancelar pedido Alterar pedido

Item de Pedido C RE CERA

UFES Departamento de Informtica

UFES Departamento de Informtica

Localizao/Classe Internet Vitria Linhares Cachoeiro

Pedido ERA CERA C C

Item de Pedido CERA CERA C C

UFES Departamento de Informtica

2.4 Estratgias de Acesso Oportuno a Dados

UFES Departamento de Informtica

UFES Departamento de Informtica

2.5 Sumrio da Determinao da Distribuio Geogrfica

UFES Departamento de Informtica

2.7 Modelo de Tarefas

UFES Departamento de Informtica

2.8 Atividades Tecnolgicas

UFES Departamento de Informtica

3 - Projeto de Interface com o Usurio

UFES Departamento de Informtica

Modificaes do Projeto de Interface

Estudo da Avaliao pelo Projetista

Projeto de Interface Completo

Figura 3.1 - Abordagem Iterativa para o Projeto de Interface com o Usurio.

3.1 Aspectos Gerais de Interface com o Usurio