Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Projeto de Sistemas
Notas de Aula
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
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
Projeto (como)
Domnio da Soluo
Mundo Computacional
Implementao
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.
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.
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
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.
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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.
Figura 2.1 Onde fazer uma torrada? Em uma torradeira ou em um fogo industrial?
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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.
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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.
13
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
Cliente R R R
Pedido C RE RA
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
Cliente R R R R
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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.
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 2 Projeto Arquitetural
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
23
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 3 Projeto de Interface com o Usurio
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
24
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 3 Projeto de Interface com o Usurio
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 3 Projeto de Interface com o Usurio
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
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 ... ...
27
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 4 Projeto de Bancos de Dados Relacionais
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 4 Projeto de Bancos de Dados Relacionais
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 4 Projeto de Bancos de Dados Relacionais
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 4 Projeto de Bancos de Dados Relacionais
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
32
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
33
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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).
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
36
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
39
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
42
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
43
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
45
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
ProdutoA1
ProdutoAbstratoB
ProdutoB2
ProdutoB1
51
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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 ()
55
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
0. .* 1
E ditorTe x to
0. .* 0..1
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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()
S ujeitoConc reto estad o atribu irEs tado() 1 obter E stad o() 0..*
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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
. ..
...
atu aliz ar( ) obt erEs tado( )
60
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 5 Projeto Orientado a Objetos
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.
61
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
62
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
Diagrama E/R
Funcionrio
#Fun
(1,1)
gerencia
(0,1)
Departamento
#Dep #Fun t
Diagrama Relacional
Funcionrio
Departamento
63
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
Diagrama E/R
Mquina
(1,1)
utiliza
(1,1)
Mistura Combustvel
Diagrama Relacional
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
64
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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.
(0,N)
R #A #B
(0,N) #B
Registro Histrico
Diagrama E/R
Aluno
(0,N)
cursou
(0,N)
Disciplina
Diagrama Relacional
#Al Aluno
# Al #Dis #Perodo
#Dis Disciplina
Registro Histrico
65
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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,1)
Unidade Organizacional
Diagrama Relacional
#UO #UO-Superior t
Unidade Organizacional
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
Registro Histrico
Diagrama E/R
Aluno
(0,N)
cursou
(0,N)
Disciplina
#Dis Disciplina
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
(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-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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
69
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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.
70
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
Funcionrio 1
Funcionrio 2
...
Funcionrio N
71
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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.
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
Consultar Cliente
Excluir Cliente
Consultar Refeies
Consultar Sobremesas
Consultar Bebidas
74
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
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
76
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
dados transao
dados transao
Transao Tipo 1
Transao Tipo n
79
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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
Alta Coeso
Fbrica de Refrigerantes Iate
Alta Coeso
Baixo Acoplamento
CST Serra
81
Projeto de Sistemas: Notas de Aula Ricardo de Almeida Falbo Captulo 6 Projeto Estruturado de Sistemas
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