Anlise Orientada a Objetos:

Consiste da definio das classes (objetos) que representam o problema a ser resolvido, o modo pelo qual as classes se relacionam e interagem umas com as outras, o funcionamento interno (atributos e operaes) dos objetos e os mecanismos de comunicao (mensagens) que permitem a eles trabalharem juntos. Deve-se fazer uma descrio das caractersticas estticas e dinmicas das classes que descrevem um sistema ou um produto. A OOA fornece um modo concreto de representar seu entendimento dos requisitos e depois testar esse entendimento contra a percepo do cliente. Passos:

A OOA comea com uma descrio de casos de uso uma descrio baseada em cenrio de como atores (pessoas, mquinas, outros sistemas) interagem com o produto a ser construdo. A modelagem Classe-ResponsabilidadeColaborao, CRC traduz a informao contida nos casos de uso, numa representao de classes e suas colaboraes com outras classes. As caractersticas estticas e dinmicas das classes so ento modeladas usando uma linguagem unificada de modelagem (ou algum outro mtodo). Cria-se um modelo de anlise orientado a objetos. composto de representaes grficas ou baseado em linguagem que definem os atributos, relacionamento e comportamento das classes, bem como comunicao interclasses e um grfico do comportamento da classe ao longo do tempo. Em cada estgio, os elementos do modelo de anlise orientada a objetos so revistos quanto clareza, correo, completeza e consistncia com os requisitos do cliente e entre si. Princpios bsicos da OOA: o O domnio da informao modelado; o A funo descrita; o O comportamento representado; o Os modelos de dado, funcional e comportamental, so particionados para expor maiores detalhes; o Os primeiros modelos representam a essncia do problema, enquanto os ltimos modelos fornecem detalhes de implementao. Objetivos da OOA:

Definir todas as classes que so relevantes ao problema a ser resolvido as operaes e atributos associados a elas, as relaes entre elas e o comportamento que elas exibem. Para tal: o Os requisitos bsicos do usurio precisam ser discutidos entre o cliente e o engenheiro de software; o As classes precisam ser identificadas; o Uma hierarquia de classes precisa ser especificada;

o As relaes de objeto para objeto devem ser apresentadas; o O comportamento do objeto precisa ser modelado; o As tarefas de 1 a 5 so replicadas iterativamente at que o modelo seja completado. Mtodos de OOA: o Booch o Rumbaugh o Jacobson o Coad e Yourdon o Wirfs-Brock Passos genricos para a conduo da anlise orientada a objetos: o Deduzir os requisitos do cliente para o sistema; o Identificar cenrios de casos de uso; o Selecionar classes e objetos usando os requisitos bsicos como diretriz; o Identificar atributos e operaes para cada objeto do sistema; o Definir estruturas e hierarquias que organizem as classes; o Construir um modelo objeto-relacionamento; o Construir um modelo de comportamento de objeto; o Revisar o modelo de anlise OO com base nos casos de uso ou cenrios. Abordagem unificada a OOA:

Em UML, um sistema representado usando cinco diferentes vises, a saber: o Viso do modelo do usurio: representa o sistema (produto) a partir da perspectiva do usurio (chamados de atores em UML). O caso de uso a abordagem de modelagem escolhida para a viso do modelo do usurio; o Viso do modelo estrutural: Dados e funcionalidades so vistos de dentro do sistema. Isto , a estrutura esttica (classes, objetos e relacionamentos) modelada; o Viso do modelo comportamental: Essa parte do modelo de anlise representa os aspectos dinmicos ou comportamentais do sistema. Ela tambm mostra as interaes ou colaboraes entre os vrios elementos estruturais descritos nas vises do modelo do usurio e do modelo estrutural; o Viso do modelo de implementao: Os aspectos estruturais e comportamentais do sistema so representados da forma como devem ser construdos; o Viso do modelo do ambiente: Os aspectos estruturais e comportamentais do ambiente, no qual o sistema dever ser implementado, devem ser representados. A OOA pode ocorrer em muitos nveis de abstrao diferentes. No nvel de negcio ou de empresa, as tcnicas associadas com a OOA podem ser combinadas com uma abordagem de engenharia de processos de negcio,

