Anlise de Sistemas

ndice
Captulo 1 - Introduo 1.1 Anlise e Especificao de Requisitos 1.2 A Organizao deste Texto PARTE I ESPECIFICAO DE REQUISITOS Captulo 2 Tcnicas de Levantamento de Requisitos 2.1 Amostragem 2.2 Investigao 2.3 Entrevistas 2.4 Questionrios 2.5 Observao 2.6 Prototipao Captulo 3 Modelagem de Casos de Uso 3.1 Casos de Uso 3.2 Diagramas de Casos de Uso 3.3 Descrio de Casos de Uso 3.4 Associaes entre Casos de Uso PARTE II ANLISE ORIENTADA A OBJETOS Captulo 4 Introduo Orientao a Objetos 4.1 Abordagem Estruturada x Abordagem Orientada a Objetos 4.2 Conceitos da Orientao a Objetos 4.3 Processo de Desenvolvimento Orientado a Objetos 4.4 A Linguagem de Modelagem Unificada Captulo 5 - Anlise Orientada a Objetos 5.1 - Identificao de Classes 5.2 - Especificao de Hierarquias de Generalizao / Especializao 5.3 - Identificao de Subsistemas 5.4 - Identificao de Associaes e Definio de Atributos 5.5 - Determinao do Comportamento 5.6 - Definio das Operaes PARTE III ANLISE ESSENCIAL DE SISTEMAS Captulo 6 Introduo Anlise Essencial 6.1 - Conceitos 6.2 - Especificao da Essncia do Sistema 1 1 2 3 4 4 7 8 13 18 20 23 23 25 26 28 33 34 34 36 47 56 59 60 62 63 64 69 72 75 76 77 82

Captulo 7 Modelagem de Dados 7.1 - Conceitos Bsicos 7.2 - Restries de Integridade ou Leis de Consolidao 7.3 - Outras Consideraes sobre Atributos 7.4 - Outros Conceitos Importantes 7.5 - Dicionrio de Dados Captulo 8 Modelagem Funcional 8.1 - Conceitos Bsicos 8.2 - Construindo DFDs 8.3 - Tcnicas de Especificao de Processos

86 86 90 94 96 102 104 105 111 113

1 Introduo
O desenvolvimento de software uma atividade de crescente importncia na sociedade contempornea. A utilizao de computadores nas mais diversas reas do conhecimento humano tem gerado uma crescente demanda por solues computadorizadas. importante observar que, associada ao acrscimo da demanda, a evoluo do hardware tem sido mais acentuada, disponibilizando aos usurios mquinas cada vez mais velozes e com maior capacidade de processamento. Neste contexto, identificou-se, j na dcada de 70, uma situao crtica no desenvolvimento de software, a chamada Crise do Software [Pressman00], caracterizada pelos seguintes fatos: demanda muito superior capacidade de desenvolvimento; qualidade insuficiente dos produtos; e estimativas de custo e tempo raramente cumpridas nos projetos. Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, surgiu a rea de pesquisa denominada Engenharia de Software. A Engenharia de Software busca organizar esforos no desenvolvimento de ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software. Dentre as principais atividades de um processo de desenvolvimento de software, destaca-se a atividade de anlise e especificao de requisitos, na qual os requisitos de um sistema so levantados e modelados, para s ento ser projetada e implementada uma soluo. Esta atividade o objeto de estudo deste texto.

1.1 Anlise e Especificao de Requisitos

Um completo entendimento dos requisitos do software essencial para o sucesso de um esforo de desenvolvimento de software. A atividade de anlise e especificao de requisitos um processo de descoberta, refinamento, modelagem e especificao. O escopo do software definido no planejamento do projeto refinado em detalhe, as funes e o desempenho do software so especificados, as interfaces com outros sistemas so indicadas e restries que o software deve atender so estabelecidas. Modelos dos dados requeridos, do controle e do comportamento operacional so construdos. Finalmente, critrios para a avaliao da qualidade em atividades subseqentes so estabelecidos. Os principais profissionais envolvidos nesta atividade so o engenheiro de software (muitas vezes chamado analista) e o cliente / usurio. Neste texto, dividiremos a atividade de Anlise e Especificao de Requisitos em duas outras com propsitos mais especficos, ainda que extremamente relacionadas: Elicitao de Requisitos: nesta atividade, os requisitos so capturados sob uma perspectiva dos usurios, isto , os modelos gerados procuram definir as funcionalidades (requisitos funcionais) e restries (requisitos no funcionais) que devem ser consideradas para atender s necessidades dos usurios; Anlise: nesta atividade, so modelados as estruturas internas de um sistema capazes de satisfazer os requisitos identificados.
1

A etapa de Elicitao de Requisitos (ou Especificao de Requisitos) independente de paradigma, uma vez que trata os requisitos do sistema sob uma perspectiva externa. Entretanto, a atividade de Anlise, que modela as estruturas internas de um sistema, completamente dependente do paradigma adotado no desenvolvimento. Assim, este texto dividido em trs partes: PARTE I - ESPECIFICAO DE REQUISITOS: trata do levantamento e da modelagem dos requisitos segundo uma perspectiva externa, independente de paradigma. Nesta parte, so discutidas tcnicas para levantamento de requisitos e a tcnica de modelagem de casos de uso, para modelagem dos requisitos funcionais de um sistema. PARTE II - ANLISE ORIENTADA A OBJETOS: apresenta os principais conceitos da orientao a objetos e a linguagem de modelagem unificada (UML) e explora a modelagem de anlise segundo o paradigma de objetos. PARTE III - ANLISE ESSENCIAL DE SISTEMAS: apresenta os principais conceitos da anlise essencial e discute a modelagem de anlise segundo o mtodo da anlise essencial, que adota o paradigma estruturado.

1.2 - A Organizao deste Texto

Este texto procura oferecer uma viso geral atividade de Anlise e Especificao de Requisitos e contm, alm desta Introduo, mais sete captulos, divididos em trs partes. Na PARTE I, o captulo 2 Tcnicas de Levantamento de Requisitos apresenta as principais tcnicas utilizadas na identificao dos requisitos de um sistema. O captulo 3 Modelagem de Casos de Uso trata da modelagem de requisitos funcionais, utilizando a tcnica de modelagem de casos de uso. Na PARTE II, o enfoque recai sobre o paradigma orientado a objetos (OO). O captulo 4 Introduo Orientao a Objetos discute os principais conceitos da orientao a objetos e alguns aspectos relacionados com o processo de desenvolvimento OO, bem como introduz a Linguagem de Modelagem Unificada (Unified Modeling Language UML). O captulo 5 Anlise Orientada a Objetos discute a modelagem de anlise segundo o paradigma OO, utilizando os modelos propostos na UML. Finalmente, na PARTE III, discute-se a Anlise Essencial. O captulo 6 Introduo Anlise Essencial apresenta os principais conceitos e modelos utilizados na Anlise Essencial. O captulo 7 Modelagem de Dados apresenta o modelo de Entidades e Relacionamentos. No captulo 8 Modelagem Funcional o foco a tcnica de Diagramas de Fluxos de Dados.

PARTE I ESPECIFICAO DE REQUISITOS

2 Tcnicas de Levantamento de Requisitos (Referncia: [Kendall92])

Em todo desenvolvimento de software, um aspecto fundamental a captura dos requisitos dos usurios. Para apoiar este trabalho, diversas tcnicas podem ser utilizadas.

2.1 Amostragem (Referncia: Captulo 4 [Kendall92])

Em um levantamento de requisitos, geralmente um engenheiro de software se depara com duas importantes questes: Entre os muitos relatrios, formulrios e documentos gerados pelos membros de uma organizao, quais devero ser objeto de investigao? Pode haver um grande nmero de pessoas afetadas pelo sistema de informao proposto. Quais delas devem ser entrevistadas, observadas ou questionadas?

Servindo de base para todas as tcnicas de levantamento de requisitos, entre elas investigao, entrevistas e observao, esto as decises cruciais dizendo respeito a o que examinar e quem questionar ou observar. Estas decises podem ser apoiadas por uma abordagem estruturada chamada amostragem. Amostragem o processo de seleo sistemtica de elementos representativos de uma populao. Quando os elementos selecionados em uma amostragem so analisados, pode-se assumir que esta anlise revelar informaes teis acerca da populao como um todo. Por que usar amostragem? diminuir custos; acelerar o processo de levantamento de informaes; eficincia: a informao tende a ser mais apurada, j que menos elementos podem ser analisados, mas estes podem ser analisados com mais detalhes; reduzir tendncias.

O Processo da Amostragem H quatro passos que um engenheiro de software deve seguir para projetar uma boa amostra: 1. Determinar os dados a serem coletados ou descritos: Definir o que coletar e para que, isto , que tipo de tcnica de levantamento de informao ser usado depois. Coletar dados irrelevantes representa perda de tempo. 2. Determinar a populao a ser amostrada (o que / quem): No caso de documentos, definir quais documentos investigar e de que perodo / intervalo. No caso de pessoas, estabelecer a que nvel da organizao pertencem ou se so pessoas de fora. 3. Escolher o tipo da amostra. 4. Decidir sobre o tamanho da amostra. Os dois primeiros passos dizem respeito ao contexto do desenvolvimento. Os dois ltimos referem-se tcnica de amostragem propriamente dita e so detalhados a seguir.
4

Tipos de Amostra Elementos da amostra so selecionados ... diretamente, sem restries segundo um critrio especfico no baseada em probabilidades de Convenincia Intencional baseada em probabilidades Randmica Simples Randmica Complexa

Amostra de Convenincia: irrestrita, no utiliza probabilidades, mais fcil e, geralmente, apresenta resultados irreais. Ex: aviso chamando os interessados a participar de uma reunio. Amostra Intencional: a escolha feita com base em critrios pr-estabelecidos pelo engenheiro de software, sem levar em conta probabilidades. uma amostra apenas moderadamente confivel. Ex: engenheiro de software escolhe, para entrevista, um grupo de indivduos que aparentam ter conhecimento e interesse no novo sistema. Amostra Randmica Simples: necessrio ter em mos uma lista da populao a ser amostrada (documentos ou pessoas) para garantir que cada elemento tem igual chance de ser selecionado. Geralmente, no prtica, especialmente para documentos e relatrios. Amostra Randmica Complexa: pode ser de trs tipos: Amostra sistemtica: o tipo mais simples de amostragem que leva em conta probabilidades. Consiste em se pegar sempre o k-simo elemento da populao. Pode introduzir tendncias. Amostra Estratificada: a abordagem mais importante para um engenheiro de software. Identifica sub-populaes e escolhe elementos dentre essas subpopulaes. Muito til quando se deseja usar diferentes tcnicas de levantamento de informao para sub-grupos especficos. Ex: coletar informaes de pessoas de diferentes nveis da organizao. Amostra de Grupos: consiste em selecionar um grupo para ser estudado. Ex: selecionar um ou duas filiais de uma organizao, assumindo que espelham o comportamento de todas filiais.

Tamanho da Amostra O tamanho da amostra depende substancialmente do custo envolvido e do tempo requerido para se proceder a investigao, entrevista ou questionrio posteriormente. O clculo do tamanho da amostra varia, ainda, em funo do tipo de informao que se deseja obter. Quando a informao desejada for quantitativa, h dois procedimentos bsicos de clculo, dependentes do tipo de informao que se deseja obter:

Percentuais: quando se deseja saber propores ou percentuais, por exemplo o percentual de pessoas em uma organizao que pensa de um certo modo, o tamanho da amostra pode ser calculado da seguinte forma: 1. 2. 3. 4. 5. Determinar o atributo a ser amostrado. Localizar onde pode ser achado. Estimar o percentual da populao que tem o atributo (p). Considerar um intervalo de aceitao (i). Ex: 10% Escolher nvel de confiabilidade (%) e procurar seu correspondente coeficiente de segurana na tabela 2.1 (z). 6. Calcular o erro padro: p = i / z. 7. Determinar o tamanho da amostra (n): n = (p (1 p) / p2) + 1 Nvel de Confiabilidade (%) 99 98 97 96 95 90 80 50 Coeficiente de Segurana (z) 2,58 2,33 2,17 2,05 1,96 1,65 1,28 0,67

Tabela 2.1 Valores de Coeficiente de Segurana [Kendall92]. Valores: quando se deseja saber quantidades (valores) reais, por exemplo o nmero de erros de preenchimento de um determinado formulrio, o tamanho da amostra pode ser calculado da seguinte forma: 1. Determinar a varivel a ser amostrada. 2. Localizar onde pode ser achada. 3. Examinar a varivel para se ter uma idia acerca de sua magnitude e disperso. Idealmente, deveria se conhecer a mdia e o desvio padro (s). Contudo, exatamente isso que normalmente se quer saber ao fazermos uma amostragem. Logo, necessrio fazer uma estimativa inicial, que ser refinada com a amostragem. 4. Considerar um intervalo de aceitao (i). 5. Escolher nvel de confiabilidade (%) e procurar seu correspondente coeficiente de segurana na tabela 1.1 (z). 6. Calcular o erro padro da mdia: x = i / z. 7. Determinar o tamanho da amostra (n): n = (s / x)2 + 1 Quando as informaes a serem coletadas forem qualitativas, melhor tentar obt-las atravs de entrevistas. Entretanto, no h frmulas mgicas para ajudar engenheiros de software a determinar quantas pessoas entrevistar em uma organizao. Esta deciso deve ser baseada no tempo gasto para se proceder uma entrevista. Uma boa regra de bolso, independentemente do tamanho da organizao, consiste em entrevistar pelo menos trs pessoas em cada nvel da organizao e uma pessoa por rea funcional.
6

2.2 Investigao (Referncia: Captulo 4 [Kendall92])

Muitas vezes, algumas informaes so difceis de serem obtidas atravs de entrevistas ou observao. Tais informaes revelam, tipicamente, um histrico da organizao e sua direo. Nestes casos, devemos utilizar investigao, isto , anlise de documentos. Atravs de investigao, podemos obter mais facilmente informaes, tais como tipos de documentos e problemas associados, informao financeira e contextos da organizao. Tais informaes so difceis de serem obtidas atravs de outras tcnicas de levantamento de requisitos, tais como entrevistas ou observao. Anlise de Documentos Quantitativos Documentos com formato pr-determinado, tais como relatrios e formulrios, trazem informaes muito teis a um engenheiro de software. Estes documentos tm um propsito especfico e um pblico-alvo. Relatrios de desempenho, por exemplo, podem mostrar metas de uma organizao, a distncia em relao meta e a tendncia atual. Relatrios usados no processo de tomada de deciso mostram informaes compiladas e podem incorporar algum conhecimento sobre a estratgia da organizao. Fichas (registros) provem atualizaes peridicas do que est ocorrendo no negcio. Um engenheiro de software pode inspecionar uma ficha para: (i) checar erros em quantidades e totais, (ii) procurar oportunidades de melhorar o desenho da ficha, (iii) observar nmero e tipos de transaes e (iv) procurar instncias onde a introduo de um sistema computadorizado pode simplificar o trabalho (clculos, por exemplo). Formulrios, assim como fichas, so muito teis para o levantamento de requisitos. Devem ser inspecionados tanto formulrios oficiais quanto no oficiais em uso. Exemplares de formulrios em branco devem ser coletados, procurando-se observar o tipo, propsito e o pblico alvo. Deve-se, ainda, verificar quem realmente recebe o formulrio. Ao se examinar formulrios preenchidos, observar se: (i) h itens no preenchidos, (ii) h formulrios nunca usados, (iii) h formulrios no oficiais usados regularmente e (iv) os formulrios so preenchidos pelas pessoas certas. Na investigao de formulrios preenchidos, possvel detectar problemas como: (i) a informao no flui como planejado, (ii) pontos de gargalo no processamento de formulrios, (iii) trabalho duplicado desnecessariamente, e (iv) falta de viso do fluxo global da informao, isto , porque um formulrio preenchido e quem o utilizar.

Anlise de Documentos Qualitativos Documentos sem formato pr-determinado, tais como memorandos, quadros de aviso e manuais, tambm so teis para o levantamento de requisitos, uma vez que mostram como os membros de uma organizao so engajados nos processos da mesma. A anlise de documentos qualitativos deve envolver as seguintes tarefas: Examinar documentos para identificar como os elementos da organizao so referenciados e, assim, conhecer a organizao. Identificar disputas (entre departamentos ou com outras empresas) e, assim, conhecer a poltica da organizao. Identificar termos que aparecem repetidamente em documentos e caracterizem o que bom ou ruim para a organizao. Reconhecer a existncia de senso de humor nos documentos, o que pode indicar o tipo dos membros da organizao (por exemplo, conservadores, ...).

Ao analisar memorandos (inclusive os eletrnicos), d preferncia queles enviados para toda a organizao. Observe quem enviou e quem recebeu. Memorandos, tipicamente fluem horizontalmente ou de cima para baixo e provem uma idia clara de valores, crenas e atitudes dos membros da organizao. Na investigao de sinais e quadros de aviso, procure por indcios que apontem a cultura da organizao. Ex: Segurana em 1o Lugar. Finalmente, ao analisar manuais e polticas organizacionais, procure identificar como as coisas devem funcionar, como as metas estratgicas da organizao devem ser atingidas e verifique se estes passos esto sendo seguidos ou no. Tanto na anlise de dados qualitativos quanto de dados quantitativos, procure observar no s os documentos correntes, mas tambm documentos arquivados.

2.3 Entrevistas (Referncia: Captulo 5 [Kendall92])

Uma entrevista de levantamento de informaes uma conversa direcionada com um propsito especfico, que utiliza um formato pergunta-resposta. Os objetivos de uma entrevista incluem: obter as opinies do entrevistado, o que ajuda na descoberta dos problemas-chave a serem tratados; conhecer os sentimentos do entrevistado sobre o estado corrente do sistema; obter metas organizacionais e pessoais; e levantar procedimentos informais.

Entrevista x Investigao Fatos obtidos em uma investigao podem explicar o desempenho passado. Metas projetam o futuro. Entrevistas so importantes para se determinar metas.
8

O Processo de uma Entrevista Em uma entrevista, o engenheiro de software est, provavelmente, estabelecendo um relacionamento com uma pessoa estranha a ele. Assim, importante que ele: construa, rapidamente, uma base de confiana e entendimento; mantenha o controle da entrevista; venda a idia do sistema, provendo ao entrevistado as informaes necessrias.

Uma entrevista envolve as seguintes etapas principais: planejamento, conduo e elaborao de um relatrio da entrevista. 2.3.1 - Planejamento O planejamento de uma entrevista envolve os seguintes passos: 1. Estudar material existente sobre os entrevistados e suas organizaes. Procure dar ateno especial linguagem usada pelos membros da organizao, procurando estabelecer um vocabulrio comum a ser usado na elaborao das questes da entrevista. Este passo visa, sobretudo, otimizar o tempo despendido nas entrevistas, evitando-se perguntar questes bsicas e gerais. 2. Estabelecer objetivos. De maneira geral, h algumas reas sobre as quais um engenheiro de software desejar fazer perguntas relativas ao processamento de informao e ao comportamento na tomada de deciso, tais como fontes de informao, formatos da informao, freqncia na tomada de deciso, estilo da tomada de deciso, etc. 3. Decidir quem entrevistar. importante incluir na lista de entrevistados pessoas-chave de todos os nveis da organizao afetados pelo sistema. A pessoa de contato na organizao pode ajudar nesta seleo. Quando necessrio, use amostragem. 4. Preparar a entrevista. Uma entrevista deve ser marcada com antecedncia e deve ter uma durao entre 45 minutos e uma hora. 5. Decidir sobre os tipos de questes e a estrutura da entrevista. O uso de tcnicas apropriadas de questionamento o corao de uma entrevista. 6. Decidir como registrar a entrevista. Entrevistas devem ser registradas para que informaes obtidas no sejam perdidas logo em seguida. Os meios mais naturais de se registrar uma entrevista incluem anotaes e o uso de gravador. Tipos de Questes Questes podem ser de trs tipos bsicos: Questes subjetivas: permitem respostas abertas. Ex: O que voc acha de ...? Explique como voc ...? Vantagens: Provem riqueza de detalhes. Revelam novos questionamentos. Colocam o entrevistado a vontade. Permitem maior espontaneidade.
9

Desvantagens: Podem resultar em muitos detalhes irrelevantes. Perda do controle da entrevista. Respostas muito longas para se obter pouca informao til. Podem dar a impresso de que o entrevistador est perdido, sem objetivo. Questes objetivas: limitam as respostas possveis. Ex: Quantos ...? Quem ...? Quanto tempo ...? Qual das seguintes informaes ...? Vantagens: Ganho de tempo, uma vez que vo direto ao ponto em questo. Mantm o controle da entrevista. Levam a dados relevantes. Desvantagens: Podem ser maantes para o entrevistado. Podem falhar na obteno de detalhes importantes. No constrem uma afinidade entre entrevistador e entrevistado. Questes de aprofundamento: permitem explorar os detalhes de uma questo. Podem ser subjetivas ou objetivas. Ex: Por que? Voc poderia dar um exemplo? Como isto acontece?

Questes Objetivas x Subjetivas Subjetivas Confiabilidade dos dados Uso eficiente do tempo Preciso dos dados Amplitude e profundidade Habilidade requerida do entrevistador Facilidade de anlise Baixa Baixo Baixa Alta Alta Baixa Objetivas Alta Alto Alta Baixa Baixa Alta

Tabela 2.2 Quadro Comparativo Questes Objetivas x Subjetivas. Problemas na Elaborao de Questes Questes capciosas: tendem a levar o entrevistado a responder de uma forma especfica, isto , so tendenciosas. Ex: Sobre este assunto, voc est de acordo com os outros diretores, no est? Opo mais adequada: O que voc pensa sobre este assunto? Duas questes em uma: O entrevistado pode responder a apenas uma delas, ou pode se confundir em relao pergunta que est respondendo. Ex: O que voc faz nesta situao e como?
10

Estrutura da Entrevista Diz respeito organizao das questes em uma seqncia lgica. H quatro formas bsicas de se estabelecer a seqncia das questes: Estrutura de Pirmide (Abordagem Indutiva): inicia com questes bastante detalhadas, geralmente objetivas, e, medida que a entrevista progride, questes mais gerais, subjetivas, so colocadas. til para situaes onde o entrevistado parece relutante em abordar um assunto determinado ou se o engenheiro de software deseja obter uma finalizao sobre o assunto. comea com uma questo

termina com uma questo geral Estrutura de Funil (Abordagem Dedutiva): inicia com questes gerais subjetivas e, medida que a entrevista avana, perguntas mais especficas, usando questes objetivas, so feitas. Esta estrutura prov um meio fcil e no ameaador para se comear uma bateria de entrevistas. Permite levantar bastante informao detalhada, sendo desnecessrias longas seqncias de questes objetivas e de aprofundamento. comea com questes genricas e

termina com questes Estrutura de Diamante: Combinao das duas anteriores: comea com questes especficas, passa a questes gerais e fecha a entrevista novamente com questes especficas. Freqentemente, a melhor forma de se estruturar uma entrevista, j que mantm o interesse do entrevistado em uma variedade de questes. Contudo, tende a ser mais longa. inicia com questes especficas examina questes gerais fecha com questes Entrevista No Estruturada: No h uma definio da seqncia das questes. De acordo com o andar da entrevista, caminhos possveis so avaliados e a seqncia estabelecida. Requer mais tempo. Vale ressaltar que, ainda que a seqncia das questes no seja definida a priori, as questes devem ser definidas antecipadamente, ou seja, o planejamento necessrio.
11

Entrevistas Estruturadas x No Estruturadas No Estruturada Avaliao Tempo Requerido Treinamento Requerido Espontaneidade Insight do Entrevistado Flexibilidade Controle Preciso Confiabilidade Amplitude e Profundidade Difcil Alto Muito Alta Muita Oportunidade Alta Baixo Baixa Baixa a Mdia Alta Estruturada Fcil Baixo a Mdio Limitado Baixa Pouca Baixa Alto Alta Mdia a Alta Baixa a Mdia

Tabela 2.3 Comparao entre as Abordagens Estruturada e No Estruturada. Registro da Entrevista importante registrar os principais aspectos de uma entrevista durante a sua realizao. No planejamento, deve-se definir como isto ser feito. H duas formas principais, cujas vantagens e desvantagens so apresentadas a seguir: Gravador: requer a permisso do entrevistado. Vantagens: Registro completo da entrevista. Rapidez e melhor desenvolvimento. Reproduo para outros membros da equipe. Desvantagens: Pode deixar o entrevistado pouco a vontade. Pode deixar o entrevistador distrado. Pode haver necessidade de transcrever a fita. Anotaes Vantagens: Mantm o entrevistador alerta. Pode ser usado para fornecer um roteiro para a entrevista. Mostra interesse e preparao do entrevistador. Desvantagens: Perda do andamento da conversa. Excessiva ateno a fatos e pouca a sentimentos e opinies.
12

2.3.2 Conduo da Entrevista Um dia antes, entre em contato com o entrevistado para confirmar o horrio e o local da entrevista. Chegue um pouco antes do horrio marcado. Apresente-se e esboe brevemente os objetivos da entrevista. Relembre o entrevistado de que voc estar registrando pontos importantes. Se for usar gravador, coloque-o em local visvel. Diga ao entrevistado o que ser feito com as informaes coletadas e re-assegure seu aspecto confidencial. A entrevista deve durar entre 45 minutos e uma hora. Quando estiver incerto sobre uma questo, pea para o entrevistado dar definies ou outros esclarecimentos. Use questes de aprofundamento. Ao trmino da entrevista, pergunte se h algo mais sobre o assunto que o entrevistado ache importante voc saber. Faa um resumo da entrevista e d suas impresses globais. Informe o entrevistado sobre os passos seguintes. Pergunte se h outra pessoa com a qual voc deveria conversar. Quando for o caso, marque nova entrevista. 2.3.3 Relatrio da Entrevista O relatrio ou ata da entrevista deve capturar a essncia da entrevista. Escreva o relatrio to rpido quanto possvel para assegurar qualidade. Registre entrevistado, entrevistador, data, assunto e objetivos. Diga se os objetivos foram alcanados e aponte objetivos para entrevistas futuras. Registre, ainda, os pontos principais da entrevista e sua opinio.

2.4 Questionrios (Referncia: Captulo 6 [Kendall92])

O uso de questionrios constitui uma tcnica de levantamento de informaes que permite ao engenheiro de software obter de vrias pessoas afetadas pelo sistema (corrente ou proposto) informaes, tais como: Posturas: o que as pessoas na organizao dizem querer; Crenas: o que as pessoas pensam ser realmente verdade; Comportamento: o que as pessoas fazem; Caractersticas: propriedades de pessoas ou coisas.

13

Um questionrio pode ter objetivos distintos, em funo de sua aplicao, tais como: Procurar quantificar o que foi levantado em entrevistas. Determinar como um sentimento (expresso em uma entrevista) realmente difundido ou limitado. Examinar uma grande amostra de usurios do sistema para sentir problemas ou levantar questes importantes, antes de se programar entrevistas.

H muitas similaridades entre estas duas tcnicas. De fato, pode ser til utilizar as duas abordagens em conjunto: procurando refinar respostas no claras de um questionrio em uma entrevista; projetando um questionrio com base no que foi levantado em uma entrevista.

Questionrios: Quando Usar? As pessoas esto espalhadas por toda a organizao. H um grande nmero de pessoas envolvidas no projeto do sistema e necessrio saber que proporo de um dado grupo aprova ou desaprova uma particular caracterstica do sistema proposto. Em estudos exploratrios, quando se deseja saber uma opinio global antes de se definir qualquer direo especfica para o projeto.

Etapas do Processo de Uso de Questionrios Assim como as entrevistas, para se empregar questionrios, um conjunto de passos deve ser realizado, envolvendo pelo menos planejamento, aplicao e anlise. 2.4.1 Planejamento No planejamento de um questionrio, devem ser levados em considerao aspectos relacionados com a redao das questes, escalas, formato e ordem das questes. Redao das Questes Uma vez que questionrios e entrevistas seguem uma abordagem pergunta-resposta, seria bastante razovel pensar que a consideraes feitas para entrevistas aplicam-se tambm para questionrios. Contudo, importante ressaltar que h diferenas fundamentais entre estas tcnicas e, portanto, novos aspectos devem ser considerados. Em primeiro lugar, entrevistas permitem interao direta com o entrevistado a respeito das questes e seus significados. Em uma entrevista, o engenheiro de software pode refinar uma questo, definir um termo obscuro, alterar o curso do questionamento e controlar o contexto de modo geral. Isto no necessariamente verdade para um questionrio e, portanto, o planejamento de um questionrio e de suas questes deve ser mais cuidadoso. Um questionrio deve: ter questes claras e no ambguas, ter fluxo bem definido,
14

ter administrao planejada em detalhes, e levantar, antecipadamente, as dvidas das pessoas que iro respond-lo.

