Apostila de Análise de Sistemas, Notas de estudo de Informática

Baixe Apostila de Análise de Sistemas e outras Notas de estudo em PDF para Informática, somente na Docsity! UFES - Universidade Federal do Espírito Santo Análise de Sistemas Notas de Aula Ricardo de Almeida Falbo E-mail: falbo@inf.ufes.br 2002/2 Índice Capítulo 1 - Introdução 1 1.1 – Análise e Especificação de Requisitos 1 1.2 – A Organização deste Texto 2 PARTE I – ESPECIFICAÇÃO DE REQUISITOS 3 Capítulo 2 – Técnicas de Levantamento de Requisitos 4 2.1 – Amostragem 4 2.2 – Investigação 7 2.3 – Entrevistas 8 2.4 – Questionários 13 2.5 – Observação 18 2.6 – Prototipação 20 Capítulo 3 – Modelagem de Casos de Uso 23 3.1 – Casos de Uso 23 3.2 – Diagramas de Casos de Uso 25 3.3 – Descrição de Casos de Uso 26 3.4 – Associações entre Casos de Uso 28 PARTE II – ANÁLISE ORIENTADA A OBJETOS 33 Capítulo 4 – Introdução à Orientação a Objetos 34 4.1 – Abordagem Estruturada x Abordagem Orientada a Objetos 34 4.2 – Conceitos da Orientação a Objetos 36 4.3 – Processo de Desenvolvimento Orientado a Objetos 47 4.4 – A Linguagem de Modelagem Unificada 56 Capítulo 5 - Análise Orientada a Objetos 59 5.1 - Identificação de Classes 60 5.2 - Especificação de Hierarquias de Generalização / Especialização 62 5.3 - Identificação de Subsistemas 63 5.4 - Identificação de Associações e Definição de Atributos 64 5.5 - Determinação do Comportamento 69 5.6 - Definição das Operações 72 PARTE III – ANÁLISE ESSENCIAL DE SISTEMAS 75 Capítulo 6 – Introdução à Análise Essencial 76 6.1 - Conceitos 77 6.2 - Especificação da Essência do Sistema 82 Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.1 - Introdução 2 UFES Departamento de Informática A etapa de Elicitação de Requisitos (ou Especificação de Requisitos) é independente de paradigma, uma vez que trata os requisitos do sistema sob uma perspectiva externa. Entretanto, a atividade de Análise, que modela as estruturas internas de um sistema, é completamente dependente do paradigma adotado no desenvolvimento. Assim, este texto é dividido em três partes: • PARTE I - ESPECIFICAÇÃO DE REQUISITOS: trata do levantamento e da modelagem dos requisitos segundo uma perspectiva externa, independente de paradigma. Nesta parte, são discutidas técnicas para levantamento de requisitos e a técnica de modelagem de casos de uso, para modelagem dos requisitos funcionais de um sistema. • PARTE II - ANÁLISE ORIENTADA A OBJETOS: apresenta os principais conceitos da orientação a objetos e a linguagem de modelagem unificada (UML) e explora a modelagem de análise segundo o paradigma de objetos. • PARTE III - ANÁLISE ESSENCIAL DE SISTEMAS: apresenta os principais conceitos da análise essencial e discute a modelagem de análise segundo o método da análise essencial, que adota o paradigma estruturado. 1.2 - A Organização deste Texto Este texto procura oferecer uma visão geral atividade de Análise e Especificação de Requisitos e contém, além desta Introdução, mais sete capítulos, divididos em três partes. Na PARTE I, o capítulo 2 – Técnicas de Levantamento de Requisitos – apresenta as principais técnicas utilizadas na identificação dos requisitos de um sistema. O capítulo 3 – Modelagem de Casos de Uso – trata da modelagem de requisitos funcionais, utilizando a técnica de modelagem de casos de uso. Na PARTE II, o enfoque recai sobre o paradigma orientado a objetos (OO). O capítulo 4 – Introdução à Orientação a Objetos – discute os principais conceitos da orientação 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 capítulo 5 – Análise Orientada a Objetos – discute a modelagem de análise segundo o paradigma OO, utilizando os modelos propostos na UML. Finalmente, na PARTE III, discute-se a Análise Essencial. O capítulo 6 – Introdução à Análise Essencial – apresenta os principais conceitos e modelos utilizados na Análise Essencial. O capítulo 7 – Modelagem de Dados – apresenta o modelo de Entidades e Relacionamentos. No capítulo 8 – Modelagem Funcional – o foco é a técnica de Diagramas de Fluxos de Dados. 3 PARTE I – ESPECIFICAÇÃO DE REQUISITOS Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 4 UFES Departamento de Informática 2 – Técnicas de Levantamento de Requisitos (Referência: [Kendall92]) Em todo desenvolvimento de software, um aspecto fundamental é a captura dos requisitos dos usuários. Para apoiar este trabalho, diversas técnicas podem ser utilizadas. 2.1 – Amostragem (Referência: Capítulo 4 [Kendall92]) Em um levantamento de requisitos, geralmente um engenheiro de software se depara com duas importantes questões: • Entre os muitos relatórios, formulários e documentos gerados pelos membros de uma organização, quais deverão ser objeto de investigação? • Pode haver um grande número de pessoas afetadas pelo sistema de informação proposto. Quais delas devem ser entrevistadas, observadas ou questionadas? Servindo de base para todas as técnicas de levantamento de requisitos, entre elas investigação, entrevistas e observação, estão as decisões cruciais dizendo respeito a o que examinar e quem questionar ou observar. Estas decisões podem ser apoiadas por uma abordagem estruturada chamada amostragem. Amostragem é o processo de seleção sistemática de elementos representativos de uma população. Quando os elementos selecionados em uma amostragem são analisados, pode-se assumir que esta análise revelará informações úteis acerca da população como um todo. Por que usar amostragem? • diminuir custos; • acelerar o processo de levantamento de informações; • eficiência: a informação tende a ser mais apurada, já que menos elementos podem ser analisados, mas estes podem ser analisados com mais detalhes; • reduzir tendências. 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 técnica de levantamento de informação será usado depois. Coletar dados irrelevantes representa perda de tempo. 2. Determinar a população a ser amostrada (o que / quem): No caso de documentos, definir quais documentos investigar e de que período / intervalo. No caso de pessoas, estabelecer a que nível da organização pertencem ou se são 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 à técnica de amostragem propriamente dita e são detalhados a seguir. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 7 UFES Departamento de Informática 2.2 – Investigação (Referência: Capítulo 4 [Kendall92]) Muitas vezes, algumas informações são difíceis de serem obtidas através de entrevistas ou observação. Tais informações revelam, tipicamente, um histórico da organização e sua direção. Nestes casos, devemos utilizar investigação, isto é, análise de documentos. Através de investigação, podemos obter mais facilmente informações, tais como tipos de documentos e problemas associados, informação financeira e contextos da organização. Tais informações são difíceis de serem obtidas através de outras técnicas de levantamento de requisitos, tais como entrevistas ou observação. Análise de Documentos Quantitativos Documentos com formato pré-determinado, tais como relatórios e formulários, trazem informações muito úteis a um engenheiro de software. Estes documentos têm um propósito específico e um público-alvo. Relatórios de desempenho, por exemplo, podem mostrar metas de uma organização, a distância em relação à meta e a tendência atual. Relatórios usados no processo de tomada de decisão mostram informações compiladas e podem incorporar algum conhecimento sobre a estratégia da organização. Fichas (registros) provêem atualizações periódicas do que está ocorrendo no negócio. 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 número e tipos de transações e (iv) procurar instâncias onde a introdução de um sistema computadorizado pode simplificar o trabalho (cálculos, por exemplo). Formulários, assim como fichas, são muito úteis para o levantamento de requisitos. Devem ser inspecionados tanto formulários oficiais quanto não oficiais em uso. Exemplares de formulários em branco devem ser coletados, procurando-se observar o tipo, propósito e o público alvo. Deve-se, ainda, verificar quem realmente recebe o formulário. Ao se examinar formulários preenchidos, observar se: (i) há itens não preenchidos, (ii) há formulários nunca usados, (iii) há formulários não oficiais usados regularmente e (iv) os formulários são preenchidos pelas pessoas certas. Na investigação de formulários preenchidos, é possível detectar problemas como: (i) a informação não flui como planejado, (ii) pontos de gargalo no processamento de formulários, (iii) trabalho duplicado desnecessariamente, e (iv) falta de visão do fluxo global da informação, isto é, porque um formulário é preenchido e quem o utilizará. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 8 UFES Departamento de Informática Análise de Documentos Qualitativos Documentos sem formato pré-determinado, tais como memorandos, quadros de aviso e manuais, também são úteis para o levantamento de requisitos, uma vez que mostram como os membros de uma organização são engajados nos processos da mesma. A análise de documentos qualitativos deve envolver as seguintes tarefas: • Examinar documentos para identificar como os elementos da organização são referenciados e, assim, conhecer a organização. • Identificar disputas (entre departamentos ou com outras empresas) e, assim, conhecer a política da organização. • Identificar termos que aparecem repetidamente em documentos e caracterizem o que é “bom” ou “ruim” para a organização. • Reconhecer a existência de senso de humor nos documentos, o que pode indicar o tipo dos membros da organização (por exemplo, conservadores, ...). Ao analisar memorandos (inclusive os eletrônicos), dê preferência àqueles enviados para toda a organização. Observe quem enviou e quem recebeu. Memorandos, tipicamente fluem horizontalmente ou de cima para baixo e provêem uma idéia clara de valores, crenças e atitudes dos membros da organização. Na investigação de sinais e quadros de aviso, procure por indícios que apontem a cultura da organização. Ex: Segurança em 1o Lugar. Finalmente, ao analisar manuais e políticas organizacionais, procure identificar como as coisas devem funcionar, como as metas estratégicas da organização devem ser atingidas e verifique se estes passos estão sendo seguidos ou não. Tanto na análise de dados qualitativos quanto de dados quantitativos, procure observar não só os documentos correntes, mas também documentos arquivados. 2.3 – Entrevistas (Referência: Capítulo 5 [Kendall92]) Uma entrevista de levantamento de informações é uma conversa direcionada com um propósito específico, que utiliza um formato “pergunta-resposta”. Os objetivos de uma entrevista incluem: • obter as opiniões 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 Investigação Fatos obtidos em uma investigação podem explicar o desempenho passado. Metas projetam o futuro. Entrevistas são importantes para se determinar metas. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 9 UFES Departamento de Informática 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 confiança e entendimento; • mantenha o controle da entrevista; • venda a “idéia do sistema”, provendo ao entrevistado as informações necessárias. Uma entrevista envolve as seguintes etapas principais: planejamento, condução e elaboração de um relatório da entrevista. 2.3.1 - Planejamento O planejamento de uma entrevista envolve os seguintes passos: 1. Estudar material existente sobre os entrevistados e suas organizações. Procure dar atenção especial à linguagem usada pelos membros da organização, procurando estabelecer um vocabulário comum a ser usado na elaboração das questões da entrevista. Este passo visa, sobretudo, otimizar o tempo despendido nas entrevistas, evitando-se perguntar questões básicas 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 informação e ao comportamento na tomada de decisão, tais como fontes de informação, formatos da informação, freqüência na tomada de decisão, estilo da tomada de decisão, etc. 3. Decidir quem entrevistar. É importante incluir na lista de entrevistados pessoas-chave de todos os níveis da organização afetados pelo sistema. A pessoa de contato na organização pode ajudar nesta seleção. Quando necessário, use amostragem. 4. Preparar a entrevista. Uma entrevista deve ser marcada com antecedência e deve ter uma duração entre 45 minutos e uma hora. 5. Decidir sobre os tipos de questões e a estrutura da entrevista. O uso de técnicas apropriadas de questionamento é o “coração” de uma entrevista. 6. Decidir como registrar a entrevista. Entrevistas devem ser registradas para que informações obtidas não sejam perdidas logo em seguida. Os meios mais naturais de se registrar uma entrevista incluem anotações e o uso de gravador. Tipos de Questões Questões podem ser de três tipos básicos: • Questões subjetivas: permitem respostas “abertas”. Ex: O que você acha de ...? Explique como você ...? Vantagens: Provêem riqueza de detalhes. Revelam novos questionamentos. Colocam o entrevistado a vontade. Permitem maior espontaneidade. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 12 UFES Departamento de Informática Entrevistas Estruturadas x Não Estruturadas Não Estruturada Estruturada Avaliação Difícil Fácil Tempo Requerido Alto Baixo a Médio Treinamento Requerido Muito Limitado Espontaneidade Alta Baixa “Insight” do Entrevistado Muita Oportunidade Pouca Flexibilidade Alta Baixa Controle Baixo Alto Precisão Baixa Alta Confiabilidade Baixa a Média Média a Alta Amplitude e Profundidade Alta Baixa a Média Tabela 2.3 – Comparação entre as Abordagens Estruturada e Não Estruturada. Registro da Entrevista É importante registrar os principais aspectos de uma entrevista durante a sua realização. No planejamento, deve-se definir como isto será feito. Há duas formas principais, cujas vantagens e desvantagens são apresentadas a seguir: • Gravador: requer a permissão do entrevistado. Vantagens: Registro completo da entrevista. Rapidez e melhor desenvolvimento. Reprodução para outros membros da equipe. Desvantagens: Pode deixar o entrevistado pouco a vontade. Pode deixar o entrevistador distraído. Pode haver necessidade de transcrever a fita. • Anotações Vantagens: Mantém o entrevistador alerta. Pode ser usado para fornecer um roteiro para a entrevista. Mostra interesse e preparação do entrevistador. Desvantagens: Perda do andamento da conversa. Excessiva atenção a fatos e pouca a sentimentos e opiniões. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 13 UFES Departamento de Informática 2.3.2 – Condução da Entrevista − Um dia antes, entre em contato com o entrevistado para confirmar o horário e o local da entrevista. − Chegue um pouco antes do horário marcado. − Apresente-se e esboçe brevemente os objetivos da entrevista. − Relembre o entrevistado de que você estará registrando pontos importantes. Se for usar gravador, coloque-o em local visível. − Diga ao entrevistado o que será feito com as informações coletadas e re-assegure seu aspecto confidencial. − A entrevista deve durar entre 45 minutos e uma hora. − Quando estiver incerto sobre uma questão, peça para o entrevistado dar definições ou outros esclarecimentos. Use questões de aprofundamento. − Ao término da entrevista, pergunte se há algo mais sobre o assunto que o entrevistado ache importante você saber. − Faça um resumo da entrevista e dê suas impressões 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 – Relatório da Entrevista O relatório ou ata da entrevista deve capturar a essência da entrevista. Escreva o relatório tão rápido quanto possível para assegurar qualidade. Registre entrevistado, entrevistador, data, assunto e objetivos. Diga se os objetivos foram alcançados e aponte objetivos para entrevistas futuras. Registre, ainda, os pontos principais da entrevista e sua opinião. 2.4 – Questionários (Referência: Capítulo 6 [Kendall92]) O uso de questionários constitui uma técnica de levantamento de informações que permite ao engenheiro de software obter de várias pessoas afetadas pelo sistema (corrente ou proposto) informações, tais como: • Posturas: o que as pessoas na organização dizem querer; • Crenças: o que as pessoas pensam ser realmente verdade; • Comportamento: o que as pessoas fazem; • Características: propriedades de pessoas ou coisas. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 14 UFES Departamento de Informática Um questionário pode ter objetivos distintos, em função de sua aplicação, 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 usuários do sistema para sentir problemas ou levantar questões importantes, antes de se programar entrevistas. Há muitas similaridades entre estas duas técnicas. De fato, pode ser útil utilizar as duas abordagens em conjunto: • procurando refinar respostas não claras de um questionário em uma entrevista; • projetando um questionário com base no que foi levantado em uma entrevista. Questionários: Quando Usar? • As pessoas estão espalhadas por toda a organização. • Há um grande número de pessoas envolvidas no projeto do sistema e é necessário saber que proporção de um dado grupo aprova ou desaprova uma particular característica do sistema proposto. • Em estudos exploratórios, quando se deseja saber uma opinião global antes de se definir qualquer direção específica para o projeto. Etapas do Processo de Uso de Questionários Assim como as entrevistas, para se empregar questionários, um conjunto de passos deve ser realizado, envolvendo pelo menos planejamento, aplicação e análise. 2.4.1 – Planejamento No planejamento de um questionário, devem ser levados em consideração aspectos relacionados com a redação das questões, escalas, formato e ordem das questões. Redação das Questões Uma vez que questionários e entrevistas seguem uma abordagem “pergunta-resposta”, seria bastante razoável pensar que a considerações feitas para entrevistas aplicam-se também para questionários. Contudo, é importante ressaltar que há diferenças fundamentais entre estas técnicas e, portanto, novos aspectos devem ser considerados. Em primeiro lugar, entrevistas permitem interação direta com o entrevistado a respeito das questões e seus significados. Em uma entrevista, o engenheiro de software pode refinar uma questão, definir um termo obscuro, alterar o curso do questionamento e controlar o contexto de modo geral. Isto não é necessariamente verdade para um questionário e, portanto, o planejamento de um questionário e de suas questões deve ser mais cuidadoso. Um questionário deve: • ter questões claras e não ambíguas, • ter fluxo bem definido, Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 17 UFES Departamento de Informática Projeto do Questionário Estilo Um formulário bem projetado (aspectos de estilo) pode aumentar taxa de respostas. As seguintes diretrizes podem ser úteis na hora de se projetar um questionário: • Deixe amplos espaços em branco para atrair as pessoas. • Deixe espaço suficiente para as respostas das questões subjetivas. • Em questões com escala, peça para fazer um círculo na resposta. • Use os objetivos do questionário para ajudar a determinar o formato (inclusive instruções). • Seja consistente no estilo. Coloque instruções sempre no mesmo local em relação ao lay-out do questionário, para facilitar a localização das instruções. Use letras maiúsculas e minúsculas nas perguntas e apenas letras maiúsculas nas respostas. Ordem das Questões Para ordenar as questões, considere os objetivos e, então, determine a função de cada questão para atingir esses objetivos. Use um grupo piloto para auxiliar ou observe o questionário com olhos de respondedor. Algumas orientações devem ser seguidas: • As primeiras questões devem ser de interesse dos respondedores. • Agrupe itens de conteúdo similar e observe tendências de associação. • Coloque os itens de menor controvérsia primeiro. 2.4.2 – Aplicação do Questionário A primeira questão a ser definida é: quem deve responder o questionário? A decisão de quem deve responder o questionário é feita em conjunto com o estabelecimento dos seus objetivos. Quando houver muitas pessoas aptas a responder o questionário, use amostragem. Métodos de Aplicação • Reunir todos os respondedores em um mesmo local para a aplicação do questionário. Vantagens: 100% de retorno Instruções uniformes Resultado rápido Problemas: Pode ser difícil reunir todas as pessoas. O respondedor pode ter coisas importantes a fazer. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 18 UFES Departamento de Informática • Analista entrega e recolhe cada questionário individualmente. Vantagens: Boa taxa de resposta Problemas: Desperdício do tempo do analista. O respondedor pode ser identificado. • Respondedor administra o questionário. 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 devolução. • Por correspondência. Útil somente para alcançar pessoas distribuídas geograficamente. 2.5 - Observação (Referência: Capítulo 7 [Kendall92]) Observar o comportamento e o ambiente do indivíduo que toma decisões pode ser uma forma bastante eficaz de levantar informações que, tipicamente, passam desapercebidas usando outras técnicas. Tomadas de decisão ocorrem em diversos níveis da organização: operacional, gerencial e estratégico e, portanto, é importante observá-las em todos os níveis que tenham interação com o sistema. Através da observação é possível capturar: • o que realmente é feito e não apenas o que é documentado ou explicado. • o relacionamento entre o “tomador de decisão” e outros membros da organização. A observação é usada para: • obter informações sobre o “tomador de decisão” e seu ambiente, que não são capturadas por outras técnicas. • confirmar ou negar informações de entrevistas e/ou questionários. Alguns pontos importantes devem ser realçados: o analista deve saber o que observar, quem observar, quando, onde, porque e como. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 19 UFES Departamento de Informática Observação do Comportamento Permite observar como um gerente obtém, processa, compartilha e usa a informação para executar seu trabalho. No planejamento da observação do comportamento, os seguintes passos devem ser realizados: 1. Decidir o que observar (atividades). 2. Decidir em que nível de detalhe a atividade deve ser observada. 3. Preparar material para a observação. 4. Decidir quando observar • Amostragem de Horários: períodos para observação escolhidos aleatoriamente. Evita tendências, mas não permite a observação completa de um evento e tão pouco de um evento pouco freqüente. • Amostragem de Eventos: observação de eventos completos. O ideal é combinar estas duas abordagens. A observação deve ser registrada. Para tal, na preparação do material para a observação, as seguintes abordagens podem ser empregadas: • Pares de adjetivos: estabeleça pares de adjetivos que capturem adequadamente o comportamento do indivíduo durante a tomada de decisão, tais como, decidido/ indeciso, confidencial/não confidencial, etc. • Categorias: defina previamente categorias de atividades e durante a observação anote sua ocorrência ou não. Ex: O Gerente instrui subordinados questiona subordinados lê informação externa processa informações • Scripts: Para cada indivíduo observado, escreva uma lista de atividades por ele desempenhadas. O “tomador de decisão” é o ator, que é observado atuando, isto é, tomando decisões. Observação de Ambiente Físico O “tomador de decisão” influencia e é influenciado pelo seu meio físico. A observação do ambiente físico tem uma forte analogia com a crítica de filmes. Muitas vezes, é possível observar particularidades do ambiente físico que confirmam ou negam narrativas encontradas em entrevistas e questionários. Uma forma sistemática de se proceder uma observação do ambiente físico é a chamada observação estruturada do ambiente. Ela é sistemática porque provê uma abordagem padrão para análise de elementos que influenciam a tomada de decisão, permitindo que vários engenheiros de software utilizem uma mesma base. Dentre os elementos a serem observados, destacam-se: • Localização do escritório em relação a outros escritórios: Escritórios de fácil acesso tendem a aumentar a freqüência de interação e o fluxo de mensagens Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.2 – Técnicas de Levantamento de Requisitos 22 UFES Departamento de Informática Problemas da Prototipação • Gerência do projeto: Normalmente, várias iterações são necessárias para se refinar um protótipo. Sob esta ótica, surge uma importante questão: quando parar? Se esta questão não for tratada com cuidado, a prototipação pode se estender indefinidamente. É importante, pois, delinear e seguir um plano para coletar, analisar e interpretar as informações de realimentação do usuário. • Considerar o protótipo como sendo o sistema final: a qualidade pode não ter sido apropriadamente considerada. Vantagens da Prototipação • Permite alterar o sistema mais cedo no desenvolvimento, adequando-o mais de perto às necessidades do usuário (menor custo de uma alteração). • Permite descartar um sistema quando este se mostrar inadequado (protótipo de viabilidade). • Possibilidade de desenvolver um sistema que atenda mais de perto as necessidades e expectativas dos usuários. Permite uma interação com o usuário ao longo de todo o ciclo de vida do desenvolvimento. Referências do Capítulo: [Kendall92] K.E. Kendall, J.E. Kendall; Systems Analysis and Design, Prentice Hall, 1992. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 – Modelagem de Casos de Uso 23 UFES Departamento de Informática 3 – Modelagem de Casos de Uso Quando um novo sistema precisa ser construído, surge uma importante questão: Como caracterizar os requisitos do sistema de um modo adequado para a Engenharia de Software, uma vez que, é necessário identificar quais os objetos/entidades relevantes, como eles se relacionam e como se comportam no contexto do sistema. Além disso, é preciso especificar e modelar o problema de maneira que seja possível criar um projeto efetivo. O desenvolvimento de sistemas é um processo de construção de modelos, que tipicamente começa com um modelo de requisitos e termina com um modelo de implementação (código). Modelos de objetos (diagramas de classes, diagramas de interação, 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 associações, como eles interagem dinamicamente e como invocam o comportamento dos demais. Estas informações são necessárias para projetar e construir um sistema, mas não são suficientes para comunicar requisitos. Elas não capturam o conhecimento sobre as tarefas do domínio e, portanto, é difícil verificar se um modelo deste tipo realmente corresponde ao sistema que tem de ser construído [Jacobson96]. Assim, o primeiro modelo do sistema a ser construído deve ser passível de compreensão tanto por desenvolvedores - analistas, projetistas, programadores e testadores - como pela comunidade usuária - clientes e usuários. Modelos estruturados e de objetos são muito complexos e, portanto, não servem para este propósito. Este modelo inicial deve descrever o sistema, seu ambiente e como sistema e ambiente estão relacionados. Em outras palavras, ele deve descrever o sistema segundo uma perspectiva externa. Modelos de caso de uso (use cases) são uma forma de estruturar esta visão externa. Como o próprio nome sugere, um caso de uso é uma maneira de usar o sistema. Usuários interagem com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casos de uso de um sistema representam tudo que os usuários podem fazer com este sistema. Casos de uso são os “itens” que um desenvolvedor vende a seus clientes. Deve-se notar que modelos de caso de uso são independentes do método de análise a ser usado. Desenvolvedores devem modelar os casos de uso explicitamente bem no início 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 começa pelo entendimento de como o sistema será usado. Uma vez que as maneiras de usar o sistema tenham sido definidas, a modelagem pode, então, 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 propósito 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 descrição de um conjunto de seqüências de ações realizadas pelo sistema para produzir um resultado de valor observável por um ator [Booch00]. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 – Modelagem de Casos de Uso 24 UFES Departamento de Informática Em essência, um caso de uso (use case) é uma interação típica entre um ator (usuário humano, outro sistema computacional ou um dispositivo) e um sistema. Um caso de uso captura alguma função visível ao ator e, em especial, busca atingir uma meta do usuário [Fowler97]. Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os usuários finais do sistema e com os especialistas do domínio. Além disso, servem para ajudar a validar e verificar o sistema à medida que ele evolui durante seu desenvolvimento. Assim, os casos de uso não apenas representam o comportamento desejado do sistema, mas também podem ser utilizados como a base de casos de teste para o sistema, principalmente os testes de integração e de sistema [Booch00]. Casos de uso têm dois importantes papéis: 1. Eles capturam os requisitos funcionais de um sistema. Um modelo de caso de uso define o comportamento de um sistema (e a informação associada) através de um conjunto de casos de uso. O ambiente do sistema é definido pela descrição dos diferentes usuários. Estes usuários utilizam o sistema através de um número 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 número de diferentes visões. Em uma abordagem guiada por casos de uso, pode-se construir uma visão para cada caso de uso, isto é, em cada visão são modelados apenas aqueles elementos que participam de um caso de uso específico. Um particular elemento pode, é claro, participar de vários casos de uso. Isto significa que um modelo do sistema completo só é visto através de um conjunto de visões - 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. Além de serem uma ferramenta essencial na captura dos requisitos de um sistema, casos de uso têm 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 não é capturado, não é possível planejar como tratá-lo. Usualmente, em primeiro lugar, casos de uso são listados e discutidos, para só então, se realizar alguma modelagem. Entretanto, em alguns casos, a modelagem conceitual ajuda a descobrir casos de uso. Um caso de uso pode ser capturado através de conversas com usuários típicos, discutindo as várias coisas que eles querem fazer com o sistema. Cada uma dessas interações discretas constitui um caso de uso. Dê a ela um nome e escreva uma descrição textual pequena (não mais do que uns poucos parágrafos). Não tente capturar todos os detalhes de um caso de uso logo no início. Os objetivos do usuário podem ser o ponto de partida para a elaboração dos casos de uso. Proponha um caso de uso para satisfazer cada um dos objetivos do usuário. A partir deles, estude as possíveis interações do usuário com o sistema e refine o modelo de casos de uso. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 – Modelagem de Casos de Uso 27 UFES Departamento de Informática 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 saudação está sendo mostrada na tela. O cliente insere seu cartão no caixa automático, que lê o código da tarja magnética e checa se ele é aceitável. Se o cartão é aceitável, 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 transação e fica aguardando. O cliente seleciona a opção saque. O caixa mostra uma tela para que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisição para o sistema bancário para que seja efetuado um saque na quantia especificada. Se o saque é autorizado, as notas são preparadas para serem entregues, o cartão é ejetado, um recibo é emitido e as notas liberadas. Cursos Alternativos • O cartão não é aceitável: Se o cartão não é aceitável porque sua tarja magnética não é passível de leitura ou é de um tipo incompatível, o cartão é 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 três vezes senha incorreta, o cartão deverá ser confiscado. • Saque não autorizado: Se o saque não for aceito pelo Sistema Bancário, uma mensagem informando o cliente é mostrada por 10 segundos e o cartão é ejetado. • Cancelamento: O cliente pode sempre cancelar a transação em qualquer momento que lhe seja perguntada alguma informação. Isto resultará na ejeção do cartão e no término da transação. Como visto pelo exemplo anterior, um caso de uso pode ter um número de cursos alternativos que podem levar o caso de uso por diferentes fluxos. Tanto quanto possível, esses cursos alternativos, freqüentemente cursos de exceção, devem ser anotados durante a especificação de um caso do uso. Cliente Efetuar Saque Emitir Extrato Sistema Bancário Informar Saldo Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 – Modelagem de Casos de Uso 28 UFES Departamento de Informática 3.4 - Associações entre Casos de Uso Uma vez que um modelo de caso de uso expressa apenas a visão externa do sistema, comunicações internas entre elementos dentro do sistema não devem ser modeladas. Contudo, para permitir uma descrição mais apurada dos casos de uso em um diagrama, três tipos de relacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser descritos como versões especializadas de outros casos de uso (relacionamento de generalização/ especialização); casos de uso podem ser incluídos como parte de outro caso de uso (relacionamento de inclusão); ou casos de uso podem estender o comportamento de um outro caso de uso básico (relacionamento de extensão). O objetivo desses relacionamentos é tornar um modelo mais compreensível, evitar redundâncias entre casos de uso e permitir descrever casos de uso em camadas. O relacionamento de inclusão 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 é incluído deve ser indicado na descrição do caso de uso base, através de uma referência explícita à chamada ao caso de uso incluído. Um relacionamento de inclusão é empregado quando há uma porção de comportamento que é similar ao longo de um ou mais casos de uso e não se deseja repetir a sua descrição. Para evitar redundância e assegurar reuso, extrai-se essa descrição e compartilha-se a mesma entre diferentes casos de uso. Um relacionamento de inclusão é representado por uma dependência, estereotipada como inclui (include), como mostra a figura 3.3. No exemplo do caixa automático, podemos perceber que todos os três casos de uso têm em comum uma porção que diz respeito à transação inicial do cartão. Neste caso, um relacionamento inclui deve ser empregado, como mostra a figura 3.3. 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 saudação está sendo mostrada na tela. O cliente insere seu cartão no caixa automático, que lê o código da tarja magnética e checa se ele é aceitável. Efetuar Saque Emitir Extrato Informar Saldo Validar Cliente <<inclui>> <<inclui>> <<inclui>> Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 – Modelagem de Casos de Uso 29 UFES Departamento de Informática Se o cartão é aceitável, 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 transação e fica aguardando. Cursos Alternativos • O cartão não é aceitável: Se o cartão não é aceitável porque sua tarja magnética não é passível de leitura ou é de um tipo incompatível, o cartão é 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 três vezes uma senha incorreta, o cartão deverá ser confiscado. • Cancelamento: O cliente pode sempre cancelar a transação em qualquer momento que lhe seja perguntada alguma informação. Isto resultará na ejeção do cartão e no término da transação. Com esta captura isolada do caso de uso de Validar Cliente, o caso de uso Efetuar Saque passaria a apresentar a seguinte descrição: Curso Normal O cliente realiza o caso de uso Validar Cliente. O cliente seleciona a opção saque. O caixa mostra uma tela para que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisição para o sistema bancário para que seja efetuado um saque na quantia especificada. Se o saque é autorizado, as notas são preparadas para serem entregues, o cartão é ejetado, um recibo é emitido e as notas liberadas. Cursos Alternativos • Saque não autorizado: Se o saque não for aceito pelo Sistema Bancário, uma mensagem informando o cliente é mostrada por 10 segundos e o cartão é ejetado. • Cancelamento: O cliente pode sempre cancelar a transação em qualquer momento que lhe seja perguntada alguma informação. Isto resultará na ejeção do cartão e no término da transação. O relacionamento de generalização 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 substituído em qualquer local no qual o pai apareça [Booch00]. Voltando ao exemplo do sistema de caixa automático, suponha que haja duas formas adotadas para se validar o cliente: a primeira através de senha, como descrito anteriormente, e a segunda por meio de análise da retina do cliente. Neste caso, poderiam ser criadas duas especializações do caso de uso Validar Cliente, como mostra a figura 3.4. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.3 – Modelagem de Casos de Uso 32 UFES Departamento de Informática 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 princípios: • As funcionalidades dos casos de uso que lidam com o registro e a manipulação de informação são mapeadas diretamente para elementos em um modelo de análise. • As funcionalidades diretamente dependentes do ambiente do sistema representam funcionalidades requeridas pela interface do sistema e, portanto, são tratadas na fase de projeto, especificamente no projeto da interface do sistema. • Finalmente, funcionalidades que tipicamente envolvem o controle de uma aplicação devem ser mapeadas em elementos no projeto do controle do sistema. Referências do Capítulo: [Booch00] G. Booch, J. Rumbaugh, I. Jacobson; UML – Guia do Usuário. Editora Campus, 2000. [Fowler97] M. Fowler, K. Scott; UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley Object Technology Series, 1997. [Furlan98] J.D. Furlan; Modelagem de Objetos Através da UML; Makron Books, 1998. [Jacobson96] I. Jacobson; “The Use Case Construct in Object-Oriented Software Engineering”, In: Scenario-Based Design, 1996. Caixa Automático Contas 33 PARTE II – ANÁLISE ORIENTADA A OBJETOS Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 34 UFES Departamento de Informática 4. Introdução à Orientação a Objetos A construção de uma solução computadorizada consiste no mapeamento do problema a ser resolvido no mundo real num modelo de solução no Espaço de Soluções, isto é, o meio computacional. A modelagem envolve, então, a identificação de objetos e operações relevantes no mundo real e o mapeamento desses em representações abstratas no Espaço de Soluções. À distância existente entre o problema no mundo real e o modelo abstrato construído, convencionou-se chamar gap semântico e, obviamente, quanto menor ele for, mais direto será o mapeamento e, portanto, mais rapidamente serão construídas soluções para o problema. Sob essa ótica, é fácil perceber que o gap semântico representa a área de atuação da Engenharia de Software. Diversas técnicas e métodos têm sido propostos para as diferentes fases do processo de desenvolvimento, buscando minimizá-lo. A Orientação a Objetos é um dos paradigmas existentes para apoiar o desenvolvimento de sistemas, que busca fornecer meios para se diminuir o gap semântico. Este capítulo visa introduzir os principais conceitos e benefícios da orientação a objetos. 4.1 – Abordagem Estruturada x Abordagem Orientada a Objetos Uma vez que, atualmente, a Orientação a Objetos tem tomado o espaço antes ocupado pelo paradigma estruturado no desenvolvimento de sistemas, é interessante fazer uma comparação entre os paradigmas que fundamentam estas abordagens: Estruturado: adota uma visão de desenvolvimento baseada em um modelo entrada- processamento-saída. No paradigma estruturado, os dados são considerados separadamente das funções que os transformam e a decomposição funcional é usada intensamente. Orientado a Objetos: pressupõe 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 são estruturados a partir dos objetos que existem no domínio do problema, isto é, os sistemas são modelados como um número de objetos que interagem. Em função do paradigma que os rege, métodos de análise e projeto de sistemas são classificados em métodos estruturados e métodos orientados a objetos. Métodos Estruturados Fazem clara distinção entre funções e dados. Funções, a princípio, são ativas e têm comportamento, enquanto dados são repositórios passivos de informação, afetados por funções. Esta divisão tem origem na arquitetura de hardware de von Neumann, onde a separação entre programa e dados é fortemente enfatizada. Os métodos orientados a funções conduzem o desenvolvimento de software estruturando as aplicações segundo a ótica das funções (ações) que o sistema deverá realizar. O sistema é decomposto em funções, e os dados são transportados entre elas. Esta é a filosofia da proposta original da Análise Estruturada [DeMarco78] [Gane79], cuja ferramenta básica de modelagem são os diagramas de fluxo de dados (DFDs). Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 37 UFES Departamento de Informática elementos relevantes são considerados. Modelos mentais, portanto, são mais simples do que os complexos sistemas que eles modelam. Consideremos, por exemplo, um mapa como um modelo do território que ele representa. Um mapa é útil porque abstrai apenas aquelas características do território que se deseja modelar. Se um mapa incluísse todos os detalhes do território, provavelmente teria o mesmo tamanho do território e, portanto, não serviria a seu propósito. Da mesma forma que um mapa precisa ser significativamente menor que o território que mapeia, incluindo apenas informações cuidadosamente selecionadas, um modelo mental abstrai apenas as características relevantes de um sistema para seu entendimento. Assim, podemos definir abstração como sendo o princípio de ignorar aspectos não relevantes de um assunto, segundo a perspectiva de um observador, tornando possível uma concentração maior nos aspectos principais do mesmo. De fato, a abstração consiste na seleção que um observador faz de alguns aspectos de um assunto, em detrimento de outros que não demonstram ser relevantes para o propósito em questão. No que tange o desenvolvimento de software, duas formas adicionais de abstração têm grande importância: a abstração de dados e a abstração de procedimentos. Figura 4.1 - A abstração enfoca as características essenciais de um objeto [Booch94]. Abstração de Dados Consiste em definir um tipo de dado conforme as operações aplicáveis aos objetos deste tipo. Os objetos só podem ser modificados e observados através dessas operações [Coad92]. Exemplo: Um tipo de dado pilha pode ser definido através das operações 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 através dessas duas operações. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 38 UFES Departamento de Informática Abstração de Procedimentos Segundo esse princípio, uma operação com um efeito bem definido pode ser tratada por seus usuários como uma entidade única, mesmo que a operação seja realmente conseguida através de alguma seqüência de operações de nível mais baixo. Exemplo: Seja a operação calcular-salário-líquido de um objeto do tipo funcionário. Essa operação pode ser tratada por seus usuários como uma entidade única, mesmo que ela seja, na realidade, construída como uma seqüência de operações de nível mais baixo, tais como: calcular-INSS, calcular-IR, calcular-anuênio, etc. Encapsulamento No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamento interno. Uma pessoa, por exemplo, geralmente utiliza uma televisão sem saber efetivamente qual a sua estrutura interna ou como seus mecanismos internos são ativados. Para utilizá-la, basta saber realizar algumas operações básicas, tais como ligar/desligar a TV, mudar de um canal para outro, regular volume, cor, etc. Como estas operações produzem seus resultados, mostrando um programa na tela, não interessa ao telespectador. O encapsulamento consiste na separação dos aspectos externos de um objeto, acessíveis por outros objetos, de seus detalhes internos de implementação, que ficam ocultos dos demais objetos [Rumbaugh94]. A interface de comunicação de um objeto deve ser definida de forma a revelar o menos possível sobre o seu funcionamento interno. Figura 4.2 - O encapsulamento oculta os detalhes de implementação de um objeto [Booch94]. Abstração e encapsulamento são conceitos complementares: enquanto a abstração enfoca o comportamento observável de um objeto, o encapsulamento enfoca a implementação que origina esse comportamento. Encapsulamento é freqüentemente conseguido através do ocultamento de informação, isto é, escondendo detalhes que não contribuem para suas características essenciais. Tipicamente, em um sistema orientado a objetos, a estrutura de um objeto, e a implementação de seus métodos, são encapsuladas [Booch94]. Por exemplo, para usar um carro, uma pessoa não precisa conhecer sua estrutura interna (motor, caixa de marcha, etc...), nem tão pouco como se dá a implementação de seus métodos. Sabe-se que é necessário ligar o carro, mas não é preciso saber como esta operação é implementada. Assim, sobre carros, um motorista precisa conhecer apenas as operações que Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 39 UFES Departamento de Informática permite utilizá-lo, a que chamamos de interface do objeto, o que inclui a ativação de operações, tais como ligar, mudar as marchas, acelerar, frear, etc..., e não como essas operações são de fato implementadas. Encapsulamento serve para separar a interface contratual de uma abstração e sua implementação. Os usuários têm conhecimento apenas das operações que podem ser requistadas e precisam estar cientes apenas do que as operações realizam e não como elas estão implementadas. A principal motivação para o encapsulamento é facilitar a reutilização de objetos e garantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base para a localização de decisões de projeto que necessitam ser alteradas. Uma operação pode ter sido implementada de maneira ineficiente e, portanto, pode ser necessário escolher um novo algoritmo. Se a operação está encapsulada, apenas o objeto que a define precisa ser modificado, garantindo estabilidade ao sistema. Modularidade Muitos métodos de construção de software buscam obter sistemas modulares, isto é, construídos a partir de elementos que sejam autônomos, 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 módulos coesos e fracamente acoplados. Assim, abstração, encapsulamento e modularidade são princípios sinergéticos1. Um objeto provê uma fronteira clara em torno de uma abstração e o encapsulamento e a modularidade provêem barreiras em torno dessa abstração [Booch94]. Hierarquia Abstração é um princípio importantíssimo, mas em todas as aplicações, exceto aquelas mais triviais, deparamo-nos com um número de abstrações maior do que conseguimos compreender em um dado momento. O encapsulamento ajuda a gerenciar esta complexidade através do ocultamento da visão interna de nossas abstrações. Modularidade auxilia também, dando-nos um meio de agrupar logicamente abstrações relacionadas. Entretanto, isto ainda não é o bastante. Um conjunto de abstrações freqüentemente forma uma hierarquia e, pela identificação dessas hierarquias, é possível simplificar significativamente o entendimento sobre um problema [Booch94]. Em suma, hierarquia é uma forma de arrumar as abstrações. 4.2.2 - Conceitos Básicos Objetos O mundo real é povoado por elementos que interagem entre si, onde cada um deles desempenha um papel específico. A esses elementos, chamamos objetos. Objetos podem ser coisas concretas ou abstratas, tais como um carro, uma reserva de passagem aérea, uma organização, 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 abstração relevante no contexto de uma aplicação. Um objeto possui um estado 1 Sinergia: esforço simultâneo de vários elementos para a realização de uma ação. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 42 UFES Departamento de Informática Alguns autores utilizam os conceitos de classe e tipo indistintamente. Entretanto, um tipo e uma classe não são a mesma coisa. Um tipo é definido por um conjunto de operações, isto é, pelas manipulações que podemos fazer com o tipo. Uma classe é mais do que isso. Podemos também olhar para dentro de uma classe, por exemplo, para ver sua estrutura de informação. Assim, uma classe é melhor conceituada como uma implementação específica de um tipo [Jacobson92]. Mecanismos de Estruturação Em qualquer sistema, objetos relacionam-se uns com os outros. Em sistemas não triviais, por sua vez, geralmente nos deparamos com uma razoável quantidade de objetos e classes e há necessidade de lidar com esta complexidade. Assim, é preciso estruturar classes e objetos. Vários mecanismos têm sido propostos, entre eles, associação, composição e herança. Ligações e Associações Objetos relacionam-se com outros objetos. Por exemplo, em “o empregado João trabalha no departamento de Pessoal”, temos um relacionamento entre o objeto empregado João e o objeto departamento Pessoal. Ligações e associações são meios de se representar relacionamentos entre objetos e entre classes, respectivamente. Uma ligação é uma conexão entre objetos. No exemplo anterior, há uma ligação entre os objetos João e Pessoal. Uma associação, por sua vez, descreve um conjunto de ligações com estrutura e semântica comuns. No exemplo anterior, há uma associação entre as classes empregado e departamento. Todas as ligações de uma associação interligam objetos das mesmas classes, e assim, uma associação descreve um conjunto de potenciais ligações da mesma maneira que uma classe descreve um conjunto de potenciais objetos [Rumbaugh94]. Composição ou Agregação Uma forma especial de relacionamento entre objetos é a composição ou agregação. Parte do poder dos softwares orientados a objetos advém de sua habilidade de manipular objetos complexos, como sendo compostos de vários outros objetos mais simples. Um carro, por exemplo, é composto por motor, rodas, carroceria, etc... Um motor, por sua vez, é composto de bloco, válvulas, pistões, e assim por diante. Composição é o relacionamento todo-parte/uma-parte-de onde os objetos representando os componentes de alguma coisa são associados a um objeto representando o todo. Em outras palavras, a composição é um tipo forte de associação, onde um objeto agregado é composto de vários objetos componentes [Rumbaugh94]. Generalização / Especialização Muitas vezes, um conceito geral pode ser especializado, adicionando-se novas características. Tomemos, como exemplo, o conceito que temos de estudantes. De modo geral, há características que são intrínsecas a quaisquer estudantes. Entretanto, é possível especializar este conceito para mostrar especificidades de subtipos de estudantes, tais como estudantes de 1o grau, estudantes de 2o grau, estudantes de graduação e estudantes de pós- graduação, entre outros. Da maneira inversa, pode-se extrair de um conjunto de conceitos, características comuns que, quando generalizadas, formam um conceito geral. Por exemplo, ao avaliarmos Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 43 UFES Departamento de Informática os conceitos que temos de carros, motos, caminhões e ônibus, podemos notar que esses têm características comuns que podem ser generalizadas em um supertipo veículos automotores terrestres. As abstrações de especialização e generalização são muito úteis para a estruturação de sistemas. Com elas, é possível construir hierarquias de classes, subclasses, subsubclasses, e assim por diante. A herança é um mecanismo para modelar similaridades entre classes, representando as abstrações de generalização e especialização. Através da herança, é possível tornar explícitos atributos e serviços comuns em uma hierarquia de classes. O mecanismo de herança possibilita reutilização, captura explícita de características comuns e definição incremental de classes. Freqüentemente, promove-se a herança como a idéia central para a reutilização na indústria de software. Entretanto, apesar da herança, quando adequadamente usada, ser um mecanismo muito útil em diversos contextos, incluindo reuso, ela não é um pré-requisito para a reutilização. Uma das principais vantagens da herança é facilitar a modificação de modelos. A herança 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 identificação de objetos e na construção de hierarquias de classes, utilizando o mecanismo de herança. Figura 4.5 - Uma subclasse herda estrutura e comportamento de suas superclasses [Booch94]. Muitas vezes alguns objetos não se enquadram satisfatoriamente às propriedades descritas em uma classe, tipicamente porque: • Além das propriedades descritas na classe, esses objetos possuem outras ainda não descritas; • Algumas das propriedades descritas para a classe não são adequadas aos novos objetos, sendo necessário, portanto, redefini-las ou mesmo cancelá-las. Vale ressaltar que o cancelamento de propriedades, contudo, é um indicador de que a hierarquia não está modelada adequadamente. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 44 UFES Departamento de Informática Através do mecanismo de herança, tais problemas podem ser contornados. A herança 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 características2 é chamada subclasse e a que fornece as características, superclasse. Desta forma, a herança representa uma hierarquia de abstrações na qual uma subclasse herda de uma ou mais superclasses. Tipicamente, uma subclasse aumenta ou redefine características das superclasses. Assim, se uma classe B herda de uma classe A, todas as características descritas em A tornam- se automaticamente parte de B, que ainda é livre para acrescentar novas características para seus propósitos específicos. A generalização permite abstrair, a partir de um conjunto de classes, uma classe mais geral contendo todas as características comuns. A especialização é a operação inversa e portanto, permite especializar uma classe em um número de subclasses, explicitando as diferenças entre as novas subclasses. Deste modo é possível compor a hierarquia de classes. Esses tipos de relacionamento são conhecidos também como relacionamentos “é um tipo de”, onde um objeto da subclasse também “é um tipo de” objeto da superclasse. Neste caso uma instância da subclasse é dita uma instância indireta da superclasse. Quando uma subclasse herda características de uma única superclasse, tem-se herança simples. Quando uma classe é definida a partir de duas ou mais superclasses, tem-se herança múltipla. É importante observar, no entanto, que na herança múltipla podem ocorrer dois problemas: colisão de nomes herdados a partir de diferentes superclasses e a possibilidade de herança repetida. A figura 4.6 ilustra estes dois casos. Figura 4.6 - (a) Colisão de nomes. (b) Herança repetida. No primeiro caso, a classe C herda das classes A e B. Entretanto ambas possuem uma característica com nome x. Assim, como será a característica 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 herança repetida, já que, indiretamente, a classe D herda duas vezes da classe A. O resultado líquido da herança é que desenvolvedores podem evitar a codificação de redundâncias através da localização de cada operação no nível apropriado na hierarquia de classes. 2 Usaremos o termo característica para designar estrutura (atributos) e comportamento (operações). Classe A x y Classe B w x Classe C r (a) Classe A x y Classe B w Classe C z Classe D r (b) Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 47 UFES Departamento de Informática ligação estática. No entanto, muitas vezes, a classe de um objeto só pode ser identificada quando a mensagem é realmente emitida e, portanto, o código só pode ser selecionado neste momento. Neste caso, tem-se ligação dinâmica ou tardia (late binding). Muitas vezes, polimorfismo e ligação dinâmica são confundidos. Porém, é importante frisar que ligação dinâmica significa apenas que a mensagem só é associada ao método específico 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 sistemática deve ser adotada. Várias abordagens têm sido propostas, todas objetivando a produção 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 usuários, um bom sistema deve ser correto, rápido, confiável, fácil de ser usado, eficiente, etc... • Do ponto de vista interno, ou seja, dos desenvolvedores, um bom sistema deve ser fácil de ser entendido e modificado, reutilizável, compatível com outros sistemas, portátil, etc... Além disso, a definição de um bom sistema varia, geralmente, em função de sua aplicação. Apesar de haver muitas abordagens documentadas para análise e projeto orientados a objetos, há muito pouca informação disponível sobre processos de desenvolvimento orientados a objetos. Um processo de desenvolvimento engloba um conjunto de atividades, métodos, técnicas e práticas que guiam as pessoas na produção de software, permitindo que um produto seja coerentemente criado. Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos requeridos e produzidos, os recursos, ferramentas e procedimentos necessários e a habilidade, o treinamento e a motivação do pessoal envolvido. Processos de desenvolvimento não são sempre necessários. Em pequenos projetos, desenvolvedores podem se comunicar informalmente, dado o pequeno número de pessoas envolvidas. À medida que o número de desenvolvedores cresce, contudo, os canais de comunicação informais não são mais confiáveis e um processo de desenvolvimento é, então, necessário. De fato, nestes casos, a definição de um processo de desenvolvimento é um elemento essencial para assegurar a qualidade em um projeto. Há vários aspectos a serem considerados na definição de um processo de software. No centro de sua arquitetura estão as atividades-chave do processo: planejamento, levantamento de requisitos, análise, projeto, implementação e testes, que são a base sobre a qual o processo de desenvolvimento deve ser construído. Entretanto, um processo envolve a escolha de um modelo de ciclo de vida, o detalhamento de suas macro-atividades, a escolha de métodos e técnicas para a sua realização e a definição de recursos e artefatos necessários e produzidos. Um processo de desenvolvimento de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e ao projeto específico. Deste modo, processos devem ser definidos caso a caso, considerando-se as especificidades da aplicação, a tecnologia a ser adotada na sua construção, a organização onde o produto será desenvolvido e o grupo de desenvolvimento. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 48 UFES Departamento de Informática Em suma, o objetivo de se definir um processo de software é favorecer a produção de sistemas de alta qualidade, atingindo as necessidades dos usuários finais, dentro de um cronograma e um orçamento previsíveis. A escolha de um modelo de ciclo de vida é o ponto de partida para a definição de um processo de software. Um modelo de ciclo de vida organiza as macro-atividades básicas, estabelecendo precedência e dependência entre as mesmas. Um ciclo de vida pode ser entendido como passos ou atividades que devem ser executados durante um projeto. Para a definição completa do processo, a cada atividade, devem ser associados técnicas, ferramentas e critérios de qualidade, entre outros, formando uma base sólida para o desenvolvimento. Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser definidas, entre elas gerência de configuração 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 razoáveis 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, análise, projeto, implementação 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 construído, o engenheiro de software tem de compreender o domínio do problema, bem como a funcionalidade e o comportamento esperados. • Análise: Uma vez identificados os requisitos do sistema a ser desenvolvido, estes devem ser modelados, avaliados e documentados. Uma parte vital desta fase é a construção de um modelo descrevendo o que o software tem de fazer (e não como fazê-lo). • Projeto: Esta fase é responsável por incorporar requisitos tecnológicos aos requisitos essenciais do sistema, modelados na fase anterior e, portanto, requer que a plataforma de implementação 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 construído na fase de análise de requisitos. Esta arquitetura deve descrever a estrutura de nível mais alto da aplicação e identificar seus principais componentes. O propósito do projeto detalhado é detalhar o projeto do software para cada componente identificado na etapa anterior. Os componentes de software devem ser sucessivamente refinados em níveis de maior detalhamento, até que possam ser codificados e testados. • Implementação: O projeto deve ser traduzido para uma forma passível de execução pela máquina. A fase de implementação realiza esta tarefa, isto é, cada unidade de software do projeto detalhado é implementada. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 49 UFES Departamento de Informática • Testes: inclui diversos níveis de testes, a saber, teste de unidade, teste de integração 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. • Implantação: uma vez testado, o software deve ser colocado em produção. Para tal, contudo, é necessário treinar os usuários, configurar o ambiente de produção e, muitas vezes, converter bases de dados. O propósito desta fase é estabelecer que o software satisfaz os requisitos dos usuários. Isto é feito instalando o software e conduzindo testes de aceitação (validação). Quando o software tiver demonstrado prover as capacidades requeridas, ele pode ser aceito e a operação iniciada. • Operação: nesta fase, o software é utilizado pelos usuários no ambiente de produção. • Manutenção: Indubitavelmente, o software sofrerá mudanças após ter sido entregue para o usuário. Alterações ocorrerão porque erros foram encontrados, porque o software precisa ser adaptado para acomodar mudanças em seu ambiente externo, ou porque o cliente necessita de funcionalidade adicional ou aumento de desempenho. Muitas vezes, dependendo do tipo e porte da manutenção necessária, esta fase pode requerer a definição de um novo processo, onde cada uma das fases precedentes é re-aplicada no contexto de um software existente ao invés de um novo. Uma vez que o software é sempre parte de um sistema (ou negócio) maior, o trabalho começa pelo estabelecimento dos requisitos para todos os elementos do sistema e, na seqüência, procede-se a alocação 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 estão relacionadas. A escolha de um modelo de ciclo de vida é fortemente dependente das características do projeto. Assim, é importante apresentar vários modelos de ciclo de vida adequados ao desenvolvimento orientado a objetos, indicando em que situações são aplicáveis. Dentre os principais modelos de ciclo de vida, destacam-se o modelo seqüencial linear, o modelo incremental e vários modelos evolutivos. 4.3.1 - O Modelo Seqüencial Linear Algumas vezes chamado de “ciclo de vida clássico” ou “modelo em cascata”, o modelo seqüencial linear sugere uma abordagem seqüencial sistemática para o desenvolvimento de software que começa no nível de sistema e avança através de análise, projeto, implementação, teste e manutenção, como mostra a figura 4.7. Na abordagem em cascata, as fases são executadas seqüencialmente. Cada fase é executada uma vez, embora um retorno à fase anterior seja permitido para correção de erros. A entrega do sistema completo ocorre em um único marco, ao final da fase de Testes de Validação e Implantação. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 52 UFES Departamento de Informática compreendido, mas os detalhes de extensões da aplicação têm ainda de ser definidos. Nestas e em situações 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 não é bem definido e ele não pode ser totalmente especificado no início do desenvolvimento, deve-se optar por um modelo evolutivo. Os modelos evolutivos aplicam seqüências lineares de modo escalonado, à medida que o calendário de tempo avança. Cada seqüência linear produz um “incremento” distribuível do software que é colocado em uso. Durante o uso, novos requisitos são levantados, dando início a um novo ciclo de desenvolvimento. Desta forma, estes modelos permitem que os engenheiros de software desenvolvam iterativamente versões do software cada vez mais completas. Modelo Espiral O modelo espiral é capaz de descrever como um produto se desenvolve para formar novas versões e como uma versão pode ser incrementalmente desenvolvida, partindo-se de um protótipo até um produto completo. A figura 4.9 ilustra este modelo. Figura 4.9 - Um modelo espiral [Jacobson92]. Uma das importantes características do desenvolvimento de software orientado a objetos é que todas as atividades do ciclo de vida compartilham vocabulário, notação e estratégias comuns, isto é, tudo gira em torno de objetos. Seja na fase de análise, projeto ou implementação, a equipe de desenvolvimento estará sempre envolvida na descoberta, documentação, prototipação e/ou desenvolvimento de objetos, e em todas as atividades do ciclo de vida, os conceitos de abstração fundamentais para a orientação a objetos, tais como encapsulamento e herança, desempenham um importante papel. Esta é uma das principais diferenças em relação às metodologias convencionais, onde, por exemplo, as atividades do grupo de modelagem de dados freqüentemente parecem não ter qualquer relação com as atividades do grupo de modelagem funcional, sendo que as notações usadas por cada um dos grupos são completamente díspares. Além disso, sistemas orientados a objetos apresentam outras características muito interessantes e desejáveis ao processo de produção de software, entre elas: Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 53 UFES Departamento de Informática • visão do mundo real mais adequada através da observação de objetos, com conseqüente redução do gap semântico, que proporciona uma visão balanceada de dados e processos; • desenvolvimento incremental e evolutivo. Esta característica é extremamente desejável para que um produto possa ser desenvolvido em etapas ou por equipes distintas; • reusabilidade. Através da reutilização, muitas vezes é possível reaproveitar parcelas de código, projetos ou mesmo de especificações de requisitos na construção de outras partes de um sistema, ou até mesmo de outros sistemas; • possibilidade de incorporação de pequenas diferenças a elementos do sistema, através da abstração de generalização/especialização, mantendo alta coesão do sistema; • modularidade. O conceito de objetos e sua descrição em classes, incorporando dados e operações, constituem critérios de modularização altamente efetivos e propiciam o encapsulamento. Dadas estas características, modelos em espiral e modelos baseados em prototipação têm sido amplamente utilizados no processo de desenvolvimento de sistemas orientados a objetos. Modelo Evolutivo Básico O modelo evolutivo básico pressupõe que o desenvolvimento se dará em ciclos, onde ao final de cada ciclo, uma versão operacional do software é colocada em uso. Durante o uso, novos requisitos são levantados, dando início a um novo ciclo no desenvolvimento. A figura 4.10 ilustra este modelo. Figura 4.10 - O modelo evolutivo básico. O primeiro incremento é geralmente um produto central, isto é, os requisitos básicos são tratados, mas muitas características suplementares (algumas conhecidas, outras não) permanecem indisponíveis. O produto central é usado pelo cliente (ou passa por uma revisão detalhada). Como resultado do uso e/ou da avaliação, um plano é desenvolvido para o próximo incremento. Este plano endereça dois aspectos principais: a modificação do produto planejamento análise projeto implementação teste realimentação do cliente 1a Versão revisão e refinamento revisão e refinamento . . . levantamento de requisitos implantação/operação planejamento análise projeto implementação teste realimentação do cliente 2a Versão levantamento de requisitos planejamento análise projeto implementação teste Produto Final levantamento de requisitos Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 54 UFES Departamento de Informática central para melhor satisfazer as necessidades do cliente e a entrega de funcionalidades e características adicionais. Este processo é repetido, seguindo a entrega de cada incremento, até que o produto completo seja construído. O desenvolvimento evolutivo é particularmente útil quando não há recursos de pessoal disponíveis para uma completa implementação nos prazos estabelecidos para o projeto. Além disso, incrementos podem ser planejados para gerenciar riscos técnicos. O Modelo Rational A Rational Software desenvolveu um modelo de processo, integrado com uma coleção de ferramentas, para o desenvolvimento de sistemas complexos, orientados a objetos [Kruchten98], que pode ser adaptado e estendido para adequar-se a projetos específicos. O ciclo de vida adotado por este processo é tipicamente evolutivo. Contudo, uma forma de organização em fases é adotada para comportar os ciclos de desenvolvimento, permitindo uma gerência mais efetiva no projeto de sistemas complexos. Ao contrário do tradicionalmente definido como fases na maioria dos modelos de ciclo de vida – planejamento, levantamento de requisitos, análise, projeto, implementação e testes – são definidas fases ortogonais a estas, a saber [Kruchten98]: • Concepção: 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 elaboração. Ao término desta fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento; • Elaboração: o propósito desta fase é analisar mais refinadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos de projeto que oferecem maior risco. Ao término desta fase, a parte considerada mais complicada do desenvolvimento é considerada completa. Embora o processo deva sempre acomodar alterações, as atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis e que os riscos estão suficientemente mitigados, de modo a se poder prever com precisão os custos e prazos para a conclusão do desenvolvimento. • Construção: durante a fase de construção, um produto completo é desenvolvido de maneira iterativa e incremental para que esteja pronto para a transição à comunidade usuária. • Transição: nesta fase, o software é disponibilizado à comunidade usuária. Após o produto ter sido colocado em uso, naturalmente surgem novas considerações que irão demandar a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou concluir algumas características que foram postergadas. É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 4.11. Na fase de concepção, o foco principal recai sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem dos requisitos (levantamento de requisitos e análise), ainda que algum trabalho Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 57 UFES Departamento de Informática Os diagramas contemplados pela UML são [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 usuário, dispositivo ou outro sistema. • Diagrama de Classes: Denota a estrutura estática de um sistema, isto é, as classes, os relacionamentos entre suas instâncias (objetos), restrições e hierarquias. O diagrama é considerado estático pois a estrutura descrita é sempre válida em qualquer ponto no ciclo de vida do sistema. • Diagramas de Interação, podendo ser: Diagramas de Seqüência: mostram a colaboração dinâmica entre um número de objetos, sendo seu objetivo principal mostrar a seqüência de mensagens enviadas entre objetos. É um gráfico bidimensional, onde a dimensão vertical representa o tempo e a dimensão horizontal os diferentes objetos. Diagramas de Colaboração: têm exatamente o mesmo propósito dos diagramas de seqüência, apresentando, contudo, um formato diferente. São desenhados como diagramas de objetos, onde são mostradas as mensagens trocadas entre os objetos. • Diagramas de Estados: mostram as seqüências de estados pelos quais um objeto pode passar ao longo de sua vida, em resposta a estímulos recebidos, juntamente com suas respostas e ações. É tipicamente um complemento de uma classe e relaciona os possíveis estados que os objetos da classe podem ter e quais eventos podem causar uma transição de um estado para outro. A UML descreve, também, uma variação dos Diagramas de Estado, na qual a maioria dos estados é estado de ação e a maioria das transições é ativada por conclusões das ações, os ditos Diagramas de Atividades; • Diagramas de Implementação, composto por dois diagramas: Diagrama de Componentes: são mostradas as dependências entre componentes de software, inclusive código fonte, código binário e componentes executáveis. Diagrama de Implantação: mostra elementos de configuração do processamento em tempo de execução, isto é, os componentes de software, processos e dispositivos físicos. Vale ressaltar mais uma vez, que a UML é uma linguagem de modelagem, não um método de desenvolvimento OO. Os métodos consistem, pelo menos em princípio, de uma linguagem de modelagem e um procedimento de uso dessa linguagem. A UML não prescreve explicitamente esse procedimento de utilização [Furlan98]. Assim, a UML deve ser aplicada no contexto de um processo, lembrando que domínios de problemas e projetos diferentes podem requerer processos diferentes. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.4 – Introdução à Orientação a Objetos 58 UFES Departamento de Informática Referências Bibliográficas do Capítulo [Booch94] G. Booch; Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin/Cummings Publishing Company, Inc, 1994. [Coad92] P. Coad, E. Yourdon; Análise Baseada em Objetos, Editora Campus, 1992. [Furlan98] J.D. Furlan; Modelagem de Objetos Através da UML; Makron Books, 1998. [Jacobson92] I. Jacobson; Object-Oriented Software Engineering, Addison-Wesley, 1992. [Kruchten98] P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. [Pompilho95] S. Pompilho. Análise Essencial: Guia Prático de Análise de Sistemas. IBPI Press, Editora Infobook, Rio de Janeiro, 1995. [Rumbaugh94] J. Rumbaugh, et alli; Modelagem e Projetos Baseados em Objetos, Editora Campus, 1994. [Snyder93] A. Snyder; “The Essence of Objects: Concepts and Terms”, IEEE Software, Janeiro 1993. [Yourdon94] E. Yourdon; Object-Oriented Systems Design: an Integrated Approach, Yourdon Press Computing Series, Prentice Hall, 1994. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 59 UFES Departamento de Informática 5. Análise Orientada a Objetos Quando um novo sistema precisa ser construído e decidimos utilizar o paradigma orientado a objetos (OO) em seu desenvolvimento, surge uma importante questão: 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, é necessário identificar quais os objetos relevantes, como eles se relacionam e como eles se comportam no contexto do sistema. Além disso, é preciso especificar e modelar o problema de maneira que seja possível criar um projeto OO efetivo. Todos estes aspectos são tratados dentro do contexto da Análise Orientada a Objetos (AOO) [Pressman00]. O propósito da Análise Orientada a Objetos (AOO) é definir todas as classes (e os relacionamentos e comportamentos associados a ela) que são relevantes para o problema a ser resolvido. Para tal, um número de tarefas deve ocorrer: • Identificação de Classes • Especificação de Hierarquias de Generalização/Especialização • Identificação de Associações e Atributos • Modelagem do Comportamento • Definição das Operações É importante notar que estas atividades são dependentes umas das outras e que, durante o desenvolvimento, elas são realizadas, tipicamente, de forma iterativa. A ênfase da fase de análise, no entanto, deve ser sempre o entendimento do domínio do problema, sempre desconsiderando aspectos de implementação. A popularidade da orientação a objetos fez surgir dezenas de métodos OO para análise e projeto. Cada um deles, introduz um processo para analisar um sistema, um conjunto de modelos que evoluem ao longo do processo e uma notação que permite ao engenheiro de software criar cada modelo de maneira consistente [Pressman00]. Entre os principais métodos existentes podemos citar o Método de Booch [Booch94], OMT [Rumbaugh94], OOSE [Jacobson92] e o Método de Coad & Yourdon [Coad92][Coad93]. Ainda que, à primeira vista, estes métodos possam parecer substancialmente diferentes, isto não é verdade. Todos eles consideram, de alguma forma, as tarefas listadas anteriormente. Essencialmente, as maiores diferenças estão nas diretrizes e heurísticas fornecidas, nos modelos utilizados, suas notações e no processo sugerido. Tentativas para se definir um método padrão têm sido realizadas, mas têm encontrado como principal obstáculo a definição de um processo padrão de análise 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 notação padrão. Neste texto, não adotamos nenhum método específico, mas, ao mesmo tempo todos. Isto é, procuramos incorporar as características que julgamos serem as mais úteis de cada um dos métodos em uma abordagem básica para o desenvolvimento OO. O processo de desenvolvimento deve ser definido caso a caso, levando-se em conta as particularidades do projeto em questão, do domínio de aplicação e das características da equipe de desenvolvimento, entre outras. Mas a abordagem aqui proposta pode ser vista como o ponto de partida para esta definição. Quanto aos modelos e suas notações, adotamos, basicamente, aqueles definidos na UML [Furlan98]. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 62 UFES Departamento de Informática 5.2 - Especificação de Hierarquias de Generalização / Especialização Um dos principais mecanismos de estruturação de conceitos é a generalização / especialização. Com este mecanismo é possível capturar similaridades entre classes, dispondo-as em hierarquias de classes. A figura 5.2 mostra a notação da UML usada para representar a estrutura de generalização - especialização. É importante realçar que esta estrutura reflete um mapeamento entre classes e não entre objetos. Figura 5.2 - Notação da UML para Hierarquia de Classes. As seguintes diretrizes podem ser usadas analisar as hierarquias modeladas: • Uma hierarquia de classes deve modelar relações “é-um-tipo-de”, ou seja, toda subclasse deve ser um tipo específico das suas superclasses. • Uma subclasse deve suportar toda a funcionalidade (atributos, relacionamentos e operações) definida por suas superclasses, e possivelmente mais. • A funcionalidade comum a diversas classes deve ser posicionada o mais alto possível na hierarquia. • Classes abstratas não podem herdar de classes concretas. • Classes que não adicionam funcionalidade devem ser eliminadas. Por adicionar funcionalidade que se dizer adicionar nova funcionalidade ou redefinir uma funcionalidade existente em uma superclasse. Cada especialização deve ser nomeada de forma a ser auto-explicativa. Um nome apropriado para a especialização pode ser formado pelos nomes de suas generalizações, acompanhados por um nome qualificador que descreve a natureza da especialização. As classes geradas através de generalização-especialização devem atender, além dos critérios para inclusão discutidos na seção anterior, aos seguintes critérios: • As potenciais especializações e/ou generalizações devem estar no domínio do problema e devem fazer parte das responsabilidades do sistema; e • Se uma classe é dita sub-classe de outra, todas as instâncias da sub-classe têm de ser também, por definição, instâncias da super-classe, isto é, tudo o que é dito sobre a super- classe (relacionamentos, atributos e operações) tem de ser válido também para a sub- classe. Se a única distinção entre as especializações for o seu tipo, ou se as classes de especialização não adicionarem nenhuma funcionalidade, então a estrutura de generalização- especialização não é necessária. Super-classe Sub-classe 1 Sub-classe N Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 63 UFES Departamento de Informática 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 realçada: a figura 5.3 indica explicitamente que não há instâncias da classe Veículo per se; as únicas instâncias (ou objetos) ocorrem no nível de especialização de Carro, Moto, Ônibus, ou Caminhão. Isso é indicado pelo nome da classe Veículo que está escrito em itálico, em contraste com os demais nomes de classes. Este é o padrão de notação para classes abstratas na UML. Figura 5.3 - Hierarquia de Classes no Contexto de uma Auto-Escola. Um recurso adicional que muitas vezes facilita o entendimento das estruturas de generalização / especialização, principalmente quando há várias classificações para uma mesma classe, é indicar o critério de organização de cada hierarquia, adicionando um rótulo junto ao símbolo de classificação (triângulo). 5.3 - Identificação de Subsistemas Um modelo de análise para uma aplicação complexa pode ter centenas de classes e dezenas de estruturas e, portanto, pode ser necessário definir uma representação concisa capaz de orientar um leitor em um modelo desta natureza. O agrupamento de classes em subsistemas serve basicamente a este propósito, podendo ser útil também para a organização de grupos de trabalho em projetos extensos. A base principal para a identificação de subsistemas é a complexidade do domínio do problema. Através da identificação e agrupamento de classes em subsistemas, é possível controlar a visibilidade do leitor e, assim, tornar o modelo mais compreensível. Quando uma coleção de classes colaboram entre si para realizar um conjunto coeso de responsabilidades, elas podem ser vistas como um subsistema. Assim, um subsistema é uma abstração que provê uma referência para mais detalhes em um modelo de análise. Quando visto de fora, um subsistema pode ser tratado como uma caixa preta que contém um conjunto de responsabilidades e possui suas próprias colaborações [Pressman00]. O agrupamento de classes em subsistemas permite apresentar o modelo global em uma perspectiva mais alta. Este nível ajuda o leitor a rever o modelo. Além disso, constitui também um bom critério para organização da documentação. Os casos de uso são 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 informações contidas nos modelos de classe e de casos de uso. Veículo Carro Moto Caminhão Ônibus Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 64 UFES Departamento de Informática A UML propõe o uso de um tipo especial de diagrama de classes, onde apenas subsistemas e suas relações são representados, os chamados diagramas de pacotes, cuja notação é mostrada na figura 5.4. Figura 5.4 - Notação da UML para Diagramas de Pacotes. 5.4 - Identificação de Relacionamentos e Definição de Atributos 5.4.1 - Identificação de Relacionamentos Relacionamentos são representações estáticas que modelam associações entre objetos, um dos mecanismos de estruturação de objetos. Cada classe desempenha um papel na associação, ao qual pode ser dado um nome. Cada papel possui também 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. Figura 5.5 - Notações da UML para Associações e suas Cardinalidades. Há várias maneiras de nomear associações. Os seguidores da modelagem de dados tradicional, normalmente, têm o hábito de usar um verbo ou frase verbal de modo que o relacionamento possa ser lido como uma sentença. Na modelagem OO, contudo, há uma outra opção de nomeação, que consiste em utilizar nomes para rotular um ou mais papéis, indicando a responsabilidade dos objetos na associação. Além disso, só devemos nomear uma associação 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 vários empregados nele lotados, mas apenas um chefe. Sem nomear estas associações, o modelo fica confuso. Rotulando os papéis, o modelo torna-se muito mais claro. Na figura 5.6, um departamento exerce o papel de departamento de lotação do empregado e, neste caso, um empregado tem um e somente um departamento de lotação. 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 genérica a maneira de se nomear papéis em uma associação. 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. A B 1 A B 1..* A B 0..1 A B * Pacote 1 Pacote 2 Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 67 UFES Departamento de Informática Figura 5.11 – Relacionamento Ternário. 5.4.2 - Agregação Uma agregação é uma forma especial de associação utilizada para mostrar que um tipo de objeto é composto, pelo menos em parte, de outro em uma relação todo/parte [Furlan98]. Um carro, por exemplo, tem um motor e rodas como suas partes. Entretanto, muitas vezes é difícil perceber a diferença entre uma agregação e um relacionamento comum. De fato, não há uma definição única aceita por todos os métodos do que seja a diferença entre agregação e relacionamento. Ainda assim, a UML apresenta notações para agregação, como mostra a figura 5.12. É importante realçar que, uma vez que uma agregação é, na verdade, um tipo de relacionamento, cardinalidades devem ser indicadas. Ao se utilizar a notação de agregação, espera-se que as partes “vivam” e “morram” com o todo, isto é, na criação do objeto-todo, os objetos-parte são criados e a remoção do objeto- todo deve ser aplicada em cascata às suas partes. Esta remoção em cascata é freqüentemente considerada como sendo uma característica da definição de agregação, contudo, ela é imposta por qualquer papel cuja cardinalidade é 1..1. Contudo, na agregação, os objetos-parte não podem ser destruídos por outro objeto a não ser pelo objeto-todo que os criou. Esta condição não é obrigatória para objetos em uma associação comum. Figura 5.12 - Notações da UML para Agregação e Composição. A UML oferece ainda notações para alguns tipos de agregação, chamadas de composição. Ao utilizar uma composição, está-se afirmando que o objeto-parte pode pertencer a apenas um todo. Todo Parte Todo Parte Agregação Composição 1 A B ABC C Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 68 UFES Departamento de Informática 5.4.3 - Definição de Atributos Um atributo é um dado (informação de estado) para o qual cada objeto em uma classe tem o seu próprio valor. Os atributos adicionam detalhes às abstrações e são apresentados na parte central do símbolo de classe. Atributos são muito similares a associações. De fato, conceitualmente, não há diferença entre atributos e associações. Podemos dizer que atributos representam associações entre as classes do domínio do problema e classes básicas, tais como strings, datas, inteiros e reais. Exatamente por estas classes serem básicas e ocorrerem em quase todos os domínios de problemas, elas não são representadas e, portanto, atributos são descritos como uma informação de um determinado tipo. A estratégia para a definição de atributos envolve: • Descoberta de atributos • Posicionamento dos atributos em uma hierarquia de classes • Revisão da hierarquia de classes • Especificação dos Atributos É bom realçar que, com o tempo, as classes do domínio de problemas permanecem relativamente estáveis, enquanto os atributos provavelmente se alteram. Atributos são bastante voláteis, em função das responsabilidades do sistema. Descoberta de Atributos A AOO não provê nenhuma técnica mágica para se descobrir os atributos que um objeto requer para realizar seus objetivos. A tarefa é essencialmente a mesma usada em qualquer forma de análise de sistemas: estudo do domínio da aplicação, entrevistas com o usuário, etc. Cada atributo deve capturar um “conceito atômico”4 que ajude a descrever um objeto e que seja de responsabilidade do sistema. Um atributo representa uma informação de estado de um objeto que precisa ser lembrada. Uma vez que, conceitualmente, atributos e associações são a mesma coisa, não devemos incluir na lista de atributos de uma classe, atributos representando associações. Estas já têm sua presença 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 generalização-especialização, atributos genéricos devem ser posicionados no topo da estrutura, de modo a serem aplicáveis a cada uma das especializações. Em outras palavras, se um atributo é aplicável a um nível inteiro de especializações, então ele deve ser posicionado na generalização correspondente. Por outro lado, se algumas vezes um atributo tiver um valor significativo, mas em outras ele não for aplicável, deve-se rever o posicionamento do atributo ou a estratégia da estrutura de generalização-especialização adotada. Esta estratégia é válida também para operações. 4 um único valor ou um agrupamento de valores fortemente relacionados Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 69 UFES Departamento de Informática Revisão da Hierarquia de Classes Inevitavelmente, o processo detalhado de designar atributos a classes conduz a um entendimento mais completo do que era possível em estágios anteriores do desenvolvimento. Assim, devemos esperar que algumas revisões de definições de classes e suas hierarquias resultem deste passo. Especificação de Atributos Um aspecto bastante importante na especificação de atributos é a escolha de nomes. Deve-se procurar utilizar o vocabulário padronizado para o domínio do problema, usando nomes legíveis e abrangentes. A especificação de atributos deve incluir unidade de medida, intervalo, limite, enumeração, precisão, valor default e obrigatoriedade, entre outros. Caso valha a pena, em termos de custo-benefício, pode ser importante adicionar uma descrição breve para cada atributo. A notação da UML para atributos é a seguinte: visibilidade nome: tipo = valorDefault, onde visibilidade é um dos seguintes símbolos: + , público, isto é, o atributo pode ser acessado por qualquer classe cliente; # , protegido, isto é, o atributo só é passível de acesso pela própria classe ou por uma de suas especializações; e - , privado, isto é, o atributo só pode ser acessado pela própria classe. O nome do atributo é uma seqüência de caracteres de identificação, começando tipicamente, com letra minúscula. Concatena-se as demais palavras que compõem o nome, preservando-se a primeira letra de cada palavra em maiúscula [Furlan98], por exemplo, limiteDeCrédito. Pode-se também desprezar preposições. Assim, o exemplo anterior assumiria a seguinte forma: limiteCrédito. 5.5 - Determinação do Comportamento Os Diagramas de Classes, gerados pelas atividades anteriormente descritas, representam apenas os elementos estáticos de um modelo de análise OO. É preciso analisar, ainda, o comportamento dinâmico da aplicação. Para tal, devemos representar o comportamento do sistema como uma função do tempo e de eventos específicos. Um modelo de comportamento indica como o sistema irá responder a eventos ou estímulos externos e auxilia o processo de descoberta das operações das classes do sistema. Para apoiar a modelagem do comportamento do sistema, a UML oferece duas ferramentas: • Diagramas de Estados: descrevem todos os estados possíveis pelos quais um particular objeto pode passar e suas transições, como resultados de estímulos (eventos) que atingem o objeto; • Diagramas de Interação: são modelos que descrevem como grupos de objetos colaboram em um certo comportamento. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 72 UFES Departamento de Informática Diagramas de Colaborações Um diagrama de colaborações tem o mesmo propósito que um diagrama de seqüência e, portanto, ambos são similares, ou seja, trabalham com as mesmas abstrações (objetos- exemplos, mensagens e seqüências). Em um diagrama de colaborações, os objetos-exemplos são mostrados como ícones e mensagens como setas. A seqüência, por sua vez, é indicada por uma numeração das mensagens. A figura 5.15 mostra a notação básica da UML para diagramas de colaborações. Figura 5.15 - Notação Básica da UML para Diagramas de Colaborações. A numeração de mensagens torna a visualização da seqüência mais difícil do que nos diagramas de seqüência. Entretanto, este layout permite mostrar mais facilmente outras coisas. A UML adota um esquema de numeração decimal (1, 1.1, 1.1.1, 2, ...) com o objetivo de tornar mais claro que operação está chamando que outras operações, embora possa ser difícil ver a seqüência global. Tanto diagramas de seqüência quanto diagramas de colaborações não são muito apropriados para representar processos com muito comportamento condicional e repetitivo. Para estes casos, ainda que seja possível utilizar condições e marcadores de iterações, é melhor utilizar diagramas separados para cada cenário. Deve-se ressaltar, ainda, que os diagramas de interação são bons para mostrar colaborações entre objetos em um caso de uso. Para observar o comportamento de um objeto isolado ao longo de vários casos de uso, deve-se utilizar um diagrama de transição de estados. 5.6 - Definição das Operações Uma vez estudado o comportamento do sistema, tem-se uma base para a definição das operações das classes que compõem o sistema. Na notação da UML, operações são apresentadas na seção inferior do símbolo de classe, com a seguinte sintaxe: visibilidade nome(lista_de_parâmetros): tipo_de_retorno onde a visibilidade tem a mesma sintaxe e semântica definida para atributos. Normalmente, operações que simplesmente manipulam atributos não são representadas, já que podemos deduzir que elas existem, tais como: • Operações que obtêm valores de atributos: apenas retornam um valor de um atributo e não fazem mais nada; • Operações que colocam valores em atributos: apenas colocam um valor em um atributo e não fazem mais nada. : Nome_classe_1 : Nome_classe_2 1: [condição] *msg() Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 73 UFES Departamento de Informática Além dessas, operações para criar uma nova instância da classe, selecionar e eliminar uma instância da classe também não são normalmente mostradas no diagrama de classes. Entretanto, afora os sistemas muito simples, outras operações devem ser capturadas, entre elas: • operações associados às mensagens nos diagramas de interação; • operações associadas aos relacionamentos entre objetos nos diagramas de classes, isto é, operações para associar e desassociar instâncias específicas que se relacionam. Em outras palavras, são as operações que permitem que um relacionamento seja estabelecido ou desfeito; • operações sugeridas pelos diagramas de estados. Especificação das Operações Finalmente, as operações podem ser descritas, detalhando-se o comportamento das classes. Cada operação pode dar origem a um ou mais métodos a serem executados quando uma mensagem for recebida. Se os objetos tiverem sido bem definidos, então cada método será pequeno e altamente coeso. Assim, é possível descrever uma operação compactamente em alguma notação semi-formal, como um “português-estruturado”. Um Recurso Adicional - Contratos Um recurso muito útil, empregado pelo método CRC [Wirfs-Brock90] é a definição de contratos. Um contrato define um conjunto de requisições 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 vários 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 são. Algumas responsabilidades representam um comportamento que a classe deve apresentar mas que não pode ser requisitado por objetos de outras classes. Tais responsabilidades são 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 serão utilizadas sempre pelos mesmos clientes. • Maximize a coesão das classes. Assim como um contrato deve ser composto de um conjunto coeso de responsabilidades, uma classe deve suportar um conjunto coeso de 5 Responsabilidades incluem tanto a informação mantida pelas instâncias da classe (estado dos objetos) quanto as ações que essas instâncias podem executar (comportamento dos objetos) [Wirfs-Brock90]. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.5 – Análise Orientada a Objetos 74 UFES Departamento de Informática contratos. Maximizar a coesão tende a minimizar o número de contratos suportados por uma classe. • Minimize o número de contratos. Sem violar o princípio de coesão dos contratos, a melhor maneira de reduzir o número de contratos é procurar por funcionalidades similares que possam ser generalizadas, permitindo, assim, que essas, e os contratos dos quais elas são 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 várias classes que o suportam podem herdá-lo da superclasse. Uma estratégia simples para a definição de contratos, começa pela definição 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 específicas de expressar responsabilidades herdadas, caso em que já são parte do contrato herdado. Referências Bibliográficas [Booch94] G. Booch; Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin/Cummings Publishing Company, Inc, 1994. [Coad92] P. Coad, E. Yourdon; Análise Baseada em Objetos, Editora Campus, 1992. [Coad93] P. Coad, E. Yourdon; Projeto Baseado em Objetos, Editora Campus, 1993. [Furlan98] J.D. Furlan; Modelagem de Objetos Através da UML; Makron Books, 1998. [Jacobson92] I. Jacobson; Object-Oriented Software Engineering, Addison-Wesley, 1992. [Pressman00] R.S. Pressman; Software Engineering: A Practitioner’s Approach, 5th Edition, Mc Graw Hill, 2000. [Rumbaugh94] 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. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.6 – Introdução à Análise Essencial 77 UFES Departamento de Informática físico: características dependentes de um sistema computacional específico, isto é, uma linguagem e um compilador específico, um sistema gerenciador de bancos de dados específico, o hardware de um determinado fabricante, etc. Nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e análise), o engenheiro de software representa o sistema através de modelos conceituais. Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos. O método de Análise Essencial de Sistemas [Pompilho95] preconiza que, de uma forma geral, um sistema deve ser modelado através de três dimensões: dados: diz respeito aos aspectos estáticos e estruturais do sistema; controle: leva em conta aspectos temporais e comportamentais do sistema; funções: considera a transformação de valores. Em relação ao grau de abstração, a Análise Essencial considera dois níveis: o nível essencial e o nível de implementação, representados, respectivamente, pelos seguintes modelos: Modelo Essencial: representa o sistema num grau de abstração completamente independente de restrições tecnológicas. Modelo de Implementação: passa a considerar as restrições tecnológicas impostas pela plataforma de hardware e software a ser utilizada para implementar o sistema. Podemos perceber que o modelo de implementação não corresponde a um modelo de análise propriamente dito, uma vez que considera aspectos de implementação, característica marcante da fase de projeto. De fato, na abordagem da Análise Essencial, este modelo corresponde a uma espécie de zona nebulosa entre as fases de análise e de projeto. Por considerarmos que um modelo considerando aspectos da plataforma de implementação é melhor caracterizado na fase de projeto, neste texto, não trataremos do modelo de implementação. 6.1 - Conceitos Os conceitos introduzidos pelo método de Análise Essencial endereçavam inicialmente as duas principais dificuldades que os analistas enfrentavam com a aplicação da Análise Estruturada: a distinção entre requisitos lógicos e físicos, e a ausência de uma abordagem para particionar o sistema em partes tão independentes quanto possível, de modo a facilitar o processo de análise. Durante muito tempo, houve grandes debates entre os profissionais de desenvolvimento de sistemas sobre por qual perspectiva se deveria começar a especificação de um sistema: pelos dados ou pelas funções? Os argumentos, igualmente válidos, exploravam considerações como: dados são mais estáveis que funções..., sem um entendimento das funções a serem desempenhadas pelo sistema, como definir o escopo e os dados necessários? A Análise Essencial procurou estabelecer um novo ponto de partida para a especificação de um sistema: a identificação dos eventos que o afetam [Pompilho95]. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.6 – Introdução à Análise Essencial 78 UFES Departamento de Informática Um dos problemas mais relevantes na especificação é como efetuar seu particionamento. A Análise Estruturada propõe um particionamento através de uma abordagem top-down. Embora esta seja uma boa maneira de se atacar um problema complexo – começando da visão geral e ir descendo, passo a passo, numa visão hierárquica, a níveis de detalhes cada vez maiores – na prática, esta abordagem não se mostrou eficiente como estratégia de projeto para a decomposição de sistemas. A Análise Essencial propõe 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 fácil a identificação das funções e entidades que compõem o sistema [Pompilho95]. A Análise Essencial de Sistemas, através da técnica de particionamento por eventos, oferece uma boa estratégia para modelar o comportamento do sistema, visando satisfazer os requisitos do usuário, 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 Análise Essencial preservou todos os modelos da Análise Estruturada. De fato, embora diferentes, a melhor maneira de encarar a Análise Essencial é considerá-la uma evolução da Análise Estruturada. A seguir, os principais conceitos da Análise Essencial [McMenamim84] são apresentados. Tecnologia Perfeita Durante a fase de análise, o analista deve abstrair-se da tecnologia que deverá ser utilizada na implementação do sistema. Para orientar essa abstração, a Análise Estruturada recomenda que o analista, durante a fase de análise, concentre-se apenas nos aspectos lógicos do sistema, evitando pensar nos aspectos físicos. O problema dessa abordagem é que a diferença entre “aspectos lógicos e físicos” não é clara. Partindo do princípio que os aspectos físicos de um sistema estão ligados à tecnologia de implementação, a Análise Essencial emprega uma abstração de uma tecnologia de implementação, denominada tecnologia perfeita, para facilitar a tarefa de identificar os detalhes lógicos do sistema. A tecnologia perfeita não possui limitações, 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 repositório perfeito, capaz de armazenar quantidades infinitas de dados e de ser acessado instantaneamente por qualquer processador, da forma que for mais conveniente. Naturalmente, não existe uma tecnologia de implementação com tais características. Então, qual é a utilidade dessa abstração? Quando o analista pensa em aspectos físicos, ele está, na verdade, tentando identificar (e resolver) as limitações de uma determinada tecnologia. Pensamentos típicos do gênero são: quanto de espaço em disco vou precisar? qual o melhor método de acesso aos dados, considerando as funções do sistema? que capacidade de processamento devo necessitar? Contudo, nenhuma dessas preocupações são próprias da fase de análise. Considerando agora que a tecnologia que será utilizada na implementação do sistema é perfeita, todas as perguntas anteriores deixam de ter importância, isto é, não preocupam mais o analista. Assim sendo, para distinguir um requisito lógico de um requisito físico, utilizando a abstração de tecnologia perfeita, formule a seguinte pergunta ao identificar um requisito qualquer: “Para atender ao seu propósito, o sistema necessitará possuir essa capacidade ou essa característica, mesmo considerando que ele será implementado em uma tecnologia perfeita?” Se a resposta for sim, esse requisito é verdadeiro e deve ser modelado. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.6 – Introdução à Análise Essencial 79 UFES Departamento de Informática Requisito Verdadeiro e Requisito Falso Uma característica ou capacidade que um sistema deve possuir para atender ao seu propósito, mesmo considerando que será implementado em uma tecnologia perfeita, é dita um requisito verdadeiro. O conjunto de requisitos verdadeiros compreende a essência do sistema. Um requisito falso, por outro lado, é uma capacidade ou característica que o sistema não precisa possuir para atender ao seu propósito, caso ele disponha de uma tecnologia de implementação perfeita. Evento e Resposta Evento e resposta são nomes genéricos de interações 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 mudança no ambiente externo que funcionará como um estímulo para o sistema, isto é, o sistema deve responder a este estímulo para atender ao seu propósito. Uma resposta é o resultado da execução de um conjunto de ações no sistema, como conseqüência 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 mudança de estado em um depósito de dados (inclusão, exclusão ou alteração); um fluxo de controle saindo de uma função para ativar uma outra. Quando um evento ocorre, é produzido um estímulo para o sistema. Ao receber o estímulo, o sistema compreende que o evento ocorreu e ativa os processos necessários para produzir a resposta. Os eventos são classificados em quatro tipos diferentes, dependendo da maneira como ocorrem e da natureza do estímulo que produzem [Pompilho95]: Evento orientado por fluxo de dados: é provocado por uma entidade externa, a qual envia dados para o sistema. O estímulo produzido por esse tipo de evento é a chegada de um fluxo de dados que vai ativar uma função. Os eventos externos são nomeados da seguinte forma: (Entidade externa que provocou o evento) + (ação – verbo na voz ativa) + (estímulo – fluxo de dados enviado ao sistema) Ex.: Cliente envia pedido. Cliente cancela pedido. Evento orientado por controle: o estímulo provocado por este evento é a chegada ao sistema de um fluxo de controle, o qual apenas notifica o sistema da ocorrência do evento. Pode haver fluxos de dados complementares associados ao evento, mas não é através da chegada do fluxo de dados que o sistema toma conhecimento da ocorrência do evento. Esse tipo de evento pode ser nomeado de duas maneiras, tendo por base a origem do evento: Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.6 – Introdução à Análise Essencial 82 UFES Departamento de Informática Figura 6.2 – Acessos a depósitos de dados. 6.2 - Especificação da Essência do Sistema (Referência: Capítulo 17 [Pompilho95]) A Análise Essencial sugere a construção de dois modelos principais, o modelo essencial e o modelo de implementação. Conforme discutido anteriormente, entendemos que apenas o modelo essencial deve ser objeto da fase de análise e, assim, discutiremos apenas a especificação da essência do sistema. A especificação da essência do sistema, produto da fase de análise, é 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 necessário para interagir com o ambiente. Atividade Essencial R1 E1 E2 Atividade Essencial E1 E2 Criar ou excluir uma ocorrência de R2. Criar ou excluir uma ocorrência de R1. E1 R E2 a Modelo de Dados R Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.6 – Introdução à Análise Essencial 83 UFES Departamento de Informática Figura 6.3 – A Análise Essencial e seus Modelos. 6.2.1 - O Modelo Ambiental (Referência: Seção 17.1 [Pompilho95]) Representa o que o sistema deve fazer para atender ao ambiente. É composto dos seguintes produtos: Propósito do Sistema: enuncia a finalidade do sistema. Pode ser acompanhado de uma breve descrição 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 estímulo e a resposta externa do sistema. Diagrama de Contexto: representa o sistema como um único processo e suas interações com o ambiente. Pode ser acompanhado de um dicionário de dados. A declaração de propósito (objetivos) do sistema deve ser elaborada em poucas frases, simples e precisas, em linguagem destituída de vocabulário técnico, de modo a ser entendida pelos usuários do sistema e pela administração da empresa, em geral. Não deve fornecer detalhes sobre como o sistema deverá operar. A elaboração 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 especificação de um sistema é identificar a quais eventos do mundo exterior ele deverá ocorrer. Esta atividade, denominada Análise de Eventos, é muito bem explorada no Capítulo 15 de [Pompilho95]. Uma vez definidos os eventos, é possível construir o Diagrama de Contexto do sistema, mostrando como ele responde a todos os eventos externos relevantes. Finalmente, pode ser útil elaborar uma descrição de como o sistema responderá a cada um dos eventos identificados na Lista de Eventos. Análise Essencial Modelo Essencial Modelo de Implementação Modelo Ambiental Modelo Comportamental Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.6 – Introdução à Análise Essencial 84 UFES Departamento de Informática 6.2.2 – O Modelo Comportamental (Referência: Seção 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 construído um DFD. Assim, a quantidade de diagramas deve ser equivalente ao número de eventos na lista. Diagramas de Transição de Estados: Representa o comportamento das entidades e relacionamentos com atributos ao longo do tempo. Será construído 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 Níveis Hierárquicos: representa os processos em níveis hierárquicos, a partir do diagrama zero. Os processos do diagrama zero são obtidos através do agrupamento de atividades essenciais dos DFDs particionados por eventos. Um critério de agrupamento bastante razoável é considerar o grau de coesão e acoplamento entre atividades essenciais. As seguintes heurísticas podem ser utilizadas, em conjunto ou em separado: Procurar agrupar em um único processo todas as atividades essenciais que acessam um determinado depósito de dados, verificando se o processo resultante desse agrupamento é adequado para representar uma das funções do sistema. Agrupar todas as atividades de custódia referentes a um mesmo depósito de dados. Procurar identificar uma função do sistema, agrupando atividades essenciais que interagem com uma mesma entidade externa. Representar no DFD-zero, um processo para cada uma das funções do negócio. Agrupar as atividades essenciais aos processo para os quais as suas ações mais contribuem. Usando esta abordagem para a construção de diagramas hierárquicos, adotamos uma estratégia middle-out (do meio para fora), onde, a partir dos eventos, estabelecemos atividades essenciais (meio) para depois agrupá-las em níveis superiores (para cima) e, em seguida, especificá-las e, se necessário, explodi-las (para baixo). Dicionário de Dados: descreve os dados representados no MER, nos DFDs e nos DTEs. Especificação da Lógica dos Processos: descreve a lógica dos processos do DFD que não foram detalhados em diagramas de nível inferior (lógica dos processos primitivos). Como podemos perceber, a Análise Essencial faz uso praticamente das mesmas técnicas de modelagem da Análise Estruturada, a saber a Modelagem de Dados (utilizando modelos de Entidades e Relacionamentos), a Modelagem Funcional (utilizando Diagramas de Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.7 – Modelagem de Dados 87 UFES Departamento de Informática Para estabelecermos uma padronização, usaremos nomes de conjuntos de entidades sempre no plural e escritos em letras maiúsculas. No entanto, isto não representa efetivamente uma regra. Atributos: descrevem características ou propriedades relevantes de um conjunto de entidades. O conjunto de atributos deve ser: • completo: deve abranger todas as informações pertinentes. • fatorado: cada atributo deve capturar um aspecto em separado. • independente: os domínios de valores de atributos devem ser independentes uns dos outros. Atributos podem ser de dois tipos: • Atributos Descritivos: descrevem características intrínsecas do objeto. Ex: sexo, altura, nacionalidade, etc ... • Atributos Nominativos: nomes e rótulos arbitrários dados aos objetos. Ex: nome, matrícula, etc ... Sobre atributos são pertinentes ainda as seguintes considerações: • Atributo Monovalorado: atributo que assume um único valor para cada elemento do conjunto de entidades. Ex: matrícula, nome, data-admissão, ... de FUNCIONÁRIOS: Cada funcionário possui uma única matrícula, um único nome, etc ... • Atributo Multivalorado: atributo que pode assumir vários valores para cada um dos elementos do conjunto de entidades. São representados com um asterisco (*) associado. Ex: telefone* de FUNCIONÁRIOS: Um mesmo funcionário pode ter mais que um telefone. • Valor vazio para um atributo: quando para algum ponto do conjunto de entidades não existe um valor para aquele atributo, ou ele ainda não é conhecido. Ex: telefone* de FUNCIONÁRIOS: Um funcionário qualquer pode não ter nenhum telefone, ou em um dado momento ele não ser conhecido. • Atributo Composto: atributo composto de um ou mais sub-atributos. Ex: endereço, composto de rua, número, 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 deverão ser sublinhados. Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.7 – Modelagem de Dados 88 UFES Departamento de Informática Atributos também descrevem características de relacionamentos (atributos de relacionamentos). Todas as considerações feitas até então são válidas, sendo que uma discussão sobre características típicas destes atributos foi propositalmente postergada, visando uma melhor compreensão. A figura 7.2 ilustra a representação gráfica para atributos. Ainda que esta notação possa ser empregada, de maneira geral, atributos são representados apenas no dicionário de dados para evitar modelos complexos e de difícil leitura. Figura 7.2 – Representação gráfica para atributos. Relacionamento: é uma abstração de uma associação entre duas ou mais entidades. Relacionamento Binário: é uma representação abstrata da associação de duas entidades. Conjunto de Relacionamentos: é um subconjunto do produto cartesiano dos conjuntos de entidades envolvidos. Ex: O mundo real nos conta que: Funcionários são lotados em Departamentos. Alunos cursaram Disciplinas. Fornecedores fornecem Materiais. É importante notar que todos os relacionamentos binários possuem uma leitura inversa: Departamentos lotam Funcionários. Disciplinas foram cursadas por Alunos. Materiais são fornecidos por Fornecedores. Algumas correntes pregam o uso de um nome que abstraia a direção da leitura. Alunos cursaram Disciplinas. ⇒ Realizações Fornecedores fornecem Materiais. ⇒ Fornecimentos Neste texto, entretanto, adotaremos a seguinte notação: Um relacionamento será representado por um losango com um verbo para indicar a ação e uma seta para informar o sentido de leitura, como mostra a figura 7.3. FUNCIONÁRIOS matrícula nome endereço telefone * Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.7 – Modelagem de Dados 89 UFES Departamento de Informática lotam ⊆ {(d,f) / d ∈ DEPARTAMENTOS e f ∈ FUNCIONÁRIOS} Figura 7.3 – Representação gráfica para relacionamentos. É importante frisar que, entre duas entidades, pode existir mais de um tipo de relacionamento, como mostra o exemplo da figura 7.4. Figura 7.4 – Dois tipos de relacionamentos entre entidades. Além disso, uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo, inclusive com ela mesma, como mostra a figura 7.5. Figura 7.5 – Exemplo de modelo ER. FUNCIONÁRIOS DEPARTAMENTOS lotam FUNCIONÁRIOS DEPARTAMENTOS lotam chefiam PROFESSORES DEPARTAMENTOS lotam DISCIPLINAS oferecem são pré-requisito para Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.7 – Modelagem de Dados 92 UFES Departamento de Informática Figura 7.11 – Tipos de Relacionamentos. 7.2.1.2 - Relacionamentos Totais e Parciais Estes tipos de relacionamentos correspondem a uma classificação relacionada com a cardinalidade mínima 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, conseqüentemente, a cardinalidade mínima de R em relação 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, conseqüentemente, a cardinalidade mínima de R em relação a A é 0. No exemplo da figura 7.12, dizemos que o relacionamento lotam é total em relação a DEPARTAMENTOS e a FUNCIONÁRIOS, pois em ambos os casos a cardinalidade mínima é 1. Figura 7.12 – Relacionamento Total. MULHERES HOMENS casam (0,1) (0,1) Monogamia MULHERES HOMENS casam (0,N) (0,1) Poligamia MULHERES HOMENS casam (0,1) (0,N) Poliandria MULHERES HOMENS casam (0,N) (0,N) Vale-tudo FUNCIONÁRIOS DEPARTAMENTOS lotam (1,N) (1,1) Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.7 – Modelagem de Dados 93 UFES Departamento de Informática No exemplo da figura 7.13, dizemos que o relacionamento cursam é total em relação a ALUNOS e parcial em relação a CURSOS, pois no segundo caso, a cardinalidade mínima é 0. Figura 7.13 – Relacionamento parcial. Vale a pena observar que a simbologia utilizada na representação de entidades, relacionamentos e restrições de integridade de cardinalidade não é padronizada, isto é, não foi definido um padrão único a ser seguido por todos que utilizam o Modelo ER. 7.2.2 - Restrições de Integridade sobre o Domínio dos Atributos Ainda visando manter a integridade do modelo de dados, devemos descrever no dicionário de projeto restrições de integridade (ou leis de consolidação) 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: • enumeração: lista explícita de valores. Ex: Estado Civil : solteiro, casado, desquitado, divorciado e viúvo. • normas de aceitação: regras para se identificar se o valor é válido ou não. Ex: Nome : qualquer conjunto de caracteres alfanuméricos, começado por uma letra. • intervalo: descrição de um subconjunto de um intervalo conhecido. Ex: Mês: de 1 até 12. Uma vez estabelecido o domínio, é interessante determinar valores possíveis e prováveis, isto é, alguns valores, apesar de poderem ocorrer, é pouco provável que ocorram, dependendo do contexto. Por exemplo, com relação ao atributo idade de um empregado, o valor 81 é um valor possível, mas será que ele é um valor provável em um contexto de uma empresa de mineração de carvão ? Outros aspectos que devem ser considerados na descrição dos atributos são: • obrigatoriedade: estabelecer se um determinado atributo pode ter um valor nulo a ele associado. Ex: Telefone : opcional. Nome : obrigatório. • dependência: Os valores que um atributo pode assumir, muitas vezes, são dependentes dos valores de outros atributos. Neste caso é importante relacionar no dicionário de projeto como se dá esta dependência. Ex: O valor do atributo dia depende fundamentalmente do valor do atributo mês. CURSOS ALUNOS cursam (1,1) (0,N) Análise de Sistemas: Notas de Aula Ricardo de Almeida Falbo Cap.7 – Modelagem de Dados 94 UFES Departamento de Informática Além 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 transição de um estado para outro. Ex: Estado Civil: não pode passar de solteiro para viúvo. Figura 7.14 – Possíveis mudanças para o atributo estado civil. 7.3 - Outras Considerações sobre Atributos 7.3.1 - Atributos de Relacionamentos Assim como as entidades, os relacionamentos também podem possuir atributos. Atributos de relacionamentos são atributos que não são de nenhuma das duas entidades, mas sim do relacionamento entre elas e, em geral, estão relacionados com “protocolos” e datas, ou são resultantes de “avaliações”, tal como no exemplo da figura 7.15. Figura 7.15 – Atributo de relacionamento. Na prática, apenas os atributos de relacionamentos N:N são 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 máxima é 1. No exemplo da figura 7.16, o atributo data-de-lotação pode ser perfeitamente caracterizado como atributo do conjunto de entidades FUNCIONÁRIOS. Figura 7.16 – Atributo de relacionamento caracterizado como atributo de uma das entidades. Solteiro Casado Desquitado Divorciado Viúvo PRODUTOS FORNECEDORES fornecem (1,N) (0,N) cnpj razão social código descrição preço FUNCIONÁRIOS DEPARTAMENTOS lotam (1,N) (1,1) data-de-lotação