num esforo para definir classes, objetos, relacionamentos e comportamentos que modelem todo o negcio. Em seu nvel mais baixo de abstrao, cai no mbito da engenharia de software orientada a objetos. Reuso e anlise de domnio:

Firesmith descreve a anlise de domnio de software do seguinte modo: A anlise de domnio de software a identificao, anlise e especificao dos requisitos comuns de um domnio de aplicao especfico, para reuso tipicamente em vrios projetos dentro do domnio de aplicao ... [Anlise de domnio Orientado a Objetos ] a identificao, anlise e especificao de capacidades comuns, reusveis dentro de um domnio de aplicao especfico, em termos de objetos comuns, classes, sub-montagens e frameworks ... Componentes Genricos do Modelo de Anlise OO

Componentes Estticos: so de natureza estrutural e indicam caractersticas que vigoram durante toda a vida operacional de uma aplicao. Essas caractersticas distinguem um objeto de outros objetos. Componentes dinmicos: objetivam o controle e so sensveis ao processamento de tempos e eventos. Eles distinguem como um objeto interage com outros objetos ao longo do tempo. O processo de OOA:

Casos de Uso: so criados com os seguintes objetivos: o Estabelecer os requisitos funcionais e operacionais do sistema (produto) pela definio de um cenrio de uso que seja combinado entre o usurio final e a equipe de engenharia de software; o Produzir uma descrio clara e no ambgua de como o usurio final e o sistema interagem um com o outro; o Produzir uma base para o teste de validao; Modelagem classe-responsabilidade-colaborao: Fornece um meio simples para identificar e organizar as classes que so relevantes aos requisitos do sistema ou produto. Um modelo CRC na realidade um conjunto de fichas padro de indexao que representam as classes. As fichas so divididas em trs sees. No alto da ficha voc escreve o nome da classe. No corpo da ficha voc lista as responsabilidades da classe esquerda e os colaboradores direita. o Classes: caractersticas de seleo: Informao retida; Servios necessrios; Atributos mltiplos;

 Atributos comuns; Operaes comuns; Requisitos essenciais. o Responsabilidades: diretrizes para atribuir responsabilidades a classes: A inteligncia do sistema deve ser distribuda uniformemente; Cada responsabilidade deve ser enunciada to genericamente quanto possvel; A informao e o comportamento relacionado devem residir dentro da mesma classe; A informao de uma coisa deve ser localizada numa nica classe, no distribuda entre vrias classes; Responsabilidades devem ser compartilhadas por classes relacionadas, quando adequado; o Colaboraes: as classes satisfazem as suas responsabilidades em um de dois modos: (1) uma classe pode usar suas prprias operaes para manipular seus prprios atributos, satisfazendo, assim, uma responsabilidade especfica, ou (2) uma classe pode colaborar com outras classes. Colaboraes representam solicitaes de um cliente para um servidor, para satisfazer as responsabilidades do cliente. Dizemos que um objeto colabora com outro objeto se, para satisfazer uma responsabilidade, ele precisa mandar quaisquer mensagens a outro objeto. As colaboraes identificam relaes entre as classes. Trs diferentes relacionamentos genricos entre classes: o O relacionamento parte de; o O relacionamento tem conhecimento de; o O relacionamento depende de. A reviso do modelo CRC pode utilizar a seguinte abordagem: o A todos os participantes da reviso so dados subconjuntos das fichas de indexao do modelo CRC. As fichas que colaboram devem ser separadas (i.e., nenhum revisor deve ter duas fichas que colaboram); o Todos os cenrios de casos de uso (e correspondentes diagramas de casos de uso) devem ser organizados em categorias; o O lder da reviso l o caso de uso pausadamente. medida que o lder da reviso chega a um objeto especificado, passa a vez para a pessoa que est com a correspondente ficha de indexao. Por exemplo:

O proprietrio observa o painel de controle de Safe-Home para determinar se o sistema est pronto para operar. Se no est, o proprietrio precisa fechar fisicamente as janelas/portas de modo que o indicador de pronto fique ligado.

[Um indicador no-pronto implica que um sensor est aberto, isto , que uma porta ou janela est aberta.] o Quando o lder da reviso chega a painel de controle, na narrativa do caso de uso, a vez passada para a pessoa que est com a ficha de indexao painel de controle. A frase implica que um sensor est aberto exige que a ficha de indexao contenha uma responsabilidade que valide essa implicao (a responsabilidade determine-estado-sensor realiza isso). Junto responsabilidade, na ficha de indexao, est o colaborador sensor. A vez ento passada ao objeto sensor; o Quando a vez passada, quem est de posse da ficha da classe deve descrever as responsabilidades anotadas na ficha. O grupo determina se uma (ou mais) das responsabilidades satisfaz a exigncia do caso de uso; o Se as responsabilidades e colaboraes anotadas nas fichas de indexao no podem acomodar o caso de uso, so feitas modificaes nas fichas. Isso pode incluir a definio de novas classes (e correspondentes fichas de indexao CRC), ou a especificao de responsabilidades, ou colaboraes novas ou revisadas nas fichas existentes. Esse modo de agir continua at que o caso de uso seja finalizado. Definio de estruturas e hierarquias: Uma vez identificados objetos e classes usando o modelo CRC, o analista comea a focalizar a estrutura do modelo de classes e as hierarquias resultantes que surgem, medida que as classes e subclasses emergem; Definio de assunto e subsistemas: Um modelo de anlise para uma aplicao completa pode ter centenas de classes e dzias de estruturas. Por esta razo, necessrio definir uma representao concisa que seja um resumo dos modelos CRC e da estrutura que acabaram de ser descritos. Quando um grupo de classes colabora entre si, para satisfazer a um conjunto coesivo de responsabilidades, freqentemente referido como subsistema ou pacote (UML). O modelo Objeto-relacionamento

O modelo objeto-relacionamento (como o modelo entidade-relacionamento) pode ser derivado em trs partes: Usando as fichas CRC, uma rede de objetos colaboradores pode ser desenhada; Revisando as fichas do modelo CRC, as responsabilidades e colaboraes so avaliadas e cada linha de conexo no rotulada rotulada;

Uma vez estabelecidos relacionamentos rotulados, cada extremo avaliado para determinar a cardinalidade. O modelo Objeto-comportamento

Representa o comportamento do sistema como uma funo de eventos e tempo especficos. Para cri-lo, o analista precisa executar os seguintes passos: o Avaliar todos os casos de uso para entender plenamente a seqncia de interao dentro do sistema; o Identificar os eventos que dirigem a seqncia de interao e entender como esses eventos se relacionam a objetos especficos; o Criar uma marcao de eventos em cada caso de uso; o Construir um diagrama de transio de estados para o sistema; o Revisar o modelo objeto-comportamento para verificar a preciso e a consistncia.

Projeto Orientado a Objetos (OOD):

O projeto Orientado a Objetos (OOD), transforma o modelo de anlise criado, usando anlise orientada a objetos, num modelo de projeto que serve como documento para a construo do software. Exige uma arquitetura de software multicamada, a especificao de subsistemas que realizam as funes necessrias e fornecem a infra-estrutura de apoio, uma descrio de objetos (classes) que formam os blocos construtivos do sistema e uma descrio dos mecanismos de comunicao que permitem aos dados fluir entre camadas, subsistemas e objetos. 1. A OOD estabelece uma documentao de projeto que permite ao engenheiro de software definir a arquitetura OO de forma a maximizar o reuso, aumentando assim a velocidade de desenvolvimento e a qualidade do produto final. A OOD est dividida em duas atividades principais: a. Projeto de Sistema: cria a arquitetura do produto definindo uma srie de camadas que realizam funes especficas do sistema e identificando as classes que so encapsuladas por subsistemas que residem em cada camada. Tambm considera a especificao de trs componentes: a interface com o usurio, as funes de gesto de dados e as facilidades de gesto de tarefas; b. O Projeto de Objetos: focaliza o detalhe interno de classes individuais, definindo detalhes de atributos, operaes e mensagem. Como produto, um modelo de projeto OO inclui a arquitetura do software,a descrio da interface com o usurio, os componentes de gesto de dados, as facilidades de gesto de tarefas e as descries detalhadas de cada classe a