Questes Subjetivas Quando for utilizar questes subjetivas em um questionrio, antecipe o tipo de resposta que voc espera obter. Estas questes devem ser restritas o suficiente para guiar as pessoas, de modo que respondam de uma maneira especfica. Tome cuidado com perguntas que permitam respostas muito amplas, pois isto pode dificultar a comparao e a interpretao dos resultados. Questes subjetivas devem ser usadas em questionrios para levantar opinies sobre algum aspecto do sistema ou em situaes exploratrias. Questes Objetivas Questes objetivas devem ser utilizadas em um questionrio: quando o engenheiro de software capaz de listar as possveis respostas ou para examinar uma grande amostra de pessoas.

Respostas a questes objetivas podem ser mais facilmente quantificadas. Respostas a questes subjetivas so analisadas e interpretadas de maneira diferente. A tabela 2.4 compara o uso de questes objetivas e subjetivas em questionrios. Questes Subjetivas Tempo gasto para responder Natureza exploratria Amplitude e profundidade Facilidade de preparao Facilidade de anlise Alto Alta Alta Alta Baixa Questes Objetivas Baixo Baixa Baixa Baixa Alta

Tabela 2.4 Uso de questes subjetivas e objetivas em questionrios. Linguagem Utilizada: Diretrizes Sempre que possvel, use o vocabulrio das pessoas que iro responder. Prime pela simplicidade. Utilize perguntas simples e curtas. Evite redao tendenciosa. Garanta que as questes esto tecnicamente precisas antes de inclui-las no questionrio. Para verificar a linguagem utilizada, aplique o questionrio antecipadamente em um grupo piloto, pedindo ateno adequabilidade dos termos empregados.
15

Escalas So usadas para medir um atributo ou caracterstica. A razo para se utilizar escalas permitir medio ou julgamento. Escalas so geralmente arbitrrias e podem no ser nicas, por exemplo, temperatura: oC, oF, K. H quatro tipos bsicos de escalas: Nominal: utilizada para classificar coisas. a forma mais fraca de medio, uma vez que s obtm totais para cada classificao. Ex: Que tipo de software voc mais usa? 1- Editor de Texto 2- Planilha 3- Grfico 4- Outros Ordinria: tambm permite classificao, mas implica em um rank, isto , uma escala maior ou menor que a outra. Contudo, no se pode assumir que a distncia entre as classes a mesma. Ex: O suporte tcnico do Centro de Informao : (a) Extremamente til (b) Muito til (c) til (d) Pouco til (e) Nada til de Intervalo: intervalos entre os nmeros das opes so iguais, o que permite que sejam feitas operaes matemticas sobre os dados obtidos do questionrio e, portanto, uma anlise mais completa. Ex: O suporte tcnico do Centro de Informao : 1- Nada til 2 3 4 5- Extremamente til de Razo: idem de intervalo, s que possui um zero absoluto. Ex: Quantas horas, aproximadamente, voc despende diariamente no computador: 0 2 4 6 8

Tipos de Escala: Quando usar? de Razo: os intervalos so iguais e h um zero absoluto. de Intervalo: os intervalos so iguais, mas no h um zero absoluto. Ordinria: no possvel assumir que os intervalos so iguais, mas as classes podem ser colocadas em uma ordem. Nominal: deseja-se classificar coisas, mas estas no podem ser ordenadas.

Problemas na Construo de Escalas Lenidade: a pessoa responde a todas as questes do mesmo jeito. Soluo: mover a categoria para a esquerda ou direita. Tendncia Central: a pessoa responde tudo na mdia. Soluo: criar uma escala com mais pontos, ajustar os descritores ou tornar as diferenas menores nos extremos. Efeito Aurola: a impresso formada em uma questo levada para outra. Soluo: mesclar questes sobre objetos diferentes.

16

Projeto do Questionrio Estilo Um formulrio bem projetado (aspectos de estilo) pode aumentar taxa de respostas. As seguintes diretrizes podem ser teis na hora de se projetar um questionrio: Deixe amplos espaos em branco para atrair as pessoas. Deixe espao suficiente para as respostas das questes subjetivas. Em questes com escala, pea para fazer um crculo na resposta. Use os objetivos do questionrio para ajudar a determinar o formato (inclusive instrues). Seja consistente no estilo. Coloque instrues sempre no mesmo local em relao ao lay-out do questionrio, para facilitar a localizao das instrues. Use letras maisculas e minsculas nas perguntas e apenas letras maisculas nas respostas.

Ordem das Questes Para ordenar as questes, considere os objetivos e, ento, determine a funo de cada questo para atingir esses objetivos. Use um grupo piloto para auxiliar ou observe o questionrio com olhos de respondedor. Algumas orientaes devem ser seguidas: As primeiras questes devem ser de interesse dos respondedores. Agrupe itens de contedo similar e observe tendncias de associao. Coloque os itens de menor controvrsia primeiro.

2.4.2 Aplicao do Questionrio A primeira questo a ser definida : quem deve responder o questionrio? A deciso de quem deve responder o questionrio feita em conjunto com o estabelecimento dos seus objetivos. Quando houver muitas pessoas aptas a responder o questionrio, use amostragem. Mtodos de Aplicao Reunir todos os respondedores em um mesmo local para a aplicao do questionrio. Vantagens: 100% de retorno Instrues uniformes Resultado rpido Problemas: Pode ser difcil reunir todas as pessoas. O respondedor pode ter coisas importantes a fazer.

17

Analista entrega e recolhe cada questionrio individualmente. Vantagens: Boa taxa de resposta Problemas: Desperdcio do tempo do analista. O respondedor pode ser identificado.

Respondedor administra o questionrio. Vantagens: Anonimato garantido. Respostas mais reais. Problemas: Taxa menor de respostas. Este problema pode ser minimizado, mantendo-se uma lista de respondedores e controlando a devoluo.

Por correspondncia. geograficamente.

til

somente

para

alcanar

pessoas

distribudas

2.5 - Observao (Referncia: Captulo 7 [Kendall92])

Observar o comportamento e o ambiente do indivduo que toma decises pode ser uma forma bastante eficaz de levantar informaes que, tipicamente, passam desapercebidas usando outras tcnicas. Tomadas de deciso ocorrem em diversos nveis da organizao: operacional, gerencial e estratgico e, portanto, importante observ-las em todos os nveis que tenham interao com o sistema. Atravs da observao possvel capturar: o que realmente feito e no apenas o que documentado ou explicado. o relacionamento entre o tomador de deciso e outros membros da organizao. obter informaes sobre o tomador de deciso e seu ambiente, que no so capturadas por outras tcnicas. confirmar ou negar informaes de entrevistas e/ou questionrios.

A observao usada para:

Alguns pontos importantes devem ser realados: o analista deve saber o que observar, quem observar, quando, onde, porque e como.

18

Observao do Comportamento Permite observar como um gerente obtm, processa, compartilha e usa a informao para executar seu trabalho. No planejamento da observao do comportamento, os seguintes passos devem ser realizados: 1. Decidir o que observar (atividades). 2. Decidir em que nvel de detalhe a atividade deve ser observada. 3. Preparar material para a observao. 4. Decidir quando observar Amostragem de Horrios: perodos para observao escolhidos aleatoriamente. Evita tendncias, mas no permite a observao completa de um evento e to pouco de um evento pouco freqente. Amostragem de Eventos: observao de eventos completos.

O ideal combinar estas duas abordagens. A observao deve ser registrada. Para tal, na preparao do material para a observao, as seguintes abordagens podem ser empregadas: Pares de adjetivos: estabelea pares de adjetivos que capturem adequadamente o comportamento do indivduo durante a tomada de deciso, tais como, decidido/ indeciso, confidencial/no confidencial, etc. Categorias: defina previamente categorias de atividades e durante a observao anote sua ocorrncia ou no. Ex: O Gerente instrui subordinados questiona subordinados l informao externa processa informaes Scripts: Para cada indivduo observado, escreva uma lista de atividades por ele desempenhadas. O tomador de deciso o ator, que observado atuando, isto , tomando decises.

Observao de Ambiente Fsico O tomador de deciso influencia e influenciado pelo seu meio fsico. A observao do ambiente fsico tem uma forte analogia com a crtica de filmes. Muitas vezes, possvel observar particularidades do ambiente fsico que confirmam ou negam narrativas encontradas em entrevistas e questionrios. Uma forma sistemtica de se proceder uma observao do ambiente fsico a chamada observao estruturada do ambiente. Ela sistemtica porque prov uma abordagem padro para anlise de elementos que influenciam a tomada de deciso, permitindo que vrios engenheiros de software utilizem uma mesma base. Dentre os elementos a serem observados, destacam-se: Localizao do escritrio em relao a outros escritrios: Escritrios de fcil acesso tendem a aumentar a freqncia de interao e o fluxo de mensagens
19

informais. Grupos de escritrios encorajam o compartilhamento de informaes. Escritrios de difcil acesso tendem a aumentar a freqncia de mensagens orientadas a tarefas. Mveis e publicaes em geral: revelam necessidade de informao interna ou externa. Outros: vestimentas, equipamentos, etc.

2.6 Prototipao (Referncia: Captulo 8 [Kendall92])

A prototipao uma tcnica valiosa para se obter rapidamente informaes especficas sobre requisitos de informao do usurio. Tipicamente, a prototipao permite capturar os seguintes tipos de informao: Reaes iniciais do usurio: Como o usurio se sente em relao ao sistema em desenvolvimento? Reaes ao prottipo podem ser obtidas atravs da observao, entrevistas, questionrio ou relatrio de avaliao. Sugestes do usurio para refinar ou alterar o prottipo: guiam o engenheiro de software na direo de melhor atender as necessidades dos usurios. Inovaes: novas capacidades, no imaginadas antes da interao com o prottipo. Informaes para reviso de planos: estabelecer prioridades e redirecionar planos.

Abordagens para a Prototipao Prottipo no-operacional: apenas as interfaces de entrada e sada so implementadas; o processamento propriamente dito no. til para avaliar certos aspectos do sistema quando a codificao requerida pela aplicao custosa e a noo bsica do que o sistema pode ser transmitida pela anlise de suas entradas e sadas. Prottipo arranjado s pressas: o prottipo possui toda a funcionalidade do sistema final, mas no foi construdo com o devido cuidado e, portanto, sua qualidade e desempenho so deficientes. Prottipo primeiro de uma srie: um sistema piloto desenvolvido para ser avaliado antes de ser distribudo. til quando o sistema ser implantado em vrios locais diferentes. Prottipo de caractersticas selecionadas: apenas parte das caractersticas do sistema final so implementadas. O sistema vai sendo construdo em partes: cada prottipo aprovado passa a ser um mdulo do sistema.

Prototipao como Alternativa para o Ciclo de Vida no Desenvolvimento de Sistemas Quando um modelo de ciclo de vida clssico (seqencial linear) utilizado, dependendo do tamanho do sistema, o tempo requerido para completar o ciclo pode ser muito grande e os requisitos dos usurios podem ser alterados, fazendo com que o sistema entregue no satisfaa as necessidades dos usurios.
20

Usando a prototipao como uma alternativa para o ciclo de vida de desenvolvimento de um sistema, possvel capturar mais rapidamente se os requisitos colocados sobre o software esto em conformidade com o requerido pelos usurios. De fato, a rigor, a abordagem de prottipo de caractersticas selecionadas no deveria ser considerada prototipao, mas sim parte da estratgia de um desenvolvimento incremental ou evolutivo. Contudo, as outras trs abordagens poderiam ser utilizadas em um desenvolvimento com ciclo de vida com prototipao. Decidindo quando e que tipo de Prototipao usar Considerar: Tipo do problema a ser resolvido (domnio do problema, tipo do sistema) Soluo a ser apresentada pelo sistema (tecnologia a ser empregada domnio da soluo) Novidade (em termos de tecnologia e do domnio do problema) Complexidade (considerar clareza dos requisitos e tamanho do sistema)

Diretrizes para o Desenvolvimento de um Prottipo Trabalhe com mdulos gerenciveis: para fins de prototipao no necessrio e muitas vezes, nem desejvel, construir um sistema completo. Construa o prottipo rapidamente: a construo de um prottipo na fase de anlise e especificao de requisitos no pode consumir tempo em demasia, caso contrrio perde sua finalidade. Para acelerar a construo, use ferramentas adequadas. Modifique o prottipo em iteraes sucessivas: o prottipo deve ser alterado em direo s necessidades do usurio. Cada modificao requer uma nova avaliao. Enfatize a interface com o usurio: as interfaces do prottipo devem permitir que o usurio interaja facilmente com o sistema. Um mnimo de treinamento deve ser requerido. Sistemas interativos com interfaces grficas so muito indicados prototipao.

Usurios na Prototipao Usurios so fundamentais na prototipao. Para capturar as reaes dos usurios em relao ao prottipo, outras tcnicas de levantamento de informao devem ser usadas em conjunto. Durante a experimentao do usurio com o prottipo, utiliza-se a observao. Para capturar opinies e sugestes, podem ser empregados, alm da observao, entrevistas e questionrios.

21

Problemas da Prototipao Gerncia do projeto: Normalmente, vrias iteraes so necessrias para se refinar um prottipo. Sob esta tica, surge uma importante questo: quando parar? Se esta questo no for tratada com cuidado, a prototipao pode se estender indefinidamente. importante, pois, delinear e seguir um plano para coletar, analisar e interpretar as informaes de realimentao do usurio. Considerar o prottipo como sendo o sistema final: a qualidade pode no ter sido apropriadamente considerada.

Vantagens da Prototipao Permite alterar o sistema mais cedo no desenvolvimento, adequando-o mais de perto s necessidades do usurio (menor custo de uma alterao). Permite descartar um sistema quando este se mostrar inadequado (prottipo de viabilidade). Possibilidade de desenvolver um sistema que atenda mais de perto as necessidades e expectativas dos usurios. Permite uma interao com o usurio ao longo de todo o ciclo de vida do desenvolvimento.

Referncias do Captulo: [Kendall92] K.E. Kendall, J.E. Kendall; Systems Analysis and Design, Prentice Hall, 1992.

22

3 Modelagem de Casos de Uso

Quando um novo sistema precisa ser construdo, surge uma importante questo: Como caracterizar os requisitos do sistema de um modo adequado para a Engenharia de Software, uma vez que, necessrio identificar quais os objetos/entidades relevantes, como eles se relacionam e como se comportam no contexto do sistema. Alm disso, preciso especificar e modelar o problema de maneira que seja possvel criar um projeto efetivo. O desenvolvimento de sistemas um processo de construo de modelos, que tipicamente comea com um modelo de requisitos e termina com um modelo de implementao (cdigo). Modelos de objetos (diagramas de classes, diagramas de interao, etc...) e modelos estruturados (diagramas de entidades e relacionamentos, diagramas de fluxo de dados, etc...) incluem detalhes, tais como, a estrutura interna dos objetos/entidades, suas associaes, como eles interagem dinamicamente e como invocam o comportamento dos demais. Estas informaes so necessrias para projetar e construir um sistema, mas no so suficientes para comunicar requisitos. Elas no capturam o conhecimento sobre as tarefas do domnio e, portanto, difcil verificar se um modelo deste tipo realmente corresponde ao sistema que tem de ser construdo [Jacobson96]. Assim, o primeiro modelo do sistema a ser construdo deve ser passvel de compreenso tanto por desenvolvedores - analistas, projetistas, programadores e testadores como pela comunidade usuria - clientes e usurios. Modelos estruturados e de objetos so muito complexos e, portanto, no servem para este propsito. Este modelo inicial deve descrever o sistema, seu ambiente e como sistema e ambiente esto relacionados. Em outras palavras, ele deve descrever o sistema segundo uma perspectiva externa. Modelos de caso de uso (use cases) so uma forma de estruturar esta viso externa. Como o prprio nome sugere, um caso de uso uma maneira de usar o sistema. Usurios interagem com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casos de uso de um sistema representam tudo que os usurios podem fazer com este sistema. Casos de uso so os itens que um desenvolvedor vende a seus clientes. Deve-se notar que modelos de caso de uso so independentes do mtodo de anlise a ser usado. Desenvolvedores devem modelar os casos de uso explicitamente bem no incio do desenvolvimento de software. Em todo projeto, para que seja bem sucedido, casos de uso devem ser identificados [Jacobson96]. Em suma, o processo de desenvolvimento de software comea pelo entendimento de como o sistema ser usado. Uma vez que as maneiras de usar o sistema tenham sido definidas, a modelagem pode, ento, ser iniciada.

3.1 Casos de Uso

Nenhum sistema computacional existe isoladamente. Todo sistema interage com atores humanos ou outros sistemas, que utilizam esse sistema para algum propsito e esperam que o sistema se comporte de acordo com as maneiras previstas. Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa e uma descrio de um conjunto de seqncias de aes realizadas pelo sistema para produzir um resultado de valor observvel por um ator [Booch00].

23

Em essncia, um caso de uso (use case) uma interao tpica entre um ator (usurio humano, outro sistema computacional ou um dispositivo) e um sistema. Um caso de uso captura alguma funo visvel ao ator e, em especial, busca atingir uma meta do usurio [Fowler97]. Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreenso comum com os usurios finais do sistema e com os especialistas do domnio. Alm disso, servem para ajudar a validar e verificar o sistema medida que ele evolui durante seu desenvolvimento. Assim, os casos de uso no apenas representam o comportamento desejado do sistema, mas tambm podem ser utilizados como a base de casos de teste para o sistema, principalmente os testes de integrao e de sistema [Booch00]. Casos de uso tm dois importantes papis: 1. Eles capturam os requisitos funcionais de um sistema. Um modelo de caso de uso define o comportamento de um sistema (e a informao associada) atravs de um conjunto de casos de uso. O ambiente do sistema definido pela descrio dos diferentes usurios. Estes usurios utilizam o sistema atravs de um nmero de casos de uso. 2. Eles oferecem uma abordagem para a modelagem de sistemas. Para gerenciar a complexidade de sistemas reais, comum apresentar os modelos do sistema em um nmero de diferentes vises. Em uma abordagem guiada por casos de uso, pode-se construir uma viso para cada caso de uso, isto , em cada viso so modelados apenas aqueles elementos que participam de um caso de uso especfico. Um particular elemento pode, claro, participar de vrios casos de uso. Isto significa que um modelo do sistema completo s visto atravs de um conjunto de vises - uma por caso de uso. Encontra-se todas as responsabilidades de um elemento de modelo, olhando todos os casos de uso onde este tem um papel. Alm de serem uma ferramenta essencial na captura dos requisitos de um sistema, casos de uso tm um papel fundamental no planejamento e controle de projetos iterativos. A captura dos casos de uso a primeira atividade a ser realizada no desenvolvimento, propriamente dito. A maioria dos casos de uso normalmente gerada durante a fase de levantamento de requisitos, mas outros casos de uso podem ser descobertos medida que o trabalho prossegue. Todo caso de uso um requisito potencial e, enquanto um requisito no capturado, no possvel planejar como trat-lo. Usualmente, em primeiro lugar, casos de uso so listados e discutidos, para s ento, se realizar alguma modelagem. Entretanto, em alguns casos, a modelagem conceitual ajuda a descobrir casos de uso. Um caso de uso pode ser capturado atravs de conversas com usurios tpicos, discutindo as vrias coisas que eles querem fazer com o sistema. Cada uma dessas interaes discretas constitui um caso de uso. D a ela um nome e escreva uma descrio textual pequena (no mais do que uns poucos pargrafos). No tente capturar todos os detalhes de um caso de uso logo no incio. Os objetivos do usurio podem ser o ponto de partida para a elaborao dos casos de uso. Proponha um caso de uso para satisfazer cada um dos objetivos do usurio. A partir deles, estude as possveis interaes do usurio com o sistema e refine o modelo de casos de uso.
24

3.2 - Diagramas de Casos de Uso

Diagramas de casos de uso especificam as funcionalidades que um sistema tem de oferecer, segundo diferentes perspectivas dos usurios. Basicamente, um diagrama de casos de uso apresenta dois elementos: os atores e os casos de uso. Um ator um papel que um usurio, outro sistema ou dispositivo desempenha com respeito ao sistema. Casos de uso representam funcionalidades requeridas externamente. Uma associao entre um ator e um caso de uso significa que estmulos podem ser enviados entre atores e casos de uso. Os atores podero estar conectados aos casos de uso somente por meio de associaes. A associao entre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si, cada um com a possibilidade de enviar e receber mensagens [Booch00]. A figura 3.1 mostra a notao bsica da Linguagem de Modelagem Unificada UML [Booch00] para diagramas de casos de uso.

Caso de Uso 1 Ator 1 Caso de Uso 3 Caso de Uso 2 Ator 2

Ator

Caso de

Uso

Figura 3.1 - Notao Bsica da UML para Modelos de Caso de Uso. Um ator modela qualquer coisa que precise interagir com o sistema, tais como usurios e outros sistemas que se comunicam com o sistema em questo. Atores so externos ao sistema; os casos de uso comportam os elementos de modelo que residem dentro do sistema. Assim, ao se definir fronteiras entre atores e casos de uso, est-se delimitando o escopo do sistema. Por estarem fora do sistema, atores esto fora do controle de nossas ferramentas de modelagem e no precisam ser descritos em detalhes. Atores representam tudo que tem necessidade de trocar informao com o sistema. Nada mais externo ao sistema deve ter impacto sobre o sistema. importante realar a diferena entre ator e usurio. Um usurio uma pessoa que utiliza o sistema, enquanto um ator representa um papel especfico que um usurio pode desempenhar. Vrios usurios em uma organizao podem interagir com o sistema da mesma forma e, portanto, desempenham o mesmo papel. Um ator representa exatamente um certo papel que diversos usurios podem desempenhar. Assim, atores podem ser pensados como classes, isto , descries de um comportamento, enquanto usurios podem desempenhar diversos papis e, assim, servir como instncias de diferentes classes de atores. Ao lidar com atores, importante pensar em termos de papis ao invs de usurios. Um bom ponto de partida para a identificao de atores verificar por que o sistema deve ser desenvolvido, procurando observar que atores o sistema se prope a ajudar.
25

Quando um ator interage com o sistema, normalmente, ele realiza uma seqncia comportamentalmente relacionada de aes em um dilogo com o sistema. Tal seqncia compreende um caso de uso. Um caso de uso , de fato, uma maneira especfica de utilizar o sistema, atravs da execuo de alguma parte de sua funcionalidade. Cada caso de uso constitui um curso completo de eventos com um ator e especifica a interao que acontece entre o ator e o sistema. O conjunto de todas as descries de casos de uso especifica todas as maneiras de se usar o sistema e, conseqentemente, a sua funcionalidade completa. Um bom caso de uso compreende uma seqncia de transaes realizadas pelo sistema, que produz um resultado de valor observvel para um particular ator. Por produzir um resultado de valor observvel, queremos dizer que um caso de uso tem de garantir que um ator realiza uma tarefa que tem um valor identificvel. Isso importante para se obter casos de uso que no sejam muito pequenos. Por outro lado, a identificao de um particular ator importante na obteno de casos de uso que no sejam muito grandes. Uma boa fonte para identificar casos de uso so os eventos externos. Pense sobre todos os eventos do mundo externo para os quais o sistema deve reagir. Identificar estes eventos pode ajud-lo a identificar os casos de uso. Para sistemas grandes, pode ser difcil propor uma lista de casos de uso. Nestas situaes, mais fcil chegar primeiro a uma lista de atores e tentar elaborar os casos de uso para cada ator. Para cada curso completo de eventos com um ator, um caso de uso identificado. Nem sempre est claro qual funcionalidade deve ser colocada em casos de uso separados ou o que apenas uma variante de um caso de uso. A priori, se as diferenas forem pequenas, elas podem ser descritas como variantes do caso de uso; caso contrrio, devem ser descritas como casos de uso separados. Qualquer que seja a abordagem utilizada, devemos sempre identificar os atores de um caso de uso, descobrir qual o objetivo real do usurio e considerar modos alternativos de satisfazer estes objetivos.

3.3 - Descrio de Casos de Uso

Um caso de uso deve descrever o que um sistema faz. Geralmente, um diagrama de casos de uso insuficiente para este propsito. Assim, deve-se especificar o comportamento de um caso de uso pela descrio textual de seu fluxo de eventos, de modo que algum de fora possa compreend-lo. Ao escrever o fluxo de eventos, deve-se incluir como e quando o caso de uso inicia e termina, quando o caso de uso interage com os atores e outros casos de uso e quais so as informaes transferidas e o fluxo bsico e fluxos alternativos do comportamento [Booch00]. Uma vez que o conjunto inicial de casos de uso estiver estabilizado, cada um deles deve ser descrito em mais detalhes. Primeiro, deve-se descrever o fluxo de eventos principal (ou curso bsico), isto , o curso de eventos mais importante, que normalmente ocorre. Variantes do curso bsico de eventos e erros que possam vir a ocorrer devem ser descritos em cursos alternativos. Normalmente, um caso de uso possui apenas um nico curso bsico, mas diversos cursos alternativos. Tomemos como exemplo, um caixa automtico de banco, cujo diagrama de casos de uso mostrado na figura 3.2.

26

Efetuar Saque

Cliente

Emitir Extrato

Sistema Bancrio

Informar Saldo

Figura 3.2 - Exemplo de um modelo de caso de uso. O caso de uso Efetuar Saque poderia ser descrito da seguinte maneira: Fluxo de Eventos Principal Uma mensagem de saudao est sendo mostrada na tela. O cliente insere seu carto no caixa automtico, que l o cdigo da tarja magntica e checa se ele aceitvel. Se o carto aceitvel, o caixa pede ao cliente para informar a senha e fica aguardando at que ela seja informada. O cliente informa a senha. Se a senha estiver correta, o caixa solicita que o cliente informe o tipo de transao e fica aguardando. O cliente seleciona a opo saque. O caixa mostra uma tela para que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. Se o saque autorizado, as notas so preparadas para serem entregues, o carto ejetado, um recibo emitido e as notas liberadas. Cursos Alternativos O carto no aceitvel: Se o carto no aceitvel porque sua tarja magntica no passvel de leitura ou de um tipo incompatvel, o carto ejetado com um bip. Senha incorreta: Se a senha informada est incorreta, uma mensagem deve ser mostrada para o cliente que poder entrar com a senha correta. Caso o cliente informe trs vezes senha incorreta, o carto dever ser confiscado. Saque no autorizado: Se o saque no for aceito pelo Sistema Bancrio, uma mensagem informando o cliente mostrada por 10 segundos e o carto ejetado. Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento que lhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trmino da transao. Como visto pelo exemplo anterior, um caso de uso pode ter um nmero de cursos alternativos que podem levar o caso de uso por diferentes fluxos. Tanto quanto possvel, esses cursos alternativos, freqentemente cursos de exceo, devem ser anotados durante a especificao de um caso do uso.
27

3.4 - Associaes entre Casos de Uso

Uma vez que um modelo de caso de uso expressa apenas a viso externa do sistema, comunicaes internas entre elementos dentro do sistema no devem ser modeladas. Contudo, para permitir uma descrio mais apurada dos casos de uso em um diagrama, trs tipos de relacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser descritos como verses especializadas de outros casos de uso (relacionamento de generalizao/ especializao); casos de uso podem ser includos como parte de outro caso de uso (relacionamento de incluso); ou casos de uso podem estender o comportamento de um outro caso de uso bsico (relacionamento de extenso). O objetivo desses relacionamentos tornar um modelo mais compreensvel, evitar redundncias entre casos de uso e permitir descrever casos de uso em camadas. O relacionamento de incluso entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso. O local em que esse comportamento includo deve ser indicado na descrio do caso de uso base, atravs de uma referncia explcita chamada ao caso de uso includo. Um relacionamento de incluso empregado quando h uma poro de comportamento que similar ao longo de um ou mais casos de uso e no se deseja repetir a sua descrio. Para evitar redundncia e assegurar reuso, extrai-se essa descrio e compartilha-se a mesma entre diferentes casos de uso. Um relacionamento de incluso representado por uma dependncia, estereotipada como inclui (include), como mostra a figura 3.3. No exemplo do caixa automtico, podemos perceber que todos os trs casos de uso tm em comum uma poro que diz respeito transao inicial do carto. Neste caso, um relacionamento inclui deve ser empregado, como mostra a figura 3.3.

Validar Cliente <<inclui>> <<inclui>> <<inclui>>

Efetuar Saque

Emitir Extrato

Informar Saldo

Figura 3.3 O relacionamento inclui para descrever compartilhamento entre casos de uso. O caso de uso Validar poderia ser descrito da seguinte forma: Curso Normal Uma mensagem de saudao est sendo mostrada na tela. O cliente insere seu carto no caixa automtico, que l o cdigo da tarja magntica e checa se ele aceitvel.

28

