UNIVERSIDADE LUTERANA DO BRASIL COMUNIDADE EVENGÉLICA LUTERANA “SÃO PAULO”Reconhecida pela Portaria Ministerial nº 681 de0...
2
SumárioLista de Tabelas e Figuras............................................................................................
Lista de Tabelas e Figuras            4
Resumo       Este trabalho contém os fundamentos básicos da metodologia Objectory, desenvolvida por Ivar Jacobson.Começand...
Introdução       O desenvolvimento de software orientado a objeto é a grande tendência desses tempos, devido às grandesvan...
1 Histórico       O Dr. Ivar Jacobson é um dos líderes mundiais em metodologia de desenvolvimento de software. Étambém o p...
Modelo de                                               Casos de Uso                   Expressado                  Realiza...
3.1 Análise dos Requisitos / Modelo dos Requisitos       Este modelo delimita o sistema e define quais as funcionalidades ...
uso é descrito em de forma mais detalhada. Até então eles só descreviam o curso básico, a mais importanteseqüência para a ...
relacionamento, mostrando instâncias de objetos, classes e associações. Dentre as associações incluem herança eexistência ...
Objeto de Interface        Modela comportamento e informação que é dependente de uma interface do sistema. É através desse...
4 Construção       Qual o propósito da fase de construção? O código fonte não pode ser escrito diretamente a partir domode...
4.1.2 Diagrama de Interação       Os diagramas de interação são utilizados no modelo de projeto para descrever como cada c...
No diagrama está a representação de um dos casos de uso do sistema de sistema de recebimento deembalagens, citado anterior...
5.2 Teste de Integração        Quando todas as classes envolvidas num determinado caso de uso já foram testadas no teste d...
Conclusão       A metodologia de desenvolvimento de software Objectory realmente favorece a produção de um sistemacom as c...
Bibliografia1. SELLERS, Brian Henderson; EDWARD, Julian M.. THE WORKING OBJECT. Rio de Janeiro: Prentice     Hall, 1994.2....
Upcoming SlideShare
Loading in …5
×

Objectory

378 views

Published on