ser usada no sistema. Em cada estgio, os elementos do modelo de projeto orientado a objetos so revisados quanto clareza, correo, completeza e consistncia com os requisitos do usurio e entre si. 2. As quatro camadas do projeto OO so: a. Camada de subsistema: contm uma representao de cada um dos subsistemas que permitem ao software satisfazer os requisitos definidos pelo cliente e implementar a infra-estrutura tcnica que suporta esses requisitos; b. Camada de classes e objetos: contm as hierarquias de classes que permitem a criao do sistema usando generalizaes e especializaes cada vez mais focalizadas. Essa camada tambm contm representaes de cada objeto; c. Camada de mensagens: contm os detalhes de projeto que permitem a cada objeto se comunicar com seus colaboradores. Essa camada estabelece as interfaces externa e interna do sistema; d. Camada de responsabilidade: contm as estruturas de dados e o projeto algortmico de todos os atributos e operaes de cada objeto.

Fichrio CRC

Modelo Objeto Relacioname nto

Projeto de Responsabilidades

Casos de Uso Modelo Objeto Comportamento Atributos, operaes, colaboradores

Projeto de mensagens Projeto de classes e objetos Projeto de subsistemas

Essas camadas repousam sobre uma base, chamada de fundao e tem por objetivo o projeto de objetos do domnio (chamados padres de projeto). 3. O processo do projeto do sistema: inclui as seguintes atividades:

Anlise Orientada a Objetos Projeto da gesto de tarefas Projeto da gesto de dados Projeto da Interface Humana Projeto do sistema

Projeto de Objetos

a. b. c. d. e. f.

Particionar o modelo de anlise em subsistemas; Identificar a concorrncia que ditada pelo problema; Alocar subsistemas a processadores e tarefas; Desenvolver um projeto para a interface do usurio; Escolher uma estratgica bsica para implementar a gesto de dados; Identificar os recursos globais e os mecanismos de controle necessrios para ter acesso a eles; g. Projetar um mecanismo de controle adequado para o sistema, incluindo gesto de tarefas; h. Considerar como as condies limite devem ser manipuladas; i. Revisar e considerar concesses. Particionar o modelo de anlise: No projeto de sistemas OO particionamos o modelo de anlise para definir colees de classes, relacionamentos e comportamentos coesivos. Esses elementos de projeto so empacotados como um subsistema; Concorrncia e alocao de subsistemas: quando subsistemas so concorrentes, existem duas opes de alocao: alocar cada subsistema a um processador independente ou alocar os subsistemas ao mesmo processador e providenciar

suporte de concorrncia atravs das caractersticas do SO. Tarefas concorrentes so definidas examinando o diagrama de estados de cada objeto (thread); O componente de gesto de tarefas: (para tarefas concorrentes) o As caractersticas da tarefa so determinadas; o Uma tarefa coordenadora e os objetivos associados so definidos; o A coordenadora e as outras tarefas so integradas. Podem ser dirigidas por eventos ou por relgio; Template para definio dos atributos e operaes, necessrios para conseguir coordenao e comunicao com outras tarefas: Nome da tarefa o nome do objeto Descrio uma narrativa descrevendo a finalidade do objeto Prioridade prioridade da tarefa (ex.: baixa, mdia, alta) Servios uma lista de operaes que so responsabilidade do objeto Coordenada por modo pelo qual o comportamento do objeto invocado Comunica-se atravs de valores de dados de entrada e sada relevantes para a tarefa.

