projeto orientado a objeto - dcce.ibilce.unesp.br · um objeto é uma entidade que possui um estado...

55
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Slide 1 Projeto Orientado a Objetos Engenharia de Software 2o. Semestre de 2006

Upload: letruc

Post on 02-Oct-2018

216 views

Category:

Documents


0 download

TRANSCRIPT

UNIVERSIDADE ESTADUAL PAULISTAINSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA

Slide 1

Projeto Orientado a Objetos

Engenharia de Software

2o. Semestre de 2006

Slide 2

Projeto Orientado a Objeto

Objetivo: Projetar sistemas usando objetos auto-contidos e classes de objetos.

Slide 3

Características de Projeto Orientado a objetos

Projeto orientado a objetos é uma estratégia de projeto em que os projetistas pensam em termos de coisas, em vez de funções.A funcionalidade do sistema é expressa em termos de serviços oferecidos pelos objetos.Objetos são abstrações do mundo real ou entidades do sistema que se auto gerenciam.Objetos são independentes e encapsulam representações de informação e estado.Áreas de dados compartilhado são eliminadas. Objetos se comunicam por passagem de mensagem.

Slide 4

Características de Projeto Orientado a objetos

Projeto orientado a objeto é parte do desenvolvimento orientado a objeto:

Análise OO – se dedica a desenvolver um modelo orientado a objeto do domínio da aplicação. Os objetos identificados refletem entidades e operações associadas com o problema a ser resolvido.

Slide 5

Características de Projeto Orientado a objetos

Projeto OO – se dedica a desenvolver um modelo orientado a objeto de um sistema de software para implementar os requisitos. Os objetos em um projeto OO estão relacionados à solução do problema que está sendo resolvido.Programação OO – realiza um projeto de software em uma linguagem de programação OO, que aceita a implementação direta de objetos e fornece recursos para definir as classes de objeto.

Slide 6

Características de Projeto Orientado a objetos

A transição entre esses estágios de desenvolvimento deve se contínua e direta, com a mesma notação utilizada em cada estágio;Mover para o próximo estágio envolve aprimorar o estágio anterior:

Adição de detalhes às classes de objetos existentesCriação de novas classes, para fornecer funcionalidade adicional.

Slide 7

Objetos que interagem entre si

state o3o3:C3

state o4o4: C4

state o1o1: C1

state o6o6: C1

state o5

o5:C5

state o2o2: C3

ops1() ops3 () ops4 ()

ops3 () ops1 () ops5 ()

Slide 8

Vantagens do Projeto OOFacilidade de manutenção. Objetos podem ser entendidos como entidades independentes.Os objetos são componentes potencialmente reutilizáveis.Para vários sistemas, existe um nítido mapeamento entre as entidades do mundo real para objetos no sistema.

Slide 9

Objetos e classes de objetos no Projeto OO

Objetos são entidades no sistema de software que representam instâncias de entidades do mundo real e do sistema.Classes de objetos são templates utilizados para criar objetos. Classes de objetos podem herdar atributos e serviços de outras classes de objetos.

Slide 10

Objetos

Um objeto é uma entidade que possui um estado e um conjunto de operações que operam nesse estado. O estado é representado por um conjunto de atributos. As operações associadas ao objeto fornecem serviços para outros objetos.

Objetos são criados de acordo com uma definição de classe de objetos. Uma classe inclui declarações de todos os atributos e serviços que devem ser associados a um objeto dessa classe.

Slide 11

Classe de Objetos funcionário (UML)

Funcionário

Nome: stringEndereço: stringDataNasc: DataNempregado: inteiroDepartamento: DeptoGerenteL EmpregadoSalário: inteiro...

Contratar()Demitir()Aposentar()AlterarDetalhes()

Slide 12

Comunicação entre objetosConceitualmente, objetos se comunicam por passagem de mensagem.Mensagens:

O nome do serviço requerido pelo objeto chamador.Cópias da informação necessária para executar o serviço e o nome do possuidor do serviço.

Na prática, mensagens são implementadas como chamadas de procedimentos.

Nome = nome do procedimentoInformação = lista de parâmetros

Slide 13

Exemplos de mensagens// Chamar um método associado a um // objeto ListaCircular que retorna o próximo // valor na Lista

v = ListaCircular.obterproximo () ;// Chamar o método associado a um objeto// termostato para ajustar a temperatura a ser // mantida

termostado.setTemp (20) ;

Slide 14

Generalização e HerançaEmployee

Programmer

projectprogLanguage

Manager

ProjectManager

budgetsControlleddateAppointed

projects

Dept.Manager

StrategicManager

dept responsibilities

Funcionário

Gerente

orçamentosControladosdataDesignação

Programador

ProjetoLing. Programação

Gerente deprojeto

Projetos

Gerente dedepartamento

Departamento

Gerente estratégico

Responsabilidades

Slide 15

Vantagens da herançaÉ um mecanismo de abstração que pode ser usado para classificar entidades.É um mecanismo de reutilização tanto a nível de projeto quando de programação.O grafo de herança é uma forma de organizar o conhecimento sobre o domínio e os sistemas.

Slide 16

Problema com herança em POO

Classes de objetos não são auto-contidas. Não podem ser entendidas sem fazer referência à suas superclasses.

Slide 17

Especificação de requisitos

Cenários

Diagramas de classe

Diagramas de atividade

Diagramas de estado

Diagramas de

seqüência

Diagramas de

colaboração

Diagramas de pacotes

Diagramas de componentes

Diagramas de implantação

ESTADOS

ESTRUTURA DA CLASSE

INTERAÇÕES

AnáliseDescrições e diagramas de casos de uso

Modelos de objetos

Definições e relacionamentos de classes

Descrição textual de casos de uso

A UML e o apoio ao processo de desenvolvimento OO

Projeto Codificação

Slide 18

Processo de análise OODefinir os casos de uso do sistemaIdentificar os principais objetos do sistema.Desenvolver o modelo conceitual -> diagrama de classe e relacionamentos.Especificar os diagramas de seqüência, considerando o sistema como uma caixa preta.

Os diagramas de seqüências evidenciam as principais operações que o sistema deve implementar.

Slide 19

Processo de projeto OOProjetar a arquitetura do sistema.Desenvolver os Diagramas de Colaboração e/ourefinar os modelos de seqüência produzidos na etapa anterior.Desenvolver o modelo de classes de projeto -> refinamento do modelo conceitual, incluindo objetos e classes para a solução do problema.Especificar as interfaces dos objetos.

Slide 20

Descrição do Sistema Meteorológico

Um sistema de mapeamento meteorológico é necessário para gerar mapas meteorológicos regularmente, utilizando dados coletados a partir de estações meteorológicas remotas, sem que seus funcionários estejam presentes, e de outras fontes de dados, como observadores de tempo, balões e satélites meteorológicos. As estações meteorológicas transmitem seus dados ao computador da área, em resposta a uma requisição dessa máquina.

O sistema de computador da área faz a validação dos dados coletados e também a integração dos dados a partir das diferentes fontes. Os dados integrados são arquivados. Os dados desse arquivo e um banco de dados de mapas digitalizados são utilizados para a criação de um conjunto de mapas meteorológicos locais. Os mapas podem ser impressos em uma impressora especial ou ser exibidos em diversos formatos.

Slide 21

Descrição da Estação Meteorológica

A estação meteorológica é um pacote de instrumentos (termômetros, barômetros, etc.) controlados por software que coleta dados, realiza alguns processamentos de dados e transmiteesses dados para outros processamentos. Os dados são coletados acada cinco minutos.

Ao receber uma requisição, a estação meteorológica processa e resume os dados coletados. Os dados resumidos são transmitidos para o computador.

Slide 22

