Projeto orientado a objetos

Transcrição

1 Projeto orientado a objetos Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 1 Objetivos Explicar como um projeto de software pode ser representado como um conjunto de objetos que interagem e que gerenciam seu estado e operações. Descrever as atividades no processo de projeto orientado a objetos Apresentar vários modelos que podem ser usados para descrever um projeto orientado a objetos Mostrar como a UML pode ser usada para representar esses modelos Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 2

2 Tópicos abordados Objetos e classes de objetos Processo de projeto orientado a objetos Evolução de projeto Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 3 Desenvolvimento orientado a objetos Análise, projeto e programação orientados a objetos estão relacionados, mas são distintos. A análise orientada a objetos concentra-se no desenvolvimento de um modelo de objetos do domínio da aplicação. O projeto orientado a objetos concentra-se no desenvolvimento de um modelo orientado a objetos de sistema para implementar requisitos. A programação orientada a objetos concentra-se no desenvolvimento de um projeto orientado a objetos usando uma linguagem de programação, tal como Java ou C++. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 4

3 Características do projeto orientado a objetos Objetos são abstrações do mundo real ou entidades de sistema e gerenciam a si próprios. Os objetos são independentes e englobam estados e informações de representação. A funcionalidade do sistema é expressa em termos de serviços de objetos. Áreas de dados compartilhados são eliminados e os objetos se comunicam por meio da passagem de mensagens. Objetos podem ser distribuídos e executados seqüencialmente ou em paralelo. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 5 Objetos que interagem entre si Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 6

4 Vantangens do projeto orientado a objetos Maior facilidade de manutenção. Os objetos podem ser compreendidos como entidades autônomas. Objetos são, potencialmente, componentes reusáveis. Para alguns sistemas, pode haver um mapeamento óbvio de entidades do mundo real para objetos de sistema. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 7 Objetos e classes de objetos Objetos são entidades em um sistema de software que representam instâncias do mundo real e entidades de sistema. Classes de objeto podem herdar atributos e serviços de outras classes de objeto. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 8

5 Objetos e classes de objetos Um objeto é uma entidade que possui um estado e um conjunto definido operações definidas para funcionar nesse estado. O estado é representado como um conjunto de atributos de objeto. As operações associadas ao objeto fornecem serviços a outros objetos (clientes) que solicitam estes serviços quando alguma computação é necessária. Os objetos são criados de acordo com uma definição de classe de objeto. Uma definição de classe de objeto funciona tanto como uma especificação quanto como um template para criação de objetos. Essa definição inclui declarações de todos os atributos e operações que devem ser associadas a um objeto dessa classe. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 9 A linguagem de modelagem unificada (UML) Várias notações diferentes para a descrição de projetos orientados a objetos foram propostas nas décadas de 1980 e A UML é uma integração dessas notações. Ela descreve notações para uma série de modelos diferentes que podem ser produzidos durante a análise e o projeto de objetos orientados. Ela é atualmente um padrão de fato para modelagem de objetos orientados. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 10

6 Classe de objeto Funcionário (UML) Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 11 Comunicação de objetos Conceitualmente, os objetos se comunicam por meio da de passagem de mensagens. Mensagens O nome do serviço solicitado pelo objeto chamador; As cópias das informações necessárias para executar o serviço e o nome de um objeto para o resultado do serviço. Na prática, as mensagens são freqüentemente implementadas pelas chamadas de procedimentos Nome = nome de procedimento; Informação = lista de parâmetros. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 12

7 Exemplo de mensagens //Chamar um método associado a um // objeto buffer que retorna o próximo valor // no buffer v = circularbuffer.get () ; // Chamar o método associado a um objeto // termostato que ajuste a temperatura a ser // mantida thermostat.settemp (20) ; Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 13 Generalização e herança Objetos são membros de classes que definem tipos de atributos e operações. As classes podem ser organizadas em uma hierarquia onde uma classe (uma classe-pai) é uma generalização de uma ou mais classes (classesfilho). Uma classe-filho herda os atributos e as operações da classe-pai e pode adicionar novos métodos ou atributos para si. A generalização na UML é implementada como herança nas linguagens de programação orientada a objetos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 14