Se o carto aceitvel, o caixa pede ao cliente para informar a senha e fica aguardando at que ela seja informada. O cliente informa a senha. Se a senha estiver correta, o caixa solicita que o cliente informe o tipo de transao e fica aguardando. Cursos Alternativos O carto no aceitvel: Se o carto no aceitvel porque sua tarja magntica no passvel de leitura ou de um tipo incompatvel, o carto ejetado com um bip. Senha incorreta: Se a senha informada est incorreta, uma mensagem deve ser mostrada para o cliente que poder entrar com a senha correta. Caso o cliente informe trs vezes uma senha incorreta, o carto dever ser confiscado. Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento que lhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trmino da transao. Com esta captura isolada do caso de uso de Validar Cliente, o caso de uso Efetuar Saque passaria a apresentar a seguinte descrio: Curso Normal O cliente realiza o caso de uso Validar Cliente. O cliente seleciona a opo saque. O caixa mostra uma tela para que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. Se o saque autorizado, as notas so preparadas para serem entregues, o carto ejetado, um recibo emitido e as notas liberadas. Cursos Alternativos Saque no autorizado: Se o saque no for aceito pelo Sistema Bancrio, uma mensagem informando o cliente mostrada por 10 segundos e o carto ejetado. Cancelamento: O cliente pode sempre cancelar a transao em qualquer momento que lhe seja perguntada alguma informao. Isto resultar na ejeo do carto e no trmino da transao. O relacionamento de generalizao entre casos de uso significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai. O caso de uso filho dever acrescentar ou sobrescrever o comportamento de seu pai e poder ser substitudo em qualquer local no qual o pai aparea [Booch00]. Voltando ao exemplo do sistema de caixa automtico, suponha que haja duas formas adotadas para se validar o cliente: a primeira atravs de senha, como descrito anteriormente, e a segunda por meio de anlise da retina do cliente. Neste caso, poderiam ser criadas duas especializaes do caso de uso Validar Cliente, como mostra a figura 3.4.

29

Validar Cliente

Verificar Senha

Analisar Retina

Figura 3.4 O relacionamento de generalizao/especializao entre casos de uso. Um relacionamento de extenso entre casos de uso significa que o caso de uso base incorpora implicitamente o comportamento de um outro caso de uso em um local especificado em sua descrio como sendo um ponto de extenso. O caso de uso base poder permanecer isolado, mas, sob certas circunstncias, seu comportamento poder ser estendido pelo comportamento de um outro caso de uso [Booch00]. Um relacionamento de extenso utilizado para modelar uma parte de um caso de uso que o usurio considera como opcional. Desse modo, separa-se o comportamento opcional do comportamento obrigatrio. Um relacionamento de extenso tambm poder ser empregado para modelar um subfluxo separado, que executado somente sob determinadas condies. Assim como o relacionamento de incluso, o relacionamento de extenso representado como uma associao de dependncia, agora estereotipada como estende (extend). O relacionamento estende nos permite capturar os requisitos funcionais de um sistema complexo de forma incremental. Inicialmente, as funes bsicas so entendidas, para s ento a complexidade ser introduzida. Na modelagem de casos de uso, devemos primeiro descrever os casos de uso bsicos, para s ento estend-los para permitir descrever casos de uso mais avanados. O caso de uso no qual a nova funcionalidade adicionada deve ter um curso de eventos completo e significativo por si prprio. Assim, sua descrio deve ser completamente independente. Suponha que, no exemplo do caixa automtico, deseja-se coletar dados estatsticos sobre o uso da transao de saque para alimentar o caixa eletrnico com as notas mais adequadas para saque. Para tal, poderamos estender o caso de uso Efetuar Saque, de modo que, quando necessrio, um outro caso de uso, denominado Coletar Informaes Estatsticas de Saque, contasse e acumulasse o tipo das notas entregues em um saque. A figura 3.5 ilustra este caso.

30

Efetuar Saque <<estende>>

Coletar Informaes Estatsticas de Saque

Figura 3.5 O relacionamento estende entre casos de uso. O relacionamento estende usado, ento, para modelar extenses a outros casos de uso completos e utilizado para modelar: partes opcionais de casos de uso, cursos complexos e alternativos, subseqncias que so executadas apenas em certos casos ou a insero de diversos casos de uso diferentes dentro de um outro A quebra de um caso de uso em vrios pode ocorrer tanto na fase de levantamento de requisitos, quanto na fase de anlise e projeto. Na fase de levantamento de requisitos, interessante desmembrar aqueles casos de uso que se apresentam muito complicados. Entretanto, h casos de uso cuja complexidade global no deve ser detalhada antes da fase de projeto. Para utilizar os relacionamentos de incluso e extenso, aplique as seguintes regras: Utilize o relacionamento estende quando estiver descrevendo uma variao de um curso normal; Utilize o relacionamento inclui quando houver repetio em dois ou mais casos de uso separados e for desejvel evitar esta repetio. Durante a anlise e descrio detalhada dos casos de uso, o sistema cuidadosamente estudado. Uma vez que, geralmente, os casos de uso enfocam uma particular funcionalidade, possvel analisar a funcionalidade total do sistema de maneira incremental. Deste modo, casos de uso para reas funcionalmente diferentes podem ser desenvolvidos independentemente e, mais tarde, reunidos para formar um modelo de requisitos completo. Com isso, permite-se enfocar um problema de cada vez, abrindo caminho para um desenvolvimento incremental. medida que os modelos crescem, importante dividi-los para facilitar a leitura e o entendimento. Dividir um sistema complexo em subsistemas sempre uma boa opo. Para dividir e reunir casos de uso em grupos relacionados conceitual e semanticamente, a UML oferece como ferramenta de modelagem os pacotes. A figura 3.6 mostra um exemplo no contexto de um sistema bancrio. Neste exemplo, o sistema bancrio no est mais sendo considerado um outro sistema, mas um subsistema do mesmo sistema do caixa automtico. A associao de dependncia entre os pacotes mostrada nessa figura indica que o pacote Caixa Automtico solicita servios do pacote Contas.
31

Caixa Automtico

Contas

Figura 3.5 Casos de Uso Agrupados em Pacotes. Uma vez que a funcionalidade do sistema tiver sido capturada nos casos de uso, ela deve ser alocada a diferentes elementos de modelagem. Um elemento de modelagem, obviamente, pode ser comum a diversos casos de uso. Basicamente, o mapeamento de um caso de uso em elementos de modelo pode ser apoiado pelos seguintes princpios: As funcionalidades dos casos de uso que lidam com o registro e a manipulao de informao so mapeadas diretamente para elementos em um modelo de anlise. As funcionalidades diretamente dependentes do ambiente do sistema representam funcionalidades requeridas pela interface do sistema e, portanto, so tratadas na fase de projeto, especificamente no projeto da interface do sistema. Finalmente, funcionalidades que tipicamente envolvem o controle de uma aplicao devem ser mapeadas em elementos no projeto do controle do sistema.

Referncias do Captulo: [Booch00] [Fowler97] [Furlan98] G. Booch, J. Rumbaugh, I. Jacobson; UML Guia do Usurio. Editora Campus, 2000. M. Fowler, K. Scott; UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley Object Technology Series, 1997. J.D. Furlan; Modelagem de Objetos Atravs da UML; Makron Books, 1998.

[Jacobson96] I. Jacobson; The Use Case Construct in Object-Oriented Software Engineering, In: Scenario-Based Design, 1996.

32

PARTE II ANLISE ORIENTADA A OBJETOS

33

4. Introduo Orientao a Objetos

A construo de uma soluo computadorizada consiste no mapeamento do problema a ser resolvido no mundo real num modelo de soluo no Espao de Solues, isto , o meio computacional. A modelagem envolve, ento, a identificao de objetos e operaes relevantes no mundo real e o mapeamento desses em representaes abstratas no Espao de Solues. distncia existente entre o problema no mundo real e o modelo abstrato construdo, convencionou-se chamar gap semntico e, obviamente, quanto menor ele for, mais direto ser o mapeamento e, portanto, mais rapidamente sero construdas solues para o problema. Sob essa tica, fcil perceber que o gap semntico representa a rea de atuao da Engenharia de Software. Diversas tcnicas e mtodos tm sido propostos para as diferentes fases do processo de desenvolvimento, buscando minimiz-lo. A Orientao a Objetos um dos paradigmas existentes para apoiar o desenvolvimento de sistemas, que busca fornecer meios para se diminuir o gap semntico. Este captulo visa introduzir os principais conceitos e benefcios da orientao a objetos.

4.1 Abordagem Estruturada x Abordagem Orientada a Objetos

Uma vez que, atualmente, a Orientao a Objetos tem tomado o espao antes ocupado pelo paradigma estruturado no desenvolvimento de sistemas, interessante fazer uma comparao entre os paradigmas que fundamentam estas abordagens: Estruturado: adota uma viso de desenvolvimento baseada em um modelo entradaprocessamento-sada. No paradigma estruturado, os dados so considerados separadamente das funes que os transformam e a decomposio funcional usada intensamente. Orientado a Objetos: pressupe que o mundo composto por objetos, onde um objeto uma entidade que combina estrutura de dados e comportamento funcional. No paradigma orientado a objetos, os sisitemas so estruturados a partir dos objetos que existem no domnio do problema, isto , os sistemas so modelados como um nmero de objetos que interagem. Em funo do paradigma que os rege, mtodos de anlise e projeto de sistemas so classificados em mtodos estruturados e mtodos orientados a objetos. Mtodos Estruturados Fazem clara distino entre funes e dados. Funes, a princpio, so ativas e tm comportamento, enquanto dados so repositrios passivos de informao, afetados por funes. Esta diviso tem origem na arquitetura de hardware de von Neumann, onde a separao entre programa e dados fortemente enfatizada. Os mtodos orientados a funes conduzem o desenvolvimento de software estruturando as aplicaes segundo a tica das funes (aes) que o sistema dever realizar. O sistema decomposto em funes, e os dados so transportados entre elas. Esta a filosofia da proposta original da Anlise Estruturada [DeMarco78] [Gane79], cuja ferramenta bsica de modelagem so os diagramas de fluxo de dados (DFDs).
34

Os mtodos orientados a dados, por sua vez, enfatizam a identificao e estruturao dos dados, subjulgando a anlise das funes para um segundo plano. Esses mtodos tm origem no projeto de bancos de dados e, geralmente, tm no modelo de Entidades e Relacionamentos (ER) [Chen79] sua principal ferramenta. A nfase nas funes, geralmente, leva a sistemas com muita redundncia e, conseqentemente, inconsistentes e difceis de serem integrados. Por outro lado, a nfase nos dados est fundamentada em dois fatores significativos: Dados possuem existncia prpria nas organizaes independentemente dos processos que os manipulam. Dados so muito mais estveis que as funes em uma organizao. A menos que haja grandes mudanas nos negcios de uma empresa, os dados tendem a se manter estveis. Assim, possvel desenvolver modelos de dados sem redundncia, sem inconsistncia e fceis de integrar. Entretanto, uma vez que o modelo de dados deve representar a realidade, e o conhecimento da realidade, muitas vezes, passa pelo conhecimento das funes, ele deve ser construdo de forma iterativa, no podendo ser considerado um produto acabado. A Anlise Essencial [Pompilho95] procurou conciliar as abordagens orientadas a dados e a funes em um nico mtodo, utilizando modelos para dados, funes e controles (DFDs e Modelo ER e Diagramas de Transio de Estados, respectivamente) como ferramentas para a modelagem de sistemas. Um sistema desenvolvido usando um mtodo estruturado, freqentemente, difcil de ser mantido. A princpio, o problema principal advm do fato de todas as funes terem de conhecer como os dados esto armazenados, isto , a estrutura dos dados. Alm disso, mudanas na estrutura dos dados quase sempre acarretam modificaes em todas as funes relacionadas a essa estrutura. Em suma, a interpretao dos dados apenas implcita, provida pelos programas que lem ou escrevem dados. Diferentes programas podem dar diferentes interpretaes aos dados e, portanto, necessrio conhecer como eles foram projetados para poder interpret-los corretamente [Snyder93]. Mtodos Orientados a Objetos Os mtodos orientados a objetos partem de um ponto de vista distinto e intermedirio, onde se pressupe que o mundo real povoado por objetos, onde um objeto uma entidade que combina estrutura de dados e comportamento funcional. Mtodos orientados a objetos estruturam os sistemas a partir dos objetos que existem no domnio do problema. A orientao a objetos oferece um nmero de conceitos bastante apropriados para a modelagem de sistemas. Utilizando a orientao a objetos como base, os sistemas so modelados como um nmero de objetos que interagem. Os modelos baseados em objetos so teis para a compreenso de problemas, para a comunicao com os especialistas e usurios das aplicaes, e para a realizao das tarefas ao longo do ciclo de desenvolvimento de software. Os principais objetivos da orientao a objetos so: diminuir a distncia conceitual entre o mundo real (domnio do problema) e o modelo abstrato de soluo (domnio da soluo); trabalhar com noes intuitivas (objetos e aes) durante todo o ciclo de vida, atrasando, ao mximo, a introduo de conceitos de implementao.
35

Normalmente, esta uma maneira mais natural para descrever sistemas, j que os objetos so geralmente bastante estveis. Alteraes que por ventura venham a ocorrer, geralmente, afetam um ou alguns poucos objetos [Jacobson92]. Eduard Yourdon [Yourdon94] d uma bom resumo do que pode ser considerado um produto orientado a objeto: Um sistema construdo usando um mtodo orientado a objetos aquele cujos componentes so partes encapsuladas de dados e funes, que podem herdar atributos e comportamento de outros componentes da mesma natureza, e cujos componentes comunicam-se entre si por meio de mensagens. Mtodos orientados a objetos utilizam uma perspectiva mais humana de observao da realidade, incluindo objetos, classificao e compreenso hierrquica. So benefcios esperados com o uso da orientao a objetos: Capacidade de enfrentar novos domnios de aplicao; Melhoria da interao entre analistas e especialistas; Aumento da consistncia interna dos resultados da anlise; Uso de uma representao bsica consistente para a anlise e projeto; Alterabilidade, legibilidade e extensibilidade; Possibilidade de ciclos de desenvolvimento variados; Apoio reutilizao. importante enfatizar, no entanto, que a orientao a objetos no mgica, isto , ela no uma nova tbua de salvao para eliminar os problemas de produtividade e qualidade que tm atormentado a indstria de software ao longo das ltimas dcadas. Se praticada cuidadosamente, combinada com vrias outras tcnicas de Engenharia de Software - tais como, uso de mtricas, reutilizao, testes, e garantia da qualidade - a orientao a objetos pode ajudar a levar a melhorias substanciais no desempenho de uma organizao de software [Yourdon94]. Portanto, imprescindvel, para grandes projetos, a definio de um processo de desenvolvimento que garanta o uso consistente dessas tcnicas e que seja apoiado por ferramentas computacionais, tais como ferramentas CASE e Ambientes de Desenvolvimento de Software.

4.2 Conceitos da Orientao a Objetos

4.2.1 - Princpios para Administrar Complexidade
O mundo real algo extremamente complexo. Quanto mais de perto o observamos, mais claramente percebemos sua complexidade. A orientao a objetos tenta gerenciar a complexidade inerente dos problemas do mundo real, abstraindo conhecimento relevante e encapsulando-o dentro de objetos. De fato, alguns princpios bsicos gerais para a administrao da complexidade norteiam este processo de modelagem, entre eles, abstrao, encapsulamento, modularidade e hierarquia. Abstrao Uma das principais formas do ser humano lidar com a complexidade atravs do uso de abstraes. As pessoas tipicamente tentam compreender o mundo, construindo modelos mentais de partes dele. Tais modelos so uma viso simplificada de algo, onde apenas
36

elementos relevantes so considerados. Modelos mentais, portanto, so mais simples do que os complexos sistemas que eles modelam. Consideremos, por exemplo, um mapa como um modelo do territrio que ele representa. Um mapa til porque abstrai apenas aquelas caractersticas do territrio que se deseja modelar. Se um mapa inclusse todos os detalhes do territrio, provavelmente teria o mesmo tamanho do territrio e, portanto, no serviria a seu propsito. Da mesma forma que um mapa precisa ser significativamente menor que o territrio que mapeia, incluindo apenas informaes cuidadosamente selecionadas, um modelo mental abstrai apenas as caractersticas relevantes de um sistema para seu entendimento. Assim, podemos definir abstrao como sendo o princpio de ignorar aspectos no relevantes de um assunto, segundo a perspectiva de um observador, tornando possvel uma concentrao maior nos aspectos principais do mesmo. De fato, a abstrao consiste na seleo que um observador faz de alguns aspectos de um assunto, em detrimento de outros que no demonstram ser relevantes para o propsito em questo. No que tange o desenvolvimento de software, duas formas adicionais de abstrao tm grande importncia: a abstrao de dados e a abstrao de procedimentos.

Figura 4.1 - A abstrao enfoca as caractersticas essenciais de um objeto [Booch94]. Abstrao de Dados Consiste em definir um tipo de dado conforme as operaes aplicveis aos objetos deste tipo. Os objetos s podem ser modificados e observados atravs dessas operaes [Coad92]. Exemplo: Um tipo de dado pilha pode ser definido atravs das operaes empilhar, isto , colocar um elemento no topo da pilha, e desempilhar, ou seja, retirar o elemento que est no topo da pilha. Um objeto do tipo pilha s pode ser modificado e observado atravs dessas duas operaes.

37

Abstrao de Procedimentos Segundo esse princpio, uma operao com um efeito bem definido pode ser tratada por seus usurios como uma entidade nica, mesmo que a operao seja realmente conseguida atravs de alguma seqncia de operaes de nvel mais baixo. Exemplo: Seja a operao calcular-salrio-lquido de um objeto do tipo funcionrio. Essa operao pode ser tratada por seus usurios como uma entidade nica, mesmo que ela seja, na realidade, construda como uma seqncia de operaes de nvel mais baixo, tais como: calcular-INSS, calcular-IR, calcular-anunio, etc. Encapsulamento No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamento interno. Uma pessoa, por exemplo, geralmente utiliza uma televiso sem saber efetivamente qual a sua estrutura interna ou como seus mecanismos internos so ativados. Para utiliz-la, basta saber realizar algumas operaes bsicas, tais como ligar/desligar a TV, mudar de um canal para outro, regular volume, cor, etc. Como estas operaes produzem seus resultados, mostrando um programa na tela, no interessa ao telespectador. O encapsulamento consiste na separao dos aspectos externos de um objeto, acessveis por outros objetos, de seus detalhes internos de implementao, que ficam ocultos dos demais objetos [Rumbaugh94]. A interface de comunicao de um objeto deve ser definida de forma a revelar o menos possvel sobre o seu funcionamento interno.

Figura 4.2 - O encapsulamento oculta os detalhes de implementao de um objeto [Booch94]. Abstrao e encapsulamento so conceitos complementares: enquanto a abstrao enfoca o comportamento observvel de um objeto, o encapsulamento enfoca a implementao que origina esse comportamento. Encapsulamento freqentemente conseguido atravs do ocultamento de informao, isto , escondendo detalhes que no contribuem para suas caractersticas essenciais. Tipicamente, em um sistema orientado a objetos, a estrutura de um objeto, e a implementao de seus mtodos, so encapsuladas [Booch94]. Por exemplo, para usar um carro, uma pessoa no precisa conhecer sua estrutura interna (motor, caixa de marcha, etc...), nem to pouco como se d a implementao de seus mtodos. Sabe-se que necessrio ligar o carro, mas no preciso saber como esta operao implementada. Assim, sobre carros, um motorista precisa conhecer apenas as operaes que
38

permite utiliz-lo, a que chamamos de interface do objeto, o que inclui a ativao de operaes, tais como ligar, mudar as marchas, acelerar, frear, etc..., e no como essas operaes so de fato implementadas. Encapsulamento serve para separar a interface contratual de uma abstrao e sua implementao. Os usurios tm conhecimento apenas das operaes que podem ser requistadas e precisam estar cientes apenas do que as operaes realizam e no como elas esto implementadas. A principal motivao para o encapsulamento facilitar a reutilizao de objetos e garantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base para a localizao de decises de projeto que necessitam ser alteradas. Uma operao pode ter sido implementada de maneira ineficiente e, portanto, pode ser necessrio escolher um novo algoritmo. Se a operao est encapsulada, apenas o objeto que a define precisa ser modificado, garantindo estabilidade ao sistema. Modularidade Muitos mtodos de construo de software buscam obter sistemas modulares, isto , construdos a partir de elementos que sejam autnomos, conectados por uma estrutura simples e coerente. Modularidade crucial para se obter reusabilidade e extensibilidade. Modularidade uma propriedade de sistemas decompostos em um conjunto de mdulos coesos e fracamente acoplados. Assim, abstrao, encapsulamento e modularidade so princpios sinergticos1. Um objeto prov uma fronteira clara em torno de uma abstrao e o encapsulamento e a modularidade provem barreiras em torno dessa abstrao [Booch94]. Hierarquia Abstrao um princpio importantssimo, mas em todas as aplicaes, exceto aquelas mais triviais, deparamo-nos com um nmero de abstraes maior do que conseguimos compreender em um dado momento. O encapsulamento ajuda a gerenciar esta complexidade atravs do ocultamento da viso interna de nossas abstraes. Modularidade auxilia tambm, dando-nos um meio de agrupar logicamente abstraes relacionadas. Entretanto, isto ainda no o bastante. Um conjunto de abstraes freqentemente forma uma hierarquia e, pela identificao dessas hierarquias, possvel simplificar significativamente o entendimento sobre um problema [Booch94]. Em suma, hierarquia uma forma de arrumar as abstraes.

4.2.2 - Conceitos Bsicos

Objetos O mundo real povoado por elementos que interagem entre si, onde cada um deles desempenha um papel especfico. A esses elementos, chamamos objetos. Objetos podem ser coisas concretas ou abstratas, tais como um carro, uma reserva de passagem area, uma organizao, uma planta de engenharia, um componente de uma planta de engenharia, etc... Do ponto de vista da modelagem de sistemas, um objeto uma entidade que incorpora uma abstrao relevante no contexto de uma aplicao. Um objeto possui um estado
1

Sinergia: esforo simultneo de vrios elementos para a realizao de uma ao. 39

(informao), exibe um comportamento bem definido, expresso por um nmero de operaes para examinar ou alterar seu estado, e tem identidade nica.

Figura 4.3 - Um objeto possui estado, exibe algum comportamento bem definido e possui identidade prpria [Booch94]. Estado O estado de um objeto compreende o conjunto de suas propriedades, associadas a seus valores correntes. Propriedades de objetos so geralmente referenciadas como atributos e, portanto, o estado de um objeto diz respeito aos seus atributos e aos valores a eles associados. Comportamento A abstrao incorporada por um objeto caracterizada por um conjunto de servios ou operaes, que outros objetos, ditos clientes, podem requisitar. Operaes so usadas para recuperar ou manipular a informao de estado de um objeto e referem-se apenas s estruturas de dados do prprio objeto, no devendo acessar diretamente estruturas de outros objetos. A comunicao entre objetos d-se por meio de troca de mensagens. Para acessar a informao de estado de um objeto, necessrio enviar uma mensagem para ele. Uma mensagem consiste do nome de uma operao e os argumentos requeridos. Assim, o comportamento de um objeto representa como este objeto reage s mensagens a ele enviadas. Em outras palavras, o conjunto de mensagens a que um objeto pode responder representa o seu comportamento. Um objeto , pois, uma entidade que tem seu estado representado por um conjunto de atributos (uma estrutura de informao) e seu comportamento representado por um conjunto de operaes. Identidade Cada objeto tem uma identidade prpria, que lhe inerente. Todos os objetos tm existncia prpria, ou seja, dois objetos so distintos mesmo se seu estado e comportamento forem iguais. A identidade de um objeto transcende os valores correntes de suas variveis de estado (atributos). Identificar um objeto diretamente geralmente mais eficiente que designlo pela sua descrio [Snyder93]. No mundo real, um objeto limita-se a existir, mas, no que se refere ao mundo computacional, cada objeto dispe de um identificador nico pelo qual pode ser referenciado inequivocamente [Rumbaugh94].
40

Classes e Instncias bastante comum encontrarmos no mundo real, diferentes objetos desempenhando um mesmo papel. Consideremos, por exemplo, duas cadeiras. Apesar de serem objetos diferentes, elas compartilham uma mesma estrutura e um mesmo comportamento. Entretanto, no h necessidade de se despender tempo modelando as duas cadeiras, ou vrias delas. Basta definir, em um nico lugar, um modelo descrevendo a estrutura e o comportamento desses objetos. A esse modelo damos o nome de classe. Uma classe descreve um conjunto de objetos com as mesmas propriedades (atributos), o mesmo comportamento (operaes), os mesmos relacionamentos com outros objetos e a mesma semntica. Objetos que se comportam da maneira especificada pela classe so ditos instncias dessa classe. Todo objeto pertence a uma classe, ou seja, instncia de uma classe. De fato, a orientao a objetos norteia o processo de desenvolvimento atravs da classificao de objetos, isto , objetos so agrupados em classes, em funo de exibirem facetas similares, sem, no entanto, perda de sua individualidade. Assim, a modelagem orientada a objetos consiste, basicamente, na definio de classes. O comportamento e a estrutura de informao de uma instncia so definidos pela sua classe. Objetos com propriedades e comportamento idnticos so descritos como instncias de uma mesma classe, de modo que a descrio de suas propriedades possa ser feita uma nica vez, de forma concisa, independentemente do nmero de objetos que tenham tais propriedades em comum. Deste modo, uma classe captura a semntica das caractersticas comuns a todas as suas instncias. Enquanto um objeto individual uma entidade real, que executa algum papel no sistema como um todo, uma classe captura a estrutura e comportamento comum a todos os objetos que ela descreve. Assim, uma classe serve como uma espcie de contrato que deve ser estabelecido entre uma abstrao e todos os seus clientes.

Figura 4.4 - Classificao o meio pelo qual ordenamos conhecimento [Booch94].

41

Alguns autores utilizam os conceitos de classe e tipo indistintamente. Entretanto, um tipo e uma classe no so a mesma coisa. Um tipo definido por um conjunto de operaes, isto , pelas manipulaes que podemos fazer com o tipo. Uma classe mais do que isso. Podemos tambm olhar para dentro de uma classe, por exemplo, para ver sua estrutura de informao. Assim, uma classe melhor conceituada como uma implementao especfica de um tipo [Jacobson92]. Mecanismos de Estruturao Em qualquer sistema, objetos relacionam-se uns com os outros. Em sistemas no triviais, por sua vez, geralmente nos deparamos com uma razovel quantidade de objetos e classes e h necessidade de lidar com esta complexidade. Assim, preciso estruturar classes e objetos. Vrios mecanismos tm sido propostos, entre eles, associao, composio e herana. Ligaes e Associaes Objetos relacionam-se com outros objetos. Por exemplo, em o empregado Joo trabalha no departamento de Pessoal, temos um relacionamento entre o objeto empregado Joo e o objeto departamento Pessoal. Ligaes e associaes so meios de se representar relacionamentos entre objetos e entre classes, respectivamente. Uma ligao uma conexo entre objetos. No exemplo anterior, h uma ligao entre os objetos Joo e Pessoal. Uma associao, por sua vez, descreve um conjunto de ligaes com estrutura e semntica comuns. No exemplo anterior, h uma associao entre as classes empregado e departamento. Todas as ligaes de uma associao interligam objetos das mesmas classes, e assim, uma associao descreve um conjunto de potenciais ligaes da mesma maneira que uma classe descreve um conjunto de potenciais objetos [Rumbaugh94]. Composio ou Agregao Uma forma especial de relacionamento entre objetos a composio ou agregao. Parte do poder dos softwares orientados a objetos advm de sua habilidade de manipular objetos complexos, como sendo compostos de vrios outros objetos mais simples. Um carro, por exemplo, composto por motor, rodas, carroceria, etc... Um motor, por sua vez, composto de bloco, vlvulas, pistes, e assim por diante. Composio o relacionamento todo-parte/uma-parte-de onde os objetos representando os componentes de alguma coisa so associados a um objeto representando o todo. Em outras palavras, a composio um tipo forte de associao, onde um objeto agregado composto de vrios objetos componentes [Rumbaugh94]. Generalizao / Especializao Muitas vezes, um conceito geral pode ser especializado, adicionando-se novas caractersticas. Tomemos, como exemplo, o conceito que temos de estudantes. De modo geral, h caractersticas que so intrnsecas a quaisquer estudantes. Entretanto, possvel especializar este conceito para mostrar especificidades de subtipos de estudantes, tais como estudantes de 1o grau, estudantes de 2o grau, estudantes de graduao e estudantes de psgraduao, entre outros. Da maneira inversa, pode-se extrair de um conjunto de conceitos, caractersticas comuns que, quando generalizadas, formam um conceito geral. Por exemplo, ao avaliarmos
42

os conceitos que temos de carros, motos, caminhes e nibus, podemos notar que esses tm caractersticas comuns que podem ser generalizadas em um supertipo veculos automotores terrestres. As abstraes de especializao e generalizao so muito teis para a estruturao de sistemas. Com elas, possvel construir hierarquias de classes, subclasses, subsubclasses, e assim por diante. A herana um mecanismo para modelar similaridades entre classes, representando as abstraes de generalizao e especializao. Atravs da herana, possvel tornar explcitos atributos e servios comuns em uma hierarquia de classes. O mecanismo de herana possibilita reutilizao, captura explcita de caractersticas comuns e definio incremental de classes. Freqentemente, promove-se a herana como a idia central para a reutilizao na indstria de software. Entretanto, apesar da herana, quando adequadamente usada, ser um mecanismo muito til em diversos contextos, incluindo reuso, ela no um pr-requisito para a reutilizao. Uma das principais vantagens da herana facilitar a modificao de modelos. A herana nos permite conceber uma nova classe como um refinamento de outras classes. A nova classe pode herdar as similaridades e definir apenas a funcionalidade nova. O desenvolvimento orientado a objetos fortemente baseado na identificao de objetos e na construo de hierarquias de classes, utilizando o mecanismo de herana.