Descrição da Estação Meteorológica(Principais subsistemas)

Coleta de dados Integração de Dados(processamento)

Criação de MapasArquivamento De dados

Slide 23

Uma possível arquitetura –Arquitetura em Camada

«subsystem»Data collection

«subsystem»Data processing

«subsystem»Data archiving

«subsystem»Data display

Data collection layer where objectsare concerned with acquiring datafrom remote sources

Data processing layer where objectsare concerned with checking andintegrating the collected data

Data archiving layer where objectsare concerned with storing the data for future processing

Data display layer where objects areconcerned with preparing andpresenting the data in a human-readable form

<<Subsistema>>Apresentação dados

<<Subsistema>>Arquivam. de dados

<<Subsistema>>Processam. de dados

<<Subsistema>>Coleta de dados

Camada de exibição de dados, em que os objetos se ocupam da preparação e da apresentação de dados em forma de fácil leitura pelas pessoas.

Camada de arquivamento de dados, em que os objetos se ocupam do armazenamento de dados para futuro processamento

Camada de processamento de dados, em que os objetos se ocupam da verificação e da integração de dados coletados.

Camada de coleta de dados, em que os objetos se ocupam da aquisição de dados a partir de fontes remotas.

Slide 24

Subsistemas em um sistema de mapeamento meteorológico

«subsystem»Data collection

«subsystem»Data processing

«subsystem»Data archiving

«subsystem»Data display

Weatherstation

Satellite

Comms

Balloon

Observer

Datachecking

Dataintegration

Map store Data store

Datastorage

Map

Userinterface

Mapdisplay

Mapprinter

Observador

EstaçãoMeteorológica

Satélite

Balão

Comunicações

Interface como usuário

Mapa

Displayde Mapa

Impressão de Mapas

Verificaçãode dados

Integração de dados

Repos. Mapa Repos. Dados

<<subsistema>>

Coleta de dados <<subsistema>>

Display de dados

<<subsistema>>

Proces. de dados

<<subsistema>>

Arquiv. de dados

Armazenamentode dados

Slide 25

Contexto do sistema e modelos de uso

Desenvolver uma compreensão das relações entre o software que está sendo projetado e seu ambiente externo.Contexto do sistema

Um modelo estático que descreve os outros sistemas naquele ambiente. (ilustração anterior)

Modelo de uso do sistemaUm modelo dinâmico, que descreve como o sistema realmente interage com seu ambiente. Pode-se usar casos de uso para mostrar essa interação.

Slide 26

Casos de uso para a estação meteorológica (etapa de análise)

Startup

Shutdown

Report

Calibrate

TestTestar

Desativar

Relatar

Calibrar

Iniciar

Sistema deProssamento de

Dados

Slide 27

Descrição do caso de uso Relatar dados climáticosSistema Estação Meteorológica Use-case Relatar Agentes Sistema de processamento de dados sobre o clima, Estação

meteorológica. Dados A estação meteorológica envia para o sistema de processamento de

dados climáticos um resumo de dados sobre o clima, que foram coletados a partir de instrumentos, no período de coleta. Os dados enviados referem-se às temperaturas máximas, mínimas e médias do solo e do ar; à pressão máxima, mínima e média do ar; às velocidades máxima, mínima e média do vento, conforme amostragem a cada intervalo de cinco minutos

Estímulo O sistema de processamento de dados sobre o clima estabelece um link de modem com a estação meteorológica e requisita a transmissão dos dados

Resposta Os dados resumidos pelo sistema de coleta de dados sobre o clima são enviados ao sistema de processamento de dados.

Comentários Em geral, as estações meteorológicas recebem um pedido de relatório por hora, mas essa freqüência pode diferir de uma estação para outra a ser modificada no futuro.

Casos de uso (etapa de análise)

Slide 28

É preciso desenvolver descrições para todos os casos de uso representados no modelo de caso de uso.Utilidade de casos de uso

