Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Engenharia de Software

Projeto Orientado a Objetos


Projeto Orientado a objetos

• Um projeto orientado a objetos é representado pelos projetistas em termos de “coisas”, em vez de operações ou funções.

• O sistema em funcionamento é constituído de objetos que interagem entre si, que mantêm seu próprio estado local e fornecem operações com base nessas informações de estado.

• Os objetos ocultam informações e estados, limitam o acesso e se comunicam entre si.



• A Análise Orientada a Objetos se dedica a desenvolver um modelo orientado a objetos do domínio de aplicação.

• O Projeto Orientado a Objetos se dedica a desenvolver um modelo orientado a objetos de um sistema de software para implementar os requisitos identificados.

• A Programação Orientada a Objetos se ocupa de realizar um projeto de software utilizando uma linguagem orientada a objetos.



• Os sistemas orientados devem possui as seguintes características:

– Fácil manutenção

– Pouco impacto em modificações

– “Objetos–componentes” de fácil reutilização

• Reutilizar componentes de projetos antecedentes

• Reduz custo, validação, desenvolvimento.

• Diminui o risco do projeto



• Um objeto é uma entidade que possui um estado e um conjunto definido de operações que operam nesse estado.

– O estado é representado por um conjunto de atributos de objeto.

– As operações associadas com o objeto fornecem serviços para outros objetos (cliente), que requisitam esses serviços quando alguma computação é necessária.

• Os objetos são criados de acordo com uma definição de classe de objetos, que serve como um template para criar objetos. Esta classe apresenta declarações de todos os atributos e operações que devem ser associados a um objeto dessa classe.



• Notação UML para Classe de Objetos

Funcionário

nome: stringendereco: stringmatricula: integerdepartamento:

baterPonto();retirarSalario();mudarDados();

Atributos

Operações

Nome da Classe



• A comunicação entre os objetos de um sistema de software orientado a objetos pode ser:

– Síncrona: O objeto que chama espera que a requisição de serviço seja concluída.

– Assíncrona: o objeto que chama pode continuar em operação enquanto o serviço requisitado está sendo executado. Neste caso os objetos foram implementados como processos simultâneos ou threads.



• O processo geral para o projeto orientado a objetos engloba os seguintes estágios:

– Compreender e definir o contexto e os modos de utilização dos sistema.

– Projetar a arquitetura do sistema.

– Identificar os principais objetos do sistema

– Desenvolver os modelos de projeto

– Especificar as interfaces dos objetos.


Projeto Orientado a objetos(compreender e definir contexto)

• O primeiro estágio do processo de software é desenvolver a compreensão das relações entre o software que está sendo projetado e seu ambiente externo.

O contexto do sistema é o modelo estático, que descreve os outros sistemas naquele ambiente.

O modelo de uso do sistema é um modelos dinâmico, que descreve como o sistema realmente interage com seu ambiente.

É recomendado utilizar os diagramas de contexto e caso de uso da UML.


Projeto Orientado a objetos(Projetar a Arquitetura)

• Uma vez as interações entre o sistema de software que está sendo projetado e o ambiente do sistema tenham sido definidas, é possível utilizar essas informações como base para projetar a arquitetura do sistema

• O sistema deve ser decomposto de modo que as arquiteturas sejam o mais simples possível. A boa prática indica no máximo 7 entidades fundamentais para um modelo de arquitetura.


Projeto Orientado a objetos(Identificar os objetos )

• Nesta fase do projeto já deve haver uma idéia dos objetos essenciais do sistema. Embora a fase seja ‘identificar objetos’, na verdade esse processo se ocupa em identificar as classes de objetos.

• Algumas dicas para identificação de objetos:

• Utilizar o vocabulário usual do sistema, onde atributos são nomes e operações são verbos.

• Utilizar entidades tangíveis (exemplos do mundo real) como: aeronave, gerente, cliente, pedido.

• Utilizar uma abordagem comportamental, onde primeiro deve ser compreendido o comportamento geral do sistema.

• Realizar uma abordagem baseada em cenários, onde vários cenários de utilização do sistema são identificados e analisados de cada vez.


Projeto Orientado a objetos(Modelos de projeto)

• Há dois modelos de projetos que podem ser produzidos para descrever um projeto orientado a objetos.