8 Uma hierarquia de generalização Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 15 Vantagens da herança É um mecanismo de abstração que pode ser usado para classificar entidades. É um mecanismo de reuso em ambos os níveis, projeto e programação. O gráfico de herança é uma fonte de conhecimento da organização acerca de domínios e sistemas. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 16

9 Problemas com herança Classes de objetos não são auto-contidas. Elas não podem ser compreendidas sem referência às suas classes-pai. Projetistas tendem a reusar o gráfico de herança criado durante a análise. Isso pode conduzir à uma ineficiência significativa. Os gráficos de herança de análise, projeto e implementação têm diferentes funções, e devem ser mantidos separadamente. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 17 Associações de UML Objetos e classes de objeto participam de relacionamentos com outros objetos e classes de objeto. Na UML, um relacionamento generalizado é indicado por uma associação. Associações podem ser anotadas com informações que descrevem a associação. Associações são gerais, mas podem indicar que o atributo de um objeto é um objeto associado, ou que um método conta com um objeto associado. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 18

10 Um modelo de associação Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 19 Objetos concorrentes A natureza dos objetos como entidades auto-contidas os torna adequados para implemantação de concorrência. O modelo da passagem de mensagem da comunicação de objetos pode ser implementado diretamente se eles são executados em processadores separados em um sistema distribuído. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 20

11 Servidores e objetos ativos Servidores O objeto é implementado como um processo paralelo (servidor) com pontos de entrada que correspondem às operações de objeto. Se nenhuma chamada é feita para ele, o objeto suspende a sua execução e aguarda outras solicitações de serviço. Objetos ativos Os objetos são implementados como processos paralelos, e o estado interno do objeto pode ser modificado por ele próprio, e não simplesmente por chamadas externas. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 21 Objeto ativo transponder Objetos ativos podem ter seus atributos modificados, mas podem, também, atualizálos autonomamente usando operações internas. Um objeto transponder transmite a posição da aeronave. A posição pode ser atualizada usando um sistema de navegação por satélite. O objeto atualiza peeriodicamente a posição pela triangulação dos satélites. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 22

12 Um objeto ativo Transponder Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 23 Threads Java Threads em Java são uma construção simples para implementar objetos concorrentes. Os threads devem incluir um método chamado run() e é iniciado pelo sistema runtime Java. Objetos ativos incluem tipicamente um loop infinito e, assim, eles estão sempre executando o processamento. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 24

13 Um processo de projeto orientado a objetos Processos de projeto estruturados envolvem o desenvolvimento de uma série de modelos diferentes de sistema. Eles requerem uma grande quantidade de esforço para desenvolvimento e manutenção desses modelos e, para sistemas pequenos, isto pode não ser adequado em termos de custo. Contudo, para sistemas grandes desenvolvidos por grupos diferentes, modelos de projeto são um mecanismo essencial de comunicação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 25 Estágios de processo Destaca as atividades-chave sem estar amarrado a qualquer processo proprietário, tal como o RUP. Define o contexto e os modelos de uso do sistema; Projeta a arquitetura do sistema; Identifica os objetos principais do sistema; Desenvolve modelos de projeto; Especifica interfaces de objetos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 26

14 Descrição do sistema de meteorologia Um sistema de mapeamento meteorológico é necessário para gerar mapas meteorológicos regularmente usando dados coletados de estações remotas, sem funcionários, e de outras fontes de dados, como observatórios, balões e satélites. As estações meteorológicas transmitem seus dados para um computador local em resposta à solicitação dessa máquina. O sistema de computador local valida os dados coletados e integra os dados a partir de diferentes fontes. Os dados integrados são arquivados e, usando dados desse arquivo e um banco de dados de mapas digitalizados, um conjunto de mapas meteorológicos locais é criado. Os mapas podem ser impressos para distribuição em uma impressora de mapas especial e ser apresentados em diversos formatos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 27 Contexto de sistema e modelos de uso Desenvolver uma compreensão dos relacionamentos entre o software que está sendo desenvolvido e seu ambiente externo. Contexto do sistema É um modelo estático que descreve outros sistemas no ambiente. Use um modelo de subsistema para mostrar outros sistemas. O slide seguinte mostra os sistemas em torno do sistema da estação meteorológica. Modelo de uso do sistema É um modelo dinâmico que descreve como o sistema interage com seu ambiente. Use casos de uso para mostrar as interações. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 28