Figura 4.5 - Uma subclasse herda estrutura e comportamento de suas superclasses [Booch94]. Muitas vezes alguns objetos no se enquadram satisfatoriamente s propriedades descritas em uma classe, tipicamente porque: Alm das propriedades descritas na classe, esses objetos possuem outras ainda no descritas; Algumas das propriedades descritas para a classe no so adequadas aos novos objetos, sendo necessrio, portanto, redefini-las ou mesmo cancel-las. Vale ressaltar que o cancelamento de propriedades, contudo, um indicador de que a hierarquia no est modelada adequadamente.
43

Atravs do mecanismo de herana, tais problemas podem ser contornados. A herana define o relacionamento entre classes, no qual uma classe compartilha a estrutura e comportamento definido em uma ou mais outras classes. A classe que herda caractersticas2 chamada subclasse e a que fornece as caractersticas, superclasse. Desta forma, a herana representa uma hierarquia de abstraes na qual uma subclasse herda de uma ou mais superclasses. Tipicamente, uma subclasse aumenta ou redefine caractersticas das superclasses. Assim, se uma classe B herda de uma classe A, todas as caractersticas descritas em A tornamse automaticamente parte de B, que ainda livre para acrescentar novas caractersticas para seus propsitos especficos. A generalizao permite abstrair, a partir de um conjunto de classes, uma classe mais geral contendo todas as caractersticas comuns. A especializao a operao inversa e portanto, permite especializar uma classe em um nmero de subclasses, explicitando as diferenas entre as novas subclasses. Deste modo possvel compor a hierarquia de classes. Esses tipos de relacionamento so conhecidos tambm como relacionamentos um tipo de, onde um objeto da subclasse tambm um tipo de objeto da superclasse. Neste caso uma instncia da subclasse dita uma instncia indireta da superclasse. Quando uma subclasse herda caractersticas de uma nica superclasse, tem-se herana simples. Quando uma classe definida a partir de duas ou mais superclasses, tem-se herana mltipla. importante observar, no entanto, que na herana mltipla podem ocorrer dois problemas: coliso de nomes herdados a partir de diferentes superclasses e a possibilidade de herana repetida. A figura 4.6 ilustra estes dois casos. Classe A x Classe A Classe B y x w y x Classe B Classe C w z Classe C r (a) Classe D r (b)

Figura 4.6 - (a) Coliso de nomes. (b) Herana repetida. No primeiro caso, a classe C herda das classes A e B. Entretanto ambas possuem uma caracterstica com nome x. Assim, como ser a caracterstica x em C, igual definida na classe A ou igual da classe B? No segundo caso, a classe D herda das classes B e C, que por sua vez herdam da classe A. Assim, temos um caso de herana repetida, j que, indiretamente, a classe D herda duas vezes da classe A. O resultado lquido da herana que desenvolvedores podem evitar a codificao de redundncias atravs da localizao de cada operao no nvel apropriado na hierarquia de classes.
2

Usaremos o termo caracterstica para designar estrutura (atributos) e comportamento (operaes). 44

Mensagens e Mtodos A abstrao incorporada por um objeto caracterizada por um conjunto de operaes que podem ser requisitadas por outros objetos, ditos clientes. Mtodos so implementaes reais de operaes. Para que um objeto realize alguma tarefa, necessrio enviar a ele uma mensagem, solicitando a execuo de um mtodo especfico. Um cliente s pode acessar um objeto atravs da emisso de mensagens, isto , ele no pode acessar ou manipular diretamente os dados associados ao objeto. Os objetos podem ser complexos e o cliente no precisa tomar conhecimento de sua complexidade interna. O cliente precisa saber apenas como se comunicar com o objeto e como ele reage. As mensagens so o meio de comunicao entre objetos e so responsveis pela ativao de todo e qualquer processamento. Dessa forma, possvel garantir que clientes no sero afetados por alteraes nas implementaes de um objeto que no alterem o comportamento esperado de seus servios.

4.2.3 - Conceitos Avanados

Classes e Operaes Abstratas Nem todas as classes so projetadas para instanciar objetos. Algumas so usadas simplesmente para organizar caractersticas comuns a diversas classes ou para encapsular classes que participam de uma mesma associao ou composio. Tais classes so ditas classes classes abstratas. Uma classe abstrata desenvolvida basicamente para ser herdada por outras classes. Ela existe meramente para que um comportamento comum a um conjunto de classes possa ser fatorado em uma localizao comum e definido uma nica vez. Assim, uma classe abstrata no possui instncias diretas mas suas classes descendentes concretas, sim. Uma classe concreta uma classe instancivel, isto , que pode ter instncias diretas. Uma classe abstrata pode ter subclasses tambm abstratas, mas as classes-folhas na rvore de herana devem ser classes concretas. Classes abstratas podem ser projetadas de duas maneiras distintas. Primeiro, elas podem prover implementaes completamente funcionais do comportamento que pretendem capturar. Alternativamente, elas podem prover apenas definio de um protocolo para uma operao sem apresentar um mtodo correspondente. Tal operao dita uma operao genrica ou abstrata. Neste caso, a classe abstrata no completamente implementada e todas as suas subclasses concretas so obrigadas a prover uma implementao para suas operaes abstratas. Assim, diz-se que uma operao abstrata uma operao com mltiplas implementaes. Ela define apenas a assinatura3 a ser usada nas implementaes que as subclasses devero prover, garantindo, assim, uma interface consistente. Mtodos que implementam uma operao genrica tm a mesma semntica. Uma vez que a mesma operao definida em vrias classes de uma mesma hierarquia, importante que os mtodos que a implementam conservem sua interface com o exterior (assinatura), isto , o nome, o nmero e o tipo dos argumentos, e os resultados da operao.

nome da operao, parmetros e retorno 45

Uma classe concreta no pode conter operaes abstratas porque seno seus objetos teriam operaes indefinidas. Analogamente, toda classe que possuir uma operao genrica no pode ter instncias diretas e, portanto, obrigatoriamente uma classe abstrata. Sobrecarga Em sistemas orientados a objetos, operaes distintas de classes distintas, ou at de uma mesma classe, podem ter o mesmo nome. Neste caso, temos um nome de operao sobrecarregado. Polimorfismo O polimorfismo uma poderosa ferramenta para o desenvolvimento de sistemas flexveis. Polimorfismo significa a habilidade de tomar vrias formas. No contexto da orientao a objetos, o polimorfismo est intrinsecamente ligado comunicao entre objetos. De fato, polimorfismo pode ser melhor caracterizado, neste contexto, como o fato de um objeto emissor de uma mensagem no precisar conhecer a classe do objeto receptor. Assim, uma mensagem pode ser interpretada de diferentes maneiras, dependendo da classe do objeto receptor, ou seja, o objeto que receptor que determina a interpretao da mensagem, e no o objeto emissor. O emissor precisa saber apenas que o receptor pode realizar certo comportamento, mas no a que classe ele pertence e, portanto, que operao efetivamente executada. Um objeto sabe qual a sua classe, e, portanto, a correta implementao da operao requisitada. A mensagem associada ao mtodo a ser realmente executado, atravs da identificao da operao e da classe do objeto receptor. Freqentemente, o polimorfismo caracterizado como o fato de uma operao poder ser implementada de diferentes maneiras em diferentes classes. Todavia, isto apenas uma conseqncia do que foi dito anteriormente e no polimorfismo em si. A maioria dos autores no diferencia sobrecarga e polimorfismo, tratando ambos os casos como polimorfismo. Neste texto, entretanto, preferimos utilizar polimorfismo com uma semntica mais rgida: polimorfismo limitado a uma hierarquia de classes. Uma operao ser dita polimrfica se ela existir, com a mesma assinatura, em uma cadeia de superclassessubclasses. Uma operao polimrfica tem uma nica semntica e os mtodos que a implementam conservam essa semntica e, por conseguinte, a sua interface (assinatura). Na sobrecarga de operador, as operaes no tm necessariamente a mesma semntica e no h necessidade de se preservar a assinatura. Ao contrrio, se as operaes sobrecarregadas forem da mesma classe, elas devero ter assinaturas diferentes. Na prtica as operaes sobrecarregadas so, normalmente, uma coincidncia na escolha de nomes de operao. De um outro ponto de vista, o polimorfismo pode ser considerado uma caracterstica dos objetos, refletindo a capacidade deles mudarem de classe em tempo de execuo. O polimorfismo extremamente til quando deseja-se executar alguma operao em um objeto, mas no se sabe, a priori, qual ser exatamente a sua classe em tempo de execuo. Ligao Dinmica Quando uma mensagem enviada a um objeto, deve ser estabelecida uma ligao entre a mensagem enviada e o mtodo a ser executado. A seleo do cdigo para executar uma operao, como dito anteriormente, baseada nos objetos identificados nas mensagens. Quando a classe do objeto que recebe a mensagem conhecida em tempo de compilao, a ligao pode ser feita nesta etapa ou durante a link-edio. Neste caso, tem-se
46

ligao esttica. No entanto, muitas vezes, a classe de um objeto s pode ser identificada quando a mensagem realmente emitida e, portanto, o cdigo s pode ser selecionado neste momento. Neste caso, tem-se ligao dinmica ou tardia (late binding). Muitas vezes, polimorfismo e ligao dinmica so confundidos. Porm, importante frisar que ligao dinmica significa apenas que a mensagem s associada ao mtodo especfico da classe do objeto receptor no momento em que enviada.

4.3 O Processo de Desenvolvimento Orientado a Objetos

No desenvolvimento de grandes sistemas, uma abordagem sistemtica deve ser adotada. Vrias abordagens tm sido propostas, todas objetivando a produo de bons sistemas. Mas o que um bom sistema? Segundo Jacobson [Jacobson92], para responder a essa pergunta, dois pontos de vista devem ser observados: Do ponto de vista externo, isto , dos usurios, um bom sistema deve ser correto, rpido, confivel, fcil de ser usado, eficiente, etc... Do ponto de vista interno, ou seja, dos desenvolvedores, um bom sistema deve ser fcil de ser entendido e modificado, reutilizvel, compatvel com outros sistemas, porttil, etc... Alm disso, a definio de um bom sistema varia, geralmente, em funo de sua aplicao. Apesar de haver muitas abordagens documentadas para anlise e projeto orientados a objetos, h muito pouca informao disponvel sobre processos de desenvolvimento orientados a objetos. Um processo de desenvolvimento engloba um conjunto de atividades, mtodos, tcnicas e prticas que guiam as pessoas na produo de software, permitindo que um produto seja coerentemente criado. Um processo eficaz deve, claramente, considerar as relaes entre as atividades, os artefatos requeridos e produzidos, os recursos, ferramentas e procedimentos necessrios e a habilidade, o treinamento e a motivao do pessoal envolvido. Processos de desenvolvimento no so sempre necessrios. Em pequenos projetos, desenvolvedores podem se comunicar informalmente, dado o pequeno nmero de pessoas envolvidas. medida que o nmero de desenvolvedores cresce, contudo, os canais de comunicao informais no so mais confiveis e um processo de desenvolvimento , ento, necessrio. De fato, nestes casos, a definio de um processo de desenvolvimento um elemento essencial para assegurar a qualidade em um projeto. H vrios aspectos a serem considerados na definio de um processo de software. No centro de sua arquitetura esto as atividades-chave do processo: planejamento, levantamento de requisitos, anlise, projeto, implementao e testes, que so a base sobre a qual o processo de desenvolvimento deve ser construdo. Entretanto, um processo envolve a escolha de um modelo de ciclo de vida, o detalhamento de suas macro-atividades, a escolha de mtodos e tcnicas para a sua realizao e a definio de recursos e artefatos necessrios e produzidos. Um processo de desenvolvimento de software no pode ser definido de forma universal. Para ser eficaz e conduzir construo de produtos de boa qualidade, um processo deve ser adequado ao domnio da aplicao e ao projeto especfico. Deste modo, processos devem ser definidos caso a caso, considerando-se as especificidades da aplicao, a tecnologia a ser adotada na sua construo, a organizao onde o produto ser desenvolvido e o grupo de desenvolvimento.
47

Em suma, o objetivo de se definir um processo de software favorecer a produo de sistemas de alta qualidade, atingindo as necessidades dos usurios finais, dentro de um cronograma e um oramento previsveis. A escolha de um modelo de ciclo de vida o ponto de partida para a definio de um processo de software. Um modelo de ciclo de vida organiza as macro-atividades bsicas, estabelecendo precedncia e dependncia entre as mesmas. Um ciclo de vida pode ser entendido como passos ou atividades que devem ser executados durante um projeto. Para a definio completa do processo, a cada atividade, devem ser associados tcnicas, ferramentas e critrios de qualidade, entre outros, formando uma base slida para o desenvolvimento. Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser definidas, entre elas gerncia de configurao e controle e garantia da qualidade. De maneira geral, o ciclo de vida de um software envolve as seguintes fases: Planejamento: O objetivo do planejamento de projeto fornecer uma estrutura que possibilite ao gerente fazer estimativas razoveis de recursos, custos e prazos. Uma vez estabelecido o escopo de software, uma proposta de desenvolvimento deve ser elaborada, isto , um plano de projeto deve ser elaborado configurando o processo a ser utilizado no desenvolvimento de software. medida que o projeto progride, o planejamento deve ser detalhado e atualizado regularmente. Pelo menos ao final de cada uma das fases do desenvolvimento (levantamento de requisitos, anlise, projeto, implementao e teste) o planejamento como um todo deve ser revisto e o planejamento da etapa seguinte deve ser detalhado. Levantamento de Requisitos: Nesta fase, o processo de coleta (levantamento) de requisitos intensificado. O escopo deve ser refinado e os requisitos identificados. Para entender a natureza do software a ser construdo, o engenheiro de software tem de compreender o domnio do problema, bem como a funcionalidade e o comportamento esperados. Anlise: Uma vez identificados os requisitos do sistema a ser desenvolvido, estes devem ser modelados, avaliados e documentados. Uma parte vital desta fase a construo de um modelo descrevendo o que o software tem de fazer (e no como faz-lo). Projeto: Esta fase responsvel por incorporar requisitos tecnolgicos aos requisitos essenciais do sistema, modelados na fase anterior e, portanto, requer que a plataforma de implementao seja conhecida. Basicamente, envolve duas grandes etapas: projeto da arquitetura do sistema e projeto detalhado. O objetivo da primeira etapa definir a arquitetura geral do software, tendo por base o modelo construdo na fase de anlise de requisitos. Esta arquitetura deve descrever a estrutura de nvel mais alto da aplicao e identificar seus principais componentes. O propsito do projeto detalhado detalhar o projeto do software para cada componente identificado na etapa anterior. Os componentes de software devem ser sucessivamente refinados em nveis de maior detalhamento, at que possam ser codificados e testados. Implementao: O projeto deve ser traduzido para uma forma passvel de execuo pela mquina. A fase de implementao realiza esta tarefa, isto , cada unidade de software do projeto detalhado implementada.
48

Testes: inclui diversos nveis de testes, a saber, teste de unidade, teste de integrao e teste de sistema. Inicialmente, cada unidade de software implementada deve ser testada e os resultados documentados. A seguir, os diversos componentes devem ser integrados sucessivamente at se obter o sistema. Finalmente, o sistema como um todo deve ser testado. Implantao: uma vez testado, o software deve ser colocado em produo. Para tal, contudo, necessrio treinar os usurios, configurar o ambiente de produo e, muitas vezes, converter bases de dados. O propsito desta fase estabelecer que o software satisfaz os requisitos dos usurios. Isto feito instalando o software e conduzindo testes de aceitao (validao). Quando o software tiver demonstrado prover as capacidades requeridas, ele pode ser aceito e a operao iniciada. Operao: nesta fase, o software utilizado pelos usurios no ambiente de produo. Manuteno: Indubitavelmente, o software sofrer mudanas aps ter sido entregue para o usurio. Alteraes ocorrero porque erros foram encontrados, porque o software precisa ser adaptado para acomodar mudanas em seu ambiente externo, ou porque o cliente necessita de funcionalidade adicional ou aumento de desempenho. Muitas vezes, dependendo do tipo e porte da manuteno necessria, esta fase pode requerer a definio de um novo processo, onde cada uma das fases precedentes re-aplicada no contexto de um software existente ao invs de um novo.

Uma vez que o software sempre parte de um sistema (ou negcio) maior, o trabalho comea pelo estabelecimento dos requisitos para todos os elementos do sistema e, na seqncia, procede-se a alocao para software de algum subconjunto destes requisitos. Esta etapa a Engenharia de Sistemas e antecede a todas as demais relacionadas. Um modelo de ciclo de vida estrutura as atividades do projeto em fases e define como estas fases esto relacionadas. A escolha de um modelo de ciclo de vida fortemente dependente das caractersticas do projeto. Assim, importante apresentar vrios modelos de ciclo de vida adequados ao desenvolvimento orientado a objetos, indicando em que situaes so aplicveis. Dentre os principais modelos de ciclo de vida, destacam-se o modelo seqencial linear, o modelo incremental e vrios modelos evolutivos. 4.3.1 - O Modelo Seqencial Linear Algumas vezes chamado de ciclo de vida clssico ou modelo em cascata, o modelo seqencial linear sugere uma abordagem seqencial sistemtica para o desenvolvimento de software que comea no nvel de sistema e avana atravs de anlise, projeto, implementao, teste e manuteno, como mostra a figura 4.7. Na abordagem em cascata, as fases so executadas seqencialmente. Cada fase executada uma vez, embora um retorno fase anterior seja permitido para correo de erros. A entrega do sistema completo ocorre em um nico marco, ao final da fase de Testes de Validao e Implantao.

49

Planejamento

Levantamento de Requisitos Anlise

Projeto Implementao e Teste de Unidade Testes Testes de Validao e Implantao Operao e Manuteno

Figura 4.7 - O Modelo Seqencial Linear. O modelo seqencial linear o modelo de ciclo de vida mais antigo e mais amplamente usado. Entretanto, crticas tm levado ao questionamento de sua eficincia. Dentre os problemas algumas vezes encontrados na sua aplicao, destacam-se: Projetos reais muitas vezes no seguem o fluxo seqencial que o modelo prope. Freqentemente, difcil para o usurio colocar todos os requisitos explicitamente. O modelo seqencial linear requer isto e tem dificuldade de acomodar a incerteza natural que existe no incio de muitos projetos. O usurio precisa ser paciente. Uma verso operacional do software no estar disponvel at o final do projeto. A introduo de certos membros da equipe, tais como projetistas e programadores, freqentemente adiada desnecessariamente. A natureza linear do ciclo de vida clssico leva a estados de bloqueio nos quais alguns membros da equipe do projeto precisam esperar que outros membros da equipe completem tarefas dependentes. Cada um desses problemas real. Entretanto, o modelo de ciclo de vida clssico tem um lugar definitivo e importante no trabalho de engenharia de software. Embora tenha fraquezas, ele significativamente melhor do que uma abordagem casual para o desenvolvimento de software. De fato, para problemas pequenos e bem-definidos, onde os desenvolvedores conhecem bem o domnio do problema e os requisitos podem ser estabelecidos claramente, este modelo deve ser o preferido, uma vez que o mais fcil de ser gerenciado.

50

4.3.2 - O Modelo Incremental O modelo incremental uma variao do modelo de ciclo de vida seqencial linear, na qual as fases de levantamento de requisitos, anlise e projeto da arquitetura so realizadas para o software como um todo. Uma vez definida a arquitetura do software, as demais fases (projeto detalhado, implementao e teste) so divididas em unidades mais gerenciveis e, assim sendo, o software distribudo em vrias verses, cada uma delas com funcionalidade e capacidade aumentadas, como mostra a figura 4.8.

Planejamento Levantamento de Requisitos Anlise Projeto da Arquitetura Projeto Detalhado incremento

1
Teste

Implantao Entrega do 1o incremento

Implementao

incremento 2 Projeto Detalhado Implementao Teste Entrega do 2o incremento

...
incremento n Projeto Detalhado Implementao Teste Entrega do incremento-n tempo

Figura 4.8 - O Modelo Incremental. Este modelo de processo aplica-se quando o software a ser desenvolvido grande, mas o problema bem-definido, e no h recursos para seu desenvolvimento como um todo, ou quando se deseja apresentar resultados para o cliente mais rapidamente. De fato, ao se adotar este modelo, est-se estabelecendo um critrio para o escalonamento do trabalho de projeto detalhado, implementao e testes. 4.3.3 - Modelos Evolutivos H um crescente reconhecimento que software, assim como todo sistema complexo, evolui por um perodo de tempo. Requisitos do negcio e do produto freqentemente mudam medida que o desenvolvimento avana, abrindo caminho para um produto final irreal; prazos apertados tornam impossvel o trmino de um produto de software completo, mas uma verso limitada tem de ser introduzida para satisfazer s presses do negcio ou competitividade; um conjunto de requisitos centrais do produto ou sistema bem
51

compreendido, mas os detalhes de extenses da aplicao tm ainda de ser definidos. Nestas e em situaes similares, engenheiros de software necessitam de um modelo de ciclo de vida que tenha sido explicitamente projetado para acomodar um produto que evolua ao longo do tempo. Assim, quando o problema no bem definido e ele no pode ser totalmente especificado no incio do desenvolvimento, deve-se optar por um modelo evolutivo. Os modelos evolutivos aplicam seqncias lineares de modo escalonado, medida que o calendrio de tempo avana. Cada seqncia linear produz um incremento distribuvel do software que colocado em uso. Durante o uso, novos requisitos so levantados, dando incio a um novo ciclo de desenvolvimento. Desta forma, estes modelos permitem que os engenheiros de software desenvolvam iterativamente verses do software cada vez mais completas. Modelo Espiral O modelo espiral capaz de descrever como um produto se desenvolve para formar novas verses e como uma verso pode ser incrementalmente desenvolvida, partindo-se de um prottipo at um produto completo. A figura 4.9 ilustra este modelo.

Figura 4.9 - Um modelo espiral [Jacobson92]. Uma das importantes caractersticas do desenvolvimento de software orientado a objetos que todas as atividades do ciclo de vida compartilham vocabulrio, notao e estratgias comuns, isto , tudo gira em torno de objetos. Seja na fase de anlise, projeto ou implementao, a equipe de desenvolvimento estar sempre envolvida na descoberta, documentao, prototipao e/ou desenvolvimento de objetos, e em todas as atividades do ciclo de vida, os conceitos de abstrao fundamentais para a orientao a objetos, tais como encapsulamento e herana, desempenham um importante papel. Esta uma das principais diferenas em relao s metodologias convencionais, onde, por exemplo, as atividades do grupo de modelagem de dados freqentemente parecem no ter qualquer relao com as atividades do grupo de modelagem funcional, sendo que as notaes usadas por cada um dos grupos so completamente dspares. Alm disso, sistemas orientados a objetos apresentam outras caractersticas muito interessantes e desejveis ao processo de produo de software, entre elas:

52

 viso do mundo real mais adequada atravs da observao de objetos, com conseqente reduo do gap semntico, que proporciona uma viso balanceada de dados e processos; desenvolvimento incremental e evolutivo. Esta caracterstica extremamente desejvel para que um produto possa ser desenvolvido em etapas ou por equipes distintas; reusabilidade. Atravs da reutilizao, muitas vezes possvel reaproveitar parcelas de cdigo, projetos ou mesmo de especificaes de requisitos na construo de outras partes de um sistema, ou at mesmo de outros sistemas; possibilidade de incorporao de pequenas diferenas a elementos do sistema, atravs da abstrao de generalizao/especializao, mantendo alta coeso do sistema; modularidade. O conceito de objetos e sua descrio em classes, incorporando dados e operaes, constituem critrios de modularizao altamente efetivos e propiciam o encapsulamento. Dadas estas caractersticas, modelos em espiral e modelos baseados em prototipao tm sido amplamente utilizados no processo de desenvolvimento de sistemas orientados a objetos. Modelo Evolutivo Bsico O modelo evolutivo bsico pressupe que o desenvolvimento se dar em ciclos, onde ao final de cada ciclo, uma verso operacional do software colocada em uso. Durante o uso, novos requisitos so levantados, dando incio a um novo ciclo no desenvolvimento. A figura 4.10 ilustra este modelo.
implantao/operao planejamento levantamento de requisitos anlise projeto implementao teste 1a realimentao Verso do cliente

reviso e refinamento planejamento levantamento de requisitos anlise projeto implementao teste 2a realimentao Verso do cliente

reviso e refinamento

...
planejamento levantamento de requisitos anlise projeto implementao teste Produto Final

Figura 4.10 - O modelo evolutivo bsico. O primeiro incremento geralmente um produto central, isto , os requisitos bsicos so tratados, mas muitas caractersticas suplementares (algumas conhecidas, outras no) permanecem indisponveis. O produto central usado pelo cliente (ou passa por uma reviso detalhada). Como resultado do uso e/ou da avaliao, um plano desenvolvido para o prximo incremento. Este plano enderea dois aspectos principais: a modificao do produto
53

central para melhor satisfazer as necessidades do cliente e a entrega de funcionalidades e caractersticas adicionais. Este processo repetido, seguindo a entrega de cada incremento, at que o produto completo seja construdo. O desenvolvimento evolutivo particularmente til quando no h recursos de pessoal disponveis para uma completa implementao nos prazos estabelecidos para o projeto. Alm disso, incrementos podem ser planejados para gerenciar riscos tcnicos. O Modelo Rational A Rational Software desenvolveu um modelo de processo, integrado com uma coleo de ferramentas, para o desenvolvimento de sistemas complexos, orientados a objetos [Kruchten98], que pode ser adaptado e estendido para adequar-se a projetos especficos. O ciclo de vida adotado por este processo tipicamente evolutivo. Contudo, uma forma de organizao em fases adotada para comportar os ciclos de desenvolvimento, permitindo uma gerncia mais efetiva no projeto de sistemas complexos. Ao contrrio do tradicionalmente definido como fases na maioria dos modelos de ciclo de vida planejamento, levantamento de requisitos, anlise, projeto, implementao e testes so definidas fases ortogonais a estas, a saber [Kruchten98]: Concepo: nesta fase, estabelecido o escopo do projeto e suas fronteiras, discriminando os principais casos de uso do sistema. Deve-se estimar os custos e prazos globais para o projeto como um todo e prover estimativas detalhadas para a fase de elaborao. Ao trmino desta fase, so examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento; Elaborao: o propsito desta fase analisar mais refinadamente o domnio do problema, estabelecer uma arquitetura de fundao slida, desenvolver um plano de projeto para o sistema a ser construdo e eliminar os elementos de projeto que oferecem maior risco. Ao trmino desta fase, a parte considerada mais complicada do desenvolvimento considerada completa. Embora o processo deva sempre acomodar alteraes, as atividades da fase de elaborao asseguram que os requisitos, a arquitetura e os planos esto suficientemente estveis e que os riscos esto suficientemente mitigados, de modo a se poder prever com preciso os custos e prazos para a concluso do desenvolvimento. Construo: durante a fase de construo, um produto completo desenvolvido de maneira iterativa e incremental para que esteja pronto para a transio comunidade usuria. Transio: nesta fase, o software disponibilizado comunidade usuria. Aps o produto ter sido colocado em uso, naturalmente surgem novas consideraes que iro demandar a construo de novas verses para permitir ajustes do sistema, corrigir problemas ou concluir algumas caractersticas que foram postergadas. importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo planejamento, levantamento de requisitos, anlise, projeto e implementao e testes, realizado. Contudo, de uma iterao para outra e de uma fase para a prxima, a nfase sobre as vrias atividades muda, como mostra a figura 4.11. Na fase de concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho
54

de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e rechear o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de transio concentra-se na garantia de que o sistema possui o nvel adequado de qualidade (testes). Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecidos adicionados.

Levantamento de Requisitos Concepo Elaborao Construo Transio

Anlise

Projeto

Implementao

Testes

Figura 4.11 A nfase principal de cada uma das fases. Alm dos conjuntos de iteraes em cada fase, o conjunto de fases em si pode ser iterativo. Como mostra a figura 4.12, as fases no necessariamente tm a mesma durao. O esforo realizado em cada fase ir variar fortemente em funo das circunstncias especficas do projeto. V1 Concepo Iterao Preliminar Elaborao Construo Transio

Iterao Iterao Iterao Iterao Iterao Itera ... ... ... #1 #k #k+1 #m #m+1 o #n V2

Concepo

Elaborao ...

Construo

Transio

Vn Concepo Elaborao Construo Transio

Figura 4.12 O Modelo da Rational. A figura 4.13 mostra uma distribuio de tempo tpica para ciclos de desenvolvimento iniciais de um projeto [Kruchten98].