– Os modelos estáticos, que descrevem a estrutura estática do sistema em termos das classes de objetos de sistema e de seus relacionamentos. Ex. diagrama de Classe na UML.

– Os modelos dinâmicos,que descrevem a estrutura dinâmica do sistema e mostram as interações entre os objetos do sistema (e não as classes de objetos).Ex. diagrama de seqüência, atividades e estado na UML.


Projeto Orientado a objetos(Especificação de interface entre objetos)

• É necessário especificar as interfaces para que os objetos e outros componentes possam ser projetados em paralelo, considerando a interface já oferecida.

• Deve ser evitado informações de representação de interface nos projetos de interface. As representações devem ser ocultas e as operações de objeto devem ser fornecidas para modificar e atualizar dados.

• Não existe necessariamente a relação 1:1 entre objeto e interface. Um objeto pode ter mais de uma interface de serviço que o mesmo implemente.



Projeto de Softwares de Tempo Real


Projeto de Software em Tempo Real

• Um sistema em tempo real é um sistema de software que precisa responder a eventos em tempo real. Sua precisão não depende apenas dos resultados que ele produz, mas também do momento em que esses resultados são produzidos.

• Os sistemas de tempo real são diferentes de outros tipos de sistemas de software seu funcionamento correto depende da resposta do sistema aos eventos dentro de um determinado intervalo de tempo (geralmente curto).



• Um sistema em tempo real é como um sistema de estímulo/resposta. Considerando um determinado estímulo fornecido, o sistema deve produzir uma resposta correspondente.

• Os estímulos são de duas classes:

– Estímulo Periódico: Eles ocorrem em intervalos de tempo previsíveis. Ex. examinar um sensor a cada 50 milisegundos e reagir (responder) de acordo com valor (estímulo) deste sensor.

– Estímulo Aperiódico: ocorrem irregularmente, em geral são assinalados utilizando-se o mecanismo de interrupção do computador.



• Modelo Geral de um sistema de tempo real

Sensor Sensor SensorSensor

Sistema de ControleDe Tempo Real

AtuadorAtuador Atuador

Atuador

Sensores associados ao sistemaque fornecem informações sobreo estado do ambiente do sistema.

Controlam alguma unidade de hardware que influencia o ambiente.



• Um sistema em tempo real tem de responder a estímulos que ocorrem em diferentes momentos. Sua arquitetura deve ser organizada de modo que o controle seja transferido ao manipulador apropriado para aquele estímulo, assim que ele for recebido.

• Sistemas em tempo real são normalmente projetados como um conjunto de processos concorrentes e cooperantes e parte do sistema é dedicado a gerenciar estes processos.



• O processo de projeto para sistemas de tempo real difere de outros processos de projeto de software, porque os tempos de resposta do sistema devem ser considerados logo no início do processo. Os eventos (estímulos), em vez dos objetos ou das funções, devem ser a parte central do processo de projeto.

• Os estágios deste processo são:

– Identificar os estímulos que o sistema deve processar e as repostas associadas.

– Para cada estímulo e cada resposta associada, identificar as restrições de tempo que se aplicam ao processamento de estímulo e resposta.



– Agregar o processamento de estímulo e de resposta em uma série de processos simultâneos.

– Para cada estímulo e resposta, projetar algoritmos para realizar os cálculos requeridos.

– Projetar um sistema de escalonamento que assegura que os processos sejam iniciados a tempo de atender seus prazos.

– Integrar o sistema sob o controle de um executivo tempo real. Um executivo em tepo real é responsável pelo gerenciamento de processos e recursos. Ele sempre inclui um escalonador, que é o componente responsável por decidir qual processo devem ser escalonado para ser executado. As decisões de escalonamento são tomadas utilizando-se prioridades de processo.



Projeto de Software com Reuso


Projeto com Reuso

• A engenharia baseada em reuso é uma abordagem para o desenvolvimento que tenta maximizar o reuso do software já existente.

• Reuso de sistemas de aplicações:Todo sistema de aplicação pode ser reutilizado pela sua incorporação, sem mudança, em outros sistemas.

• Reuso de Componentes: Os componentes de uma aplicação, que variam em tamanho incluindo desde subsistemas até objetos isolados.