Baixe mais arquivos em http://pastadomau.wikidot.com.
Trabalho sobre a metodologia de desenvolvimento de software de Ivar Jacobson chamada Objectory. Claro, isso foi antes dele juntar-se a Grady Booch e Jim Rumbaugh para desenvolver a UML e o RUP.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
378
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Objectory

  1. 1. UNIVERSIDADE LUTERANA DO BRASIL COMUNIDADE EVENGÉLICA LUTERANA “SÃO PAULO”Reconhecida pela Portaria Ministerial nº 681 de07/12/89 – DOU de 11/12/89 CAMPUS TORRESCENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO OBJECTORY MAURICIO VOLKWEIS ASTIAZARA MARCELO WAIHRICH DE SOUZA ENGENHARIA DE SOFTWARE II PROF. ADRIANA ROMA TORRES, OUTUBRO DE 2001
  2. 2. 2
  3. 3. SumárioLista de Tabelas e Figuras.........................................................................................................................................4MERGEFORMAT....................................................................................................................................................5MERGEFORMAT....................................................................................................................................................61 Histórico.................................................................................................................................................................72 Visão Geral.............................................................................................................................................................73 Análise....................................................................................................................................................................8 3.1 Análise dos Requisitos / Modelo dos Requisitos...........................................................................9 3.1.1 Modelo de Casos de Uso....................................................................................................... 9 3.1.2 Descrição de Interfaces do Usuário......................................................................................10 3.1.3 Modelo de Objetos do Domínio............................................................................................10 3.2 Análise Robusta / Modelo de Análise.......................................................................................... 11 3.2.1 Os Três Tipos de Objetos..................................................................................................... 11 3.2.2 Subsistemas......................................................................................................................... 124 Construção............................................................................................................................................................13 4.1 Projeto / Modelo de Projeto......................................................................................................... 13 4.1.1 Diagrama de Blocos............................................................................................................. 13 4.1.2 Diagrama de Interação......................................................................................................... 14 4.1.3 Modelo de Interface de Blocos............................................................................................. 15 4.2 Implementação / Modelo de Implementação...............................................................................155 Teste / Modelo de Teste.......................................................................................................................................15 5.1 Teste de Unidade........................................................................................................................ 15 5.2 Teste de Integração.................................................................................................................... 16 5.3 Teste do Sistema........................................................................................................................ 16Conclusão................................................................................................................................................................17Bibliografia.............................................................................................................................................................18 3
  4. 4. Lista de Tabelas e Figuras 4
  5. 5. Resumo Este trabalho contém os fundamentos básicos da metodologia Objectory, desenvolvida por Ivar Jacobson.Começando por um histórico sobre o autor e o surgimento da metodologia. Depois são abordadas cada uma dasfases descritas pelo Objectory: Análise, Projeto, Construção e Teste, bem como os modelos produzidos por cadauma delas. Se tem um foco especial no conceito de Casos de Uso, que é base fundamental desta metodologia. Abstract This work contain the basic foudation of Objectory metodology, developed by Ivar Jacobson. Starting bya historic about author and his metodology. We shall describe each phase of Objectory: Analysis, Design,Construction and Testing, also the models developed in each phase. There are a special focus in Use Caseconcept, that is the base this metodology. 5
  6. 6. Introdução O desenvolvimento de software orientado a objeto é a grande tendência desses tempos, devido às grandesvantagens que oferece, como reusabilidade, encapsulamento e extensibilidade. Mas um real aproveitamentodessas vantagens não é obtido simplesmente adotando-se uma linguagem de programação orientada a objeto. Énecessário uma metodologia de desenvolvimento que apoie a orientação a objeto, imprimindo essascaracterísticas em todo o desenvolvimento desde o princípio até o término. Por isso abordamos aqui uma das diversas metodologias orientadas a objeto existentes: a Objectory. Combase neste trabalho o leitor será capaz de avaliar esta metodologia, o que pode contribuir na sua escolha de umametodologia de desenvolvimento de software orientada a objeto. 6
  7. 7. 1 Histórico O Dr. Ivar Jacobson é um dos líderes mundiais em metodologia de desenvolvimento de software. Étambém o principal autor da metodologia Objectory, uma das metodologias pioneiras em relação à orientação aobjeto. O nome Objectory vem de Object Factory, ou seja, “fábrica de objetos” para o desenvolvimento desoftware. Veremos um breve histórico sobre Ivar Jacobson e a metodologia Objectory. Em 1967, Jacobson, trabalhando na empresa Ericsson, desenvolve a abordagem da arquitetura cêntricapara desenvolvimento de software, que é baseada na interação e colaboração de subsistemas. Esta abordagem foiadotada pelo padrão de telecomunicação SDL (Specification and Description Language). Jacobson passa aenfatizar o desenvolvimento de software baseado em casos de uso, processo este que foi o primeiro exemplo dedesenvolvimento baseado em componentes. Em 1987, com o aprimoramento desse processo de desenvolvimento, Jacobson o nomeia Objectory eacaba fundando a sua própria empresa: a Objectory AB, na Suécia. A metodologia passa a chamar a atenção daindústria de desenvolvimento de software devido a 15 projetos de sucesso ao redor do mundo. No começo de 1990, Jacobson expande o Objectory para incluir a engenharia de negócios, para assimmelhor entender o contexto do negócio e melhor capturar os seus requisitos. Em 1992, o metodologista lança o OOSE, Object-oriented Software Engeneering – Engenharia deSoftware Orientada a Objeto, que nada mais é que uma versão simplificada do método Objectory. A companhia de Jacobson, Objectory AB, acaba se fundindo com a empresa Rational SoftwareCorporation em 1995. Junto com seus colegas da Rational, Grady Booch e Jim Rumbaugh, ele desenvolveu aLinguagem Unificada de Modelagem – UML (Unified Modeling Language), que é a linguagem padrão paraespecificação, visualização, construção e documentação para artefatos de sistema de software. A UML foioficialmente adotada como padrão pelo Grupo de Gerenciamento de Objetos – OMG (Object ManagementGroup) em 1997. Atualmente, Jacobson é vice presidente de desenvolvimento de software na Rational, sendo responsávelpor ajudar a empresa a definir associações e estratégias de produto na área de desenvolvimento de software. Eletambém trabalha com Grady Booch e Jim Rumbaugh no refinamento e aperfeiçoamento da UML. Jacobson durante este tempo escreveu com a ajuda de outros autores três influentes livros campeões devenda: Object-Oriented Software Engineering - A Use Case Driven Approach, The Object Advantage--BusinessProcess Reengineering with Object Technology, and Software Reuse: Architecture, Process, and Organizationfor Business Success.2 Visão Geral A metodologia Objectory descreve todo o ciclo de vida de desenvolvimento, enfatizando o usuário, oprocesso de engenharia e a interação entre as fases do ciclo de vida. O ciclo de vida é dividido em três fases:Análise, Construção e Teste. Cada fase tem seus processos, que geram diferentes modelos representando diferentes visões do sistema.Os modelos gerados numa fase serão utilizados em outras fases. Fase Entrada Processos Saída Análise Especificação dos Requisitos Análise de Requisitos Modelo de Requisitos Análise Rigorosa Modelo de Análise Construção Modelo de Requisitos Projeto Modelo de Projeto Modelo de Análise Implementação Modelo de Implementação Teste Modelo de Requisitos Teste de Unidade Modelo de Teste Modelo de Projeto Teste de Integração Modelo de Implementação Teste do SistemaTabela 1: Fases e Modelos do Objectory Todo o processo de desenvolvimento é baseado nos casos de uso. Um caso de uso representa um diálogo(seqüência de transações) entre o sistema e um usuário realizado para alcançar algum objetivo. Os casos de usotentam capturar a funcionalidade do sistema pela representação do que os usuários deveriam ser capazes de fazercom ele. Todos os outros modelos são construídos com base nas considerações feitas para os casos de uso; comoconseqüência esses casos proporcionam elos de ligação entre as fases do Objectory. 7
  8. 8. Modelo de Casos de Uso Expressado Realizado Testado em por por Estruturado Implementad por o por Modelo de Modelo de Modelo de Modelo de Modelo de Requisitos Análise Projeto Implementação TesteFigura 1: Coesão de Todos os Modelos com os Casos de Uso Apesar de as fases estarem descritas de forma seqüencial, elas não são executadas seqüencialmente, e simiterativamente. Quando o modelo que está sendo usado numa fase possui pontos não esclarecidos, deve-se voltara fase que gerou o modelo para o esclarecimento desses pontos. A execução de forma iterativa permite que fasesocorram em paralelo. Esta metodologia tem como argumento que um sistema construído ao redor de exemplos de ações deprováveis usuários terá um grande grau de reusabilidade e flexibilidade. Veremos agora de forma detalhada cada uma das fases, seus processos e modelos, mostrando qual oobjetivo de cada um, como são construídos e a forma como representam o sistema.3 Análise O objetivo da análise e especificar e definir o sistema que será construído. Os modelos desenvolvidos irãodescrever o que o sistema faz. A base para esta modelagem são os requisitos dos clientes ou usuários finais parao sistema. Por isso é importante manter um diálogo contínuo com os clientes e possíveis usuários para que setenha certeza que o sistema a ser construído é o sistema que se quer. Os modelos são construídos de forma afacilitar o entendimento do sistema. Os modelos desenvolvidos durante a análise são completamente orientados para a aplicação e não para oambiente de implementação. Eles são modelos “essenciais”, que são independentes de coisas como sistemaoperacional, linguagem de programação, banco de dados, configuração de hardware. Os modelos baseados emconceitos orientados a aplicação podem ser discutidos com os usuários sem o uso de termos de implementação. Eventualmente o sistema terá que ser adaptado para o ambiente de implementação, mas isto é feito naconstrução. O fato de pouca atenção ser dada ao ambiente de implementação garante que a arquitetura resultanteseja baseada no próprio problema e não em condições de implementação. Além disso, os modelos de análisepermaneceram intactos e utilizáveis se as condições de implementação mudarem. A análise consiste de dois processos: Análise de Requisitos e Análise Robusta, que respectivamenteproduzem o Modelo de Requisitos e Modelo de Análise. Análise Especificação Análise dos Análise dos Requisitos Rigorosa Requisitos Modelo dos Modelo de Requisitos AnáliseFigura 2: Fase de Análise 8
  9. 9. 3.1 Análise dos Requisitos / Modelo dos Requisitos Este modelo delimita o sistema e define quais as funcionalidades que o sistema deve oferecer. Ele é visãodo desenvolvedor do que o cliente quer, e serve como um contrato entre o desenvolvedor e o cliente. É essencialque este modelo seja legível por pessoas que não estejam familiarizadas com orientação a objeto e comobjectory, sendo fácil entendimento. Para isso ele deve ser elaborado a partir da perspectiva do usuário. Omodelo de requisitos consiste de: Modelo de Casos de Uso, Descrição de Interfaces do Usuário e Modelo deObjetos do Domínio. Já a partir do primeiro modelo elaborado, é possível avaliar se o usuário está satisfeito como que nós estamos projetando sobre o sistema, sem termos iniciado a sua construção.3.1.1 Modelo de Casos de Uso Este modelo é baseado em atores e casos de uso. Estes conceitos auxiliam a definir o que existe fora dosistema (atores) e o que o sistema deve ser capaz de desempenhar (casos de uso). Atores representam tudo o que interage com o sistema, tudo que precisa trocar informações com ele. Umator não é um usuário, mas o papel que um usuário pode exercer em relação ao sistema. Um usuário é umapessoa (às vezes um dispositivo, ou outro sistema) que usa o sistema. Diferente de muitos outros objetos, osatores não são deterministas (possuem liberdade para executar as ações). Atores podem ser comparados a classes e usuários a instâncias dessas classes. Esta instância somenteocorre quando o usuário faz alguma coisa no sistema. Uma mesma pessoa pode aparecer como instância dediversos atores. Por exemplo, um sistema pode ter pilotos e passageiros como atores. João pode ser um usuárioque às vezes atua no papel de piloto e às vezes como passageiro, desempenhando diferentes casos de uso. Cadaator pode desempenhar diferentes ações com o sistema. A definição de um casos de uso é: um ator utilizando o sistema para desempenhar uma seqüência detransações que possuem um comportamento relacionado, num diálogo com o sistema. Cada caso de uso é umamaneira específica de utilizar o sistema, logo a coleção de casos de uso contém a funcionalidade completa dosistema a ser construído. Cada caso de uso tem uma descrição e o sistema deve ser capaz de executar tudo o queestá descrito no modelo de casos de uso. No modelo os casos de uso são representados por elipses e os atores por bonecos. A relação que existeentre eles é representada por uma seta de duplo sentido, representando uma troca de informações. Vejamos oesboço de um modelo de casos de uso para um sistema para uma máquina que recebe embalagens retornáveis emum supermercado. O cliente utiliza o sistema para trocar suas embalagens (garrafas e outros recipientesretornáveis) por tickets para serem descontados no supermercado. Diariamente um operador do sistema pede umrelatório e recolhe as embalagens depositadas. Sistema de Recebimento de Embalagens Receber Imprimir Embalagens Relatório Cliente Recolher Embalagens Operado Depositadas rFigura 3: Esboço de um Diagrama de Casos de Uso Nem sempre é fácil identificar se uma funcionalidade deve ser colocada como um caso de uso separadoou como uma variação de um casos de uso existente. Se as diferença são pequenas, é melhor descrever comouma variação de um caso de uso. Se as diferenças são grandes, deve ser descrito como um caso de uso separado. A identificação dos casos de uso é iterativa, ou seja, sofrerá diversas modificações até que os casos de usosejam identificados da forma apropriada, se estabilizando. Só depois que desta estabilização é que cada caso de 9
  10. 10. uso é descrito em de forma mais detalhada. Até então eles só descreviam o curso básico, a mais importanteseqüência para a compreensão do caso de uso. A partir do detalhamento, variações do curso básico e erros quepodem ocorrer são descritos nas alternativas de curso. Um conceito poderoso utilizado para estruturar e relacionar descrições de casos de uso é o “ConstruçãoAssociada”. Este conceito relata como uma descrição de caso de uso pode estar inserida em outra descrição,consequentemente expandindo esta descrição. Desta forma, descrições de casos de uso podem ser descritas deforma compacta, permitindo facilmente mudanças e adição de outras funcionalidades. Importante salientar que ocaso “construído” deve compreender um curso completo por si próprio, totalmente independente da seqüênciainserida. A descrição original não faz referência a qualquer curso inserido, escapando de compor complexidadeou dependência. Descrevendo o caso de uso independente de qualquer funcionalidade estendida, podemosadicionar novas extensões sem alterar a descrição original. O conceito de construção associada favorece muito a reutilização, uma das principais vantagens daorientação a objeto. Quando o sistema é projetado com o foco nos casos de uso ele possui uma importante característica noque se refere à mudanças: quando se deseja mudar o comportamento do sistema, se remodela apropriadamente osatores e os casos de uso. Como toda a arquitetura é controlada pelos casos de uso as mudanças irão se refletir emtodos os outros modelos. Nós simplesmente questionamos os usuários sobre o que eles querem mudar (qual casode uso) e veremos diretamente onde essas mudanças devem ser feitas em outros modelos.3.1.2 Descrição de Interfaces do Usuário Para apoiar os casos de uso é essencial desenvolver modelos de interface para os casos de uso. Protótiposde interface facilitam a comunicação com os usuários mostrando o que eles verão quando estiverem executandoo caso de uso no sistema que será construído. Pode-se, da forma mais simples, utilizar esboços de interface, ouda forma mais sofisticada, utilizar um software que permita a construção rápida de interfaces para que, comalgum código, realize simulações. O uso de descrição de interfaces reduz a possibilidade de um desentendimento entre o que o usuário quere o que o analista projeta. Quando se está projetando as interfaces, o futuro usuário deve estar envolvido noprocesso (casos de uso) para que então, as interfaces reflitam a sua visão lógica do sistema. CONTROLE PATRIMONIAL - Mombelli & Cia Ltda TÍTULOS MENSAGENS TECLAS DE FUNÇÕESFigura 4: Descrição de Interface com o Usuário3.1.3 Modelo de Objetos do Domínio Com a elaboração dos casos de uso, aparecerão objetos que tem relação direta com o ambiente e sobre osquais o sistema deve manipular informações. Estes objetos são especificados no modelo de objetos do domínio. O modelo de objetos do domínio, assim como a descrição de interfaces, apoia a especificação dos casosde uso, definindo os conceitos com o a qual o sistema deve trabalhar. A notação é similar a um modelo entidade 10
  11. 11. relacionamento, mostrando instâncias de objetos, classes e associações. Dentre as associações incluem herança eexistência (isso é, um objeto mantém referência a outro). O modelo de objetos do domínio pode ser consideradocomo uma versão preliminar para modelo de análise desenvolvido na fase seguinte. Este modelo também tem a capacidade de funcionar como um glossário para os casos de uso, o que é degrande valor, especialmente quando diversas pessoas estão envolvidas na especificação dos casos de uso.3.2 Análise Robusta / Modelo de Análise Uma vez que o modelo de requisitos foi desenvolvido e aprovado pelos clientes, nos podemos iniciar umprocesso mais voltado à estrutura lógica interna do sistema, primeiramente com o desenvolvimento do modelode análise. Este modelo define a estrutura lógica do sistema de forma independente do ambiente deimplementação. A análise robusta distribui os comportamentos especificados na descrição dos casos de uso entre osobjetos no modelo. Um objeto pode ser comum a diferentes casos de uso, e nos devemos definir qual objeto éresponsável por oferecer qual comportamento em cada caso de uso. Ainda não é necessário quebrar ocomportamento em operações nesta fase, a maneira mais natural é uma descrição verbal das responsabilidadesou papel desempenhado por cada objeto. Embora seja possível usar o modelo de objetos do domínio como base para a implementação do sistema,isto não resulta na estrutura mais robusta. O modelo de análise representa a mais estável e manutenível estruturado sistema, que será robusta por todo o ciclo de vida. Isso significa que as muitas mudanças futuras, vindas doambiente de implementação não irão afetar a estrutura lógica.3.2.1 Os Três Tipos de Objetos Muitas metodologias de análise orientada a objetos reconhecem apenas um tipo básico de objeto. Mascom o emprego de três diferentes tipos de objetos, a estrutura será muito mais adaptável a mudanças. Os tipos deobjetos utilizados na análise são: Objeto Entidade, Objeto de Interface e Objeto de Controle. Objeto Entidade Objeto de Interface Objeto de ControleFigura 5: Representação Gráfica dos Diferentes Tipos de Objetos Cada tipo de objeto tem seus diferentes propósitos:Objeto Entidade Modela a informação do sistema que deve ser armazenada por algum período de tempo. Tipicamentesobrevive depois que o caso de uso é terminado. Toda a informação e comportamento que são naturalmenteacoplados devem ser colocados em um objeto entidade. Os objetos entidade normalmente são os primeiros a serem encontrados e estão presentes no modelo deobjetos do domínio. Outros além desses são difíceis de serem encontrados. Objetos entidade na maioria dasvezes correspondem a algo do mundo real, fora do sistema. É muito fácil elaborar um modelo com muitos objetos entidade, que não são realmente necessários. Parauma modelagem correta, é preciso utilizar os casos de uso como guia: somente objetos que podem serjustificados por descrições de casos de uso é que devem ser incluídos. Cada lugar num caso de uso onde énecessário armazenar informação é um objeto entidade em potencial. Para aramazenar informação, objetos entidade utilizam atributos. Cada atributo tem um tipo, que pode sertipo primitivo de dado, como inteiro ou string, ou pode ser um tipo de dado composto, que é mais complexo eespecialmente definido. Para decidir se um pedaço de informação deve ser modelado como uma entidade ou umatributo, devemos analisar como a informação é utilizada. A informação que é manipulada separadamente deveser modelada como um objeto entidade. A informação que está fortemente relacionada à outras informações enunca é utilizada isoladamente deve ser um atributo. Como o caso de uso manipula a informação é decisivo. Um exemplo de objeto entidade é uma pessoa dados associados e comportamentos, como um cliente. 11
  12. 12. Objeto de Interface Modela comportamento e informação que é dependente de uma interface do sistema. É através dessesobjetos que os atores se comunicam com o sistema. A tarefa de um objeto de interface é traduzir as ações do atorno sistema em eventos no sistema e traduzir eventos no sistema no qual o ator está interessado em algoapresentável para o ator. Objetos de interface, em outras palavras, descreve a comunicação bidirecional entre osistema e seus usuários, sendo que estes podem ser humanos ou outros sistemas. Logo, qualquer coisa sobreinterface do sistema é colocada em objeto de interface. Um exemplo de objeto de interface é a funcionalidade deuma interface de usuário utilizada para apresentar informações sobre um cliente.Objeto de Controle Modela funcionalidades (são normalmente comportamentais) que não estão naturalmente ligadas aosoutros tipos de objetos. Tipicamente um comportamento que consiste em operar diferentes objetos entidade,realizar algum processo e retornar o resultado para um objeto de interface, servindo como uma “cola” para uniros outros objetos num caso de uso. Este tipo de objeto aparece mais freqüentemente e sistemas mais complexos, e na maioria dos casos temuma vida curta, sobrevivendo apenas durante a execução do caso de uso do qual faz parte. Um exemplo de objeto de controle é um objeto que calcula uma taxa utilizando diversos diferentesfatores. Para suportar melhor mudanças de funcionalidade, é importante que os objetos no modelo de análiseestejam modelados com seu tipo adequado (entidade, interface ou controle). Dessa forma uma mudança defuncionalidade relacionada a uma informação que é mantida pelo sistema deve afetar somente o objeto entidadeque representa esta informação. Da mesma forma, mudanças exigidas na interface afetarão somente objetos deinterface e mudanças na funcionalidade envolvendo múltiplos objetos afetarão objetos de controle. Através dessetrês tipos de objetos nós podemos encapsular as áreas que nos queremos mudar.3.2.2 Subsistemas Um número grande de objetos pode surgir, dependendo da complexidade do sistema. Para obter umaclara visão e entendimento do modelo é necessário agrupar os objetos em um ou mais níveis, dependendo dotamanho do sistema. Grupos de objetos são chamados de subsistemas. Subsistemas podem conter subsistemas,formando uma hierarquia. Os subsistemas empacotam os objetos para reduzir a complexidade, organizando odesenvolvimento e manutenção da estrutura. Os nomes dos subsistemas podem ser unidades da organização,como vendas, marketing, entrega, etc. A divisão em subsistemas deve ser baseada na funcionalidade do sistema e no forte acoplamento (relaçõesfuncionais) entre alguns objetos. Abaixo temos um exemplo de diagrama com divisão em subsistemas. Ele modela parte de um sistemapara uma máquina que recebe embalagens retornáveis em um supermercado, citado anteriormente. Pacote Cliente Pacote Alarme e Impressora Receptor de Itens Dispositivo de Alarme Painel do Cliente ImpressoraFigura 6: Divisão do Modelo em Subsistemas 12
  13. 13. 4 Construção Qual o propósito da fase de construção? O código fonte não pode ser escrito diretamente a partir domodelo de análise, uma vez que ele já descreve os objetos no sistema e como eles se relacionam? Existem trêsrazões principais para o processo de construção:1. O modelo de análise não é formal o suficiente. Para a transição para o código fonte devemos refinar os objetos – que operações devem ser oferecidas, qual exatamente deve ser a comunicação entre os diferentes objetos, que estímulos são enviados, etc.2. Deve ser feita uma adaptação para o atual ambiente de implementação. Na fase de análise nos assumimos um mundo ideal para o nosso sistema. Nós devemos agora transformar o modelo de análise do espaço de análise para o espaço de projeto, considerando por exemplo: requisitos de desempenho, requisitos de tempo real e concorrência, propriedades da linguagem de programação, o gerenciamento do banco de dados a ser usado, etc.3. Nós queremos fazer a validação interna do resultado da análise. Como o sistema está crescendo e está sendo formalizado, nós veremos se os modelos da análise descrevem bem o sistema. Se forem descobertos pontos que não estejam claros no modelo de análise ou no modelo de requisitos nós devemos esclarecê-los, talvez pelo retorno à fase de análise. A construção é dividida em dois processos, projeto e implementação, cada um desenvolve o seu modelo.O modelo de projeto é um refinamento e formalização do modelo de análise no qual as conseqüências doambiente de implementação tem que ser levadas em conta. O modelo de implementação é a atual implementação(código fonte) do sistema. Processo de Construção Modelo de Requisitos Projeto Implementação Modelo de Análise Modelo de Modelo de Projeto ImplementaçãoFigura 7: Fase de Construção4.1 Projeto / Modelo de Projeto O principal trabalho realizado no projeto é a adaptação do sistema ao ambiente de implementação queserá utilizado. A meta é refinar o modelo de análise o suficiente para que ele facilite a escrita do código fonte(que é o modelo de implementação) na linguagem de programação escolhida a partir dele. Como dito, o modelode análise servirá como base, entretanto, mudanças terão que ser feitas visando o ambiente de implementação,especialmente quando se tem por exemplo um banco de dados relacional, um ambiente distribuído, requisitos dedesempenho ou processos concorrentes. O modelo de projeto consiste de três elementos: Diagrama de Blocos, Diagrama de Interações e Modelode Interface de Blocos.4.1.1 Diagrama de Blocos As estruturas com as quais nós trabalhamos no diagrama de blocos são basicamente as mesmas domodelo de análise, mas a visão muda já que é um passo na direção da implementação. Um bloco é um objeto deprojeto. Como na análise diferentes tipos de blocos podem ser usados (Entidade, Interface e Controle). Inicialmente, cada objeto da análise é simplesmente transformado em um bloco. Mas com o trabalho deprojeto, acaba-se inserindo alterações, por exemplo: um bloco pode ser dividido em dois para fins dedesempenho, ou novos blocos podem ser adicionados para servirem de interface com um gerenciador de bancode dados. 13
  14. 14. 4.1.2 Diagrama de Interação Os diagramas de interação são utilizados no modelo de projeto para descrever como cada caso de uso émanipulado pela interação dos objetos se comunicando. Interação é o envio ou recebimento de um estímulo deum bloco para outro. No diagrama de interação, cada bloco participante de um caso de suo particular érepresentado por uma coluna desenhada como uma linha vertical. Normalmente o ambiente externo ao sistema, aborda do sistema, é também representada por uma coluna mais à esquerda. Ela representa a interface para tudo oque está fora do diagrama de blocos (atores) e pode consequentemente corresponder a diferentes interfaces dosistema. No lado esquerdo da borda do sistema nos descrevemos as seqüências de interação. Esta descrição étextual, como texto estruturado ou pseudocódigo. Para pseudocódigo, a construção deve ser coerente com alinguagem de programação que será utilizada, para facilitar a migração para a implementação. O texto descreveo que está acontecendo numa parte particular caso de uso, chamada operação. A coluna, portanto o bloco, naqual a operação pertence é marcada com um retângulo, representando a operação. O diagrama de interação é controlado por eventos. Um novo evento dá margem a uma nova operação.Estes eventos são estímulos que são enviados de um objeto para outro e iniciam uma operação. Borda do Painel Receptor Base de Item de Impressor Sistema do de Itens Recibos Depósito a Cliente iniciar criar ativar novo item Item( ) existe( ) inserir( item) incr obter nome obter valor recibo Imprimir Imprimir( logo, data) recibo imprimir Imprimir( nome, qtd, valor) destruir Figura 8: Diagrama de Interação 14
  15. 15. No diagrama está a representação de um dos casos de uso do sistema de sistema de recebimento deembalagens, citado anteriormente. O caso de uso começa quando o cliente pressiona o botão “Iniciar”. O blocopainel do cliente então ativa os sensores que são externos ao sistema. Agora o cliente pode iniciar oabastecimento de embalagens retornáveis. Isto é resolvido pelo comando DO...WHILE que termina quando ocliente requisita o recibo. Os itens são checados neste loop. Se o item é aceitável, nós incrementamos o númerode coisas deste tipo abastecidas pelo cliente e no total do dia.4.1.3 Modelo de Interface de Blocos Este modelo apresenta toda a funcionalidade que cada bloco deve oferecer (interface). Para isso devepegar um bloco e todos os diagramas de interação onde ele aparece, e a partir deles extrair as todas as operaçõesque são requisitadas. Assim se obtém um retrato completo de cada bloco.4.2 Implementação / Modelo de Implementação Na implementação é feita a codificação do sistema. A base para a implementação é o modelo de projeto,que especifica a interface de cada bloco e descreve o comportamento esperado atrás de cada interface. O modelode implementação consiste do código fonte acompanhado de seus comentários. O que ocorre é a transformação de cada bloco do modelo de projeto em uma ou mais unidades de códigofonte, que nas linguagens de programação orientadas a objeto é representada por uma classe. A meta é que asclasses sejam robustas e altamente reutilizáveis. Se uma classe oferece funcionalidade similar à outra, elasdevem estar relacionadas por herança. As classes devem ter também alto grau de coesão, oferecendofuncionalidades que internamente estão fortemente interrelacionadas. Apesar de às vezes se ter a impressão que a construção é como caminho reto e fácil de se seguir, nãoexatamente esse o caso. O real desenvolvimento é um processo incremental, e freqüentemente muitas iteraçõesdevem ser feitas. Um exemplo de implementação complexa é o mapeamento para um banco de dados relacional,que requer coisas do tipo conversão de tipos, utilização de chaves, manipulação de erros e etc.5 Teste / Modelo de Teste A fase de teste verifica se o sistema que está sendo construído está correto. Os testes tradicionalmente sãocustosos, principalmente porque muitos defeitos não são detectados até o desenvolvimento. Uma abordagembem organizada e disciplinada é necessária para aumentar a qualidade do sistema e diminuir o custo dos testes. Assim como as outras fases do objectory, os testes também são guiados pelos casos de uso, que afinalrepresentam o que é desejado para o sistema. Os testes do sistema são realizados em três níveis, que serão vistosabaixo. Processo de Teste Modelo de Requisitos Teste de Teste de Teste do Unidade Integração Sistema Modelo de Projeto Modelo de Modelo de Implementação TesteFigura 9: Fase de Teste5.1 Teste de Unidade Este tipo de teste consiste em examinar o sistema a partir de suas menores partes, como as operações deuma classe. Cada uma das operações é testada em separado. Quando estes testes tiverem sido terminados, inicia-se o teste da classe como um todo. A base para estes dois testes é o modelo de projeto, em especial o modelo deinterface de blocos que especifica o comportamento que é esperado para cada unidade de código. 15
  16. 16. 5.2 Teste de Integração Quando todas as classes envolvidas num determinado caso de uso já foram testadas no teste de unidade,pode-se iniciar o teste de integração para este caso de uso. Este teste visa verificar se os objetos envolvidos estãose comunicando e colaborando corretamente para a resolução do caso de uso. Este teste é guiado pelo caso deuso que se está testando no momento, observando a devida descrição que está documentada no modelo de casosde uso.5.3 Teste do Sistema Quando dois ou mais casos de uso que estejam relacionados já foram testados no teste de integração, épossível começar o teste do sistema, que só termina quando todos os casos de uso são testados em conjunto.Mais uma vez, o modelo de casos de uso é vital para estes testes. O modelo de testes nada mais é que o resultado documentado dos testes citados acima, relatando todo oteste: parte que estava sendo testada, tipo de teste realizado, dados utilizados, resultado obtido e avaliação (falhoou OK). Este modelo é especialmente importante quando o sistema está sendo desenvolvido em equipe. Osoutros profissionais (analistas e programadores) poderão consultar o modelo de testes para auxiliar nodescobrimento da causa do erro. Como os testes se iniciam por pequenas partes e vão crescendo com tempo, é perfeitamente possível queesta fase ocorra em paralelo com a fase de implementação e de forma paralela internamente. Importante salientar que em todos os níveis de testes, devem ser realizados os testes de caixa branca e decaixa preta, aplicando-se diversas técnicas diferentes de teste. Assim se tem uma melhor garantia contra erros. 16
  17. 17. Conclusão A metodologia de desenvolvimento de software Objectory realmente favorece a produção de um sistemacom as caraterísticas da orientação a objeto, desde a análise até os testes. Porém, a metodologia parece se basearsempre na construção de um novo sistema, ainda não existente. Ela não oferece uma descrição explícita (pelomenos no material pesquisado) de qual deve ser o procedimento de análise baseada em um sistema já existente,como um sistema não informatizado ou um sistema legado. Talvez isso se deva ao fato de que o Objectory tenhasurgido no meio das telecomunicações, onde a maioria dos sistemas é algo novo e inédito. Ele foigradativamente adaptado para as áreas de negócios menores. Mas não se pode afirmar que em um dos livros deautoria do Jacobson, sobre Objectory, não haja alguma descrição de método para adaptação de sistemasexistentes. Entre tanto, Objectory é uma metodologia que deve ser muito leva em consideração. Devido à sua técnicade desenvolvimento, sempre centrada nos casos de uso em todas as fases, tende a garantir um sistema consiste ecoerente, que não se desvia de seus objetivos. Além disso, esta metodologia favorece o desenvolvimento emequipe, pois permite que as fases de desenvolvimento ocorram em paralelo, aumentando a produtividade. Isto sedeve ao sistema de desenvolvimento de forma iterada, e não em seqüência. Outra vantagem do objectory é que ele descreve uma forma de análise em que o usuário é muitoenvolvido, não de forma formal como em entrevistas, mas de forma muito sinérgica, quase como se os usuáriosfizessem parte da equipe de desenvolvimento. Isso é possível devido a não utilização de termos técnicos na fasede análise e sim de termos do usuário. Com esta forma de análise é menor as chances de erros e se acabarconstruindo um sistema que não é o desejado pelos usuários. 17
  18. 18. Bibliografia1. SELLERS, Brian Henderson; EDWARD, Julian M.. THE WORKING OBJECT. Rio de Janeiro: Prentice Hall, 1994.2. CARMICHAEL, Andy. OBJECT DEVELOPMENT. Nova York: Sigs, 1994.3. RATIONAL CORPORATION. DIRETORIA. Disponível na Internet no endereço http://www.rational.com/university/rubios.jsp#jacobson em 14/09/01.4. UML. Disponível na Internet no endereço http://sites.uol.com.br/quites/aulas/uml_slides.pdf em 14/09/01. 18

×