55

Concepo 10%

Elaborao 30%

Construo 50%

Transio 10%

Figura 4.13 Uma distribuio de tempo tpica para ciclos iniciais. Durante a captura e descrio detalhada dos casos de uso, o sistema cuidadosamente estudado. Uma vez que, geralmente, casos de uso enfocam uma particular funcionalidade, possvel analisar a funcionalidade total do sistema de maneira incremental. Deste modo, casos de uso para reas funcionalmente diferentes podem ser desenvolvidos independentemente e, mais tarde, reunidos para formar um modelo de requisitos completo. Com isso, permite-se enfocar um problema de cada vez, abrindo caminho para um desenvolvimento incremental ou evolutivo.

4.4 - A Linguagem de Modelagem Unificada

A Linguagem de Modelagem Unificada (Unified Modeling Language UML) a linguagem padro para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser utilizada em todos os processos de desenvolvimento orientados a objetos, ao longo de seus ciclos de desenvolvimento, usando diferentes tecnologias de implementao [Furlan98]. A UML teve origem em uma tentativa de se unificar os principais mtodos orientados a objetos utilizados at ento: a OMT [Rumbaugh94] e o Mtodo de Booch [Booch94]. A este esforo juntou-se tambm Ivar Jacobson, fundindo tambm seu mtodo OOSE [Jacobson92]. Contudo, percebeu-se que no era possvel estabelecer um nico mtodo adequado para todo e qualquer desenvolvimento. De fato, um mtodo composto por uma notao para os artefatos produzidos e de um processo descrevendo que artefatos construir e como construilos. A notao pode ser unificada, mas a deciso de quais artefatos produzir e que passos seguir no passvel de padronizao, j que varia de projeto para projeto. Assim, ao invs de criarem um mtodo unificado, Rumbaugh, Booch e Jacobson propuseram a UML, incorporando as principais notaes para os produtos de seus mtodos e de vrios outros, com a colaborao de vrias empresas e autores. A UML foi aprovada em novembro de 1997 pela OMG Object Management Group pondo fim a uma guerra de mtodos OO. A UML pode ser usada para [Furlan98]: Mostrar as fronteiras de um sistema e suas funes principais, utilizando atores e casos de uso; Representar a estrutura esttica de um sistema, utilizando diagramas de classes; Modelar o comportamento de objetos com diagramas de estados; Ilustrar a realizao de casos de uso com diagramas de interao; Revelar a arquitetura de implementao fsica com diagramas de implementao. A UML vai alm de uma simples padronizao em busca de uma notao unificada, uma vez que contm conceitos novos que no so encontrados em outros mtodos orientados a objetos, como o caso dos diagramas de atividade.
56

Os diagramas contemplados pela UML so [Furlan98]: Diagrama de Casos de Uso: Os casos de uso descrevem a funcionalidade do sistema percebida por atores externos. Um ator interage com o sistema, podendo ser um usurio, dispositivo ou outro sistema. Diagrama de Classes: Denota a estrutura esttica de um sistema, isto , as classes, os relacionamentos entre suas instncias (objetos), restries e hierarquias. O diagrama considerado esttico pois a estrutura descrita sempre vlida em qualquer ponto no ciclo de vida do sistema. Diagramas de Interao, podendo ser: Diagramas de Seqncia: mostram a colaborao dinmica entre um nmero de objetos, sendo seu objetivo principal mostrar a seqncia de mensagens enviadas entre objetos. um grfico bidimensional, onde a dimenso vertical representa o tempo e a dimenso horizontal os diferentes objetos. Diagramas de Colaborao: tm exatamente o mesmo propsito dos diagramas de seqncia, apresentando, contudo, um formato diferente. So desenhados como diagramas de objetos, onde so mostradas as mensagens trocadas entre os objetos. Diagramas de Estados: mostram as seqncias de estados pelos quais um objeto pode passar ao longo de sua vida, em resposta a estmulos recebidos, juntamente com suas respostas e aes. tipicamente um complemento de uma classe e relaciona os possveis estados que os objetos da classe podem ter e quais eventos podem causar uma transio de um estado para outro. A UML descreve, tambm, uma variao dos Diagramas de Estado, na qual a maioria dos estados estado de ao e a maioria das transies ativada por concluses das aes, os ditos Diagramas de Atividades; Diagramas de Implementao, composto por dois diagramas: Diagrama de Componentes: so mostradas as dependncias entre componentes de software, inclusive cdigo fonte, cdigo binrio e componentes executveis. Diagrama de Implantao: mostra elementos de configurao do processamento em tempo de execuo, isto , os componentes de software, processos e dispositivos fsicos. Vale ressaltar mais uma vez, que a UML uma linguagem de modelagem, no um mtodo de desenvolvimento OO. Os mtodos consistem, pelo menos em princpio, de uma linguagem de modelagem e um procedimento de uso dessa linguagem. A UML no prescreve explicitamente esse procedimento de utilizao [Furlan98]. Assim, a UML deve ser aplicada no contexto de um processo, lembrando que domnios de problemas e projetos diferentes podem requerer processos diferentes.

57

UFES
Departamento de Informtica

Anlise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 Introduo Orientao a Objetos

Referncias Bibliogrficas do Captulo [Booch94] [Coad92] [Furlan98] [Jacobson92] [Kruchten98] [Pompilho95] [Rumbaugh94] [Snyder93] [Yourdon94] G. Booch; Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin/Cummings Publishing Company, Inc, 1994. P. Coad, E. Yourdon; Anlise Baseada em Objetos, Editora Campus, 1992. J.D. Furlan; Modelagem de Objetos Atravs da UML; Makron Books, 1998. I. Jacobson; Object-Oriented Software Engineering, Addison-Wesley, 1992. P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. S. Pompilho. Anlise Essencial: Guia Prtico de Anlise de Sistemas. IBPI Press, Editora Infobook, Rio de Janeiro, 1995. J. Rumbaugh, et alli; Modelagem e Projetos Baseados em Objetos, Editora Campus, 1994. A. Snyder; The Essence of Objects: Concepts and Terms, IEEE Software, Janeiro 1993. E. Yourdon; Object-Oriented Systems Design: an Integrated Approach, Yourdon Press Computing Series, Prentice Hall, 1994.

58

5. Anlise Orientada a Objetos

Quando um novo sistema precisa ser construdo e decidimos utilizar o paradigma orientado a objetos (OO) em seu desenvolvimento, surge uma importante questo: Como modelar os requisitos do sistema de um modo adequado para a Engenharia de Software OO? Uma vez que, essencialmente, este paradigma trabalha com objetos, necessrio identificar quais os objetos relevantes, como eles se relacionam e como eles se comportam no contexto do sistema. Alm disso, preciso especificar e modelar o problema de maneira que seja possvel criar um projeto OO efetivo. Todos estes aspectos so tratados dentro do contexto da Anlise Orientada a Objetos (AOO) [Pressman00]. O propsito da Anlise Orientada a Objetos (AOO) definir todas as classes (e os relacionamentos e comportamentos associados a ela) que so relevantes para o problema a ser resolvido. Para tal, um nmero de tarefas deve ocorrer: Identificao de Classes Especificao de Hierarquias de Generalizao/Especializao Identificao de Associaes e Atributos Modelagem do Comportamento Definio das Operaes

importante notar que estas atividades so dependentes umas das outras e que, durante o desenvolvimento, elas so realizadas, tipicamente, de forma iterativa. A nfase da fase de anlise, no entanto, deve ser sempre o entendimento do domnio do problema, sempre desconsiderando aspectos de implementao. A popularidade da orientao a objetos fez surgir dezenas de mtodos OO para anlise e projeto. Cada um deles, introduz um processo para analisar um sistema, um conjunto de modelos que evoluem ao longo do processo e uma notao que permite ao engenheiro de software criar cada modelo de maneira consistente [Pressman00]. Entre os principais mtodos existentes podemos citar o Mtodo de Booch [Booch94], OMT [Rumbaugh94], OOSE [Jacobson92] e o Mtodo de Coad & Yourdon [Coad92][Coad93]. Ainda que, primeira vista, estes mtodos possam parecer substancialmente diferentes, isto no verdade. Todos eles consideram, de alguma forma, as tarefas listadas anteriormente. Essencialmente, as maiores diferenas esto nas diretrizes e heursticas fornecidas, nos modelos utilizados, suas notaes e no processo sugerido. Tentativas para se definir um mtodo padro tm sido realizadas, mas tm encontrado como principal obstculo a definio de um processo padro de anlise e projeto. Assim, um primeiro passo foi dado ao se propor a Linguagem de Modelagem Unificada (UML), que estabelece, para um conjunto de modelos normalmente utilizados no desenvolvimento OO, uma notao padro. Neste texto, no adotamos nenhum mtodo especfico, mas, ao mesmo tempo todos. Isto , procuramos incorporar as caractersticas que julgamos serem as mais teis de cada um dos mtodos em uma abordagem bsica para o desenvolvimento OO. O processo de desenvolvimento deve ser definido caso a caso, levando-se em conta as particularidades do projeto em questo, do domnio de aplicao e das caractersticas da equipe de desenvolvimento, entre outras. Mas a abordagem aqui proposta pode ser vista como o ponto de partida para esta definio. Quanto aos modelos e suas notaes, adotamos, basicamente, aqueles definidos na UML [Furlan98].
59

5.1 - Identificao de Classes

Com base na especificao de requisitos e nos diagramas de casos de uso e suas descries, possvel iniciar o trabalho de modelagem do sistema. O modelo de objetos dos requisitos dos usurios para o sistema a ser gerado deve ser to independente de sua futura implementao quanto possvel. No h nada mais central e crucial para qualquer mtodo orientado a objetos do que o processo de descoberta de quais classes devem ser includas no modelo. O cerne de um modelo OO exatamente o seu conjunto de classes [Yourdon94]. A figura 5.1 mostra a notao bsica da UML para classes em um Diagrama de Classes.
Classe Atributos da Classe Operaes da Classe

Figura 5.1 - Notao Bsica da UML para Classes em um Diagrama de Classes. Com a AOO, um engenheiro de software estuda, filtra e modela o domnio do problema. Dizemos que o engenheiro de software filtra o domnio, pois apenas uma parte desse domnio far parte das responsabilidades do sistema. Assim, um domnio de problemas pode incluir vrias informaes e funcionalidades, mas as responsabilidades de um sistema neste domnio podem incluir apenas uma pequena parcela deste conjunto. As classes de um modelo representam a expresso inicial do sistema. As atividades subseqentes da AOO buscam obter uma descrio cada vez mais detalhada do contexto, em termos de associaes, atributos e operaes. Assim, a identificao das classes uma tarefa crucial para o desenvolvimento de um sistema OO. Para facilitar a identificao das classes do sistema [Coad92]: Estude o domnio de aplicao; Faa uma observao geral no ambiente real onde existe o problema; Procure ouvir atentamente os especialistas do domnio do problema; Verifique, se existirem, resultados de AOOs anteriores em domnios semelhantes; Observe outros sistemas no mesmo domnio ou em domnios similares; Consulte fontes bibliogrficas; Um aspecto fundamental no processo de anlise a interao constante com os especialistas de domnio. Tcnicas de coleta de dados, tais como entrevistas, reviso de documentos e reunies informais com os usurios, tm um papel importante nesta etapa. O espao de problema em si, junto com quaisquer diagramas, figuras e informao textual providos pelos usurios, pode ser uma importante fonte para este trabalho. Para descobrir as classes de um domnio de aplicao, observe os seguintes elementos: objetos fsicos ou conceituais que formam uma abstrao coesa, sobre os quais o sistema precisa manipular informaes;

60

 outros sistemas e terminadores externos que se comunicam ou interagem com o sistema em questo, atentando para as informaes que esto sendo trocadas; dispositivos fsicos com os quais o sistema em estudo ter de interagir, sem considerar a tecnologia para implementar o sistema em si; Um primeiro passo no processo de identificao de classes deve ser a reviso e discusso da especificao de requisitos. Wirfs-Brock, Wilkerson, Wiener [Wirfs-Brock90] e Jacobson [Jacobson92] sugerem que uma boa estratgia para identificar objetos ler a especificao de requisitos procurando por substantivos. Esses autores argumentam que um objeto , tipicamente, descrito por um nome no domnio e, portanto, aprender sobre a terminologia do domnio do problema um bom ponto de partida. Uma heurstica menos vaga sugere que os seguintes elementos sejam considerados como potenciais candidatos a classes [Coad92]: coisas que so parte do domnio de informao do problema; ocorrncias ou eventos que precisam ser registrados e lembrados pelo sistema; papis desempenhados pelas diferentes pessoas que interagem direta ou indiretamente com o sistema; locais fsicos ou geogrficos e lugares que estabelecem o contexto do problema; unidades organizacionais (departamentos, divises, etc...) que possam ser relevantes para o sistema. Uma vez identificadas as potenciais classes, deve-se proceder uma avaliao para decidir o que considerar ou recusar. Dentre os critrios para incluso de classes podem ser citados [Coad92]: Lembrana necessria: o sistema precisa se lembrar de alguma coisa sobre os objetos da classe? Normalmente, devem ser necessrios, pelo menos, dois ou mais atributos; Funcionalidade necessria e essencial: deve ser possvel identificar uma ou mais operaes para as classe propostas, isto , objetos destas classes tm de fazer algo para justificar a sua existncia. Alm disso, a funcionalidade identificada para a classe proposta deve ser relevante e necessria a despeito da tecnologia de hardware e software a ser usada para implementar o sistema; caso contrrio, a classe proposta uma classe de projeto ou de implementao e sua incluso no modelo deve ser adiada at o respectivo estgio de desenvolvimento; Atributos e operaes comuns: os atributos e as operaes da classe devem ser aplicveis a todas as suas instncia, isto , aos objetos da classe. Para ser considerada uma classe legtima no modelo de anlise, uma classe candidata tem de satisfazer a todas (ou quase todas) as caractersticas acima. Alm disso, observe se existem vrias instncias da classe. Uma classe que possui uma nica instncia tambm no deve ser considerada uma classe. O resultado principal desta atividade a obteno de uma lista de potenciais classes para o sistema em estudo.

61

5.2 - Especificao de Hierarquias de Generalizao / Especializao

Um dos principais mecanismos de estruturao de conceitos a generalizao / especializao. Com este mecanismo possvel capturar similaridades entre classes, dispondo-as em hierarquias de classes. A figura 5.2 mostra a notao da UML usada para representar a estrutura de generalizao - especializao. importante realar que esta estrutura reflete um mapeamento entre classes e no entre objetos.
Super-classe

Sub-classe 1

Sub-classe N

Figura 5.2 - Notao da UML para Hierarquia de Classes. As seguintes diretrizes podem ser usadas analisar as hierarquias modeladas: Uma hierarquia de classes deve modelar relaes -um-tipo-de, ou seja, toda subclasse deve ser um tipo especfico das suas superclasses. Uma subclasse deve suportar toda a funcionalidade (atributos, relacionamentos e operaes) definida por suas superclasses, e possivelmente mais. A funcionalidade comum a diversas classes deve ser posicionada o mais alto possvel na hierarquia. Classes abstratas no podem herdar de classes concretas. Classes que no adicionam funcionalidade devem ser eliminadas. Por adicionar funcionalidade que se dizer adicionar nova funcionalidade ou redefinir uma funcionalidade existente em uma superclasse.

Cada especializao deve ser nomeada de forma a ser auto-explicativa. Um nome apropriado para a especializao pode ser formado pelos nomes de suas generalizaes, acompanhados por um nome qualificador que descreve a natureza da especializao. As classes geradas atravs de generalizao-especializao devem atender, alm dos critrios para incluso discutidos na seo anterior, aos seguintes critrios: As potenciais especializaes e/ou generalizaes devem estar no domnio do problema e devem fazer parte das responsabilidades do sistema; e Se uma classe dita sub-classe de outra, todas as instncias da sub-classe tm de ser tambm, por definio, instncias da super-classe, isto , tudo o que dito sobre a superclasse (relacionamentos, atributos e operaes) tem de ser vlido tambm para a subclasse.

Se a nica distino entre as especializaes for o seu tipo, ou se as classes de especializao no adicionarem nenhuma funcionalidade, ento a estrutura de generalizaoespecializao no necessria.
62

A figura 5.3 ilustra uma hierarquia de classes dentro do contexto de uma auto-escola. H uma pequena e importante sutileza neste exemplo que precisa ser realada: a figura 5.3 indica explicitamente que no h instncias da classe Veculo per se; as nicas instncias (ou objetos) ocorrem no nvel de especializao de Carro, Moto, nibus, ou Caminho. Isso indicado pelo nome da classe Veculo que est escrito em itlico, em contraste com os demais nomes de classes. Este o padro de notao para classes abstratas na UML.
Veculo

Carro

Moto

Caminho

nibus

Figura 5.3 - Hierarquia de Classes no Contexto de uma Auto-Escola. Um recurso adicional que muitas vezes facilita o entendimento das estruturas de generalizao / especializao, principalmente quando h vrias classificaes para uma mesma classe, indicar o critrio de organizao de cada hierarquia, adicionando um rtulo junto ao smbolo de classificao (tringulo).

5.3 - Identificao de Subsistemas

Um modelo de anlise para uma aplicao complexa pode ter centenas de classes e dezenas de estruturas e, portanto, pode ser necessrio definir uma representao concisa capaz de orientar um leitor em um modelo desta natureza. O agrupamento de classes em subsistemas serve basicamente a este propsito, podendo ser til tambm para a organizao de grupos de trabalho em projetos extensos. A base principal para a identificao de subsistemas a complexidade do domnio do problema. Atravs da identificao e agrupamento de classes em subsistemas, possvel controlar a visibilidade do leitor e, assim, tornar o modelo mais compreensvel. Quando uma coleo de classes colaboram entre si para realizar um conjunto coeso de responsabilidades, elas podem ser vistas como um subsistema. Assim, um subsistema uma abstrao que prov uma referncia para mais detalhes em um modelo de anlise. Quando visto de fora, um subsistema pode ser tratado como uma caixa preta que contm um conjunto de responsabilidades e possui suas prprias colaboraes [Pressman00]. O agrupamento de classes em subsistemas permite apresentar o modelo global em uma perspectiva mais alta. Este nvel ajuda o leitor a rever o modelo. Alm disso, constitui tambm um bom critrio para organizao da documentao. Os casos de uso so um bom ponto de partida para o agrupamento de classes em subsistemas. Ao modelar grupos coesos de casos de uso como subsistemas, estamos relacionando as informaes contidas nos modelos de classe e de casos de uso.

63

A UML prope o uso de um tipo especial de diagrama de classes, onde apenas subsistemas e suas relaes so representados, os chamados diagramas de pacotes, cuja notao mostrada na figura 5.4.

Pacote 1

Pacote 2

Figura 5.4 - Notao da UML para Diagramas de Pacotes.

5.4 - Identificao de Relacionamentos e Definio de Atributos

5.4.1 - Identificao de Relacionamentos
Relacionamentos so representaes estticas que modelam associaes entre objetos, um dos mecanismos de estruturao de objetos. Cada classe desempenha um papel na associao, ao qual pode ser dado um nome. Cada papel possui tambm uma cardinalidade, que indica quantos objetos podem participar de um dado relacionamento. Em geral, a cardinalidade indica as fronteiras inferior e superior para os objetos participantes, como mostra a figura 5.5.
Um A est sempre associado a um e somente um B. Um A est sempre associado a um ou mais Bs. Um A est associado a zero ou um B. Um A est associado a zero ou mais Bs.

1 B

1..*

0..1

* B

Figura 5.5 - Notaes da UML para Associaes e suas Cardinalidades. H vrias maneiras de nomear associaes. Os seguidores da modelagem de dados tradicional, normalmente, tm o hbito de usar um verbo ou frase verbal de modo que o relacionamento possa ser lido como uma sentena. Na modelagem OO, contudo, h uma outra opo de nomeao, que consiste em utilizar nomes para rotular um ou mais papis, indicando a responsabilidade dos objetos na associao. Alm disso, s devemos nomear uma associao se isto melhora o entendimento que temos sobre o modelo. Tomemos o exemplo da figura 5.6. Em uma empresa, um empregado est lotado em um departamento e, opcionalmente, pode chefi-lo. Um departamento, por sua vez, pode ter vrios empregados nele lotados, mas apenas um chefe. Sem nomear estas associaes, o modelo fica confuso. Rotulando os papis, o modelo torna-se muito mais claro. Na figura 5.6, um departamento exerce o papel de departamento de lotao do empregado e, neste caso, um empregado tem um e somente um departamento de lotao. No outro relacionamento, um empregado exerce o papel de chefe e, portanto, um departamento possui um e somente um chefe. A figura 5.7 ilustra de forma genrica a maneira de se nomear papis em uma associao.
64

1..*

1 1 0..1

+departamentoLotao

Empregado

Departamento

+chefe

Figura 5.6 - Nomeando Associaes.

Papel B

A
Papel A

Figura 5.7 Objetos da Classe A exercem o Papel A na associao e vice-versa. Alguns tipos de relacionamentos merecem uma discusso adicional: os relacionamentos muitos-para muitos, os relacionamentos recursivos e os relacionamentos nrios. Relacionamentos muitos-para-muitos ou N:N Relacionamentos N:N so perfeitamente legais em um modelo orientado a objetos, como mostra o exemplo da figura 5.8. Entretanto, precisamente neste tipo de relacionamento onde mais provavelmente surgem ocorrncias e eventos que precisam ser registrados e lembrados. Neste caso, uma classe do tipo evento-lembrado deve ser modelada, no porque esta classe deve mapear um relacionamento N:N, mas porque registrar este evento ou ocorrncia um requisito do sistema. O exemplo da figura 5.9 ilustra uma situao deste tipo.

Disciplina
* pr-requisito

Figura 5.8 - Auto-Relacionamento N:N.

65

Empregado

Projeto

data-incio e data-fim de alocao do empregado ao projeto

?
Empregado

Alocao dataIncio dataFim

Projeto

Figura 5.9: Uma Classe do Tipo Evento-Lembrado. No exemplo da figura 5.9, poderamos considerar Alocao como sendo uma classe de associao. Uma classe de associao pode ser vista como uma associao que tem propriedades de classe, isto , atributos, operaes e/ou relacionamentos. A figura 5.10 mostra este mesmo exemplo, sendo modelado como uma classe de associao, segundo a notao da UML.
Empregado

Projeto

Alocao dataIncio dataFim

Figura 5.10 Exemplo de Classe de Associao. Relacionamentos Recursivos (ou Associaes Unrias) Podem ocorrer associaes entre objetos de uma mesma classe. Todas as consideraes feitas para relacionamentos de maneira geral so tambm vlidas para estes casos. A figura 5.8 ilustra um relacionamento deste tipo. Mltiplos Relacionamentos entre Objetos das Mesmas Classes s vezes, necessrio mais de um relacionamento entre objetos de duas classes. Nestes casos, torna-se imprescindvel nomear os relacionamentos, como no exemplo da figura 5.6. Associaes n-rias So associaes entre trs ou mais classes. Associaes ternrias ou superiores so mostradas como losangos conectados s classes atravs de linhas, como mostra a figura 5.11. Um smbolo de classe de associao pode ser anexado ao losango por uma linha tracejada [Furlan98].

66

ABC Figura 5.11 Relacionamento Ternrio.

5.4.2 - Agregao
Uma agregao uma forma especial de associao utilizada para mostrar que um tipo de objeto composto, pelo menos em parte, de outro em uma relao todo/parte [Furlan98]. Um carro, por exemplo, tem um motor e rodas como suas partes. Entretanto, muitas vezes difcil perceber a diferena entre uma agregao e um relacionamento comum. De fato, no h uma definio nica aceita por todos os mtodos do que seja a diferena entre agregao e relacionamento. Ainda assim, a UML apresenta notaes para agregao, como mostra a figura 5.12. importante realar que, uma vez que uma agregao , na verdade, um tipo de relacionamento, cardinalidades devem ser indicadas. Ao se utilizar a notao de agregao, espera-se que as partes vivam e morram com o todo, isto , na criao do objeto-todo, os objetos-parte so criados e a remoo do objetotodo deve ser aplicada em cascata s suas partes. Esta remoo em cascata freqentemente considerada como sendo uma caracterstica da definio de agregao, contudo, ela imposta por qualquer papel cuja cardinalidade 1..1. Contudo, na agregao, os objetos-parte no podem ser destrudos por outro objeto a no ser pelo objeto-todo que os criou. Esta condio no obrigatria para objetos em uma associao comum. Todo Agregao Todo 1 Composio

Parte

Parte

Figura 5.12 - Notaes da UML para Agregao e Composio. A UML oferece ainda notaes para alguns tipos de agregao, chamadas de composio. Ao utilizar uma composio, est-se afirmando que o objeto-parte pode pertencer a apenas um todo.

67

5.4.3 - Definio de Atributos

Um atributo um dado (informao de estado) para o qual cada objeto em uma classe tem o seu prprio valor. Os atributos adicionam detalhes s abstraes e so apresentados na parte central do smbolo de classe. Atributos so muito similares a associaes. De fato, conceitualmente, no h diferena entre atributos e associaes. Podemos dizer que atributos representam associaes entre as classes do domnio do problema e classes bsicas, tais como strings, datas, inteiros e reais. Exatamente por estas classes serem bsicas e ocorrerem em quase todos os domnios de problemas, elas no so representadas e, portanto, atributos so descritos como uma informao de um determinado tipo. A estratgia para a definio de atributos envolve: Descoberta de atributos Posicionamento dos atributos em uma hierarquia de classes Reviso da hierarquia de classes Especificao dos Atributos

bom realar que, com o tempo, as classes do domnio de problemas permanecem relativamente estveis, enquanto os atributos provavelmente se alteram. Atributos so bastante volteis, em funo das responsabilidades do sistema. Descoberta de Atributos A AOO no prov nenhuma tcnica mgica para se descobrir os atributos que um objeto requer para realizar seus objetivos. A tarefa essencialmente a mesma usada em qualquer forma de anlise de sistemas: estudo do domnio da aplicao, entrevistas com o usurio, etc. Cada atributo deve capturar um conceito atmico4 que ajude a descrever um objeto e que seja de responsabilidade do sistema. Um atributo representa uma informao de estado de um objeto que precisa ser lembrada. Uma vez que, conceitualmente, atributos e associaes so a mesma coisa, no devemos incluir na lista de atributos de uma classe, atributos representando associaes. Estas j tm sua presena indicada pela linha que conecta as classes que se relacionam. Posicionamento de Atributos Cada atributo deve ser colocado na classe mais adequada. Para classes em uma hierarquia de generalizao-especializao, atributos genricos devem ser posicionados no topo da estrutura, de modo a serem aplicveis a cada uma das especializaes. Em outras palavras, se um atributo aplicvel a um nvel inteiro de especializaes, ento ele deve ser posicionado na generalizao correspondente. Por outro lado, se algumas vezes um atributo tiver um valor significativo, mas em outras ele no for aplicvel, deve-se rever o posicionamento do atributo ou a estratgia da estrutura de generalizao-especializao adotada. Esta estratgia vlida tambm para operaes.

um nico valor ou um agrupamento de valores fortemente relacionados 68

Reviso da Hierarquia de Classes Inevitavelmente, o processo detalhado de designar atributos a classes conduz a um entendimento mais completo do que era possvel em estgios anteriores do desenvolvimento. Assim, devemos esperar que algumas revises de definies de classes e suas hierarquias resultem deste passo. Especificao de Atributos Um aspecto bastante importante na especificao de atributos a escolha de nomes. Deve-se procurar utilizar o vocabulrio padronizado para o domnio do problema, usando nomes legveis e abrangentes. A especificao de atributos deve incluir unidade de medida, intervalo, limite, enumerao, preciso, valor default e obrigatoriedade, entre outros. Caso valha a pena, em termos de custo-benefcio, pode ser importante adicionar uma descrio breve para cada atributo. A notao da UML para atributos a seguinte: visibilidade nome: tipo = valorDefault, onde visibilidade um dos seguintes smbolos: + , pblico, isto , o atributo pode ser acessado por qualquer classe cliente; # , protegido, isto , o atributo s passvel de acesso pela prpria classe ou por uma de suas especializaes; e - , privado, isto , o atributo s pode ser acessado pela prpria classe. O nome do atributo uma seqncia de caracteres de identificao, comeando tipicamente, com letra minscula. Concatena-se as demais palavras que compem o nome, preservando-se a primeira letra de cada palavra em maiscula [Furlan98], por exemplo, limiteDeCrdito. Pode-se tambm desprezar preposies. Assim, o exemplo anterior assumiria a seguinte forma: limiteCrdito.

5.5 - Determinao do Comportamento