15 Arquitetura de camadas Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 29 Subsistemas no sistema de mapeamento meteorológico Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 30

16 Modelos de casos de uso Modelos de casos de uso são usados para representar cada interação com o sistema. Um modelo de caso de uso mostra as características do sistema como elípse, e a entidade de interação como a figura de um boneco. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 31 Casos de uso para a estação meteorológica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 32

17 Descrição de caso de uso Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 33 Projeto de arquitetura Uma vez que as interações entre o sistema e seu ambiente tenham sido compreendidas, você pode usar essas informações para projetar a arquitetura do sistema. Uma arquitetura de camadas, conforme discutida no Capítulo 11, é apropriada para a estação meteorológica A camada de interface cuida das comunicações; A camada de coleta de dados cuida do gerenciamento de instrumentos; A camada de instrumentos é responsável pela coleta de dados. Não deve haver normalmente mais que sete entidades em um modelo de arquitetura. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 34

18 Arquitetura da estação meteorológica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 35 Identificação de objetos A identificação de objetos (ou classes de objetos) é a parte mais difícil do projeto orientado a objetos. Não há fórmula mágica para a identificação de objetos. É baseada no perfil, experiência e conhecimento de domínio dos projetistas de sistema. Identificação de objeto é um processo iterativo. É improvável que você faça certo na primeira vez. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 36

19 Abordagens para identificação Usar uma abordgem gramatical baseada em uma descrição da linguagem natural do sistema (usado no método HOOD de projeto orientado a objetos). Basear a identificação em coisas tangíveis no domínio da aplicação. Usar uma abordagem comportamental e identificar objetos baseados em no que participa em qual comportamento. Usar uma análise baseada em cenários. Os objetos, os atributos e os métodos em cada cenário são identificados. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 37 Descrição da estação meteorológica Uma estação meteorológica é um pacote de instrumentos controlados por software que coleta dados, executa processamento de dados e transmite esses dados para processamento posterior. Os instrumentos incluem termômetros de ar e de solo, um anemômetro, uma hélice de vento, um barômetro e um medidor de chuva. Os dados são coletados periodicamente. Quando um comando é emitido para transmitir os dados meteorológicos, a estação meteorológica processa e sumariza os dados coletados. Os dados sumarizados são transmitidos para o computador de mapeamento quando uma solicitação é recebida. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 38

20 Classes de objeto da estação meteorológica Termômetro de solo, Anemômetro, Barômetro Objetos do domínio da aplicação que são objetos de hardware relacionados aos instrumentos no sistema. Estação meteorológica A interface básica da estação meteorológica em seu ambiente. Ele reflete portanto, as interações identificadas no modelo de caso de uso. Dados meteorológicos Encapsula os dados sumarizados a partir dos instrumentos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 39 Classes de objeto da estação meteorológica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 40

21 Mais objetos e refinamento de objetos Usar conhecimento de domínio para identifcar mais objetos e operações Estações meteorológicas devem ter um único identificador; As estações meteorológicas são remotamente situadas e, assim, as falhas de instrumentos devem ser reportados automaticamente. Portanto, atributos e operações para auto verificação são necessários. Objetos ativos e passivos Nesse caso, os objetos são passivos e coletam dados sob demanda ao invés de autonomamente. Isso introduz flexibilidade no gasto de tempo de processamento do controlador. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 41 Modelos de projeto Modelos de projeto mostram os objetos ou as classes de objetos e os relacionamentos entre essas entidades. Os modelos estáticos descrevem a estrutura estática do sistema em termos de classes de objeto e seus relacionamentos. Modelos dinâmicos descrevem as interações dinâmicas entre os objetos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 42