Identificar objetos no sistemaIdentificar operações no sistema

No exemplo em questão:Objetos necessários: objetos que representem instrumentos

que coletam dados e um objeto que faz o resumo dos dados

Operações necessárias: operações para requisitar e enviar dados sobre o clima

Projeto de Arquitetura

Slide 29

Uma vez definidas as interações entre o sistema que está sendo projetado e o seu ambiente, pode-se utilizar essas informações para estabelecer a arquitetura do sistema.Uma arquitetura em camadas é apropriada para a estação meteorológica.

A camada de Interface para manipular comunicações.Camada de integração de dados para gerenciar a coleta de dados a partir dos instrumentos e resumir os dados antes da transmissão.A camada de instrumentos que encapsula todos os instrumentos.

Slide 30

Arquitetura da estação metereológica

«subsystem»Data collection

«subsystem»Instruments

«subsystem»Interface

Weather station

Manages allexternal

communications

Collects andsummarisesweather data

Package ofinstruments for raw

data collections

Gerencia todas as comunicações

externas

Coleta e resume dadosclimáticos

Pacote de instrumentospara a coleta de

dados brutos

<<subsistema>>interface

<<subsistema>>Integração de dados

<<subsistema>>instrumentos

Estação Meteorológica

Slide 31

Identificação de objetosNesse estágio de projeto, os objetos essenciais do sistema já foram levantados na etapa de análise.Na etapa de projeto, refina-se os objetos identificados na análise, e define-se outros objetos que possam ser relevantes na solução do problema (na implementação do software).

Slide 32

Identificação de objetosIdentificar objetos (ou classes de objetos) é a parte mais difícil de desenvolvimento OO.Não existe uma “fórmula mágica” para a identificação de objeto. É preciso que o projetista tenha habilidade, experiência e conhecimento do domínio do sistema.A identificação de objeto é um processo iterativo. É improvável que se obtenha todos os objetos num primeiro esboço.

Slide 33

Abordagens para Identificar classes de objetos

Utilize uma análise gramatical baseada em uma descrição em linguagem natural do sistema.

Objetos e atributos são os substantivos (nomes).Serviços são verbos.

Utilize entidades tangíveis (coisas); funções(gerente); eventos(solicitações); locais; interações (reuniões) no domínio da aplicação.

Identifique estruturas de dados abstratos no domínio da solução necessárias para lidar com esses objetos

Slide 34

Abordagens para Identificar classes de objetos

Utilize uma abordagem comportamental em que se analisa o comportamento do sistema.

Os participantes que desempenham papéis ativos são candidatos a objetos.

Utilize uma abordagem baseada em cenários.Cada cenário utilizado, o projetista deve identificar objetos, atributos e operações que são necessários.

Slide 35

Classes de objetos da estação meteorológica

Termômetro de solo, Anemômetro, BarômetroObjetos do domínio da aplicação que são entidades tangíveis de hardware relacionadas aos instrumentos no sistema. As operações se ocupam de controlar esse hardware.

Estação meteorológicaÉ a interface básica da estação meteorológica com seu ambiente. Suas operações refletem as interações identificadas no modelo de caso de uso.

Dados meteorológicosEncapsula os dados resumidos dos diferentes instrumentos na estação meteorológica. Suas operações associadas se ocupam de coletar e resumir os dados que são requeridos.

Slide 36

Classes de objetos da estação meteorológica

DadosMeteorológicos

Coletar()Resumir()

TemperaturasdoArTemperaturasdoSoloVelocidadesdoVentoDireçõesdoVentoPressõesprecipitação

EstaçãoMeteorológica

RelatarClima()Calibrar(instrumentos)testar()iniciar(instrumentos)desativar(instrumentos)

Identificador

Barômetro

PressãoalturaTestar()Calibrar()

Termômetrode solo

temperaturaTestar()calibrar()

Anemômetro

velocidadedoVentodireçõesdoVentoTestar()