O componente de interface com o usurio: recebe como entrada os cenrios de uso e uma descrio dos papis que os usurios desempenham (atores), medida que interagem com o sistema. Ambos desenvolvidos durante a OOA. Dado o grande nmero de ambientes de desenvolvimento de interface, basta ao implementador instanciar os objetos que tm caractersticas adequadas para o domnio do problema. O componente de gesto de dados: inclui duas reas distintas: (1) a gesto dos dados que so crticos para a aplicao propriamente dita e (2) a criao de uma infra-estrutura para armazenamento e recuperao de objetos. Em geral, a gesto de dados projetada numa disposio em camadas. A idia isolar os requisitos de baixo nvel por manipulao das estruturas de dados dos requisitos de alto nvel, para manejar os atributos do sistema. Dentro do contexto de sistema, um sistema de gesto de base de dados freqentemente usado como um armazm de dados comum para todos os subsistemas. Os objetos necessrios para manipular a base de dados so membros de classes reusveis, que so identificados usando anlise de domnio ou so supridos diretamente pelo fornecedor da base de dados. O projeto do componente de gesto de dados inclui o projeto dos atributos e as operaes necessrias para gerir os objetos. Os atributos relevantes esto associados a cada objeto no domnio do problema e fornecem informao que corresponde questo, Como eu me armazeno?. Uma alternativa a criao de uma classe objeto-servidor com servios para (a) dizer a cada objeto para se guardar e (b) recuperar objetos guardados para uso por outros componentes de projeto. Como exemplo de gesto de dados para o objeto sensor (parte do sistema SafeHome), o projeto poderia especificar um

arquivo plano chamado de sensor. Cada registro iria corresponder a uma instncia denominada de sensor e iria conter os valores de cada atributo de sensor para aquela instncia. As operaes dentro da classe objeto-servidor iriam permitir a cada objeto especfico ser armazenado e recuperado quando necessrio para o sistema. Para objetos mais complexos, poderia ser necessrio especificar uma base de dados relacional ou uma base de dados orientada a objetos para realizar a mesma funo. O componente de gesto de recursos: subsistemas competem por recursos (ex.: unidades de disco, processador, base de dados, ...). Deve-se implementar mecanismos que controlem o acesso a tais recursos. Comunicao entre subsistemas: pode-se adotar os seguintes passos de projeto para especificar um contrato: o Listar cada solicitao que pode ser feita por colaboradores do subsistema: organize as solicitaes por subsistema e defina-as dentro de um ou mais contratos adequados. Certifique-se de anotar os contratos que so herdados de superclasses; o Para cada contrato, anote as operaes (tanto herdadas, quanto privadas) que so necessrias para implementar as responsabilidades implicadas pelo contrato: certifique-se de associar as operaes a classes especficas que residem dentro de um subsistema; o Considere um contrato de cada vez: para cada contrato so feitas as seguintes entradas em uma tabela: Tipo tipo de contrato (isto , cliente/servidor ou fim a fim); Colaboradores nome dos subsistemas que so parte do contrato; Classe nomes das classes (contidas num subsistema) que suportam os servios implicados pelo contrato; Operao nomes das operaes (dentro da classe) que implementam os servios; Formato da mensagem o formato de mensagem necessrio para implementar a interao entre colaboradores; Se os modos de interao entre subsistemas so complexos, criado um diagrama de colaborao de subsistemas. 4. O processo de Projeto de Objeto: Se o projeto de sistema OO for comparado a uma planta baixa de uma casa, o projeto de objetos focaliza os detalhes para construir cada cmodo. nesse estgio que os conceitos e princpios bsicos associados com o projeto em nvel de componente vm baila. Estruturas de dados locais so definidas (para atributos) e algoritmos (para operaes) so projetados. Descrio de objeto: deve conter (1) uma descrio de protocolo, que estabelece a interface de um objeto pela definio de cada mensagem que o objeto pode receber e da operao relacionada que o objeto realiza quando recebe a mensagem e (2) uma descrio de implementao, que mostra detalhes de implementao de cada operao implicada por uma mensagem que passada para um objeto. Projeto de algoritmos e estruturas de dados: Procede-se otimizao do modelo dos objetos bsicos: (1) Revisas o modelo objeto-

