Curso de Pós-Graduação Lato sensu Especialização em Computação Desenvolvimento de Aplicações Distribuídas Disciplina Análise Orientada a Objetos Professor Dr. Antonio Francisco do Prado Parceria Fundação Educacional do Município de Assis (FEMA) Universidade Federal de São Carlos (UFSCar) Assis, Março de 2006
Índice 1. INTRODUÇÃO...3 2. ENFOQUES DOS MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE...5 2.1 MODELAGEM USANDO DECOMPOSIÇÃO FUNCIONAL...5 2.2 MODELAGEM USANDO FLUXO DE DADOS...5 2.3 MODELAGEM DE INFORMAÇÕES...6 2.4 MODELAGEM ORIENTADA A OBJETOS...6 3. PRINCÍPIOS DA ORIENTAÇÃO A OBJETOS...8 3.1 ABSTRAÇÃO...8 3.2 ENCAPSULAMENTO...9 3.3 CLASSE E OBJETO...10 3.4 HERANÇA...11 3.5 ESCALA...12 3.6 ASSOCIAÇÃO...13 3.7 COMUNICAÇÃO COM MENSAGENS...14 3.8 POLIMORFISMO...15 4. MÉTODOS ORIENTADOS A OBJETOS(HISTÓRICO)...17 4.1 MÉTODO WIRFS-BROCK [WIRFS-BROCK ET ALII 90]...17 4.2 MÉTODO COAD/YOURDON ORIENTADO A OBJETOS[COAD E YOURDON 91A, 91B]...18 4.3 METODO FUSION [COLEMAN ET ALII 94]...20 4.3.1 Análise...21 4.3.2 Projeto...30 4.3.3 Implementação...33 4.3.4 Dicionário de Dados...34 5. LINGUAGEM UML/UML2...35 5.1 USE CASE VIEW...37 5.1.1 Diagrama de Casos de Uso...37 5.1.2 Diagrama de Seqüência...42 5.1.3 Diagrama de Colaborações...46 5.1.4 Diagrama de Atividades...47 5.2 LOGICAL VIEW...49 5.2.1 Diagrama de Classes...49 5.2.2 Diagrama de Estados...56 5.3 COMPONENT VIEW...61 5.3.1 Diagrama de Componentes...61 5.4 DEPLOYMENT VIEW...67 5.4.1 Diagrama de Deployment...67 5.5 PROCESS VIEW...70 6. DESENVOLVIMENTO BASEADO EM COMPONENTES(DBC)...71 6.1 MÉTODO CATALYSIS...71 6.2 CONSTRUÇÃO DE COMPONENTES...86 6.2.1 Domínio do Problema...86 6.2.2 Especificação de Componentes...87 6.2.3 Projeto de Componentes...91 6.2.4 Implementação de Componentes....94 6.3 REUSO DE COMPONENTES...95 6.4 ESTUDO DE CASO PROPOSTO 1...96 6.5 ESTUDO DE CASO PROPOSTO 2...97 7. REFERÊNCIAS BIBLIOGRÁFICAS...98 2
1. Introdução Desenvolvimento de Software prado@dc.ufscar.br Os sistemas desenvolvidos hoje têm características diferentes dos sistemas de 10 a 15 anos atrás. São maiores, mais complexos e mais sujeitos a alterações constantes. Também, os sistemas interativos e on-line dedicam mais atenção à interface com o usuário do que os sistemas antigos, tipicamente com entradas em batch. Hoje, alguns sistemas chegam a ter 75 a 80 porcento da codificação relacionada à interface, que inclui manipulação de janelas, menus pull-down, ícones, movimentos de mouse, e outros recursos multimidia. Por outro lado, muitas organizações consideram seus sistemas atuais mais "baseados em dados" e com menor complexidade funcional do que os sistemas dos anos 70 e 80. A verdade é que o uso de Bancos de Dados tem-se tornado mais comum nos sistemas atuais. O crescimento das redes e dos Sistemas distribuídos e o grande uso da Internet e de dispositivos móveis, como telefones celulares e palmtops, têm motivado novas pesquisas para desenvolver técnicas e ferramentas que suportem o desenvolvimento de software. Embora ainda não tenhamos tecnologias consolidadas para suportar estas últimas mudanças, o mercado e as novas pesquisas na área de desenvolvimento de software, procuram oferecer uma grande quantidade de métodos, técnicas e ferramentas que facilitam e ajudam o desenvolvedor de software. Os métodos para desenvolvimento de software, orientado a objetos e mais recentemente baseados em componentes, são relativamente novos e a tendência é de serem aperfeiçoados cada vez mais na prática. Diferentes métodos têm sido propostos para melhorar o processo de desenvolvimento de software, procurando suportar as diferentes fases do ciclo de vida do software, que vão desde a identificação e análise dos requisitos, até as fases de projeto, implementação e testes. Contudo, sabe-se que o desenvolvedor precisa se comunicar efetivamente para extrair informações sobre o domínio do problema e sobre os requisitos do sistema. A engenharia de software depende muito mais das pessoas do que das fórmulas complicadas, como ocorre nas demais engenharias. A fase de Implementação Orientada a Objetos(IOO), sabe-se que esta teve início nos anos 70 com a linguagem SIMULA, parte da linguagem Smaltalk desenvolvida pela Xerox PARC. Até então o paradigma das linguagens imperativas, funcionais e lógicas dominava a programação de sistemas desenvolvidos usando métodos: de decomposição funcional e particionado em dados. Os conceitos básicos do desenvolvimento de software orientado a objetos levaram mais de 10 anos para amadurecerem. Da mesma forma que era difícil pensar em programação estruturada quando as linguagens disponíveis eram Assembler e Fortran, também ficava difícil pensar em programação orientada a objetos quando não se dispunha de linguagens como C++, Smaltalk, Ada, Delphi e Java. Assim, hoje com as atuais linguagens de programação orientadas a objetos, combinadas com linguagens, como HTML, XML, SQL e outras, disponíveis em ambientes integrados de desenvolvimento, torna-se cada vez mais adequado adotar uma abordagem para construção e reuso de componentes orientada para a prototipação evolutiva, conforme resume a Figura 1.1. Partindo dos requisitos numa primeira etapa tem-se a Especificação dos requisitos, seguida da Análise, Projeto, Implementação e Testes. Cada ciclo de execução destas etapas resulta em versões (1,2,etc), cada vez mais refinadas do protótipo do software que está sendo construído. 3
Figura 1.1 Prototipação Evolutiva Para melhor compreensão sobre o atual processo de desenvolvimento de software, apresenta-se no capítulo 2, uma visão geral sobre os principais enfoques adotados no desenvolvimento de software, desde a decomposição funcional até o desenvolvimento baseado em componentes. Em seguida, no capítulo 3, apresentam-se os princípios essenciais da orientação a objetos, que servem como ponto de partida para o entendimento dos atuais métodos, técnicas e ferramentas utilizadas no desenvolvimento de software, principalmente nas fases da Análise e Projeto do software. O capítulo 4 faz uma breve revisão dos principais métodos de desenvolvimento orientados a objetos até o surgimento da UML (Unified Modeling Language). O capítulo 5 apresenta os principais conceitos e técnicas da UML/UML2. O capítulo 6 dá uma visão geral do método de Desenvolvimento Baseado em Componentes denominado Catalysis, e finalmente propõe uma abordagem de desenvolvimento baseado em componentes que combina idéias da UML2, do método Calaysis e das experiências com projetos de desenvolvimento de software realizados no Departamento de Computação da Universidade Federal de São Carlos SP. A abordagem proposta serve como uma orientação inicial no desenvolvimento baseado em componentes, e pode ser adequada e estendida conforme as condições do projeto e da empresa ou organização que o desenvolve. 4
2. Enfoques dos Métodos de Desenvolvimento de Software Neste capítulo, são apresentados, de uma forma sucinta, os principais enfoques, anteriores ao surgimento da UML, utilizados pelos métodos de desenvolvimento particularmente na etapa de modelagem dos requisitos do software[davis 90]. Quatro enfoques são apresentados: Decomposição Funcional, Fluxo de Dados, Modelagem de Informações e Modelagem Orientada a Objetos. 2.1 Modelagem usando Decomposição Funcional Na decomposição funcional, o domínio do problema deve ser mapeado para uma hierarquia de funções e subfunções. Por exemplo, o método HIPO(Hierarchy plus Input-Process-Output), desenvolvido pela IBM, baseia-se em dois componentes principais: Representação Hierárquica, que mostra como uma função se subdivide em várias funções e Representação de Entrada-Processo-Saída, que mostra cada função na hierarquia em termos de suas entradas e saídas. De uma forma geral, na decomposição funcional, o desenvolvedor apresenta como resultado os níveis de sistema, subsistema, função e subfunção. Apesar desse enfoque ser natural para ser aplicado na solução de um problema, decompondo-o em funções, o mesmo apresenta problemas relacionados com a instabilidade da funcionalidade do sistema e com a dificuldade de se obter alta coesão e baixo acoplamento, na descrição da composição dos componentes do sistema e nas interfaces entre estes componentes. Muitos desenvolvedores encontraram dificuldades para identificar funções capazes de suportar os novos requisitos do sistema com mínimas alterações na análise e organização da especificação. Na prática, ainda se usa a decomposição funcional, porém num contexto muito específico, quando se deseja dividir um grande Serviço (comportamento que um objeto deve apresentar) em partes menores para tornar mais claro e diminuir a complexidade. Esta prática, normalmente, é feita dentro de um contexto muito limitado, não sendo usada como estrutura organizacional principal da modelagem. 2.2 Modelagem usando Fluxo de Dados Este enfoque talvez seja o mais conhecido, pois tem sido utilizado largamente no desenvolvimento da maioria dos sistemas. A principal técnica utilizada nesse enfoque é o Diagrama de Fluxo de Dados(DFD). Métodos conhecidos como análise estruturada mapeiam o mundo real através de Atividades e Fluxos de Dados. Os problemas com a análise estruturada e mais recentemente análise estruturada moderna, são relacionados com a dificuldade de integração dos modelos especificados com o DFD com os modelos de informações especificados com outras técnicas, como o Diagrama de Entidade e Relacionamento(DER). Particularmente, nas transições das fases de análise, projeto e implementação têm-se muitas dificuldades para se manter a implementação consistente com os requisitos. Também, o lado funcional deste enfoque é muito forte e acaba tendo os mesmos problemas da decomposição funcional. A utilização do DER em conjunto com o DFD e o particionamento do sistema por eventos da Análise Essencial trouxe alguns resultados positivos, porém mesmo assim continua difícil integrar os modelos especificados com essas técnicas. É crítica a passagem do DFD, uma representação em rede das atividades e dos depósitos de dados, para o Diagrama Estruturado(DE) 5
com representação hierárquica dos módulos. Ainda, a utilização de notações distintas para funções(dfd) e dados(der), embora suportado por ferramentas CASE, não é muita adequada porque leva a raciocínios separados. Outro aspecto a ser mencionado com relação a este enfoque de fluxo de dados é o tamanho do dicionário de dados que tende a ficar enorme no caso de existirem vários níveis de DFDs, quando centenas de equações de nivelamento de fluxo de dados podem ser necessárias. Outra consideração é que DFDs não são muito úteis para sistemas ou partes de sistemas baseados principalmente na atualização e recuperação de dados, ao contrário dos sistemas voltados para o processamento de transações. 2.3 Modelagem de Informações A modelagem de informações numa abordagem mais moderna consiste em mapear objetos do mundo real através de seus atributos; adicionar relacionamentos entre estes objetos; aperfeiçoar com supertipos/subtipos (para extrair atributos comuns) e objetos associativos (para descrever certos relacionamentos); e finalmente normalizar (um enfoque passo a passo para reduzir redundâncias de dados, o que é uma implementação típica de banco de dados relacional). A principal ferramenta deste enfoque é o DER. Esse enfoque tem sido bastante utilizado, particularmente para sistemas voltados para banco de dados. A predominância dos bancos de dados relacionais e, mais recentemente os relacionais estendidos fazem com que esse enfoque continue sendo bastante utilizado. Com o paradigma da orientação a objetos muito tem sido pesquisado para combinar as idéias desse enfoque com a de objetos, conforme apresentado a seguir. 2.4 Modelagem Orientada a Objetos Muito se tem pesquisado segundo este enfoque, que representa o mundo real com objetos e suas interações. Busca-se a solução dos problemas através de uma modelagem orientada a objetos, conforme ilustra a Figura 2.1. Os autores [Rumbaugh et all 91] apresentam conceitos importantes nos quais se baseia a modelagem orientada a objetos. Os grandes problemas da análise de sistemas em quase todos os sistemas estão relacionados com: a compreensão do domínio do problema, comunicação dos fatos, evolução contínua e reutilização. Para uma boa modelagem o desenvolvedor precisa compreender o domínio do problema, especialmente no caso de sistemas grandes e complexos. A partir do domínio do problema, concentrarse-á nos aspectos específicos do seu problema, ou seja, na descrição das responsabilidades do sistema que está sendo considerado, estabelecendo dessa forma as fronteiras do sistema. A interação entre o usuário e o sistema é baseada em mensagens, que correspondem, na análise estruturada moderna, à associação dos fluxos de dados com os eventos que documentam as solicitações do usuário. A grande dificuldade é que o desenvolvedor tem que conhecer o domínio do problema no qual trabalha, o que abrange um campo de atividades sob estudo ou consideração. Exemplos de domínios incluem as linguagens, as leis, as finanças e o controle do espaço aéreo. Assim, num domínio de bibliotecas o desenvolvedor precisa conhecer tudo sobre bibliotecas, regras gerais, linguagem usada, detalhes e exceções. Uma vez definido o domínio podem-se então desenvolver sistemas específicos de biblioteca. Se o desenvolvedor simplesmente assumir certos conhecimentos sobre o assunto, provavelmente, estabelecerá requisitos confusos ou inválidos. 6
Outro fator crítico do desenvolvimento é que os requisitos para um sistema são mutáveis. Sabese que novos requisitos podem surgir devido às mudanças de software, hardware, legislações, melhorias, ou outras necessidades. Na modelagem orientada a objetos, a identificação de características comuns facilita a absorção de alterações. Também, cada vez mais, a reutilização está presente em todo o ciclo de vida do software. O reuso da análise, projeto e código em sistemas semelhantes economiza tempo e recursos. Sabe-se que o domínio de problemas mudou muito pouco nos últimos anos. Os resultados das diferentes fases do desenvolvimento podem ser reutilizados e aperfeiçoados em novos sistemas, com soluções específicas de acordo com as restrições de cronograma e orçamento. Mundo dos Objetos Modelagem Problemas Sistemas Soluções Figura 2.1 - Paradigma da Orientação a Objetos Assim, a orientação a objetos aceitou o desafio de solucionar ou pelo menos amenizar estes problemas de: compreensão do domínio do problema, comunicação dos fatos, evolução contínua e reutilização. Para tal, a modelagem orientada a objetos baseia-se na aplicação uniforme dos princípios para administração da complexidade de um domínio de problemas e das responsabilidades do sistema dentro dele. Definido o domínio do problema, o desenvolvedor se concentrará nos aspectos específicos do seu trabalho, ou seja, na descrição das responsabilidades do sistema que está sendo considerado. Considerando sistema como um conjunto ou arranjo de elementos relacionados ou interligados de modo a formar uma unidade ou um todo orgânico[webster's 77] (como por exemplo o sistema rodoviário, de contabilidade ou de irrigação), as responsabilidades do sistema podem ser definidas como uma organização de elementos relacionados de modo a formar um todo. A modelagem orientada a objetos baseia-se em princípios cujo conhecimento é importante para o entendimento dos métodos utilizados no desenvolvimento de sistemas segundo esse paradigma. Esses princípios, usados em diferentes métodos de desenvolvimento orientado a objetos, para administrar a complexidade e facilitar a modelagem de sistemas, são apresentados a seguir. 7
3. Princípios da Orientação a Objetos O conhecimento dos princípios da Orientação a Objetos é de grande importância porque facilita o entendimento das idéias, técnicas e ferramentas deste novo paradigma. Um método, uma ferramenta, um ambiente ou uma linguagem é tanto mais orientado a objeto quanto mais atende aos princípios da orientação a objeto. 3.1 Abstração Abstração é a habilidade de ignorar os aspectos de um assunto não relevantes para o propósito em questão, tornando possível uma concentração maior nos assuntos principais[oxford 86]. A abstração consiste na seleção que um desenvolvedor faz de alguns aspectos, suprimindo outros. Pessoas, lugares, coisas e conceitos do mundo real são normalmente complexos. Quando queremos diminuir a complexidade selecionamos parte do que estamos analisando, em vez de tentarmos compreender o todo. A abstração pode ser de: procedimentos e objetos. Abstração de procedimentos baseia-se no princípio de que qualquer 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[oxford 86]. Normalmente, usamos abstração de procedimentos quando definimos em nossos DFDs macrofunções que se decompõem em funções, as quais por sua vez se decompõem em subfunções. Um sistema em seu nível mais alto pode ser abstraído como uma caixa preta que, uma vez executado, produz os resultados desejados. Dividir o sistema em processos e subprocessos, muito usado na análise estruturada, não é a forma principal de particionamento ou abstração da AOO. Na AOO a abstração de procedimentos é usada dentro do contexto limitado da especificação e descrição de serviços. Abstração de objetos consiste em definir os serviços e atributos aplicáveis a estes objetos. Estes objetos só podem ser modificados e observados através destes serviços[oxford 86]. A abstração de objetos serve de base para a organização do pensamento e a especificação das responsabilidades do sistema. É a habilidade de descrever novos tipos de dados em termos de seus formatos e serviços que agem sobre eles. Ao aplicar a abstração de objetos, o desenvolvedor define: - atributos e - serviços que manipulam exclusivamente estes atributos. Atributo é qualquer propriedade, qualidade ou característica que pode ser atribuída a uma pessoa ou objeto[webster's 77]. Na AOO, o termo atributo é definido de forma a refletir o domínio do problema e as responsabilidades do sistema, ou seja, atributo é um dado (informação de estado) para o qual cada objeto em uma classe tem seu próprio valor. Os atributos só podem ser acessados através de um serviço. Serviço é uma atividade executada para permitir que as pessoas utilizem alguma coisa [Webster's 77]. Na AOO, o termo serviço é definido de forma a refletir o domínio do problema e as 8
responsabilidades do sistema, ou seja, serviço é um comportamento específico que um objeto deve exibir. A abstração também depende do ponto de vista. Por exemplo, o coelho da Figura 3.1, sob o ponto de vista da moça podem-se identificar os atributos cor, aparência, etc, e sob o ponto de vista do veterinário podem-se indenticar os atributos peso, tamanho, etc. Da mesma forma, têm-se os serviços correr e brincar, do ponto de vista da moça, e criar e comer do ponto de vista do veterinário. Correr Brincar cor aparência peso tamanho Criar Comer Figura 3.1 - Abstração 3.2 Encapsulamento Princípio usado no desenvolvimento de uma estrutura global de programa, que estabelece que cada componente do programa deve conter uma única decisão de projeto. A interface para cada módulo é definida de forma a revelar o menos possível sobre seu funcionamento interno[oxford 86]. O objetivo do encapsulamento (ocultamento de informações) é restringir o escopo ou visibilidade da informação para obter melhor legibilidade, manutebilidade e principalmente reutilizabilidade no desenvolvimento de um novo sistema. O encapsulamento permite que o desenvolvedor reuna os aspectos mais instáveis de forma a facilitar sua localização e manutenção em caso de alterações, hoje muito comum nos sistemas. O encapsulamento pode ainda ser visto como um processo pelo qual se combinam os atributos e os serviços que agem sobre esses atributos, em uma definição que oculta detalhes de implementação. Por exemplo, a calculadora da Figura 3.2, tem internamente seus registradores, que são ocultos por uma interface que disponibiliza para o usuário apenas os serviços de Somar, Subtrair e outras operações. Note ainda que detalhes dos processos pelos quais se obtem um resultado não estão diretamente visíveis para quem está usando a calculadora, e nem mesmo isto interessa. Em resumo, 9
reúnem-se atributos e serviços disponibilizando apenas o que interessa mostrar, normalmente os serviços. 3.3 Classe e Objeto Figura 3.2 - Encapsulamento : Calculadora Das idéias de abstração e encapsulamento tem-se o Tipo Abstrato de Dados(TAD), que possui uma interface para ocultar detalhes de implementação, possibilitando que se tenham diferentes especificações, em diferentes tempos, sem afetar as aplicações que utilizam o TAD. Um TAD pode também ser chamado de Classe, a qual pode ser vista como uma fábrica de objetos idênticos no que diz respeito à sua interface e implementação. Assim por exemplo, tem-se, na Figura 3.3, o TAD Pessoa, ou a Classe Pessoa, cujos atributos são Nome, Endereço, Identidade, Estado Civil e outros, e cujos serviços são Estudar, Trabalhar, Dirigir, Passear, e outros. Portanto, uma classe é um conjunto de objetos similares. Uma instância de uma classe é chamada Objeto da Classe. Na Figura 3.3 tem-se que Maria e Pedro são duas instâncias da classe Pessoa. 10
Classe Pessoa objeto Maria objeto Pedro Figura 3.3 Classe e Objeto Pessoa 3.4 Herança A abstração de dados é uma técnica efetiva para se definir um conceito único e claro, como os TADs. Contudo, muitas vezes pode-se ter um TAD que é quase, mas não exatamente o que queremos e, neste caso, a herança é uma técnica útil para ampliar a abstração de dados. Baseado nesses conceitos define-se: Herança é o mecanismo para expressar a similaridade entre Classes, simplificando a definição de Classes iguais a outras que já foram definidas. Este princípio permite representar uma só vez os membros comuns, serviços e atributos, assim como especializar estes membros em casos específicos. Outro aspecto importante é que a herança possibilita a reutilização nos diferentes níveis de abstração durante o desenvolvimento de software. Assim, logo na concepção e projeto a reutilização pode ocorrer através de especificações comuns, como no caso da hierarquia de classes. A herança define uma relação entre classes do tipo é-um(a), onde uma classe compartilha a estrutura e o comportamento definidos em uma ou mais classes. O reconhecimento da similaridade entre classes forma uma hierarquia de classes, onde superclasses representam abstrações generalizadas e subclasses representam abstrações, onde atributos e serviços específicos são adicionados, modificados ou removidos. As classes são conectadas por uma estrutura de generalização e especialização, tornando explícitos os atributos e serviços comuns em uma hierarquia de classes. Na Figura 3.4, tem-se, por exemplo, que Estudante é uma Pessoa, Professor é uma Pessoa. Um objeto da classe Estudante tem, não apenas os atributos e serviços de Estudante, como também os atributos herdados da classe Pessoa. Por exemplo, o estudante João tem atributos e serviços de Pessoa, como Nome, Endereço, Dirigir, Viajar, e atributos e serviços que expressam o comportamento específico de um estudante, como Curso, Nota, Estudar e Realizar Prova. A classe Pessoa é reconhecida como uma generalização e Estudante como uma classe especialização, a qual herda os serviços e atributos de Pessoa. Além disso, uma classe derivada (uma especialização) pode incluir novos serviços e atributos ou redefinir os serviços herdados. Dessa forma, Funcionário pode incluir 11
atributos como Salário e Profissão e serviços como CalcularSalário, que podem não ser relevantes ou apropriados para Pessoa em geral. P essoa Estudante Professor Funcionário Diretor Figura 3.4 - Herança : Classe Pessoa e classes derivadas 3.5 Escala É o princípio que permite ao desenvolvedor considerar algo muito grande através do enfoque Todo-Parte. Todo-Parte é um dos serviços básicos naturais de organização dos seres humanos que orienta o desenvolvedor através de um modelo extenso. Assim, grande parte da complexidade de um problema pode ser resolvida dividindo-o em partes. No caso de classes, Todo-Parte é um mecanismo que permite a construção de uma classe a partir de outras classes componentes. Usa-se dizer que um objeto da classe tem objetos das classes componentes (partes). Por exemplo, na Figura 3.5 tem-se que uma casa tem portas, janelas, paredes, escadas e outras partes. TODO PARTES Figura 3.5 - Todo-Parte : Classe Casa e classes compostas 12
Mesmo em se tratando de entidades abstratas, pode-se compor um objeto a partir de outros objetos. A Figura 3.6 mostra que um Pedido (Todo) é composto ou tem ItensPedidos (Partes), no caso Relógio e Computador. TODO PEDIDO PARTES Item 1: Relógio Item 2: Computador Figura 3.6 - Todo-Parte : Classe Pedido e classes compostas 3.6 Associação A associação vem do relacionamento entre as entidades do mundo real, e é usada para associar certos objetos que ocorrem em algum ponto no tempo ou sob circunstâncias similares. Associação é uma união ou conexão de idéias[webster's 77]. Na orientação a objetos a associação é modelada através de uma conexão de ocorrências. Uma conexão de ocorrência é um relacionamento que um objeto tem com outro(s) objeto(s), para cumprir suas responsabilidades. Por exemplo, a Figura 3.7 mostra a associação entre Estudante, Teste e Sala. Neste relacionamento ternário, tem-se que cada estudante faz determinado teste em uma sala. Outros tipos de relacionamentos binários ou de maior ordem podem existir, como o mostrado na Figura 3.8 onde Cliente faz determinado Pedido. 13
Estudante Faz Teste Sala Figura 3.7 - Associação : Relacionamento Estudante-Teste-Sala Cliente Faz Pe dido Figura 3.8 - Associação: Relacionamento Cliente - Pedido 3.7 Comunicação com Mensagens Mensagem é qualquer comunicação, escrita ou oral feita entre pessoas[webster's 77]. Na orientação a objetos a comunicação entre objetos, é feita através de mensagens modeladas através de conexões de mensagens. Uma conexão de mensagem representa a dependência de processamento de um objeto, indicando quais serviços ele precisa para cumprir suas responsabilidades. As conexões de mensagens existem somente em função dos serviços, e podem ser de: um objeto para outro objeto; um objeto para uma classe (criação de objetos); uma classe para outra classe (criação de objetos dentro de outros objetos). 14
Numa conexão de mensagem, tem-se uma classe ou objeto emissor que envia a mensagem para uma classe ou objeto receptor para realização de algum processamento. O processamento necessário é nomeado na especificação de serviços do emissor, e é definido na especificação de serviços do receptor. Na Figura 3.9, uma estudante, objeto da classe Estudante, dispara uma mensagem para o professor, objeto da classe Professor. A mensagem é tratada e é retornada uma resposta. Abram seus livros na página 36 Qual a próxima lição? Figura 3.9 - Conexão de Mensagem : Aluno e Professor Considerando que os serviços modelam o comportamento dos objetos, três tipos de classificações de comportamentos são mais freqüentemente usados: (1) com base na causa imediata; (2) conforme similaridade de evolução histórica(alteração com o tempo) e (3) conforme a similaridade de função. Considerando que os serviços definem o comportamento requerido que um objeto deve refletir, essas classificações são incorporadas nas estratégias que definem: (1) Estados de objeto - elaborada com base no princípio de alteração com o tempo. (2) Serviços requeridos - elaborada com base nos princípios de similaridade de função e causa imediata. 3.8 Polimorfismo 15
Polimorfismo é o princípio relacionado com as diferentes formas de um objeto. Operacionalmente, o polimorfismo pode ser visto conforme mostra a Figura 3.10, onde se pode instanciar um objeto Janela de várias formas. Também se pode observar que operadores podem ser sobrecarregados para realizar operações com diferentes tipos de objetos. Por exemplo, o operador + está sendo utilizado para somar inteiros e matrizes. 1 Janela ( ) Polimorfismo Janela ( 1 x 2, 2 ) Janela ( 1 x 2, 2, Azul ) 95 + 5 = 100 2 5 7 4 8 2 3 1 3 + 1 5 2 4 3 2 4 1 5 = Figura 3.10 - Polimorfismo Um exemplo clássico de poliformismo é o das formas geométricas. Uma hierarquia de classes pode ser construída a partir da classe FormaGeometrica. Assim, podem-se ter classes Elipse, Retângulo e outras derivadas de FormaGeometica, e classes Circulo e Quadrado, derivadas de Elipse e Retângulo, respectivamente. Essas classes podem ter atributos e comportamentos comuns definidos na classe FormaGeometica, como o centro da figura e o serviço moverfigura. Assim, para mover qualquer objeto da hierarquia de classes, por exemplo, um objeto círculo, basta mover seu centro usando o serviço moverfigura. Contudo, para redesenhar a figura é necessário buscar o comportamento específico definido em cada classe derivada. Nesse caso, tem-se o polimorfismo para buscar o comportamento adequado. Finalizando este capítulo, convém salientar que existem outros princípios aqui não apresentados, como o de meta objetos e genericidade (tipos genéricos), que também são importantes para conhecer melhor o paradigma da orientação a objetos. O conhecimento dos princípios da orientação a objetos é de fundamental importância, principalmente porque nos ajuda a pensar em objetos e não apenas em dados e/ou funções, como era no paradigma tradicional de desenvolvimento de software. Em seguida, serão apresentados alguns métodos utilizados para o desenvolvimento de software orientado a objetos, que antecederam a UML(Unified Modeling Language). 16
4. Métodos Orientados a Objetos(histórico) O termo orientado a objetos pode não apresentar uma idéia clara, porque o nome objeto tem sido usado de formas diferentes em duas áreas diferentes: (1) Na modelagem de informações para representar alguma coisa real e suas ocorrências. Aqui, objetos dizem respeito apenas a dados; e (2) Nas linguagens de programação orientada a objetos, significa uma instância em tempo de execução de algum processamento e valores, definidos por uma descrição estática chamada classe. Convém observar que na modelagem pura de informações não há mecanismo de dependência uniforme de processamento e nem herança. Peter Wegner[Wegner 89] dá o seguinte enfoque para as linguagens de programação definidas segundo o paradigma orientado a objetos: (1) Baseada em Objetos: Suporta a funcionalidade de objetos, mas não possui nem classes e nem herança. Por exemplo, ADA. (2) Baseada em Classes: Suporta a mesma funcionalidade da linguagem baseada em objetos e inclui o conceito de classe. Por exemplo, CLU. (3) Orientada a Objetos: Possui as mesmas características da linguagem baseada em classes e inclui o princípio de herança. Por exemplo, C++ e Smalltalk[Goldberg and Robson 83]. A verdade é que uma linguagem, um método ou mesmo uma ferramenta CASE é tanto mais orientado a objetos quanto mais atende aos princípios do paradigma da orientação a objetos. A AOO é baseada nos conceitos da modelagem de informações, das linguagens orientadas a objetos e ainda dos sistemas baseados em conhecimentos, ou seja, nos princípios básicos para a administração da complexidade. Existem hoje no mercado vários métodos para desenvolvimento de sistemas orientados a objetos. Alguns métodos cobrem melhor as fases iniciais da coleta de fatos e análise de requisitos e outros a fase de projeto e implementação. Poucas propostas cobrem todo ciclo de vida do software. A seguir apresentaremos uma descrição sucinta de alguns métodos mais conhecidos, elaborada por Cabral e outros [Cabral et alii 93]. Uma descrição mais detalhada pode ser encontrada nas bibliografias referenciadas. 4.1 Método Wirfs-Brock [Wirfs-Brock et alii 90] Esta metodologia utiliza a visão cliente-servidor, enfatizando o comportamento dinâmico e as responsabilidades das classes. A ênfase é dada às fases de Projeto e Implementação. O processo é exploratório e informal, sendo mais adequado ao desenvolvimento de pequenos projetos. A introdução de novas terminologias (contrato, responsabilidades e colaborações) podem dificultar a sua aceitação, por apresentar mudanças radicais em relação às metodologias já utilizadas. A sua notação é formada por: Cartões de classes e subsistemas; Diagrama de hierarquia de classes; 17
Diagrama de Venn: que ajudam a definir as responsabilidades das classes; Diagrama de colaboração entre classes: que representa o comportamento dinâmico destas e Cartões de contrato: que documentam todos os contratos entre clientes e servidores. 4.2 Método Coad/Yourdon Orientado a Objetos[Coad e Yourdon 91a, 91b] O modelo AOO proposto por Coad/Yourdon consiste em cinco atividades principais: identificação de Assuntos; localização de Classes-e-Objetos; identificação de Estruturas; definição de Atributos e definição de Serviços. Estas atividades podem ser executadas em ordens diferentes, dependendo do domínio do problema analisado e da experiência do desenvolvedor. Decidir quando a análise e a especificação termina depende do domínio, da responsabilidade dos sistema e das verificações, tudo conforme as exigências de cronograma e orçamento. Assim, o modelo de AOO é apresentado e revisado em cinco níveis, mostrados na Figura 4.1. Assunto Classe e Objeto Estrutura Atributo Servico Figura 4.1 - Níveis da AOO Estes cinco níveis podem ser vistos como cinco camadas de especificações superpostas, conforme mostra o exemplo da Figura 4.2, que modela um sistema de distribuidora de produtos. Os resultados da Análise são representados pelo componente Domínio do Problema (CDP), através dos diferentes níveis: Classe e Objetos, Atributo, Estrutura e Serviço. O sistema está particionado num único Assunto, que não está representado no modelo. 18
Conforme se pode notar, ainda não se têm idéias bem consolidadas sobre qual a melhor abordagem a aplicar no desenvolvimento de sistemas orientados a objetos. O método Coad/Yourdon, apesar de apresentar pequenos problemas denotacionais quando usado em sistemas de grande escala, tem as vantagens de ser bastante divulgado, muito didático e de facilitar a compreensão dos novos conceitos da AOO, POO e IOO. O método representa Classe e Objeto por retângulos com cantos arredondados, sendo o mais interno a representação da Classe e o mais externo os Objetos. Na parte superior, tem-se o nome da classe, no meio os atributos e na parte inferior os Serviços. A estrutura de Generalização-Especialização (herança) é representada por uma meia lua, ligando a classe pais às classes derivadas (filhos). Todo-Parte é representado por um triângulo, que aponta o Todo. As conexões de ocorrências são representadas por linhas cheias que ligam objetos de uma classe a objetos de outra classe. Tanto no Todo-Parte como nas conexões de ocorrências são indicadas as respectivas cardinalidades (mínima, máxima), que indicam as ocorrências de objetos nos relacionamentos. Conexões de mensagens são representadas por linhas mais cheias, ou também tracejadas, partindo da classe emissora da mensagem e apontando a classe receptora da mensagem. O método usa a mesma notação para análise e projeto. Outras ferramentas como Diagramas de Serviços e Diagramas de Transição de Estados são utilizados na modelagem. Cliente Cod Nome End Pagar 0,m 0,m Pedido Número Data Atender 1 1,m 1 Detalhe Pedido Quantidade Situação 0,m 1,n 1 0,m Produto Código Nome Listar 1 0,m Detalhe Requisição Quantidade Preço 1 1,m 0,m 1,m 1 0,m Fornecedor Código Nome End Pagar Requisicao Número Data NúmeroNE DataNE Situação Emitir TratarNota 0,m Pessoa Física CPF Pessoa Jurídica CGC 1 Fatura Número Valor Vencimento Situação 1 Emitir Liquidar Figura 4.2 - Distribuidora de Produtos - Camadas Classe e Objetos, Atributo, Estrutura e Serviço 19
4.3 Método Fusion [Coleman et alii 94] O método Fusion foi desenvolvido para prover uma abordagem sistemática para desenvolvimento de software orientado a objetos. O processo de desenvolvimento de software conta com dois estágios: produção e montagem. A produção cobre as três fases do ciclo de vida do software: Análise (O que o sistema faz), Projeto (define Como o comportamento especificado na análise é obtido) e Implementação (codificação do projeto em linguagem de programação). Neste estágio obtém-se qualidade, evitando os erros. No estágio da montagem do software, obtém-se qualidade pela detecção e remoção dos erros. Quanto mais tarde um erro é encontrado, mais cara será a sua reparação. Um método confiável deve usar técnicas que reduzam a probabilidade de erros, e deve conter checagem de erros que possam ocorrer, pois é mais eficiente evitar os erros que corrigi-los. O método Fusion, então, se concentra na produção, ao invés da montagem do modelo. Métodos sistemáticos gastam mais tempo nas fases prévias do desenvolvimento do software. O código leva mais tempo para aparecer, e seus benefícios incluem: verificação de requisitos; conceitos mais claros; menos reprojeto de trabalho; melhor fabricação do trabalho de projeto (decomposição do problema em partes independentes); melhoria das comunicações entre os desenvolvedores e necessidade de menos esforço na manutenção. Fusion é um método de desenvolvimento que fornece suporte em aspectos técnicos e gerenciais do desenvolvimento de software: Divide o processo de desenvolvimento em fases e indica o que deve ser feito em cada fase; Fornece notações compreensíveis e bastante formais e Possui verificações para assegurar a consistência dentro e entre as fases. Na análise, os modelos são produzidos com objetivo de descrever: classes de objetos que existem no sistema; relacionamentos entre as classes; operações que podem ser executadas no sistema e seqüências permissíveis das operações. No projeto, o desenvolvedor decide como as operações do sistema devem ser implementadas, pelo comportamento em tempo de execução da interação entre os objetos. Durante o processo, operações se prendem às classes, e o desenvolvedor escolhe também como os objetos vão se referir uns aos outros, e quais são os relacionamentos de herança apropriados entres as classes. Os modelos desta fase mostram: Como operações de sistemas são implementadas pela interação entre objetos; Como as classes se referem umas às outras e como se relacionam por herança; Classes, atributos e operações em classes. 20
Na fase de implementação, o projeto deve ser transformado em código numa linguagem de programação executável. A codificação numa linguagem orientada a objetos facilita a implementação. Convém observar que: Herança, referência e atributos de classes são implementados em linguagem de programação; Interações entre objetos são codificadas como serviços pertencendo à determinada classe e As seqüências permitidas de operações são reconhecidas por máquina de estados. O Fusion também oferece informação em questões de performance, e sugere como a inspeção tradicional e as técnicas de teste devem ser modificadas para software orientado a objetos. 4.3.1 Análise A análise focaliza o domínio do problema, e diz respeito ao comportamento visivelmente externo do sistema. A preocupação principal é com os requisitos do sistema, ou seja, O Que? se deseja do sistema. As restrições de implementação e os problemas de tecnologias como por exemplo, limitações de processadores, memória, tempo de resposta e outros, não são relevantes nesta fase. A fase de análise produz dois modelos que capturam diferentes aspectos de um sistema: Modelo Objeto: define a estrutura estática de informação no sistema e Modelo de Interface: define as comunicações de entrada e saída do sistema. Dependendo da complexidade do sistema, pode-se ter mais de um Modelo Objeto. Uma divisão por assuntos pode proporcionar uma visão geral que orienta o desenvolvedor em um modelo extenso. Os assuntos também são úteis para a organização de pacotes de trabalho em grandes projetos, para facilitar a visibilidade e compreensão do modelo. 4.3.1.1 Modelo Objeto Modela as classes de objetos e a associação entre objetos pertencentes às classes. Objeto é uma instância da classe que pode ser univocamente identificada. A parte estática do objeto é composta de: Identificador; número de atributos e nome dos atributos. Na fase de análise, raramente nos preocupamos em como um objeto pode ser univocamente identificado. Deve haver um identificador ou alguma combinação de atributos que contenha informações suficientes para tornar a identificação possível. É sempre possível distinguir objetos distintos, mesmo que tenham os mesmos valores de atributos. O objeto possui uma identidade que não pode ser mudada. Os objetos se comunicam para executar operações através de métodos ou serviços. Os serviços tratam da parte comportamental dos objetos. Uma classe é uma abstração que representa a idéia ou a noção geral de um conjunto de objetos similares. Objetos podem ter instâncias de conexões um com o outro, mas não necessariamente ter relacionamentos de subordinação. Estas conexões complementam a representação do estado do objeto feita pelos seus atributos, modelando a união ou conexão de idéias. As pessoas usam estas conexões para modelar certas coisas que acontecem em um determinado instante ou sob circunstâncias similares, 21
ou seja, para mapear os relacionamentos entre os objetos, para que estes cumpram suas responsabilidades. Na Figura 4.3 têm-se duas classes: Professor e Curso, cujos objetos se relacionam através do relacionamento ensina, representado pelo losango que liga as duas classes. Professor Curso Nome Disciplina + ensina 1 Nome Figura 4.3 - Relacionamento entre classes O relacionamento entre as classes utiliza o limite de cardinalidade para restringir o número de objetos que devem participar do relacionamento. As formas de representação são: 12 numérica 1..4 intervalo * zero ou mais (representação default ) + um ou mais todos os objetos da classe adjacente devem aparecer no relacionamento. Quando o relacionamento é obscuro, podemos atribuir papéis aos objetos, por exemplo no caso em que um objeto pessoa é pai ou mãe de outra pessoa ou é casado com outra pessoa. Algumas perguntas, apresentadas a seguir, podem orientar o desenvolvedor na definição dos atributos. Supondo ser um objeto específico, pergunte: Como sou descrito em geral? Como sou descrito neste domínio de problemas? Como sou descrito no contexto das responsabilidades do sistema? O que preciso saber? De quais informações de estado preciso sempre me lembrar? Quais podem ser meus estados? Seguindo os princípios básicos da análise, não crie atributos como Chave e TotalParcial, apenas para atender restrições de implementação. Identificadores explícitos como Chave servem para identificar um objeto específico, porém necessitam de garantias que evitem duplicatas, o que implica em decisões de projeto não importantes em nível de análise. TotalParcial representa um valor batch dos resultados de processamentos anteriores. Na AOO é mais adequado especificar o cálculo requerido, através de um Serviço CalcularTotalParcial, do que especificar o atributo TotalParcial. Outro caso, é o da normalização, que exige que não se tenha atributo multivalorado, porém esta preocupação também não é importante durante esta fase da modelagem, mesmo porque nesta fase o desenvolvedor ainda não sabe se irá normalizar os dados. A Figura 4.4 mostra um relacionamento entre Médico e PacienteInterno, tal que cada paciente de PacienteInterno tem obrigatoriamente um médico, e um médico pode ter 0 ou mais pacientes. Isto significa que paciente não existe sem médico e médico existe mesmo sem paciente. 22
Médico Id Nome Endereço 1 examina * PacienteInterno Quarto Leito Medicação Figura 4.4 - Conexão de Ocorrência O caso especial com relacionamento muitos-para-muitos, como o mostrado na Figura 4.5, em que os atributos DataHora e Quantia descrevem a interação, em determinado instante, entre um autor e um livro, podem requerer a adição ao modelo, na fase de implementação, de uma classe do tipo evento lembrado. Autor Nome Endereço + Publica DataHora Quantia + Livro Título ISBN Ano Figura 4.5 - Conexão de Ocorrência muitos-para-muitos A Figura 4.6 mostra um relacionamento entre objetos de uma única classe. Se o significado de um mapeamento for simples, como por exemplo, Proprietário que é casado com outro, então apenas a Conexão de Ocorrência é suficiente. Caso contrário, adicione uma nova Classe-e-Objeto do tipo evento lembrado. Proprietário 1 Marido Casado 1 Esposa Figura 4.6 - Relacionamento entre objetos de uma única classe Outro caso especial de Conexão de Ocorrência ocorre quando for necessário mais de um mapeamento entre objetos, os quais precisam de alguma distinção semântica, que pode ser obtida com a adição de uma outra Classe-&-Objeto, evento lembrado. Na Figura 4.7 a Classe-e-Objeto eventodeacesso capta a diferença semântica entre os diferentes mapeamentos das conexões ler e modificar. 23
eventolegal * ler * escriturário * modificar * eventolegal eventode 1 tem * acesso datahora * faz 1 tipoacesso escriturário Figura 4.7 - Múltiplas Conexões de Ocorrências entre objetos Para um mapeamento correto, no domínio do problema e nas responsabilidades do sistema, verifique as Conexões de Ocorrências para cada par de objetos. Se for necessário, então adicione a conexão correspondente. O método Fusion permite a agregação de classes, ou seja, a implementação do Todo-Parte. Permite a construção de uma classe agregada formada por outras classes componentes. Também é possível implementar a herança de classes, tanto simples como múltipla, através de estruturas de Generalização e Especialização(Gen-Esp). Gen-Esp representa a abstração que captura a relação geral/específico entre entidades ou problemas no mundo real, e pode ser pensada como uma estrutura é um ou é um tipo de, sob o ponto de vista de Especialização. É a implementação da herança. Por exemplo, em um sistema hospitalar, PacienteInterno e PacienteExterno são vistos como especializações da Classe Paciente, conforme mostra a Figura 4.8. Relacionamentos do tipo Gen-Esp implicam que objetos subordinados(pacienteinterno e PacienteExterno) sejam membros de Classe(Paciente). O triângulo sólido indica que as subclasses particionam a superclasse, ou seja, só existem PacienteInterno e PacienteExterno. Caso contrário, o triângulo é vazio, como no caso das classes Rel01 e Rel02, derivadas de Relatório, indicando que existem outras subclasses de Relatório, além de Rel01 e Rel02. Paciente Nome Nascimento Altura Peso PacienteInterno Quarto Leito Medicação PacienteExterno ÚltimaVisita PróximaVisita Médico Figura 4.8 - Exemplos de Estrutura Generalização-Especialização 24
A estrutura Gen-Esp é representada com uma classe de generalização no topo e classe(s) de especialização abaixo, refletindo um mapeamento entre classes e não entre objetos. É conveniente nomear as especializações com o nome da classe pai seguido de um qualificador que descreve a natureza da especialização. Por exemplo, no caso da classe Sensor, a especialização SensorCrítico é preferida em relação a apenas Crítico, conforme se pode ver na Figura 4.9. Sensor Modelo SequênciaInicial Conversão Intervalo Limiar Estado Valor SensorCrítico Tolerância Figura 4.9 - Sistema Sensor - Generalização-Especialização Todo-Parte representa o particionamento que captura a relação agregação/parte de entre entidades e problemas no mundo real, e pode ser pensada como uma estrutura tem um, sob o ponto de vista do Todo. Por exemplo, no sistema hospitalar, Coração, Rim e Vista são vistos como partes do Objeto Paciente, conforme mostra a Figura 4.10. Relacionamentos do tipo Todo-Parte implicam que objetos subordinados(coração, Rim e Vista) sejam partes de outro Objeto (Paciente). Todo-Parte normalmente é usado para descrever um problema ou sua solução em termos de suas partes. Por exemplo, para descrever o problema de DefesaDeUmaNação contra mísseis balísticos fica mais fácil descrevê-lo em termos de sua partes: Detecção, Comunicação, Reconhecimento, Lançamento e Defensiva. Decompondo o problema em subproblemas facilita a análise. 25
Paciente Nome Nascimento Altura Peso 1 1,2 0,2 Coração Natural/Artificial Implantado Bpm Rim Natural/Artificial Implantado Tipo Vista Natural/Artificial Visão Tipo Figura 4.10 - Exemplo de Estrutura Todo-Parte A notação usada para representar a estrutura Todo-Parte permite expressar os diferentes relacionamentos entre os objetos. Em particular, na Figura 4.10, Paciente tem obrigatoriamente 1 Coração e 1 ou 2 Rins e até 2 Vistas. Uma estrutura Todo-Parte pode indicar: Montagem de partes, Conteúdos de Recipiente e Membros de Conjunto. Na Figura 4.11tem-se que 1 Avião é uma montagem com Motor como Parte. Note que posso ter vários motores em um avião, cujas montagens são realmente físicas. Avião 1,4 Motor Figura 4.11 - Estrutura Todo-Parte - Montagem-Partes Na Figura 4.12, tem-se que o Avião é considerado como um recipiente no qual Passageiro está dentro dele. 26
Avião * Passageiro Figura 4.12 - Estrutura Todo-Parte - Recipiente-Conteúdos Na Figura 4.13, tem-se que 1 Organização é um conjunto de Escriturário. Um PlanoDeGuerra pode ser visto como um conjunto ordenado de Ação, conforme mostra a Figura 4.14. Organização * Escriturário Figura 4.13 - Estrutura Todo-Parte - Conjunto-Membros PlanoGuerra 1,m Especificação Adicional Ação Ação é um conjunto ordenado Figura 4.14 - Estrutura Todo-Parte - Conjunto-Membros (com uma restrição) 4.3.1.2 Modelo de Interface Um sistema é modelado como uma entidade ativa que interage com outras entidades chamadas agentes. Os agentes modelam usuários humanos ou outros sistemas de hardware e software. O ambiente é constituído de agentes com os quais o sistema se comunica. A comunicação entre o sistema e o ambiente se dá através de eventos. Um evento pode ser disparado por agentes externos ou pelo tempo. Associado a cada evento externo tem-se um estímulo que vai disparar uma atividade do sistema. A interface de um sistema é o conjunto de operações associadas aos eventos que podem ser disparados. 27