Slide 37

Outros objetos e refinamentos de objetos

Utilize o conhecimento do domínio do problema para identificar outros objetos e serviços.

Estações meteorológicas devem ter um identificador único.Estações meteorológicas são localizadas em lugares remotos, assim falhas nos instrumentos devem ser registradas automaticamente. Portanto atributos e operações são necessários para verificar o funcionamento correto dos instrumentos.

Slide 38

Modelos de projetoDiferentes modelos com diferentes níveis de detalhes são desenvolvidos na fase de projeto.Modelos dinâmicos mostram as interações dinâmicas entre os objetos do sistema.Modelos estáticos descrevem a estrutura estática do sistema em termos de classes de objetos e relacionamentos.

Slide 39

Principais modelos UML usados no projeto OO

Modelos de subsistema (ou modelos de pacotes) mostram agrupamentos lógicos de objetos em subsistemas coerentes. (Modelo estático)Modelos de Colaboração que mostram as interações entre os objetos para implementar uma dada operação (funcionalidade do sistema).(Modelo dinâmico)Modelos de Seqüência, que mostram a seqüência das interações entre objetos. (Modelo dinâmico)Modelos de máquina de estados que mostram as mudanças de estado de objetos individuais, em resposta a eventos. (Modelo dinâmico)

Slide 40

Modelos de subsistemasMostram como o projeto está organizado em termos de grupos de objetos logicamente relacionados.Na UML, são mostrados usando pacotes - uma construção encapsulada. É um modelo lógico, porém podem ser refletidos em construções estruturais, como bibliotecas JAVA.

Slide 41

Subsistemas da estação meteorológica

«subsystem»Interface

CommsController

WeatherStation

«subsystem»Data collection

«subsystem»Instruments

Air thermometer

WeatherData

Ground thermometer

Anemometer

WindVane

RainGauge

InstrumentStatus

Barometer

Controlador decomunicações

Estação Meteorológica

DadosMeteorológicos

Status doinstrumento

Termômetro de ar

Medidorde chuva Anemômetro

Termômetro de solo Barômetro Indicador

de vento

<<subsitema>>Interface

<<subsitema>>Integração de dados

<<subsitema>>Instrumentos

Slide 42

Modelo de seqüênciaModelo de seqüência mostra a seqüência de interações (envio de mensagens e respostas) entre os objetos para a realização de uma operação do sistema.

Os objetos envolvidos na operação são organizados horizontalmente, com uma linha vertical ligada a cada objeto.O tempo é representado verticalmente, assim os modelos são lido de cima para baixo.Interações entre objetos são representadas por setas rotuladas. As setas representam mensagens ou eventos, que são fundamentais para a interação.Um retângulo estreito na linha de um objeto representa o tempo pelo qual o objeto é o objeto controlador (ativo) no sistema.

Slide 43

Seqüência de operações para a operação de requisitar dados climáticos para o subsistema Estação Meteorológica

:CommsController

request (report)

acknowledge ()report ()

summarise ()

reply (report)

acknowledge ()

send (report)

:WeatherStation :WeatherData:controladordeComunicações :EstaçãoMeteorológica :DadosMeteorológicos

Requisitar(relatório)

Responder

(relatório)

Relatar()

Enviar(relatório)

Resumir()

Sistema de processamento de dados

Slide 44

Diagrama de seqüênciaÉ preciso produzir um diagrama de seqüência para cada interação significativa (cada operação do sistema).Deve haver um diagrama de seqüência para cada caso de uso identificado.DS é usado para modelar o comportamento combinado em um grupo de objetos.

Slide 45

Modelo de Máquina de Estados Statecharts (Harel 87)

Através de uma máquina de estados (statecharts) pode-se mostrar o comportamento de um único objeto em resposta a diferentes mensagens que ele pode processar.Basicamente, o modelo de máquina de estados mostra como o objeto muda de estado, dependendo das mensagens que ele recebe.De modo geral, não é normalmente necessário produzir um statechart para todos os objetos definidos.