relacionamento para garantir que o projeto implementado leve utilizao eficiente dos recursos e facilidade de implementao. Adicionar redundncia onde necessrio. (2) Revisar as estruturas de dados de atributos e os algoritmos correspondentes das operaes, para aperfeioar a eficincia de processamento. (3) Criar novos atributos para armazenar a informao derivada, evitando assim o reclculo. Componentes e interfaces de programa:

PACOTE nome-componente-programa TIPO especificao dos objetos de dados ... PROC especificao das operaes relacionadas . . . PRIVADO Detalhes das estruturas de dados dos objetos CORPO DO PACOTE nome-componente-programa PROC operao.1 (descrio da interface) ... FIM PROC operao.n (descrio da interface) ... FIM FIM nome-componente-programa

TIPO parte de especificao de componente que indica todos os objetos de dados; PROC parte da especificao de componente que indica as operaes; PRIVADO fornece detalhes das estruturas de dados e processamentos; PACOTE conceitualmente semelhante aos objetos.

PROCEDIMENTO Software SafeHome PACOTE sistema TIPO dados do sistema PROC instalar, definir, construir, carregar PROC mostrar, reajustar, consultar, modificar, chamar PRIVADO CORPO DO PACOTE sistema PRIVADO sistema.id CADEIA COMPRIMENTO (8); nmero.fone_verificao, telefone, nmero, ... CADEIA COMPRIMENTO (8); sensor.tabela DEFINIDO sensor.tipo CADEIA COMPRIMENTO (2), sensor.nmero, alarme.limiar NUMRICO; PROC instalar RECEBE (telefone.nmero) {detalhe de projeto para a operao instalar} ... FIM sistema PACOTE sensor TIPO dados do sensor PROC ler, ajustar, testar PRIVADO CORPO DO PACOTE sensor PRIVADO sensor.id CADEIA COMPRIMENTO (8); sensor.estado CADEIA COMPRIMENTO (8); alarme.caractersticas DEFINIDO limiar, tipo de sinal, nvel de sinal NUMRICO, hardware.interface DEFINIDO tipo, caractersticas.a/d, dados. Tempo NUMRICO, FIM sensor ... FIM software SafeHome PROC ler(sensor.id, sensor.estado: FORA);

PROC ajustar (alarme.caractersticas, hardware.interface: DENTRO); PROC testar (sensor.id, sensor.estado, alarme.caractersticas: FORA);

Projeto detalhado
PROC ler (sensor.id, sensor.estado: FORA); Bruto.sinal CADEIA DE BIT SE (hardware.tipo.interface = s & caractersticas.alarme.tipo.sinal = B ENTO PEGAR (sensor, exceo:sensor.estado := erro) bruto.sinal; CONVERTER bruto.sinal PARA sinal.nvel.interno; SE sinal.nvel.interno > limiar ENTO sensor.estado := evento; SENO sensor.estado := no-evento; FIM-SE SENO {processamento para outros tipos de interface seriam especificados} FIM-SE RETORNAR sensor.id, sensor.estado; FIM ler

5. Padres de Projeto: voc vai encontrar padres repetidos de classes e objetos comunicantes em muitos sistemas OO. Esses padres resolvem problemas de projeto especficos e tornam o projeto OO mais flexvel, elegante, e, em ltima anlise, reusvel. Em um sistema OO, padres de projeto podem ser usados pela aplicao de dois mecanismos diferentes: herana e composio. Sua descrio deve conter: o nome do padro, o objetivo do padro, , as influncias de projeto que motivam o padro, a soluo que atenua tais influncias, as classes que so necessrias para implementar a soluo, as responsabilidades e colaboraes entre as classes da soluo, diretrizes que levam implementao efetiva, cdigofonte exemplo ou gabaritos de cdigo-fonte e referncias cruzadas a padres de projeto relacionados.