• Reuso de Funções: Os componentes de software que implementam uma única função, como uma função matemática, podem ser reutilizados. Esse tipo de reuso tem como base bibliotecas.


Projeto com Reuso

• Requisitos fundamentais para projetos baseado em reuso:

• Deve ser possível encontrar componentes reutilizáveis apropriados. As organizações necessitam de uma base de componentes reutilizáveis adequadamente catalogados e documentados. Deve ser fácil encontrar componentes nesse catálogo, se ele existir.

• O responsável pelo reuso dos componentes precisa ter certeza de que os componentes se comportarão como especificado e de que serão confiáveis.

• Os componentes devem ter uma documentação associada para ajudar o usuário a compreendê-los e adaptá-los a uma nova aplicação.


Projeto com Reuso

• Benefícios fundamentais do reuso de software

• Maior Confiabilidade: Os componentes reutilizados que são empregados nos sistemas em operação devem ser mais confiáveis do que os componentes novos, pois os mesmos já foram experimentados e testados em diferentes ambientes.

• Redução de Riscos de Processo: recorrendo a componentes já existentes diminui-se a incerteza sobre os custos relacionados aos reuso desse componente do que sobre custos de desenvolvimento. Fator importante para o Gerenciamento de projetos para controle das estimativas de custo de software.

• Uso efetivo de especialistas: em vez de especialistas em aplicações fazerem o mesmo trabalho em diferentes projetos, eles podem desenvolver componentes reutilizáveis, que englobam seu conhecimento.


Projeto com Reuso

• Benefícios fundamentais do reuso de software

• Conformidade em padrões: Alguns padrões como os de interface com o usuário, podem ser implementados como um conjunto de componentes-padrão.

• Desenvolvimento acelerado: De modo geral, é mais importante fornecer um sistema para o mercado o mais rápido possível do que se prender aos custos gerais de desenvolvimento. O reuso de componentes acelera a produção, porque o tempo de desenvolvimento e o de validação devem ser reduzidos.


Projeto com Reuso – Desenvolvimento baseado em componentes

• O desenvolvimento baseado em componentes leva em conta a utilização de componentes “caixa-preta”, que oferecem serviços através de uma interface bem definida.

• Visualizar um componente como um provedor de serviços enfatiza duas importantes características de um componente reutilizável:

– O componente é uma entidade executável independente. O código-fonte não está disponível, de modo que o componente não é compilado com outros componentes do sistema.

– Os componentes publicam sua interface e todas as interações são feitas por meio dessa interface. A interface de um componente é expressa em termos de operações parametrizadas e seu estado interno nunca é exposto.



• Os componentes são definidos por suas interfaces (modelo mais genérico):

• Interface Provides: a interface que fornece, que define os serviços oferecidos pelo componente.

• Interface Requires: a interface que requer, que especifica os serviços que devem estar disponíveis a partir do sistema que está utilizando o componente.

• Se estas interfaces não forem definidas, o componente não funcionará.



• O termo COTS (produtos de prateleira) pode se aplicar a qualquer componente oferecido por um terceiro (fabricante).

• Problemas relacionados com sistemas COTS:

– Falta de controle sobre a funcionalidade e o desempenho.

– Problemas com interoperabilidade entre sistemas COTS

– Nenhum controle sobre a evolução do sistema.

– Suporte técnico dos fabricantes.



• Características de componentes reutilizáveis:

– O componente deve refletir abstrações estáveis de domínio, que são conceitos fundamentais no domínio de aplicações, as quais se modificam pouco.

– O componente deve ocultar a maneira como seu estado é representado e deve fornecer operações que permitam que o estado seja acessado e atualizado.

– O componente deve ser tão independente como possível.

– Todas as exceções devem ser parte da interface do componente. Os componentes não devem manipular as próprias exceções uma vez que diferentes aplicações terão diferentes requisitos para manipulação de exceções.



Projeto de Sistemas Distribuídos


Arquitetura de Sistemas Distribuídos

• Em uma arquitetura de sistemas distribuídos o processamento das informações é distribuído entre vários servidores.

• Atualmente há três tipos de sistema:

– Sistemas Pessoais: projetados para executar em computadores pessoais. Ex. Editor de texto, planilhas de cálculo, sistemas gráficos.