Slide 46

Statechart para o objeto Estação Meteorológica

Operação

Desativado Aguardando

Calibrando

Testando

Transmitindo

ResumindoColetando

Calibrar()

testar()

relógio Coleta feita

relatarClima()

Calibração OK

Teste Completado

Resumometeorológicoconcluído

desativar()Transmissão feita

iniciar()

Slide 47

Especificação de interface entre objetos

Interfaces são os serviços que os objetos oferecem a outros objetos.Após o desenvolvimento dos diagramas de seqüência para todas as operações do sistema, faz-se uma análise de cada objeto presente nesses diagramas.

Toda mensagem recebida pelo objeto é um serviço que ele deve oferecer, e portanto faz parte de sua interface.

Slide 48

Projeto de interface entre objetos

É a especificação dos detalhes da interface para um objeto ou um grupo de objetos.Significa definição das assinaturas e a semântica definida pelos serviços oferecidos pelos objetos.Vantagens:

Facilita o desenvolvimento em paralelo

Slide 49

Interface da estação meteorológica

interface Estação Meteorológica { public void EstaçãoMeteorológica () ; // contrutor public void Iniciar () ; //iniciar estação public void Iniciar (Instrumento i) ; public void desativar () ; //desativar estação public void desativar(Instrumento i) ; public void relatarClima ( ) ; public void testar () ; /testar estação public void testar ( Instrumento i ) ; public void calibrar ( Instrumento i) ; public int obtertID () ;

} // EstaçãoMeteorológica

Slide 50

Evolução de projetoUma vantagem da abordagem OO é facilitar as mudanças no projetoO ocultamento da informação dentro dos objetos permite que alterações feitas em um objeto não afetem outros objetos de forma imprevisível.Objetos fracamente acoplados podem sofrer modificações internas sem afetar outros objetos do sistema.

Slide 51

Exemplo da robustez da abordagem OO

Suponha que as estações meteorológicas deverão fazer também a monitoração da poluição do ar.

Para essa nova tarefa deve-se adicionar um medidor de qualidade do ar que calcula a concentração de vários poluentes na atmosfera.

As leituras de poluição são transmitidas ao mesmo tempo que os dados meteorológicos.

Slide 52

Alterações necessáriasAdição uma classe de objetos chamado Qualidade do ar como parte da Estação Meteorológica, no mesmo nível que DadosMeteorológicos.Adição de uma operação “RelatarQualAr” à Estação Meteorológica. Modificar o software de controle para coletar leituras de poluição.Adição de objetos representado instrumentos para monitorar a poluição.

Slide 53

Novos objetos para monitorar a poluição

EstaçãoMeteorológica

RelatarClima()RelatarQualidadeAr()Calibrar(instrumentos)testar()inicar(instrumentos)desativar(instrumentos)

Identificador

Qualidade do Ar

Coletar()Resumir()

Dados_OxidoNitrosoDadosdeFumaçaDadosdeBenzeno

MedidordeNo

MedidordeFumaça

MedidordeBenzeno

Instrumentos de monitoração de Poluição

Slide 54

Pontos ChavePOO é um meio de projetar sofware de modo que os componentes possuem seus próprios estados e operações.Objetos devem ter operações de construção (construtor) e inspeção (métodos tipo get e set). Eles fornecem serviços a outros objetos.A UML oferece diferentes notações para documentar um projeto OO.

Slide 55

Pontos ChaveUma série de diferentes modelos podem ser produzidos durante um processo de projeto OO, incluindo modelos estáticos e modelos dinâmicos do sistema.O projeto OO finaliza com a definição das interfaces dos objeto (visibilidade do objeto por outros objetos, ou serviços oferecidos pelo objeto)Uma das principais vantagens do projeto orientado a objeto é o fato de simplificar a evolução do sistema.