Os Diagramas de Classes, gerados pelas atividades anteriormente descritas, representam apenas os elementos estticos de um modelo de anlise OO. preciso analisar, ainda, o comportamento dinmico da aplicao. Para tal, devemos representar o comportamento do sistema como uma funo do tempo e de eventos especficos. Um modelo de comportamento indica como o sistema ir responder a eventos ou estmulos externos e auxilia o processo de descoberta das operaes das classes do sistema. Para apoiar a modelagem do comportamento do sistema, a UML oferece duas ferramentas: Diagramas de Estados: descrevem todos os estados possveis pelos quais um particular objeto pode passar e suas transies, como resultados de estmulos (eventos) que atingem o objeto; Diagramas de Interao: so modelos que descrevem como grupos de objetos colaboram em um certo comportamento.
69

5.5.1 - Diagramas de Transio de Estados

Diagramas de Estados so uma tcnica j bastante familiar para descrever o comportamento de um sistema. No entanto, no contexto do desenvolvimento OO, diagramas de transio de estados tm um carter bastante peculiar: cada diagrama construdo para uma nica classe, com o objetivo de mostrar o comportamento ao longo do tempo de vida de um objeto. Diagramas de Estado descrevem todos os possveis estados pelos quais um objeto pode passar e as alteraes dos estados como resultado de eventos (estmulos) que atingem o objeto [Furlan98]. A figura 5.13 mostra a notao bsica da UML para diagramas de estado. Estado Inicial
Evento [Condio] / Ao

Estado-1 Estado-2 faa: atividade-A1

Estado Final

Figura 5.13 - Notao Bsica da UML para Diagramas de Estados. Estados so representados por retngulos com os cantos arredondados e transies por setas, sendo que ambos podem ser rotulados. O rtulo de um estado pode conter, alm de seu nome, uma indicao de que o estado possui uma atividade associada a ele, cuja sintaxe :
faa: atividade

O rtulo de uma transio pode ter at trs partes, todas elas opcionais:
Evento [condio] / ao

Basicamente a semntica de um diagrama de estados a seguinte: quando um evento ocorre, se a condio verdadeira, a transio ocorre e a ao realizada. O objeto passa, ento, para um novo estado. Se neste estado, uma atividade deve ser realizada, ela iniciada. O fato de uma transio no possuir um evento associado, indica que a transio ocorrer to logo a atividade associada ao dado estado tiver sido concluda, desde que a condio seja verdadeira. Quando uma transio no possuir uma condio associada, ento ela ocorrer sempre quando o evento ocorrer. Embora ambos os termos ao e atividade denotem processos, tipicamente implementados por mtodos da classe, eles no devem ser confundidos. Aes so associadas a transies e so consideradas processos instantneos, isto , ocorrem muito rapidamente, no sendo passveis de interrupo. Atividades so associadas a estados, podendo durar bastante tempo. Assim, uma atividade pode ser interrompida por algum evento.

5.5.2 - Diagramas de Interao

Uma das coisas mais difceis de compreender e capturar em um sistema orientado a objetos o fluxo global de controle. Diagramas de interao tm por objetivo ajudar a visualizar esta seqncia.
70

Tipicamente, um diagrama de interao captura o comportamento de um grupo de objetos em um caso de uso isolado, mostrando um nmero de objetos-exemplos e as mensagens que so passadas entre esses objetos no contexto do caso de uso [Furlan98]. H dois tipos de diagramas de interao: diagramas de seqncia e diagramas de colaboraes. Diagramas de Seqncia Em um diagrama de seqncia, um objeto mostrado como um retngulo com uma linha vertical pontilhada anexada. Esta linha chamada de linha de vida do objeto e representa a vida do objeto durante a interao. Cada mensagem representada por uma seta cheia entre as linhas de vida de dois objetos. A ordem na qual as mensagens ocorrem mostrada do alto para o p da pgina. Cada mensagem rotulada com pelo menos o nome da mensagem. Adicionalmente, pode incluir tambm seus argumentos e alguma informao de controle. Informaes de controle podem ser uma condio ([condio = verdadeira]), indicando que a mensagem s enviada se a condio for verdadeira, e um marcador de iterao (*), denotando que a mensagem enviada vrias vezes para mltiplos objetos receptores, como no caso de uma iterao sobre uma coleo de objetos. O diagrama inclui ainda, um retorno, indicando o retorno de uma mensagem e no uma nova mensagem. Para diferenciar retornos so simbolizados por uma seta no slida. A figura 5.14 sumariza a notao bsica da UML para diagramas de seqncia.
: Classe 1 : Ator Texto descrevendo o que est acontecendo. mensagem msg1 : Classe 2 Objeto Nomeado : Classe 2

[condio] * msg2

Figura 5.14 - Notao da UML para Diagramas de Seqncia. Uma tcnica bastante til para facilitar o entendimento de um diagrama de seqncia consiste em inserir descries textuais do que est acontecendo ao longo do lado esquerdo do diagrama de seqncia. Isto envolve a redao de um bloco de texto alinhado com a mensagem apropriada no diagrama.

71

Diagramas de Colaboraes Um diagrama de colaboraes tem o mesmo propsito que um diagrama de seqncia e, portanto, ambos so similares, ou seja, trabalham com as mesmas abstraes (objetosexemplos, mensagens e seqncias). Em um diagrama de colaboraes, os objetos-exemplos so mostrados como cones e mensagens como setas. A seqncia, por sua vez, indicada por uma numerao das mensagens. A figura 5.15 mostra a notao bsica da UML para diagramas de colaboraes. : Nome_classe_1 1: [condio] *msg() : Nome_classe_2 Figura 5.15 - Notao Bsica da UML para Diagramas de Colaboraes. A numerao de mensagens torna a visualizao da seqncia mais difcil do que nos diagramas de seqncia. Entretanto, este layout permite mostrar mais facilmente outras coisas. A UML adota um esquema de numerao decimal (1, 1.1, 1.1.1, 2, ...) com o objetivo de tornar mais claro que operao est chamando que outras operaes, embora possa ser difcil ver a seqncia global. Tanto diagramas de seqncia quanto diagramas de colaboraes no so muito apropriados para representar processos com muito comportamento condicional e repetitivo. Para estes casos, ainda que seja possvel utilizar condies e marcadores de iteraes, melhor utilizar diagramas separados para cada cenrio. Deve-se ressaltar, ainda, que os diagramas de interao so bons para mostrar colaboraes entre objetos em um caso de uso. Para observar o comportamento de um objeto isolado ao longo de vrios casos de uso, deve-se utilizar um diagrama de transio de estados.

5.6 - Definio das Operaes

Uma vez estudado o comportamento do sistema, tem-se uma base para a definio das operaes das classes que compem o sistema. Na notao da UML, operaes so apresentadas na seo inferior do smbolo de classe, com a seguinte sintaxe:
visibilidade nome(lista_de_parmetros): tipo_de_retorno

onde a visibilidade tem a mesma sintaxe e semntica definida para atributos. Normalmente, operaes que simplesmente manipulam representadas, j que podemos deduzir que elas existem, tais como: atributos no so

Operaes que obtm valores de atributos: apenas retornam um valor de um atributo e no fazem mais nada; Operaes que colocam valores em atributos: apenas colocam um valor em um atributo e no fazem mais nada.

72

Alm dessas, operaes para criar uma nova instncia da classe, selecionar e eliminar uma instncia da classe tambm no so normalmente mostradas no diagrama de classes. Entretanto, afora os sistemas muito simples, outras operaes devem ser capturadas, entre elas: operaes associados s mensagens nos diagramas de interao; operaes associadas aos relacionamentos entre objetos nos diagramas de classes, isto , operaes para associar e desassociar instncias especficas que se relacionam. Em outras palavras, so as operaes que permitem que um relacionamento seja estabelecido ou desfeito; operaes sugeridas pelos diagramas de estados.

Especificao das Operaes Finalmente, as operaes podem ser descritas, detalhando-se o comportamento das classes. Cada operao pode dar origem a um ou mais mtodos a serem executados quando uma mensagem for recebida. Se os objetos tiverem sido bem definidos, ento cada mtodo ser pequeno e altamente coeso. Assim, possvel descrever uma operao compactamente em alguma notao semi-formal, como um portugus-estruturado. Um Recurso Adicional - Contratos Um recurso muito til, empregado pelo mtodo CRC [Wirfs-Brock90] a definio de contratos. Um contrato define um conjunto de requisies que um cliente pode fazer a um servidor, com a garantia de que o servidor capaz de respond-las. Agrupar funcionalidades em contratos auxilia o entendimento de um modelo e estabelece claramente as responsabilidades de uma classe. Uma classe pode suportar vrios contratos, apesar de ser bastante comum encontrar classes que suportam apenas um nico contrato. Cada responsabilidade5 de uma classe pode ser parte de um contrato, mas nem todas responsabilidades o so. Algumas responsabilidades representam um comportamento que a classe deve apresentar mas que no pode ser requisitado por objetos de outras classes. Tais responsabilidades so ditas responsabilidades privadas. As seguintes diretrizes ajudam a determinar que responsabilidades pertencem a que contratos: Agrupe funcionalidades usadas pelos mesmos clientes. Um contrato representa um conjunto coeso de responsabilidades. Uma maneira de encontrar responsabilidades coesas procurar por funcionalidades que sero utilizadas sempre pelos mesmos clientes. Maximize a coeso das classes. Assim como um contrato deve ser composto de um conjunto coeso de responsabilidades, uma classe deve suportar um conjunto coeso de

Responsabilidades incluem tanto a informao mantida pelas instncias da classe (estado dos objetos) quanto as aes que essas instncias podem executar (comportamento dos objetos) [Wirfs-Brock90]. 73

contratos. Maximizar a coeso tende a minimizar o nmero de contratos suportados por uma classe. Minimize o nmero de contratos. Sem violar o princpio de coeso dos contratos, a melhor maneira de reduzir o nmero de contratos procurar por funcionalidades similares que possam ser generalizadas, permitindo, assim, que essas, e os contratos dos quais elas so partes, possam ser movidos para pontos mais altos na hierarquia de classes. Deste modo, um contrato pode ser definido somente em uma classe, a superclasse, e as vrias classes que o suportam podem herd-lo da superclasse.

Uma estratgia simples para a definio de contratos, comea pela definio dos contratos das classes localizadas no topo de suas hierarquias. Novos contratos s precisam ser definidos para as subclasses que adicionam nova funcionalidade, a ser usada por outros clientes. Assim, deve-se examinar as responsabilidades adicionadas por cada uma das subclasses, avaliando se elas representam nova funcionalidade ou se apenas definem maneiras mais especficas de expressar responsabilidades herdadas, caso em que j so parte do contrato herdado. Referncias Bibliogrficas [Booch94] [Coad92] [Coad93] [Furlan98] [Jacobson92] [Pressman00] [Rumbaugh94] G. Booch; Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin/Cummings Publishing Company, Inc, 1994. P. Coad, E. Yourdon; Anlise Baseada em Objetos, Editora Campus, 1992. P. Coad, E. Yourdon; Projeto Baseado em Objetos, Editora Campus, 1993. J.D. Furlan; Modelagem de Objetos Atravs da UML; Makron Books, 1998. I. Jacobson; Object-Oriented Software Engineering, Addison-Wesley, 1992. R.S. Pressman; Software Engineering: A Practitioners Approach, 5th Edition, Mc Graw Hill, 2000. J. Rumbaugh, et alli; Modelagem e Projetos Baseados em Objetos, Editora Campus, 1994.

[Wirfs-Brock90] R. Wirfs-Brock, B. Wilkerson, L. Wiener; Designing Object-Oriented Software, Prentice Hall, 1990. [Yourdon94] E. Yourdon; Object-Oriented Systems Design: an Integrated Approach, Yourdon Press Computing Series, Prentice Hall, 1994.

74

PARTE III ANLISE ESSENCIAL DE SISTEMAS

75

6. Introduo Anlise Essencial

A etapa de anlise e especificao de requisitos, geralmente chamada de anlise de sistemas, um processo de comunicao entre engenheiros de software (analistas de sistemas) e clientes/usurios do sistema, com o objetivo de definir detalhadamente o propsito e os requisitos de um software. Os requisitos de um sistema compreendem o conjunto de caractersticas que o sistema deve possuir para atingir seu propsito. A anlise de sistemas um processo de transmisso de conhecimento e, assim sendo, envolve trs etapas: aprendizado: aprender sobre o domnio do problema onde o sistema ser inserido; estruturao e representao dos requisitos do sistema: consiste na modelagem do sistema propriamente dita; validao dos requisitos com o usurio. Ao longo do processo, o analista enfrenta o desafio de lidar com a complexidade, isto , situaes complexas do mundo real devem ser entendidas e representadas de forma simples, para facilitar a compreenso e validao. Para tal, preciso delimitar a rea de estudo, subdividir o todo complexo em partes inteligveis e gerenciveis, extrair as caractersticas essenciais da realidade e modelar essas caractersticas para mostrar o relacionamento entre seus componentes. A anlise de sistemas , em ltima instncia, uma atividade de construo de modelos. Um modelo uma representao de alguma coisa do mundo real, uma abstrao da realidade, ou seja, representa uma seleo de caractersticas do mundo real, que so relevantes para o propsito com o qual o modelo foi construdo. Modelos so ferramentas fundamentais no desenvolvimento de sistemas. Sistemas so modelados para: possibilitar o estudo do comportamento do sistema; facilitar a comunicao entre os componentes da equipe de desenvolvimento (e clientes e usurios); possibilitar a discusso de correes e modificaes com o usurio; formar uma documentao do sistema. Um modelo enfatiza um conjunto de caractersticas da realidade, que corresponde dimenso do modelo. Alm da dimenso que um modelo enfatiza, modelos possuem nveis de abstrao. O nvel de abstrao de um modelo diz respeito ao grau de detalhamento com que as caractersticas do sistema so representadas. Em cada nvel h uma nfase seletiva nos detalhes representados. No caso dos sistemas de informao, geralmente, so considerados trs nveis: conceitual: considera caractersticas do sistema independentes do ambiente computacional (hardware e software) no qual o sistema ser implementado. Essas caractersticas so dependentes unicamente das necessidades do usurio. lgico: caractersticas dependentes de um determinado tipo de sistema computacional. Essas caractersticas so, contudo, independentes de produtos especficos.
76

fsico: caractersticas dependentes de um sistema computacional especfico, isto , uma linguagem e um compilador especfico, um sistema gerenciador de bancos de dados especfico, o hardware de um determinado fabricante, etc. Nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e anlise), o engenheiro de software representa o sistema atravs de modelos conceituais. Nas etapas posteriores, as caractersticas lgicas e fsicas so representadas em novos modelos. O mtodo de Anlise Essencial de Sistemas [Pompilho95] preconiza que, de uma forma geral, um sistema deve ser modelado atravs de trs dimenses: dados: diz respeito aos aspectos estticos e estruturais do sistema; controle: leva em conta aspectos temporais e comportamentais do sistema; funes: considera a transformao de valores. Em relao ao grau de abstrao, a Anlise Essencial considera dois nveis: o nvel essencial e o nvel de implementao, representados, respectivamente, pelos seguintes modelos: Modelo Essencial: representa o sistema num grau de abstrao completamente independente de restries tecnolgicas. Modelo de Implementao: passa a considerar as restries tecnolgicas impostas pela plataforma de hardware e software a ser utilizada para implementar o sistema. Podemos perceber que o modelo de implementao no corresponde a um modelo de anlise propriamente dito, uma vez que considera aspectos de implementao, caracterstica marcante da fase de projeto. De fato, na abordagem da Anlise Essencial, este modelo corresponde a uma espcie de zona nebulosa entre as fases de anlise e de projeto. Por considerarmos que um modelo considerando aspectos da plataforma de implementao melhor caracterizado na fase de projeto, neste texto, no trataremos do modelo de implementao.

6.1 - Conceitos
Os conceitos introduzidos pelo mtodo de Anlise Essencial endereavam inicialmente as duas principais dificuldades que os analistas enfrentavam com a aplicao da Anlise Estruturada: a distino entre requisitos lgicos e fsicos, e a ausncia de uma abordagem para particionar o sistema em partes to independentes quanto possvel, de modo a facilitar o processo de anlise. Durante muito tempo, houve grandes debates entre os profissionais de desenvolvimento de sistemas sobre por qual perspectiva se deveria comear a especificao de um sistema: pelos dados ou pelas funes? Os argumentos, igualmente vlidos, exploravam consideraes como: dados so mais estveis que funes..., sem um entendimento das funes a serem desempenhadas pelo sistema, como definir o escopo e os dados necessrios? A Anlise Essencial procurou estabelecer um novo ponto de partida para a especificao de um sistema: a identificao dos eventos que o afetam [Pompilho95].
77

Um dos problemas mais relevantes na especificao como efetuar seu particionamento. A Anlise Estruturada prope um particionamento atravs de uma abordagem top-down. Embora esta seja uma boa maneira de se atacar um problema complexo comeando da viso geral e ir descendo, passo a passo, numa viso hierrquica, a nveis de detalhes cada vez maiores na prtica, esta abordagem no se mostrou eficiente como estratgia de projeto para a decomposio de sistemas. A Anlise Essencial prope uma outra forma de particionamento, a qual baseada nos eventos, e que tem demonstrado ser mais efetiva do que a abordagem top-down, pois torna mais fcil a identificao das funes e entidades que compem o sistema [Pompilho95]. A Anlise Essencial de Sistemas, atravs da tcnica de particionamento por eventos, oferece uma boa estratgia para modelar o comportamento do sistema, visando satisfazer os requisitos do usurio, pressupondo-se que dispomos de tecnologia perfeita e que ela pode ser obtida a custo zero [Xavier95]. Apesar de introduzir novos conceitos e novas abordagens, a Anlise Essencial preservou todos os modelos da Anlise Estruturada. De fato, embora diferentes, a melhor maneira de encarar a Anlise Essencial consider-la uma evoluo da Anlise Estruturada. A seguir, os principais conceitos da Anlise Essencial [McMenamim84] so apresentados. Tecnologia Perfeita Durante a fase de anlise, o analista deve abstrair-se da tecnologia que dever ser utilizada na implementao do sistema. Para orientar essa abstrao, a Anlise Estruturada recomenda que o analista, durante a fase de anlise, concentre-se apenas nos aspectos lgicos do sistema, evitando pensar nos aspectos fsicos. O problema dessa abordagem que a diferena entre aspectos lgicos e fsicos no clara. Partindo do princpio que os aspectos fsicos de um sistema esto ligados tecnologia de implementao, a Anlise Essencial emprega uma abstrao de uma tecnologia de implementao, denominada tecnologia perfeita, para facilitar a tarefa de identificar os detalhes lgicos do sistema. A tecnologia perfeita no possui limitaes, isto , existe um processador perfeito, capaz de executar qualquer processamento, tudo instantaneamente, sem qualquer custo, sem consumir energia, sem gerar calor, sem jamais cometer erros ou parar de funcionar, e um repositrio perfeito, capaz de armazenar quantidades infinitas de dados e de ser acessado instantaneamente por qualquer processador, da forma que for mais conveniente. Naturalmente, no existe uma tecnologia de implementao com tais caractersticas. Ento, qual a utilidade dessa abstrao? Quando o analista pensa em aspectos fsicos, ele est, na verdade, tentando identificar (e resolver) as limitaes de uma determinada tecnologia. Pensamentos tpicos do gnero so: quanto de espao em disco vou precisar? qual o melhor mtodo de acesso aos dados, considerando as funes do sistema? que capacidade de processamento devo necessitar? Contudo, nenhuma dessas preocupaes so prprias da fase de anlise. Considerando agora que a tecnologia que ser utilizada na implementao do sistema perfeita, todas as perguntas anteriores deixam de ter importncia, isto , no preocupam mais o analista. Assim sendo, para distinguir um requisito lgico de um requisito fsico, utilizando a abstrao de tecnologia perfeita, formule a seguinte pergunta ao identificar um requisito qualquer: Para atender ao seu propsito, o sistema necessitar possuir essa capacidade ou essa caracterstica, mesmo considerando que ele ser implementado em uma tecnologia perfeita? Se a resposta for sim, esse requisito verdadeiro e deve ser modelado.
78

Requisito Verdadeiro e Requisito Falso Uma caracterstica ou capacidade que um sistema deve possuir para atender ao seu propsito, mesmo considerando que ser implementado em uma tecnologia perfeita, dita um requisito verdadeiro. O conjunto de requisitos verdadeiros compreende a essncia do sistema. Um requisito falso, por outro lado, uma capacidade ou caracterstica que o sistema no precisa possuir para atender ao seu propsito, caso ele disponha de uma tecnologia de implementao perfeita. Evento e Resposta Evento e resposta so nomes genricos de interaes entre o ambiente externo e o sistema. Um evento pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema uma resposta. Corresponde a alguma mudana no ambiente externo que funcionar como um estmulo para o sistema, isto , o sistema deve responder a este estmulo para atender ao seu propsito. Uma resposta o resultado da execuo de um conjunto de aes no sistema, como conseqncia do reconhecimento pelo sistema de que um evento ocorreu. Uma resposta tipicamente pode ser [Pompilho95]: um fluxo de dados saindo do sistema para uma entidade externa; uma mudana de estado em um depsito de dados (incluso, excluso ou alterao); um fluxo de controle saindo de uma funo para ativar uma outra. Quando um evento ocorre, produzido um estmulo para o sistema. Ao receber o estmulo, o sistema compreende que o evento ocorreu e ativa os processos necessrios para produzir a resposta. Os eventos so classificados em quatro tipos diferentes, dependendo da maneira como ocorrem e da natureza do estmulo que produzem [Pompilho95]: Evento orientado por fluxo de dados: provocado por uma entidade externa, a qual envia dados para o sistema. O estmulo produzido por esse tipo de evento a chegada de um fluxo de dados que vai ativar uma funo. Os eventos externos so nomeados da seguinte forma: (Entidade externa que provocou o evento) + (ao verbo na voz ativa) + (estmulo fluxo de dados enviado ao sistema) Ex.: Cliente envia pedido. Cliente cancela pedido. Evento orientado por controle: o estmulo provocado por este evento a chegada ao sistema de um fluxo de controle, o qual apenas notifica o sistema da ocorrncia do evento. Pode haver fluxos de dados complementares associados ao evento, mas no atravs da chegada do fluxo de dados que o sistema toma conhecimento da ocorrncia do evento. Esse tipo de evento pode ser nomeado de duas maneiras, tendo por base a origem do evento:
79

Caso 1 Uma entidade externa envia um comando (fluxo de controle) para o interior do sistema, ativando uma funo. (Entidade externa que provocou o evento) + (ao verbo na voz ativa) + (complemento) Ex.: Gerente solicita relao de clientes. Diretoria autoriza o pagamento de uma fatura. Caso 2 Uma funo ativada por um fluxo de controle oriundo de outra funo interna. (Sujeito) + (ao verbo na voz passiva) Ex.: Nvel de reabastecimento do estoque de um produto atingido. Evento temporal: aquele em que o estmulo a chegada ao sistema da informao de haver passado um determinado intervalo de tempo. Esses eventos estimulam as aes que o sistema tem de executar em datas previamente conhecidas, isto , diariamente, mensalmente, etc (o tempo passa e chega o momento do sistema fazer alguma coisa). Pode haver fluxos de dados complementares associados ao evento, mas no atravs da chegada destes que o sistema toma conhecimento da ocorrncia do evento. Os eventos temporais podem ser nomeados como abaixo: ( hora de) + (ao) + (complemento) Ex.: Mensalmente, emitir relatrio de vendas. ou hora de emitir relatrio mensal de vendas. Atividades Essenciais So todas as tarefas que o sistema deve executar para atender completamente ao seu propsito, mesmo considerando que ele ser implementado em uma tecnologia perfeita. Uma atividade essencial deve executar todo o conjunto de aes necessrias para responder completamente a um e somente um evento. As atividades essenciais subdividem-se em: Atividades Fundamentais: produzem uma informao que parte do propsito declarado do sistema. Assim sendo, o propsito do sistema atendido pelas atividades fundamentais, as quais produzem as respostas externas do sistema. Atividades Custodiais: criam e mantm a memria necessria execuo das atividades fundamentais, adquirindo dados do ambiente externo ao sistema e os armazenando nos depsitos de dados. As respostas que so internas ao sistema so produzidas pelas suas atividades custodiais. Quando uma atividade executa tarefas dos dois tipos, ela denominada atividade composta. As atividades compostas produzem respostas internas e externas. Os diferentes tipos de atividade essencial esto representados na figura 6.1.

80

estmulo

Atividade Fundamental

resposta externa

estmulo

Atividade de Custdia resposta interna

estmulo

Atividade Composta

resposta externa

resposta interna Memria

Memria

Memria

Figura 6.1 Tipos de Atividades Essenciais. Como as atividades essenciais respondem completamente a um e somente um evento, a comunicao entre elas ser feita sempre via memria e nunca diretamente. Essa caracterstica da comunicao entre atividades essenciais torna o particionamento por eventos uma abordagem adequada para dividir o problema em partes independentes. Memria Essencial Consiste no conjunto mnimo de dados que deve ser armazenado pelo sistema, para atender ao seu propsito, considerando que ele ser implementado em uma tecnologia perfeita. O modelo normalmente utilizado para modelar a memria essencial o Modelo de Entidades e Relacionamentos (MER). Nos DFDs, a memria essencial representada pelos depsitos de dados. Para derivar os depsitos de dados do DFD a partir do MER, utilize a seguinte correspondncia: cada entidade e relacionamento com atributos do MER ser um depsito de dados do DFD. Para manter a abstrao da tecnologia perfeita consistente, os depsitos de dados no armazenam chaves estrangeiras (atributos determinantes transpostos entre entidades) para representar um relacionamento entre entidades, pois essa uma caracterstica especfica dos bancos de dados relacionais, uma tecnologia nada perfeita. Lembre-se que, na fase de anlise, a tecnologia de implementao ainda no foi selecionada e deve ser considerada perfeita. Para indicar que o relacionamento entre entidades existe, sem no entanto definir como ele ser implementado, a representao dos acessos das atividades de custdia memria essencial deve obedecer seguinte regra geral: ao criar ou excluir um relacionamento ou uma entidade que participa de um relacionamento, mostre o acesso aos depsitos de dados que correspondem ao relacionamento e s entidades que participam do relacionamento. A figura 6.2 mostra a representao grfica desses acessos.

81

E1 R

E2

Modelo de Dados

Atividade Essencial

Atividade Essencial

E1

R1

E2

E1

E2

Criar ou excluir uma ocorrncia de R1.

Criar ou excluir uma ocorrncia de R2.

Figura 6.2 Acessos a depsitos de dados.

6.2 - Especificao da Essncia do Sistema (Referncia: Captulo 17 [Pompilho95])

A Anlise Essencial sugere a construo de dois modelos principais, o modelo essencial e o modelo de implementao. Conforme discutido anteriormente, entendemos que apenas o modelo essencial deve ser objeto da fase de anlise e, assim, discutiremos apenas a especificao da essncia do sistema. A especificao da essncia do sistema, produto da fase de anlise, composta de dois modelos, como mostra a figura 6.3: Modelo Ambiental: define a fronteira entre o sistema e o resto do mundo. Modelo Comportamental: define o comportamento das partes internas do sistema necessrio para interagir com o ambiente.

82

Anlise Essencial

Modelo Essencial

Modelo de Implementao

Modelo Ambiental

Modelo Comportamental

Figura 6.3 A Anlise Essencial e seus Modelos. 6.2.1 - O Modelo Ambiental (Referncia: Seo 17.1 [Pompilho95]) Representa o que o sistema deve fazer para atender ao ambiente. composto dos seguintes produtos: Propsito do Sistema: enuncia a finalidade do sistema. Pode ser acompanhado de uma breve descrio do contexto do sistema (mini-mundo). Lista de Eventos: lista de eventos aos quais o sistema deve responder. Deve conter, pelo menos, o nome do evento, o estmulo e a resposta externa do sistema. Diagrama de Contexto: representa o sistema como um nico processo e suas interaes com o ambiente. Pode ser acompanhado de um dicionrio de dados. A declarao de propsito (objetivos) do sistema deve ser elaborada em poucas frases, simples e precisas, em linguagem destituda de vocabulrio tcnico, de modo a ser entendida pelos usurios do sistema e pela administrao da empresa, em geral. No deve fornecer detalhes sobre como o sistema dever operar. A elaborao da lista de eventos o passo principal desta etapa do desenvolvimento, uma vez que os eventos constituem a parte fundamental de um sistema. De fato, o primeiro passo na especificao de um sistema identificar a quais eventos do mundo exterior ele dever ocorrer. Esta atividade, denominada Anlise de Eventos, muito bem explorada no Captulo 15 de [Pompilho95]. Uma vez definidos os eventos, possvel construir o Diagrama de Contexto do sistema, mostrando como ele responde a todos os eventos externos relevantes. Finalmente, pode ser til elaborar uma descrio de como o sistema responder a cada um dos eventos identificados na Lista de Eventos.

83