22 Exemplos de modelos de projeto Modelos de subsistema que mostram os agrupamentos lógicos de objetos em subsistemas coerentes. Modelos de seqüência que mostram a seqüência das interações entre objetos. Modelos de máquina de estado que mostram como objetos individuais mudam seu estado em resposta aos eventos. Outros modelos incluem modelos de caso de uso, modelos de agregação, modelos de generalização, etc. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 43 Modelos de subsistema Mostram como o projeto é organizado em grupos de objetos logicamente relacionados. Na UML, esses modelos são mostrados usando pacotes uma construção de englobamento. Isso é um modelo lógico. A organização real dos objetos no sistema pode ser diferente. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 44

23 Subsistemas da estação meteorológica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 45 Modelos de seqüência Os modelos de seqüência mostram a seqüência das interações de objetos que ocorrem Os objetos são organizados horizontalmente no topo; O tempo é representado verticalmente e, assim, os modelos são lidos de cima para baixo; As interações são representadas por setas rotuladas. Estilos diferentes de seta representam tipos diferentes de interação; Um retângulo estreito no tempo de vida do objeto representa o tempo em que este é objeto de conrole no sistema. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 46

24 Seqüência de coleta de dados Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 47 Statecharts Mostram como os objetos respondem às solicitações diferentes de serviço e as transições de estado disparadas por estas solicitações Se o estado de objeto for Desativado, o sistema poderá somente responder à mensagem iniciar(); No estado Aguardando, o objeto está aguardando outras mensagens; Se uma mensagem relatarclima() for recebida, então o sistema passará ao estado Sumarizando; Se uma mensagem calibrar() for recebida, o sistema passará ao estado Calibrando; Um estado Coletando é atingido quando um sinal de relógio for recebido. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 48

25 Diagrama de estado da estação meteorológica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 49 Especificação de interface entre objetos As interfaces de objeto têm de ser especificados, de tal modo que os objetos e outros componentes possam ser projetados em paralelo. Os projetistas devem evitar projetar a representação da interface, mas devem ocultar isso no próprio objeto. Os objetos podem ter várias interfaces que são pontos de vista sobre os métodos fornecidos. A UML usa diagramas de classe para especificação de interface, embora Java também possa ser usada. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 50

26 Interface da estação meteorológica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 51 Evolução de projeto Ocultar informação dentro de objetos significa que mudanças feitas nesses objeto não afetam quaisquer outros objetos de maneira imprevisível. Assuma que capacidades de monitoração de poluição devem ser acrescentadas às estações meteorológicas. Essas coletam amostras do ar e calculam a quantidade de poluentes diferentes na atmosfera. Leituras de poluição são transmitidas com dados meteorológicos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 52

27 Mudanças requeridas Acrescentar uma classe de objeto chamada QualidadeDoar como parte da EstaçãoMeteorológica. Acrescentar uma operação relatarqualidadedoar para EstaçãoMeteorológica. Modificar o software de controle para coletar leituras de poluição. Acrescentar objetos que representem instrumentos de monitoração de poluição. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 53 Monitoração de poluição Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 54

28 Pontos-chave O projeto orientado a objetos é uma abordagem para projeto na qual os componentes de projeto têm seu próprio estado privado e operações. Os objetos devem ter operações de construção e de inspeção. Eles fornecem serviços para outros objetos. Os objetos podem ser implementados seqüencial ou concorrentemente. A UML fornece notações diferentes para a definição de modelos de objetos diferentes. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 55 Pontos-chave Uma variedade de modelos diferentes podem ser produzidos durante um processo de projeto orientado a objetos. Esses modelos incluem modelos de sistema estáticos e dinâmicos. As interfaces de objeto devem ser definidas precisamente usando, por exemplo, uma linguagem de programação como Java. Projeto orientado a objetos simplifica potencialmente a evolução do sistema. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 14 Slide 56