– Sistemas Embutidos: são projetados em um único processador ou em um grupo de processadores integrados. Ex. sistemas de controle de dispositivos domésticos.

– Sistemas Distribuídos: o software é executado em um grupo de processadores fracamente integrados, que cooperam entre si conectados por uma rede. Ex. caixa eletrônico, site de compras.



• Importantes características de um sistema distribuído:

– Compartilhamento de recursos de hardware, software, impressora, arquivo, porém tudo gerenciado por um computador central.

– Abertura de sistema, que diz até que ponto ele pode ser ampliado, adicionando-se novos recursos não proprietários a ele. Os sistemas distribuídos normalmente incluem hardware e software de diferentes fabricantes.

– Controle de Concorrência: em um sistema distribuído vários processos podem operar ao mesmo tempo em computadores diferentes.

– Escalabilidade : a capacidade do sistema de aumentar com o aumento de recursos.



• Importantes características de um sistema distribuído:

– Transparência: o usuário não necessita saber da natureza distribuída do sistema.

• Os diferentes componentes de um sistema Distribuído podem ser implementados em diferentes linguagens de programação e serem executados em processadores diferentes.

• Modelo de dados e protocolo de comunicação podem ser inteiramente diferentes.



• Para possibilitar a comunicação dos vários componentes distribuídos no sistema é necessário um software para gerenciar a comunicação entre os diferentes ambientes, chamado Middleware.

• Middlewares são softwares para gerenciamento de comunicação com banco de dados, gerentes de transações, conversores de dados e controladores de comunicação.



• Arquitetura Cliente – Servidor– Em uma arquitetura Cliente-Servidor um conjunto de serviços é

fornecido por servidores a um conjunto de clientes que utilizam este serviço.

– Os clientes devem estar cientes que os servidores estão disponíveis, porém não sabem da existências dos demais clientes.


Arquitetura de Sistemas Distribuídos (Cliente-Servidor)

• Aspectos de um cliente sistema distribuído Cliente-Servidor

– Clientes e Servidores são diferentes

– Clientes recebem serviços dos servidores e não de outros clientes.

– Servidores podem atuar como clientes solicitando serviço de outro servidor, porém nunca de outro cliente.

– Os clientes devem saber dos serviços oferecidos pelos servidores.

– Os clientes devem saber como contatar os servidores.



• Não necessariamente existe a proporção 1 processo – 1 processador, pois a arquitetura se refere a estrutura lógica e não física da execução do sistema.

Camada de Apresentação

Camada de processamento da aplicação

Camada Gerenciamento de Dados

Sistema em 3 camadasCada parte pode estar sendo executada em servidores distintos. Responsável pela

interface com o usuário

Implementa a lógica

Operações com o banco de dados.



• A arquitetura Cliente – Servidor mais simples é a de 2 camadas:

– Modelo Cliente Magro: o processamento da aplicação fica todo no servidor, o cliente só é responsável por executar o software de apresentação.

Cliente

Servidor

Gerenciamento de dados e processamento

da aplicação

Apresentação



– Modelo Cliente Gordo: o servidor é responsável apenas pelo gerenciamento dos dados. O cliente impolementa a lógica da aplicação e as interações com o usuário.

Cliente

Servidor

Gerenciamento de Dados

Apresentação e processamento de aplicações



• Desvantagens dos Modelos 2 camadas

Cliente Magro Cliente Gordo

Escalabilidade e Desempenho Precisa reinstalar o cliente a cada versão

Atribui grande carga a rede. Problema de gerenciamento do sistema



• Modelo 3 camadas

Cliente

Servidor

Processamento de Aplicações

Servidor

Gerenciamento de Dados

Não necessariamente em máquinas distintas

Cliente

Cliente

Cliente

Cliente

Servidor Web

Provisão de Serviço de Conta

Servidor de Banco de Dados

Banco de DadosDa contacliente

SQL

Interação HTTP

Consulta SQL



• Arquitetura de Objetos Distribuídos

• Nesta arquitetura os componentes fundamentais são objetos que fornecem em uma interface um conjunto de serviços.

• Não há distinção entre cliente e servidor pois os objetos realizam requisições e dão retorno de operações entre si.

• Os objetos podem ser distribuídos na rede em uma série de computadores que se comunicam entre si através de um Middleware.

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...

Documents

Transcript of Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...