6.2.2 O Modelo Comportamental (Referncia: Seo 17.2 [Pompilho95]) Representa o que o interior do sistema deve fazer para atender ao ambiente. Deve conter os seguintes produtos: Diagrama de Entidades e Relacionamentos Diagramas de Fluxos de Dados Particionados por Eventos: Para cada evento do sistema, deve ser construdo um DFD. Assim, a quantidade de diagramas deve ser equivalente ao nmero de eventos na lista. Diagramas de Transio de Estados: Representa o comportamento das entidades e relacionamentos com atributos ao longo do tempo. Ser construdo um DTE para cada entidade ou relacionamento com atributo do DER que possuir comportamento significativo, isto , possuir mais de um estado ao longo de seu ciclo de vida. Diagramas de Fluxos de Dados Organizados em Nveis Hierrquicos: representa os processos em nveis hierrquicos, a partir do diagrama zero. Os processos do diagrama zero so obtidos atravs do agrupamento de atividades essenciais dos DFDs particionados por eventos. Um critrio de agrupamento bastante razovel considerar o grau de coeso e acoplamento entre atividades essenciais. As seguintes heursticas podem ser utilizadas, em conjunto ou em separado: Procurar agrupar em um nico processo todas as atividades essenciais que acessam um determinado depsito de dados, verificando se o processo resultante desse agrupamento adequado para representar uma das funes do sistema. Agrupar todas as atividades de custdia referentes a um mesmo depsito de dados. Procurar identificar uma funo do sistema, agrupando atividades essenciais que interagem com uma mesma entidade externa. Representar no DFD-zero, um processo para cada uma das funes do negcio. Agrupar as atividades essenciais aos processo para os quais as suas aes mais contribuem. Usando esta abordagem para a construo de diagramas hierrquicos, adotamos uma estratgia middle-out (do meio para fora), onde, a partir dos eventos, estabelecemos atividades essenciais (meio) para depois agrup-las em nveis superiores (para cima) e, em seguida, especific-las e, se necessrio, explodi-las (para baixo). Dicionrio de Dados: descreve os dados representados no MER, nos DFDs e nos DTEs. Especificao da Lgica dos Processos: descreve a lgica dos processos do DFD que no foram detalhados em diagramas de nvel inferior (lgica dos processos primitivos). Como podemos perceber, a Anlise Essencial faz uso praticamente das mesmas tcnicas de modelagem da Anlise Estruturada, a saber a Modelagem de Dados (utilizando modelos de Entidades e Relacionamentos), a Modelagem Funcional (utilizando Diagramas de
84

Fluxo de Dados DFDs) e a Modelagem de Controle (utilizando Diagramas de Transio de Estados). Isso bastante natural, j que a Anlise Essencial , de fato, uma extenso da Anlise Estruturada. Na realidade, a principal diferena entre a Anlise Essencial e a Anlise Estruturada est na estratgia para atacar o problema: a primeira defende uma abordagem baseada em eventos, onde a Anlise de Eventos passa a ser um passo fundamental, a segunda baseada apenas na decomposio top-down da funcionalidade do sistema. A figura 6.4 apresenta de forma sinttica a organizao do modelo essencial.
Lista de Eventos

Modelo Ambiental

Diagrama de Contexto Declarao de Objetivos

Modelo Essencial Diagramas de Fluxo de Dados Diagrama de Entidades e Relacionamentos MiniEspecificaes Diagrama de Transies de Estados

D I C I O N R I O D E D A D O S

Modelo Comportamental

Figura 6.4 Organizao do Modelo Essencial. Referncias Bibliogrficas [McMenamim84] S.M. McMenamim, J.F. Palmer. Anlise Essencial de Sistemas. McGrawHill, So Paulo, 1984. [Pompilho95] [Xavier95] [Yourdon90] S. Pompilho. Anlise Essencial: Guia Prtico de Anlise de Sistemas. IBPI Press, Editora Infobook, Rio de Janeiro, 1995. C.M.S. Xavier, C. Portilho. Projetando com Qualidade a Tecnologia de Sistemas de Informao. Livros Tcnicos e Cientficos Editora, 1995. E. Yourdon. Anlise Estruturada Moderna. Editora Campus, 1990.
85

7. Modelagem de Dados
A primeira atividade realizada no processo de construo do Modelo Comportamental da Anlise Essencial de Sistemas deve ser a modelagem de dados e, para tal, o modelo de Entidades e Relacionamentos (ER) utilizado. O modelo ER uma tcnica top-down de modelagem conceitual, utilizada para representar os dados a serem armazenados em um sistema de informao, tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos de dados [Chen90] [Setzer87]. Basicamente, o modelo ER representa as entidades (coisas) e os relacionamentos (fatos) do mundo real, que um sistema de informao precisa simular internamente.

7.1 - Conceitos Bsicos

Entidades: so representaes abstratas de coisas do mundo real que temos interesse em monitorar o comportamento. Podem ser a representao de um ser, um objeto, um organismo social, etc. Conjuntos de Entidades: so grupos de entidades que tm caractersticas semelhantes. So representados graficamente por retngulos, como mostra a figura 7.1. Ex: Livros, Clientes, Funcionrios. LIVROS CLIENTES
FUNCIONRIOS

Figura 7.1 Representao Grfica de Conjuntos de Entidades. Os conjuntos de entidades so substantivos e perduram no tempo. Cada elemento de um conjunto de entidades s ocorre uma nica vez e a ordenao do conjunto irrelevante. A princpio so representados em um conjunto de entidades, todos os elementos do mundo real referidos pelo conjunto. Ex: LIVROS = todos os livros de uma biblioteca. FUNCIONRIOS = todos os funcionrios de uma empresa, ... Para descrevermos conjuntos de entidades, podemos utilizar as seguintes diretrizes: critrios para incluso; critrios para excluso; contexto (ilustre como ele utilizado no sistema); exemplos. Se no quisermos utilizar todos as diretrizes apresentadas, devemos optar pela utilizao de descries com base nos critrios para incluso.

86

Para estabelecermos uma padronizao, usaremos nomes de conjuntos de entidades sempre no plural e escritos em letras maisculas. No entanto, isto no representa efetivamente uma regra. Atributos: descrevem caractersticas ou propriedades relevantes de um conjunto de entidades. O conjunto de atributos deve ser: completo: deve abranger todas as informaes pertinentes. fatorado: cada atributo deve capturar um aspecto em separado. independente: os domnios de valores de atributos devem ser independentes uns dos outros. Atributos podem ser de dois tipos: Atributos Descritivos: descrevem caractersticas intrnsecas do objeto. Ex: sexo, altura, nacionalidade, etc ... Atributos Nominativos: nomes e rtulos arbitrrios dados aos objetos. Ex: nome, matrcula, etc ... Sobre atributos so pertinentes ainda as seguintes consideraes: Atributo Monovalorado: atributo que assume um nico valor para cada elemento do conjunto de entidades. Ex: matrcula, nome, data-admisso, ... de FUNCIONRIOS: Cada funcionrio possui uma nica matrcula, um nico nome, etc ... Atributo Multivalorado: atributo que pode assumir vrios valores para cada um dos elementos do conjunto de entidades. So representados com um asterisco (*) associado. Ex: telefone* de FUNCIONRIOS: Um mesmo funcionrio pode ter mais que um telefone. Valor vazio para um atributo: quando para algum ponto do conjunto de entidades no existe um valor para aquele atributo, ou ele ainda no conhecido. Ex: telefone* de FUNCIONRIOS: Um funcionrio qualquer pode no ter nenhum telefone, ou em um dado momento ele no ser conhecido. Atributo Composto: atributo composto de um ou mais sub-atributos. Ex: endereo, composto de rua, nmero, complemento, bairro, cidade, estado e cep. Identificadores ou Atributos Determinantes: conjunto de um ou mais atributos que identificam univocamente um elemento do conjunto de entidades. Os atributos determinantes devero ser sublinhados.

87

Atributos tambm descrevem caractersticas de relacionamentos (atributos de relacionamentos). Todas as consideraes feitas at ento so vlidas, sendo que uma discusso sobre caractersticas tpicas destes atributos foi propositalmente postergada, visando uma melhor compreenso. A figura 7.2 ilustra a representao grfica para atributos. Ainda que esta notao possa ser empregada, de maneira geral, atributos so representados apenas no dicionrio de dados para evitar modelos complexos e de difcil leitura.

FUNCIONRIOS

endereo nome matrcula

telefone *

Figura 7.2 Representao grfica para atributos. Relacionamento: uma abstrao de uma associao entre duas ou mais entidades. Relacionamento Binrio: uma representao abstrata da associao de duas entidades. Conjunto de Relacionamentos: um subconjunto do produto cartesiano dos conjuntos de entidades envolvidos. Ex: O mundo real nos conta que: Funcionrios so lotados em Departamentos. Alunos cursaram Disciplinas. Fornecedores fornecem Materiais. importante notar que todos os relacionamentos binrios possuem uma leitura inversa: Departamentos lotam Funcionrios. Disciplinas foram cursadas por Alunos. Materiais so fornecidos por Fornecedores. Algumas correntes pregam o uso de um nome que abstraia a direo da leitura. Alunos cursaram Disciplinas. Realizaes Fornecedores fornecem Materiais. Fornecimentos Neste texto, entretanto, adotaremos a seguinte notao: Um relacionamento ser representado por um losango com um verbo para indicar a ao e uma seta para informar o sentido de leitura, como mostra a figura 7.3.

88

DEPARTAMENTOS

FUNCIONRIOS lotam

lotam {(d,f) / d DEPARTAMENTOS e f FUNCIONRIOS} Figura 7.3 Representao grfica para relacionamentos. importante frisar que, entre duas entidades, pode existir mais de um tipo de relacionamento, como mostra o exemplo da figura 7.4.

lotam
DEPARTAMENTOS

FUNCIONRIOS

chefiam Figura 7.4 Dois tipos de relacionamentos entre entidades. Alm disso, uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo, inclusive com ela mesma, como mostra a figura 7.5.

DEPARTAMENTOS

PROFESSORES lotam

oferecem

DISCIPLINAS

so pr-requisito para

Figura 7.5 Exemplo de modelo ER.

89

7.2 - Restries de Integridade ou Leis de Consolidao

Restries de integridade (ou leis de consolidao) so restries do mundo real que devem ser expressas para manter a integridade do modelo. Devemos identificar leis que regem: os possveis relacionamentos e os valores dos atributos. 7.2.1 - Restries de Integridade em Relacionamentos Um conjunto de relacionamentos um subconjunto do produto cartesiano das entidades envolvidas. necessrio, portanto, descrever de forma mais apurada qual este subconjunto. Isto feito via Restries de Integridade ou Leis de Consolidao, que devem ser observadas, sendo que elas podem ser de trs tipos: Cardinalidade: indica os nmeros mnimo (cardinalidade mnima) e mximo (cardinalidade mxima) de associaes possveis em um relacionamento. Ex: Um professor tem que estar lotado em um e somente um departamento, enquanto um departamento deve ter no mnimo 13 professores e no mximo um nmero arbitrrio (N). Esta restrio imposta pelo mundo real, deve ser considerada no modelo de dados atravs da cardinalidade, como mostra a figura 7.6.
(1,1) DEPARTAMENTOS (13,N)

PROFESSORES lotam

Figura 7.6 Representao de cardinalidades em relacionamentos. Repetio: indica quantas vezes os mesmos dois elementos de conjuntos de entidades podem ser associados. Ex: Um aluno no pode cursar a mesma disciplina mais do que 3 vezes. Dependncia: um tipo de relacionamento pode ser restringido por um outro relacionamento, ou depender de suas associaes anteriores. Ex: Um aluno no pode matricular-se em uma disciplina que ainda no tenha cumprido seus pr-requisitos. Um empregado no pode ser colocado em um cargo cujo salrio seja inferior ao do seu cargo atual. Restries de Integridade de Dependncia e Repetio no so representadas no diagrama, como ocorre com a Cardinalidade, e devem ser descritas em um dicionrio do projeto.

90

7.2.1.1 - Tipos de Relacionamentos Correspondem a uma classificao baseada na cardinalidade mxima dos relacionamentos. Para ilustrar, tomemos um relacionamento R entre dois conjuntos de entidades A e B, como mostra a figura 7.7.

Figura 7.7 Relacionamento R entre dois conjuntos de entidades A e B. Relacionamento 1:1: cada elemento de A ou de B pode aparecer no mximo em um nico par de R, como mostra o exemplo da figura 7.8. (0,1)
DEPARTAMENTOS

(1,1) PROFESSORES

so chefiados por Figura 7.8 Relacionamento 1:1. Relacionamentos 1:N ou N:1: cada elemento de B pode aparecer no mximo em um nico par de R, enquanto cada elemento de A pode ocorrer em um nmero qualquer de pares, como ilustra o exemplo da figura 7.9. (1,1)
DEPARTAMENTOS (13,N)

PROFESSORES

lotam Figura 7.9 Relacionamento 1:N. Relacionamentos N:N: cada elemento de A ou de B pode aparecer em um nmero no determinado de pares de R, como ilustra o exemplo da figura 7.10. (0,N) PROFESSORES
so habilitados a ministrar

(1,N) DISCIPLINAS

Figura 7.10 Relacionamento N:N. A figura 7.11 mostra um exemplo com os vrios tipos de relacionamentos.

91

(0,1) HOMENS

casam

(0,1) MULHERES

Monogamia (0,1) HOMENS casam (0,N) MULHERES

Poligamia (0,N) HOMENS casam (0,1) MULHERES

Poliandria (0,N) HOMENS (0,N) MULHERES

casam

Vale-tudo Figura 7.11 Tipos de Relacionamentos. 7.2.1.2 - Relacionamentos Totais e Parciais Estes tipos de relacionamentos correspondem a uma classificao relacionada com a cardinalidade mnima do relacionamento. Tomando o exemplo da figura 6.7, temos que: Relacionamento Total: dizemos que R um relacionamento total em A se e somente se: a A, b B / (a, b) R , isto , todo elemento de A tem de participar obrigatoriamente de R e, conseqentemente, a cardinalidade mnima de R em relao a A 1. Relacionamento Parcial: dizemos que R um relacionamento parcial em A se e somente se: a A / b B / (a, b) R , isto , nem todo elemento de A participa de R e, conseqentemente, a cardinalidade mnima de R em relao a A 0.

DEPARTAMENTOS

No exemplo da figura 7.12, dizemos que o relacionamento lotam total em relao a e a FUNCIONRIOS, pois em ambos os casos a cardinalidade mnima 1. (1,1)
DEPARTAMENTOS

(1,N) FUNCIONRIOS lotam

Figura 7.12 Relacionamento Total.

92

No exemplo da figura 7.13, dizemos que o relacionamento cursam total em relao a ALUNOS e parcial em relao a CURSOS, pois no segundo caso, a cardinalidade mnima 0. (0,N) ALUNOS cursam Figura 7.13 Relacionamento parcial. Vale a pena observar que a simbologia utilizada na representao de entidades, relacionamentos e restries de integridade de cardinalidade no padronizada, isto , no foi definido um padro nico a ser seguido por todos que utilizam o Modelo ER. 7.2.2 - Restries de Integridade sobre o Domnio dos Atributos Ainda visando manter a integridade do modelo de dados, devemos descrever no dicionrio de projeto restries de integridade (ou leis de consolidao) que regem os valores dos atributos, isto , o conjunto de valores que um atributo pode assumir. Esta tarefa deve ser feita utilizando-se dos seguintes recursos: enumerao: lista explcita de valores. Ex: Estado Civil : solteiro, casado, desquitado, divorciado e vivo. normas de aceitao: regras para se identificar se o valor vlido ou no. Ex: Nome : qualquer conjunto de caracteres alfanumricos, comeado por uma letra. intervalo: descrio de um subconjunto de um intervalo conhecido. Ex: Ms: de 1 at 12. Uma vez estabelecido o domnio, interessante determinar valores possveis e provveis, isto , alguns valores, apesar de poderem ocorrer, pouco provvel que ocorram, dependendo do contexto. Por exemplo, com relao ao atributo idade de um empregado, o valor 81 um valor possvel, mas ser que ele um valor provvel em um contexto de uma empresa de minerao de carvo ? Outros aspectos que devem ser considerados na descrio dos atributos so: obrigatoriedade: estabelecer se um determinado atributo pode ter um valor nulo a ele associado. Ex: Telefone : opcional. Nome : obrigatrio. dependncia: Os valores que um atributo pode assumir, muitas vezes, so dependentes dos valores de outros atributos. Neste caso importante relacionar no dicionrio de projeto como se d esta dependncia. Ex: O valor do atributo dia depende fundamentalmente do valor do atributo ms. (1,1) CURSOS

93

Alm disso, os valores que um atributo pode assumir em um novo estado, muitas vezes, dependem dos valores de estados anteriores. Neste caso, importante relacionar como deve se dar a transio de um estado para outro. Ex: Estado Civil: no pode passar de solteiro para vivo.
Solteiro Casado Desquitado Divorciado Vivo

Figura 7.14 Possveis mudanas para o atributo estado civil.

7.3 - Outras Consideraes sobre Atributos

7.3.1 - Atributos de Relacionamentos Assim como as entidades, os relacionamentos tambm podem possuir atributos. Atributos de relacionamentos so atributos que no so de nenhuma das duas entidades, mas sim do relacionamento entre elas e, em geral, esto relacionados com protocolos e datas, ou so resultantes de avaliaes, tal como no exemplo da figura 7.15. (0,N)
FORNECEDORES

(1,N) PRODUTOS fornecem preo

razo social

cnpj

cdigo

descrio

Figura 7.15 Atributo de relacionamento.

Na prtica, apenas os atributos de relacionamentos N:N so caracterizados como atributos de relacionamentos. No caso de relacionamentos 1:N ou N:1, os atributos do relacionamento podem ser perfeitamente caracterizados como atributos da entidade cuja a cardinalidade mxima 1. No exemplo da figura 7.16, o atributo data-de-lotao pode ser perfeitamente caracterizado como atributo do conjunto de entidades FUNCIONRIOS. (1,1)
DEPARTAMENTOS

(1,N) FUNCIONRIOS lotam

data-de-lotao

Figura 7.16 Atributo de relacionamento caracterizado como atributo de uma das entidades.

94

Quando o relacionamento N:N, h um teste que pode ser aplicado para se deduzir se um atributo de um dos dois conjuntos de entidades ou se do relacionamento. Seja o exemplo da figura 7.17: (0,N)
FORNECEDORES

(1,N) MATERIAIS

fornecem Figura 7.17 Relacionamento N:N com atributos. 1. Fixa-se um material, por exemplo impressora, e varia-se os fornecedores deste material. Evidentemente o valor do atributo pode mudar. Por exemplo, a Casa do Analista vende uma impressora por R$ 350, enquanto a loja Compute vende a mesma impressora por R$ 310. Se o valor do atributo mudar ao variarmos o elemento do outro conjunto de entidades, porque este no atributo do primeiro conjunto de entidades, no caso MATERIAIS. 2. Procedimento anlogo deve ser feito, agora, para a outra entidade. Fixando-se um fornecedor e variando-se os materiais temos: A Casa do Analista vende uma impressora por R$ 350 e um microcomputador R$ 1.700. Como o valor do atributo variou para a mesma entidade, sinal de que ele no atributo de FORNECEDORES. 3. Se no atributo nem de MATERIAIS, nem de FORNECEDORES, ento um atributo do relacionamento entre os dois conjuntos de entidades, como mostra a figura 7.18. (0,N)
FORNECEDORES

(1,N) MATERIAIS fornecem

preo Figura 7.18 Atributo do Relacionamento. 7.3.2 - Atributo de Entidade ou Nova Entidade ? Pode no ser fcil decidir se um determinado elemento de informao deve ser tratado como atributo de uma entidade ou como uma segunda entidade relacionada primeira. Analisemos o seguinte exemplo: Ser que o cdigo do departamento que oferece uma disciplina deve ser modelado como atributo de DISCIPLINAS, ou merece ser uma nova entidade relacionada entidade DISCIPLINAS? De forma geral, convm tratar um elemento de informao como uma segunda entidade se: O elemento em questo tem atributos prprios; A segunda entidade resultante relevante para a organizao; O elemento em questo de fato identifica a segunda entidade; A segunda entidade pode ser relacionada a diversas ocorrncias da entidade-1 (1:N); A segunda entidade relaciona-se a outras entidades que no a entidade-1. Podemos notar que, no exemplo, todos os critrios anteriormente enumerados foram satisfeitos e, portanto, departamento deve ser tratado como uma nova entidade, como mostra a figura 7.19.
95

(1,1) DEPARTAMENTOS (1,1)

lotam

(13,N)

PROFESSORES
(1,1)

(0,1 chefiam

oferecem
(0,N)

DISCIPLINAS

Figura 7.19 Departamento como Nova Entidade.

7.4 - Outros Conceitos Importantes

7.4.1 - Auto Relacionamento Se R um relacionamento que relaciona elementos de um conjunto de entidades A a elementos deste mesmo conjunto A, ento R denominado de auto-relacionamento. A figura 7.20 mostra um exemplo de auto-relacionamento.
pr-requisito (0,N) so pr-requisito para

DISCIPLINAS

(0,N) ps-requisito

Figura 7.20 Exemplo de Auto-relacionamento. Neste caso, necessrio distinguir qual a atuao de cada elemento do conjunto de entidades no relacionamento e, portanto, importante atribuir papis. Assim no par (Clculo I, Clculo II), precisamos definir quem pr-requisito de quem: pr-requisitos { (d1, d2) / d1, d2 DISCIPLINAS e papel (d1) = pr-requisito e papel (d2) = ps-requisito}

96

7.4.2 - Relacionamentos Mltiplos So relacionamentos envolvendo mais de dois conjuntos de entidades. Um relacionamento ternrio, por exemplo, s se caracteriza pelo terno, como mostra a figura 7.21. Os relacionamentos ternrios normalmente so difceis de se dar um nome e por isso usual represent-los pelas iniciais das trs entidades envolvidas, como mostra o exemplo da figura 7.22. A R B

C R {(a,b,c) / a A, b B, c C} Figura 7.21 Relacionamento Ternrio. (0,N) LOJAS

LMF

(1,N) MATERIAIS

(0,N)
FORNECEDORES

Figura 7.22 Exemplo de Relacionamento Ternrio. 7.4.3 - Agregaes ou Agregados Agregao uma abstrao atravs da qual relacionamentos entre duas entidades so tratados como entidades em um nvel mais alto. Representa uma extenso do modelo originalmente proposto por Chen [Chen90], onde um relacionamento binrio R e as entidades envolvidas X e Y so considerados uma nica entidade A, agregando todas as informaes. Esta nova entidade, a agregao, pode, ento, relacionar-se com outras entidades do modelo, como mostra a figura 7.23. A agregao , normalmente, representada por um retngulo envolvendo as duas entidades e o relacionamento entre elas. agregao deve ser dado um nome que represente esta entidade de nvel mais alto, como mostra o exemplo da figura 7.24.

97

A X R1 Y

R2

Z R1 {(x, y) / x X, y Y} R2 {((x, y),z) / (x, y) R1, z Z} Figura 7.23 Agregao. CORRENTISTAS (1,N) CLIENTES
possuem

(0,N) CONTAS CORRENTES

(1,1)
so emitidos para

(0,1)
CARTES MAGNTICOS

Figura 7.24 Exemplo de Agregao. Para prover maior facilidade na representao, muitas vezes, representaremos a agregao com um retngulo envolvendo apenas o relacionamento, como mostra o exemplo da figura 7.25.

98

CORRENTISTAS

(1,N) CLIENTES
possuem

(0,N)

CONTAS CORRENTES

(1,1)
so emitidos para

(0,1)
CARTES MAGNTICOS

Figura 7.25 Outra representao para Agregados. importante observar que agregaes envolvendo relacionamentos N:1 ou 1:N no fazem sentido. Em relacionamentos desta natureza, cada entidade cuja cardinalidade mxima 1 (Y) s aparece no mximo uma nica vez no relacionamento e, conseqentemente, j representa o par que eventualmente possa ocorrer. Assim, as duas verses apresentadas nas figuras 7.26 e 7.27 so equivalentes quanto s informaes apresentadas e devemos utilizar sempre a verso da figura 7.27. Portanto, s devemos representar agregaes de relacionamentos N:N. A (0,1) X R1 (0,N) Y

R2

Z Figura 7.26 Agregado em relacionamento 1:N.

99

(0,1) X

R1

(0,N) Y

R2

Z Figura 7.27 Soluo mais apropriada. 7.4.4 - Particionamentos de Conjuntos de Entidades Muitas vezes, elementos de um conjunto de entidades do mundo real, se subdividem em categorias com atributos parcialmente distintos. Passa a ser interessante, ento, representar os atributos comuns em um supertipo e os atributos distintos em subtipos. As abstraes que norteiam este procedimento so: Generalizao: entidades de um nvel mais baixo de abstrao so agrupadas, dando origem a uma entidade de nvel mais alto. Especializao: uma entidade de nvel mais alto de abstrao desmembrada em vrias entidades de nvel mais baixo. O particionamento pode ser: Disjunto: cada elemento do conjunto de entidades s se enquadra em uma das categorias. No Disjunto: cada elemento pode ser enquadrado em mais de uma categoria. A figura 7.28 mostra um exemplo de particionamento disjunto. (1,1)
DEPARTAMENTOS

(1,N) FUNCIONRIOS lotam matrcula

(0,N)
PROJETOS

(0,N)
ENGENHEIROS SECRETRIAS MOTORISTAS

participam
crea lngua* habilitao

Figura 7.28 Particionamento Disjunto de um Conjunto de Entidades.

100

7.4.5 - Conectores So uma extenso do Modelo E/R para representar restries de integridade no que diz respeito totalidade dos relacionamentos. Podem ser de dois tipos: Ou obrigatrio: Apenas um dos relacionamentos ocorre efetivamente, mas sempre um deles ocorre. No exemplo da figura 7.29, todo contrato financiado (no existe contrato que no seja financiado), mas pode ser financiado ou por um banco ou por um fornecedor.
CONTRATOS

(0,N)
financiam

(0,N)
financiam

(1,1) BANCOS

(1,1)
FORNECEDORES

Figura 7.29 Exemplo de Conector Ou-Obrigatrio. Ou opcional: Apenas um dos relacionamentos ocorre efetivamente, mas pode ser que nenhum dos dois ocorra. No exemplo da figura 7.30, nem todo contrato financiado. Mas se um contrato for financiado, ele ser financiado ou por um banco ou por um fornecedor.
CONTRATOS

(0,N)
financiam

(0,N)
financiam

(0,1) BANCOS

(0,1)
FORNECEDORES

Figura 7.30 Exemplo de Conector Ou-Opcional. 7.4.6 - Entidade Fraca Existem entidades do mundo real que no tm existncia prpria, isto , s aparecem no modelo quando relacionadas a outra entidade (dita forte), sendo seus atributos determinantes compostos por pelo menos dois campos, um deles um atributo da entidade forte. A figura 7.31 ilustra uma entidade fraca.

101

TALES DE CHEQUE

(0,N)

(1,1) CONTAS

so emitidos para
(nmero_conta, nmero_cheque) nmero

Figura 7.31 Exemplo de Entidade Fraca.

7.5 Dicionrio de Dados

O Dicionrio de Dados uma listagem organizada de todos os elementos de dados pertinentes ao sistema, com definies precisas para que os usurios e desenvolvedores possam conhecer o significado de todos os itens de dados manipulados pelo sistema. Esta listagem contm, em ordem alfabtica, as seguintes definies: entidades e relacionamentos com atributos de um DER. depsitos de dados e fluxos de dados dos DFDs, sendo que os primeiros devem corresponder s entidades e relacionamentos do DER. estruturas de dados que compem os depsitos de dados ou fluxos de dados. elementos de dados que compem os depsitos de dados, fluxos de dados ou estruturas de dados. A figura 7.32 apresenta a notao adotada neste texto para elaborao de Dicionrios de Dados.

Smbolo = + () [|] n{ }m composto de e dado ou estrutura opcional

Significado

dados ou estruturas alternativas (ou exclusivo) repetio de dados ou estruturas, onde n representa o nmero mnimo de repeties e m o nmero mximo. Se n e m no so especificados, significa zero ou mais repeties. delimitadores de comentrios atributo determinante Figura 7.32 Notao para Dicionrios de Dados.

** ________

102

Os exemplos mostrados a seguir ilustram diversas situaes e o emprego das notaes. (a) O cliente pode possuir um telefone. CLIENTES = *clientes da livraria* cdigo-cliente + nome-cliente + endereo-cliente + (telefone-cliente) (b) O cliente pode possuir um ou mais telefones. CLIENTES = *clientes da livraria* cdigo-cliente + nome-cliente + endereo-cliente + {telefone-cliente} (c) O cliente pode possuir at trs telefones. CLIENTES = *clientes da livraria* cdigo-cliente + nome-cliente + endereo-cliente + {telefone-cliente}3 (d) O cliente pode possuir telefone comercial, residencial ou ambos. CLIENTES = *clientes da livraria* cdigo-cliente + nome-cliente + endereo-cliente + [telefone-comercial| telefone-residencial | telefone-comercial + telefone-residencial] Os nomes das entidades e relacionamentos (e, por conseguinte, dos depsitos de dados dos DFDs) devero ser escritos no plural e com letras maisculas. Os atributos determinantes so assinalados por um sublinhado.

Referncias Bibliogrficas [Chen90] [Setzer87] [Yourdon90] P. Chen. Gerenciando Banco de Dados: A Abordagem EntidadeRelacionamento para Projeto Lgico. McGraw-Hill, 1990. W. Setzer. Bancos de Dados. 2a Edio, Editora Edgard Blcher, 1987. E. Yourdon. Anlise Estruturada Moderna. Editora Campus, 1990.

103

8. Modelagem Funcional
A partir deste momento, passaremos a nos preocupar com a modelagem das funes que o sistema dever executar para atender aos anseios dos usurios do sistema. A tcnica mais difundida para esta finalidade a utilizao de Diagramas de Fluxo de Dados - DFDs, proposta por Gane e Sarson em [Gane83] e por De Marco em [De Marco83]. Muitos outros autores citam esta tcnica em suas obras, sendo que destacamos como referncia [Gane88] e [Yourdon90]. Um Diagrama de Fluxo de Dados, conforme proposto originalmente, uma ferramenta top-down para modelagem de processos. Representa um sistema como uma rede de processos interligados entre si por fluxos de dados e depsitos de dados. O DFD utiliza-se de quatro smbolos grficos, visando representar os seguintes componentes: Processos, Fluxos de Dados, Depsitos de Dados e Entidades Externas. A figura 8.1 mostra a notao usada por Yourdon [Yourdon90], que ser a adotada neste texto. Atravs da utilizao desses quatro componentes, podemos representar satisfatoriamente os processos e interaes entre os elementos de um sistema.

Processos

Fluxos de Dados

Entidades Externas

Depsitos de Dados

Figura 8.1 Notao bsica para construo de DFDs. A idia bsica desta tcnica ir refinando o conhecimento das funes a partir da decomposio de um DFD em vrios outros com nveis maiores de detalhamento, at se chegar a um entendimento completo das funes que o sistema dever desempenhar. Alm dos Diagramas de Fluxo de Dados, so necessrios para uma completa modelagem das funes: Dicionrio de Dados; Descrio da lgica dos processos simples que no meream ser decompostos em outros.

104

Um DFD mostra as fronteiras do sistema: aquilo que no for uma Entidade Externa, ser interno ao sistema, delimitando assim a abrangncia do sistema. uma ferramenta particularmente til para a modelagem de sistemas por mostrar todas as relaes entre dados (armazenados e que fluem no sistema) e os processos que manipulam e transformam esses dados. Devemos lembrar que esta uma tcnica de modelagem conceitual e, portanto, no deve estar presa a nenhuma plataforma computacional de implementao.

8.1 - Conceitos Bsicos

Processos Representam as transformaes e manipulaes feitas sobre os dados em um sistema e correspondem a procedimentos ou funes que um sistema tem de prover. A ocorrncia de um evento de um dos seguintes tipos deve ser representada como um processo em um DFD: transformaes do contedo de um dado de entrada no contedo de um dado de sada, como mostra a figura 8.2; entrada sada

Figura 8.2 Transformaes de dados. inseres ou modificaes do contedo de dados armazenados, a partir do contedo (possivelmente transformado) de dados de entrada, como mostra a figura 8.3; entrada sada

Figura 8.3 Armazenamento de dados. transformaes de dados previamente armazenados no contedo de um dado de sada, como mostra a figura 8.4. entrada sada

Figura 8.4 Gerao de dados de sada a partir de dados armazenados.

105

Um processo representado por um crculo, com uma sentena simples (verbo + objetos) em seu interior e, opcionalmente, um identificador (nmero). A sentena deve tentar descrever o melhor possvel a funo a ser desempenhada, sem ambigidades. Devem ser evitados nomes muito fsicos (p. ex., gravar, imprimir, ...) ou muito tcnicos (p. ex., apagar, fazer backup, ...) . Os processos representados em um DFD no precisam ser necessariamente funes a serem informatizadas. Muitas vezes, para se prover um entendimento mais completo do sistema, processos manuais ou mistos (parte manual, parte informatizada) so representados. Toda transformao de dados deve ser representada e, deste modo, no se admite ligao direta entre entidades externas e depsitos de dados. Por outro lado, devemos observar se um mesmo fluxo de dados entra e sai de um processo sem modificao, j que todo processo transforma dados. Como j mencionado anteriormente, para uma completa modelagem das funes, so necessrios, alm dos DFDs, um Dicionrio de Dados e as Especificaes das Lgicas dos processos. Deste modo, s teremos um entendimento completo de um processo, aps descrevermos sua lgica. As especificaes das lgicas dos processos s devem ser feitas para processos simples. Processos complexos devem ser decompostos em outros processos, at se atingir um nvel de reduzida complexidade. Esta descrio no deve ser confundida com o detalhamento integral da lgica do processo que dever ser feito na fase de projeto, mas deve servir de base para esta outra etapa. Um processo s merece ser representado em um DFD quando a descrio de sua lgica utilizar aproximadamente uma pgina. Processos descritos em trs ou quatro linhas so simples demais para serem tratados como processos em um DFD. Por outro lado, se a descrio da lgica do processo necessitar de trs ou mais pginas, ento esse processo est muito abrangente e no deve ser tratado como um nico processo, mas sim ser decomposto em processos de menor complexidade. Para situaes desta natureza, podemos utilizar duas tcnicas : fisso ou exploso, como estudaremos a seguir. Como regra geral, os fluxos de erro e exceo no devem ser mostrados nos diagramas, mas apenas na descrio da lgica dos processos. Esta regra s deve ser desrespeitada quando tais fluxos forem muito significativos para a comunidade usuria. Fluxos de Dados Fluxos de dados so utilizados para representar a movimentao de dados atravs do sistema. So simbolizados por setas, que identificam a direo do fluxo, e devem ter associado um nome o mais significativo possvel, de modo a facilitar a validao do diagrama com os usurios. Esse nome deve ser um substantivo que facilite a identificao do dado (ou pacote de dados) transportado. Um fluxo de dado em um DFD pode ser considerado como um caminho atravs do qual podero passar uma ou mais estruturas de dados em tempo no especificado. Note que

106

em um DFD no se representam elementos de natureza no informacional, isto , dinheiro, pessoas, materiais, etc... Devemos observar se um fluxo de dados entra e sai de um processo sem modificao. Isto representa uma falha, haja visto que um processo transforma dados. Embora possa parecer um tanto bvio, bom lembrar que um mesmo contedo pode ter diferentes significados em pontos distintos do sistema e, portanto, os fluxos devem ter nomes diferentes. No DFD da figura 8.5, um mesmo conjunto de informaes sobre um cliente tem significados diferentes quando passa pelos fluxos dados-novo-cliente e dadoscliente. No primeiro caso, os dados ainda no foram validados e, portanto, podem ser vlidos ou invlidos, enquanto, no segundo fluxo, esses mesmos dados j foram validados.
dados-novocliente dados-cliente

Setor de Pessoal

Cadastrar cliente

clientes

Figura 8.5 Mesmo contedo de dados em fluxos diferentes. Fluxos de dados que transportam exatamente o mesmo contedo de/para um depsito de dados, no precisam ser nomeados. No exemplo da figura 8.5, se o fluxo dados-cliente apresentar exatamente o mesmo contedo do depsito clientes, no h necessidade de nome-lo, como mostra a figura 8.6. Setor de Pessoal
dados-novocliente

Cadastrar cliente

clientes

Figura 8.6 Fluxo de dados no nomeado. Fluxos de erro ou exceo (no exemplo, dados-cliente-invlidos) s devem ser mostrados em um DFD, se forem muito significativos para o seu entendimento. Caso contrrio, devem ser tratados apenas na descrio da lgica do processo. Setas ramificadas significam que o mesmo fluxo de dados est indo de uma fonte para dois destinos diferentes, isto , cpias do mesmo pacote de dados esto sendo enviadas para diferentes partes do sistema, como mostra a figura 8.7.

Figura 8.7 Fluxo ramificado.

107

Quando for necessrio cruzar fluxos de dados em um DFD, devemos utilizar um arco, como mostra a figura 8.8.

Figura 8.8 Fluxos de dados que se cruzam em um diagrama. importante realar que DFDs no indicam a seqncia na qual fluxos de dados entram ou saem de um processo. Depsitos de Dados Depsitos de dados so pontos de reteno permanente ou temporria de dados, que permitem a integrao entre processos assncronos, isto , processos realizados em tempos distintos. Sem nos comprometermos quanto ao aspecto fsico, representam um local de armazenamento de dados entre processos. Um depsito de dados representado por um retngulo sem a linha lateral direita, com um nome e um identificador (opcional) em seu interior. s vezes, para evitar o cruzamento de linhas de fluxos de dados ou para impedir que longas linhas de fluxos de dados saiam de um lado para outro do diagrama, um mesmo depsito de dados pode ser representado mais de uma vez no diagrama. Nesta situao, adicionamos uma linha vertical na lateral esquerda do retngulo, como mostra a figura 8.9.

clientes

D1 clientes

Figura 8.9 Notao para depsitos de dados. Um depsito de dados no se altera quando um pacote de informao sai dele atravs de um fluxo de dados. Por outro lado, um fluxo para um depsito representa uma das seguintes aes: uma incluso, isto , um ou mais novos pacotes de informao esto sendo introduzidos no depsito; uma atualizao, ou seja, um ou mais pacotes esto sendo modificados, sendo que isso pode envolver a alterao de todo um pacote, ou apenas de parte dele; uma excluso, isto , pacotes de informao esto sendo removidos do depsito.

A semntica dos acessos aos depsitos de dados mostrada na figura 8.10.

108

Leitura no destrutiva do contedo do depsito de dados.

Incluso, excluso ou alterao do contedo do depsito de dados. Leitura e modificao do contedo do depsito de dados. Figura 8.10 Semntica dos acessos a depsitos de dados em um DFD. Quando examinamos fluxos de dados que entram ou saem de um depsito, surge uma dvida: o fluxo representa um nico pacote, mltiplos pacotes, partes de um pacote, ou partes de vrios pacotes de dados? Em algumas situaes, essas dvidas podem ser respondidas pelo simples exame do rtulo do fluxo e, para tal, adotamos a seguinte conveno: se um fluxo no possuir rtulo ou tiver o mesmo rtulo do depsito de dados, ento um pacote inteiro de informao ou mltiplas instncias do pacote inteiro esto trafegando pelo fluxo; se o rtulo de um fluxo nomeado for diferente do rtulo do depsito, ento as informaes que esto trafegando so um ou mais componentes (partes) de um ou mais pacotes, e estaro definidas no dicionrio de dados.

Muitas vezes, diferentes sistemas compartilham uma mesma base de dados e, portanto, vrios sistemas podero estar lendo e atualizando os contedos de um mesmo depsito de dados. interessante mostrar este fato explicitamente no DFD e, neste caso, podemos notar trs situaes distintas: O sistema em questo apenas l as informaes do depsito de dados, no sendo responsvel por qualquer alterao de seu contedo. Neste caso, utilizamos a notao da figura 8.11.
Sistema Mantenedor DD compartilhado

Figura 8.11 Sistema apenas acessando depsito de dados mantido por outro sistema.

109

O sistema em questo apenas gera as informaes que so utilizadas por outros sistemas. Representaremos esta situao segundo a notao da figura 8.12.

Atualizar dados

DD
Outro Sistema

Figura 8.12 Sistema atualizando dados utilizados por outro sistema. Ambos os sistemas atualizam o depsito de dados. A notao para esta situao mostrada na figura 8.13.

Atualizar dados

DD
Outro Sistema

Figura 8.13 Ambos os sistema atualizando dados de um mesmo depsito. Estas notaes so excees regra de que os dados no devem fluir diretamente entre uma entidade externa e um depsito de dados, sem passar por um processo responsvel pela transferncia dos dados. A fora as situaes anteriormente descritas, devemos observar a integridade de um depsito de dados segundo dois prismas: Observar se todos os elementos de dados que fazem parte do depsito tm como efetivamente chegar l, isto , fazem parte de pelo menos um fluxo de dados que chega ao depsito. Observar se todos os elementos de dados que fazem parte do depsito so, em algum momento, solicitados por um processo, isto , fazem parte de pelo menos um fluxo de dados que sai do depsito.

Entidades Externas Entidades externas ou terminadores so fontes ou destinos de dados do sistema. Representam os elementos do ambiente com os quais o sistema se comunica. Tipicamente, uma entidade externa uma pessoa (p.ex. um cliente), um grupo de pessoas (p. ex. um departamento da empresa ou outras instituies) ou um outro sistema que interaja com o sistema em questo. Uma entidade externa deve ser identificada por um nome e
110

representada por um retngulo. Assim como no caso dos depsitos de dados, em diagramas complexos, podemos desenhar um mesmo terminador mais de uma vez, para se evitar o cruzamento de linhas de fluxos de dados ou para impedir que longas linhas de fluxos de dados saiam de um lado a outro do diagrama. Neste caso, convenciona-se utilizar um trao diagonal no canto inferior direito do smbolo da entidade externa, como mostra a figura 8.14..

Clientes

Clientes

Figura 8.14 Notaes para representar entidades externas. Ao identificarmos alguma coisa ou sistema como uma entidade externa, estamos afirmando que esta entidade est fora dos limites do sistema em questo e, portanto, fora do controle do sistema que est sendo modelado. Assim, qualquer relacionamento existente entre entidades externas no deve ser mostrado em um DFD. Se percebermos que, em algum ponto do sistema, descrevemos algo que ocorre dentro de uma entidade externa ou relacionamentos entre entidades externas, necessrio reconhecer que a fronteira do sistema na realidade mais ampla do que foi estabelecido inicialmente e, portanto, deve ser revista. Uma vez que os terminadores so externos ao sistema, os fluxos de dados que os interligam aos diversos processos representam a interface entre o sistema e o mundo externo.

8.2 - Construindo DFDs

Como j mencionado no estudo sobre processos, uma boa prtica manter um certo nvel de complexidade nos processos representados em um DFD. Esse nvel de complexidade pode ser estabelecido pelo tamanho da especificao da lgica do processo ou pelo nmero de processos em um diagrama. Se tal nvel de complexidade for superado, devemos utilizar uma das seguintes tcnicas para decompor o DFD: fisso ou exploso. Fisso Na fisso, o processo complexo deve ser substitudo no prprio DFD do sistema por um nmero de processos mais simples. Por exemplo, se um processo requer 8 pginas de especificao de lgica, ele pode ser substitudo por 4 processos, cada um deles tendo aproximadamente 2 pginas. O problema na utilizao desta tcnica a sobrecarga a que o diagrama poder ficar sujeito, dificultando sua leitura.

111

Exploso O processo original permanece no diagrama, sendo criado um novo DFD de nvel inferior, consistindo de processos menos complexos. Assim, um projeto no representado por um nico DFD, mas sim por um conjunto de DFDs em vrios nveis de decomposio funcional. Quando a exploso utilizada, alguns aspectos importantes devem ser observados. O primeiro deles diz respeito ao nmero de nveis que devem ser esperados em um sistema. A priori, este nmero no deve ser pr-fixado, mas lembre-se que o nmero total de processos cresce exponencialmente quando se passa de um nvel para o imediatamente inferior. De uma maneira geral, quando a exploso utilizada, pelo menos trs nveis so especificados, apesar de algumas vezes s serem necessrios dois. Tipicamente so quatro os nveis de representao: C Contexto: mostra o sistema como uma caixa-preta, trocando informaes (fluxos de dados) com entidades externas ao sistema. Define o escopo de abrangncia do sistema, indicando que se est renunciando possibilidade de examinar qualquer coisa alm da fronteira definida pelas entidades externas. 0 (Zero) Geral ou de Sistema: uma decomposio do diagrama de contexto, mostrando o funcionamento do sistema em questo, isto , as grandes funes do sistema e as interfaces entre elas. Os processos nesse diagrama recebem os nmeros 1, 2, 3, etc... necessrio assegurar a coerncia entre os diagramas C e 0, isto , assegurar que os fluxos de dados entrando ou saindo do diagrama 0 efetivamente reproduzem as entradas e sadas do diagrama C. Neste diagrama, devem aparecer os depsitos de dados necessrios para a sincronizao dos processos. N Detalhe: Uma diagrama de detalhe representa a decomposio de um dos processos do diagrama 0 e, portanto, nomeado com o nmero e o nome do processo que est sendo detalhado. A princpio, devero ser elaborados diagramas N para os processos do diagrama 0 que sejam complexos e, portanto, caream de decomposio. necessrio resguardar a coerncia entre o diagrama 0 e cada diagrama detalhado elaborado. Os processos em um diagrama N so numerados com o nmero do processo que est sendo detalhado (p. ex., 2) e um nmero seqencial, separados por um ponto (p. ex., 2.1, 2.2, etc.). E Detalhe Expandido: um diagrama deste tipo representa a decomposio de um dos processos do diagrama N. Este nvel de decomposio pode vir a ser necessrio caso um processo do nvel N seja ainda muito complexo. Este nvel pode ser desdobrado sucessivamente at se atingir o grau necessrio de simplicidade. Entretanto, se muitos nveis forem necessrios, cuidado! Provavelmente, o contexto funcional da aplicao (diagrama de contexto) est muito abrangente e merece reviso.

112

Fisso ou Exploso? Recomenda-se o uso da fisso para sistemas de pequeno a mdio porte, em que a leitura do diagrama no fica prejudicada pelo aparecimento de mais alguns processos no diagrama de sistema. A fisso possui a vantagem de representar todo o sistema em um nico DFD, no sendo necessrio recorrer a outros diagramas para se obter um entendimento completo de suas funes. Em sistemas maiores, o uso da fisso pode se tornar invivel, sendo recomendado, ento, o uso da exploso. Recomendaes para a Construo de DFDs 1. Escolha nomes significativos para todos os elementos de um DFD. Utilize termos empregados pelos usurios no domnio da aplicao. 2. Os processos devem ser numerados de acordo com o diagrama a que pertencem. 3. Evite desenhar DFDs complexos. 4. Cuidado com os processos sem fluxos de dados de entrada ou de sada. 5. Cuidado com os depsitos de dados que s possuem fluxos de dados de entrada ou de sada. 6. Depsitos de dados permanentes devem manter estreita relao com os conjuntos de entidades e de relacionamentos do modelo ER. 7. Fique atento ao princpio de conservao de dados, isto , dados que saem de um depsito devem ter sido previamente l colocados e dados produzidos por um processo tm de ser passveis de serem gerados por esse processo. 8. Quando do uso de exploso, os fluxos de dados que entram e saem em um diagrama de nvel superior devem entrar e sair no nvel inferior que o detalha. 9. Mostre um depsito de dados no nvel mais alto em que ele faz a sincronizao entre dois ou mais processos. Passe a represent-lo em todos os nveis inferiores que detalham os processos envolvidos. 10. No represente no DFD fluxos de controle ou de material. Como o nome indica, DFDs representam fluxos de dados. 11. S especifique a lgica de processos primitivos, ou seja, aqueles que no so detalhados em outros diagramas.

8.3 - Tcnicas de Especificao de Processos

Quando chegamos a um nvel de especificao em que os processos no so mais decomponveis, precisamos complementar esta especificao com descries das lgicas desses processos. A especificao de processos deve ser feita de forma que possa ser validada por analistas e usurios. Entretanto, encontramos muitos problemas na descrio de forma narrativa, entre os quais podemos citar:

113

Uso de expresses do tipo: mas, todavia, a menos que ... Por exemplo, qual a diferena entre as declaraes abaixo ? - Somar A e B, a menos que A seja menor que B, onde, neste caso, subtrair A de B. - Somar A e B. Entretanto, se A for menor que B, a resposta ser a diferena entre B e A. - Somar A e B, mas subtrair A de B quando A for menor que B. - total a soma de B e A. Somente quando A for menor que B que a diferena deve ser usada como o total. Ao analisarmos estas frases, notamos que no existe diferena lgica entre elas, entretanto as formas narrativas apresentadas mascaram a semelhana existente. Se ao invs de usarmos uma forma narrativa, usarmos uma forma padro do tipo se-ento-seno, teremos maior clareza e validao.
se A < B ento TOTAL seno TOTAL fim-se; B - A; A + B;

Uso de comparativos como: Maior que / Menor que, Mais de / Menos de. Seja a seguinte declarao: At 20 unidades, sem desconto. Mais de R$20, 5% de desconto. E exatamente 20 unidades, que tratamento deve ser dado ? Ambigidades do E/OU. Seja a seguinte declarao: Clientes que gerarem mais de um milho de cruzeiros em negcios por ano e possurem um bom histrico de pagamentos ou que estiverem conosco h mais de 20 anos, devem receber tratamento prioritrio. Quem dever receber tratamento prioritrio? Clientes com mais de 1 milho em negcios por ano que possurem bom histrico de pagamentos? Clientes com mais de 20 anos? Clientes com mais de 1 milho e (ou bom histrico, ou mais de 20 anos)? Note que pela declarao no fica claro quando dever ser aplicado o tratamento prioritrio. Uso de Adjetivos Indefinidos Na declarao do item anterior, o que um bom histrico de pagamentos? Devemos tomar cuidado ao utilizarmos adjetivos indefinidos e quando o fizermos, tomarmos o cuidado de defini-los.

Para administrar os problemas oriundos da narrativa, so utilizadas tcnicas de especificao de processos, entre as quais podemos citar: Portugus Estruturado Tabelas de Deciso

114

rvores de Deciso Combinao das tcnicas acima

8.3.1 - Portugus Estruturado O Portugus Estruturado um subconjunto do Portugus, cujas sentenas so organizadas segundo as trs estruturas de controle introduzidas pela Programao Estruturada: seqncia, seleo e repetio. Instrues de Seqncia: grupo de instrues a serem executadas que no tenham repetio e no sejam oriundas de processos de deciso. So escritas na forma imperativa, como no exemplo abaixo.
obter ... atribuir ... armazenar ...

Instrues de Seleo: quando uma deciso deve ser tomada para que uma ao seja executada, utilizamos uma instruo de seleo. As instrues de seleo so expressas como uma combinao se-ento-seno, conforme abaixo.
se <condio> ento grupo_ de_aes_1; seno grupo_de_aes_2; fim-se;

Exemplo:
se Nmero_de_Dependentes = 0 ento Salrio_Famlia = 0; seno Salrio_Famlia = Salrio_Mnimo / 3; fim-se;

Quando existirem vrias aes dependentes de uma mesma condio, que sejam mutuamente exclusivas, podemos utilizar uma estrutura do tipo caso, conforme abaixo.
caso <condio> = valor_1 : grupo_de_aes_1; valor_2 : grupo_de_aes_2; ... ... valor_n : grupo_de_aes-N; fim-caso;

Exemplo:
caso opo = 1: incluir novo cliente; 2: excluir cliente existente; 3: alterar dados de cliente; seno : executar rotina de erro; fim-caso;

115

Instrues de Repetio: Aplicadas quando devemos executar uma instruo, ou um grupo de instrues, repetidas vezes. A estrutura de repetio pode ser usada de trs formas distintas:
1. para cada X faa grupo_de_aes; fim-para;

Exemplo:
para cada Aluno faa Mdia = (Prova_1 + Prova_2) / 2; imprima Mdia; fim-para;

2. enquanto <condio for verdadeira> faa grupo_de_aes; fim-enquanto;

Exemplo:
enquanto existir registro faa ler registro; consistir dados; fim-enquanto; 3. repita grupo_de_aes; at que <condio seja verdadeira>;

Exemplo:
repita ler registro consistir dados at que todos os registros do arquivo tenham sido processados;

Uma especificao de processo em Portugus Estruturado deve possuir as seguintes caractersticas gerais: deve ser clara, concisa, completa e livre de ambigidades; todos os dados citados na especificao que estejam definidos no dicionrio de dados devem ser sublinhados; os dados definidos localmente no so sublinhados; os depsitos de dados, alm de sublinhados, devem ser escritos com letras maisculas;

116

sempre que um comando de seleo ou repetio for utilizado, os comandos do bloco interno (grupo_de_aes) devem estar identados, de modo a dar a clareza de que esses comandos fazem parte das aes da seleo ou repetio.

8.3.2 rvore de Deciso rvores de Deciso so excelentes para mostrar a estrutura de deciso de um processo. Os ramos da rvore correspondem a cada uma das possibilidades lgicas. uma excelente ferramenta para esquematizar a estrutura lgica e para obter do usurio a confirmao de que a lgica expressada est correta. De forma clara e objetiva, permite a leitura da combinao das circunstncias que levam a cada ao. Como podemos notar pelo exemplo da figura 8.15, uma rvore de Deciso muito boa para representar a lgica decisria. Entretanto, se for necessrio descrever a lgica de um processo como um conjunto de instrues, combinando decises e aes intermedirias, a rvore de deciso deve ser preterida em favor do portugus estruturado ou combinada a ele. Tratamento Prioritrio
Tempo de trabalho 20 anos Tempo de trabalho < 20 anos

Sem atraso de pagamento registrado Volume de negcios R$ 1 milho

Prioritrio

Com atraso de pagamento registrado

Normal Normal

Volume de negcios < R$ 1 milho

Figura 8.15 Exemplo de rvore de Deciso. 8.3.3 Tabelas de Deciso Tabelas de deciso so usadas em aplicaes semelhantes s das rvores de deciso. As rvores de deciso so mais indicadas, quando o nmero de decises for pequeno e nem todas as combinaes de condies forem possveis. As tabelas de deciso aplicam-se melhor a situaes em que o nmero de aes grande e ocorrem muitas combinaes de condies. Tambm devemos utilizar tabelas de deciso se existirem dvidas de que a rvore de deciso no mostra toda a complexidade do problema. O formato bsico de uma tabela de deciso mostrado na figura 8.16.

117

Nome da Tabela Condies Aes Combinaes Regras

Figura 8.16 Formato bsico de uma Tabela de Deciso. A construo de uma tabela de deciso envolve os seguintes passos: 1. Levantar as aes do processo; 2. Identificar as condies que determinam estas aes; 3. Identificar os estados possveis de cada condio; 4. Identificar as combinaes dos estados das condies; 5. Construir uma coluna para cada combinao de condies; 6. Preencher cada coluna com as regras das aes correspondentes; 7. Verificar se o entendimento foi correto; 8. Alterar a tabela at obter total concordncia dos usurios; 9. Se possvel, compactar a tabela. Em funo do tipo das condies, temos dois tipos de tabelas: Tabela de Entrada Limitada: os valores de uma condio se limitam a dois. Exemplos tpicos deste tipo de tabelas so as tabelas cujas condies so escritas sob a forma de perguntas, de modo que as respostas sejam sim ou no, como mostra o exemplo da figura 8.17.

Tratamento de Clientes Volume de Negcios R$ 1 milho? Atraso de pagamento registrado? Tempo de trabalho 20 anos? Tratamento Prioritrio Tratamento Normal Figura 8.17 Tabela de Entrada Limitada. Tabela de Entrada Ampliada: Uma condio pode ter mais de dois estados diferentes, como no exemplo da figura 8.18. S N S X S N N X S S S X X X X X X S S N N N S N N N N S S N S N

118

Cobrana de Fretes Meio de Transporte Tipo de Entrega Peso R$ 100/Kg R$ 50/Kg R$ 10/Kg X X X X F R L F R P F N L F N P R R L X X X X R R P R N L R N P M R L X X X X M R P M N L M N P

Meio de Transporte: Ferrovirio (F), Rodovirio (R), Martimo (M). Tipo de Entrega: Rpida (R) at 5 dias teis; Normal (N) at 30 dias. Peso: Leve (L): 100kg; Pesado (P): > 100Kg Figura 8.18 Tabela de Entrada Ampliada. Muitas vezes, grupos de condies levam mesma ao. Para estes casos, podemos utilizar tabelas compactadas, como a do exemplo 8.19.

Tratamento de Clientes Volume de Negcios R$ 1 milho? Atraso de pagamento registrado? Tempo de trabalho 20 anos? Tratamento Prioritrio Tratamento Normal Figura 8.19 Tabela Compactada. Quando uma nica tabela se tornar muito grande ou complexa, podemos utilizar tabelas encadeadas, onde uma tabela faz referncia a outra, como mostra o exemplo da figura 8.20. S N X S S S X X X S S N N -

119

Tratamento de Clientes - 1 Volume de Negcios R$ 1 milho? Tratamento de Clientes - 2 Tratamento Normal Tratamento de Clientes - 2 Atraso de pagamento registrado? Tempo de trabalho 20 anos? Tratamento Prioritrio Tratamento Normal Figura 8.20 Tabelas Encadeadas. Referncias Bibliogrficas [De Marco83] [Gane83] [Gane88] [Yourdon90] T. De Marco. Anlise Estruturada e Especificao de Sistemas. Editora Campus, 1983. C. Gane, T. Sarson. Anlise Estruturada de Sistemas. Livros Tcnicos e Cientficos Editora, 1983. C. Gane. Desenvolvimento Rpido de Sistemas. Livros Tcnicos e Cientficos Editora, 1988. E. Yourdon. Anlise Estruturada Moderna. Editora Campus, 1990. N S X N N X S S X X S N S X X N

120