Objectory

UNIVERSIDADE LUTERANA DO BRASILCOMUNIDADE EVENGÉLICA LUTERANA “SÃO PAULO”Reconhecida pela Portaria Ministerial nº 681 de07/12/89 – DOU de 11/12/89

CAMPUS TORRES

CENTRO 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

Sumário

Lista de Tabelas e Figuras.........................................................................................................................................3

Resumo......................................................................................................................................................................4

Introdução.................................................................................................................................................................5

1 Histórico.................................................................................................................................................................6

2 Visão Geral.............................................................................................................................................................6

3 Análise....................................................................................................................................................................7

3.1 Análise dos Requisitos / Modelo dos Requisitos..................................................................................8

3.1.1 Modelo de Casos de Uso............................................................................................................8

3.1.2 Descrição de Interfaces do Usuário..............................................................................................9

3.1.3 Modelo de Objetos do Domínio...................................................................................................9

3.2 Análise Robusta / Modelo de Análise...............................................................................................10

3.2.1 Os Três Tipos de Objetos..........................................................................................................10

3.2.2 Subsistemas............................................................................................................................. 11

4 Construção............................................................................................................................................................12

4.1 Projeto / Modelo de Projeto.............................................................................................................12

4.1.1 Diagrama de Blocos.................................................................................................................12

4.1.2 Diagrama de Interação..............................................................................................................13

4.1.3 Modelo de Interface de Blocos..................................................................................................14

4.2 Implementação / Modelo de Implementação.....................................................................................14

5 Teste / Modelo de Teste.......................................................................................................................................14

5.1 Teste de Unidade........................................................................................................................... 14

5.2 Teste de Integração........................................................................................................................ 15

5.3 Teste do Sistema............................................................................................................................ 15

Conclusão................................................................................................................................................................16

Bibliografia.............................................................................................................................................................17

2

Lista de Tabelas e Figuras

Tabela 1: Fases e Modelos do Objectory......................................................................................................6

Figura 1: Coesão de Todos os Modelos com os Casos de Uso........................................................................7

Figura 2: Fase de Análise........................................................................................................................... 7

Figura 3: Esboço de um Diagrama de Casos de Uso......................................................................................8

Figura 4: Descrição de Interface com o Usuário...........................................................................................9

Figura 5: Representação Gráfica dos Diferentes Tipos de Objetos................................................................10

Figura 6: Divisão do Modelo em Subsistemas............................................................................................11

Figura 7: Fase de Construção.................................................................................................................... 12

Figura 8: Diagrama de Interação...............................................................................................................13

Figura 9: Fase de Teste............................................................................................................................ 14

3

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 das

fases descritas pelo Objectory: Análise, Projeto, Construção e Teste, bem como os modelos produzidos por cada

uma 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 by

a 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 Case

concept, that is the base this metodology.

4

Introdução

O desenvolvimento de software orientado a objeto é a grande tendência desses tempos, devido às grandes

vantagens que oferece, como reusabilidade, encapsulamento e extensibilidade. Mas um real aproveitamento

dessas 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 essas

caracterí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. Com

base neste trabalho o leitor será capaz de avaliar esta metodologia, o que pode contribuir na sua escolha de uma

metodologia de desenvolvimento de software orientada a objeto.

5

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 a objeto. O nome Objectory vem de Object Factory, ou seja, “fábrica de objetos” para o desenvolvimento de software. 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êntrica para desenvolvimento de software, que é baseada na interação e colaboração de subsistemas. Esta abordagem foi adotada pelo padrão de telecomunicação SDL (Specification and Description Language). Jacobson passa a enfatizar o desenvolvimento de software baseado em casos de uso, processo este que foi o primeiro exemplo de desenvolvimento baseado em componentes.

Em 1987, com o aprimoramento desse processo de desenvolvimento, Jacobson o nomeia Objectory e acaba fundando a sua própria empresa: a Objectory AB, na Suécia. A metodologia passa a chamar a atenção da indú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 assim melhor 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 de Software 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 Software Corporation em 1995. Junto com seus colegas da Rational, Grady Booch e Jim Rumbaugh, ele desenvolveu a Linguagem Unificada de Modelagem – UML (Unified Modeling Language), que é a linguagem padrão para especificação, visualização, construção e documentação para artefatos de sistema de software. A UML foi oficialmente adotada como padrão pelo Grupo de Gerenciamento de Objetos – OMG (Object Management Group) em 1997.

Atualmente, Jacobson é vice presidente de desenvolvimento de software na Rational, sendo responsável por ajudar a empresa a definir associações e estratégias de produto na área de desenvolvimento de software. Ele també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 de venda: Object-Oriented Software Engineering - A Use Case Driven Approach, The Object Advantage--Business Process Reengineering with Object Technology, and Software Reuse: Architecture, Process, and Organization for Business Success.

2 Visão Geral

A metodologia Objectory descreve todo o ciclo de vida de desenvolvimento, enfatizando o usuário, o processo 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ídaAnálise Especificação dos Requisitos Análise de Requisitos

Análise RigorosaModelo de RequisitosModelo de Análise

Construção Modelo de RequisitosModelo de Análise

ProjetoImplementação

Modelo de ProjetoModelo de Implementação

Teste Modelo de RequisitosModelo de ProjetoModelo de Implementação

Teste de UnidadeTeste de IntegraçãoTeste do Sistema

Modelo de Teste

Tabela 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 uso tentam capturar a funcionalidade do sistema pela representação do que os usuários deveriam ser capazes de fazer com ele. Todos os outros modelos são construídos com base nas considerações feitas para os casos de uso; como conseqüência esses casos proporcionam elos de ligação entre as fases do Objectory.

6

Figura 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 sim iterativamente. Quando o modelo que está sendo usado numa fase possui pontos não esclarecidos, deve-se voltar a fase que gerou o modelo para o esclarecimento desses pontos. A execução de forma iterativa permite que fases ocorram em paralelo.

Esta metodologia tem como argumento que um sistema construído ao redor de exemplos de ações de prová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 o objetivo 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ão descrever o que o sistema faz. A base para esta modelagem são os requisitos dos clientes ou usuários finais para o sistema. Por isso é importante manter um diálogo contínuo com os clientes e possíveis usuários para que se tenha certeza que o sistema a ser construído é o sistema que se quer. Os modelos são construídos de forma a facilitar o entendimento do sistema.

Os modelos desenvolvidos durante a análise são completamente orientados para a aplicação e não para o ambiente de implementação. Eles são modelos “essenciais”, que são independentes de coisas como sistema operacional, linguagem de programação, banco de dados, configuração de hardware. Os modelos baseados em conceitos 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 na construção. O fato de pouca atenção ser dada ao ambiente de implementação garante que a arquitetura resultante seja baseada no próprio problema e não em condições de implementação. Além disso, os modelos de análise permaneceram 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 respectivamente produzem o Modelo de Requisitos e Modelo de Análise.

7

Modelo de Casos de Uso

Modelo de Requisitos

Modelo de Análise

Modelo de Projeto

Modelo de Implementação

Modelo de Teste

Expressado por

Estruturado por

Realizado por

Implementado por

Testado em

Especificação dos

Requisitos

Análise dos Requisitos

Análise Rigorosa

Modelo dos Requisitos

Modelo de Análise

Análise

Figura 2: Fase de Análise

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ão do desenvolvedor do que o cliente quer, e serve como um contrato entre o desenvolvedor e o cliente. É essencial que este modelo seja legível por pessoas que não estejam familiarizadas com orientação a objeto e com objectory, sendo fácil entendimento. Para isso ele deve ser elaborado a partir da perspectiva do usuário. O modelo de requisitos consiste de: Modelo de Casos de Uso, Descrição de Interfaces do Usuário e Modelo de Objetos do Domínio. Já a partir do primeiro modelo elaborado, é possível avaliar se o usuário está satisfeito com o 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 do sistema (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. Um ator não é um usuário, mas o papel que um usuário pode exercer em relação ao sistema. Um usuário é uma pessoa (às vezes um dispositivo, ou outro sistema) que usa o sistema. Diferente de muitos outros objetos, os atores 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 somente ocorre quando o usuário faz alguma coisa no sistema. Uma mesma pessoa pode aparecer como instância de diversos atores. Por exemplo, um sistema pode ter pilotos e passageiros como atores. João pode ser um usuário que às vezes atua no papel de piloto e às vezes como passageiro, desempenhando diferentes casos de uso. Cada ator 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 de transações que possuem um comportamento relacionado, num diálogo com o sistema. Cada caso de uso é uma maneira específica de utilizar o sistema, logo a coleção de casos de uso contém a funcionalidade completa do sistema a ser construído. Cada caso de uso tem uma descrição e o sistema deve ser capaz de executar tudo o que está 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 existe entre eles é representada por uma seta de duplo sentido, representando uma troca de informações. Vejamos o esboço de um modelo de casos de uso para um sistema para uma máquina que recebe embalagens retornáveis em um supermercado. O cliente utiliza o sistema para trocar suas embalagens (garrafas e outros recipientes retornáveis) por tickets para serem descontados no supermercado. Diariamente um operador do sistema pede um relatório e recolhe as embalagens depositadas.

Figura 3: Esboço de um Diagrama de Casos de Uso

8

Cliente

Receber Embalagens

Imprimir Relatório

Recolher Embalagens Depositadas

Operador

Sistema de Recebimento de Embalagens

Nem sempre é fácil identificar se uma funcionalidade deve ser colocada como um caso de uso separado ou como uma variação de um casos de uso existente. Se as diferença são pequenas, é melhor descrever como uma 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 uso sejam identificados da forma apropriada, se estabilizando. Só depois que desta estabilização é que cada caso de uso é descrito em de forma mais detalhada. Até então eles só descreviam o curso básico, a mais importante seqüência para a compreensão do caso de uso. A partir do detalhamento, variações do curso básico e erros que podem ocorrer são descritos nas alternativas de curso.

Um conceito poderoso utilizado para estruturar e relacionar descrições de casos de uso é o “Construção Associada”. 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 de forma compacta, permitindo facilmente mudanças e adição de outras funcionalidades. Importante salientar que o caso “construído” deve compreender um curso completo por si próprio, totalmente independente da seqüência inserida. A descrição original não faz referência a qualquer curso inserido, escapando de compor complexidade ou dependência. Descrevendo o caso de uso independente de qualquer funcionalidade estendida, podemos adicionar novas extensões sem alterar a descrição original.

O conceito de construção associada favorece muito a reutilização, uma das principais vantagens da orientação a objeto.

Quando o sistema é projetado com o foco nos casos de uso ele possui uma importante característica no que se refere à mudanças: quando se deseja mudar o comportamento do sistema, se remodela apropriadamente os atores e os casos de uso. Como toda a arquitetura é controlada pelos casos de uso as mudanças irão se refletir em todos os outros modelos. Nós simplesmente questionamos os usuários sobre o que eles querem mudar (qual caso de 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ótipos de interface facilitam a comunicação com os usuários mostrando o que eles verão quando estiverem executando o caso de uso no sistema que será construído. Pode-se, da forma mais simples, utilizar esboços de interface, ou da forma mais sofisticada, utilizar um software que permita a construção rápida de interfaces para que, com algum código, realize simulações.

O uso de descrição de interfaces reduz a possibilidade de um desentendimento entre o que o usuário quer e o que o analista projeta. Quando se está projetando as interfaces, o futuro usuário deve estar envolvido no processo (casos de uso) para que então, as interfaces reflitam a sua visão lógica do sistema.

Figura 4: Descrição de Interface com o Usuário

3.1.3 Modelo de Objetos do Domínio9

Com a elaboração dos casos de uso, aparecerão objetos que tem relação direta com o ambiente e sobre os quais 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 casos de uso, definindo os conceitos com o a qual o sistema deve trabalhar. A notação é similar a um modelo entidade relacionamento, mostrando instâncias de objetos, classes e associações. Dentre as associações incluem herança e existência (isso é, um objeto mantém referência a outro). O modelo de objetos do domínio pode ser considerado como 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 é de grande 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 um processo mais voltado à estrutura lógica interna do sistema, primeiramente com o desenvolvimento do modelo de análise. Este modelo define a estrutura lógica do sistema de forma independente do ambiente de implementação.

A análise robusta distribui os comportamentos especificados na descrição dos casos de uso entre os objetos 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 o comportamento em operações nesta fase, a maneira mais natural é uma descrição verbal das responsabilidades ou 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 estrutura do sistema, que será robusta por todo o ciclo de vida. Isso significa que as muitas mudanças futuras, vindas do ambiente 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. Mas com o emprego de três diferentes tipos de objetos, a estrutura será muito mais adaptável a mudanças. Os tipos de objetos utilizados na análise são: Objeto Entidade, Objeto de Interface e Objeto de Controle.

Figura 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. Tipicamente sobrevive depois que o caso de uso é terminado. Toda a informação e comportamento que são naturalmente acoplados devem ser colocados em um objeto entidade.

Os objetos entidade normalmente são os primeiros a serem encontrados e estão presentes no modelo de objetos do domínio. Outros além desses são difíceis de serem encontrados. Objetos entidade na maioria das vezes 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. Para uma modelagem correta, é preciso utilizar os casos de uso como guia: somente objetos que podem ser justificados 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.

10

Objeto Entidade Objeto de Interface Objeto de Controle

Para aramazenar informação, objetos entidade utilizam atributos. Cada atributo tem um tipo, que pode ser tipo primitivo de dado, como inteiro ou string, ou pode ser um tipo de dado composto, que é mais complexo e especialmente definido. Para decidir se um pedaço de informação deve ser modelado como uma entidade ou um atributo, devemos analisar como a informação é utilizada. A informação que é manipulada separadamente deve ser modelada como um objeto entidade. A informação que está fortemente relacionada à outras informações e nunca é 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.

Objeto de Interface

Modela comportamento e informação que é dependente de uma interface do sistema. É através desses objetos que os atores se comunicam com o sistema. A tarefa de um objeto de interface é traduzir as ações do ator no sistema em eventos no sistema e traduzir eventos no sistema no qual o ator está interessado em algo apresentável para o ator. Objetos de interface, em outras palavras, descreve a comunicação bidirecional entre o sistema e seus usuários, sendo que estes podem ser humanos ou outros sistemas. Logo, qualquer coisa sobre interface do sistema é colocada em objeto de interface. Um exemplo de objeto de interface é a funcionalidade de uma 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 aos outros 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 unir os outros objetos num caso de uso.

Este tipo de objeto aparece mais freqüentemente e sistemas mais complexos, e na maioria dos casos tem uma 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 diferentes fatores.

Para suportar melhor mudanças de funcionalidade, é importante que os objetos no modelo de análise estejam modelados com seu tipo adequado (entidade, interface ou controle). Dessa forma uma mudança de funcionalidade relacionada a uma informação que é mantida pelo sistema deve afetar somente o objeto entidade que representa esta informação. Da mesma forma, mudanças exigidas na interface afetarão somente objetos de interface e mudanças na funcionalidade envolvendo múltiplos objetos afetarão objetos de controle. Através desse trê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 uma clara visão e entendimento do modelo é necessário agrupar os objetos em um ou mais níveis, dependendo do tamanho 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 o desenvolvimento 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ções funcionais) entre alguns objetos.

Abaixo temos um exemplo de diagrama com divisão em subsistemas. Ele modela parte de um sistema para uma máquina que recebe embalagens retornáveis em um supermercado, citado anteriormente.

11

Pacote Cliente Pacote Alarme e Impressora

Painel do Cliente

Dispositivo de Alarme

Impressora

Receptor de Itens

Figura 6: Divisão do Modelo em Subsistemas

4 Construção

Qual o propósito da fase de construção? O código fonte não pode ser escrito diretamente a partir do modelo de análise, uma vez que ele já descreve os objetos no sistema e como eles se relacionam? Existem três razõ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 do ambiente de implementação tem que ser levadas em conta. O modelo de implementação é a atual implementação (código fonte) do sistema.

Figura 7: Fase de Construção

4.1 Projeto / Modelo de Projeto

O principal trabalho realizado no projeto é a adaptação do sistema ao ambiente de implementação que será 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 modelo de 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 de desempenho ou processos concorrentes.

O modelo de projeto consiste de três elementos: Diagrama de Blocos, Diagrama de Interações e Modelo de Interface de Blocos.

4.1.1 Diagrama de Blocos

12


Projeto Implementação

Modelo de Projeto


Processo de Construção

Modelo de Análise

As estruturas com as quais nós trabalhamos no diagrama de blocos são basicamente as mesmas do modelo de análise, mas a visão muda já que é um passo na direção da implementação. Um bloco é um objeto de projeto. 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 de projeto, acaba-se inserindo alterações, por exemplo: um bloco pode ser dividido em dois para fins de desempenho, ou novos blocos podem ser adicionados para servirem de interface com um gerenciador de banco de dados.

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 de um 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, a borda do sistema, é também representada por uma coluna mais à esquerda. Ela representa a interface para tudo o que está fora do diagrama de blocos (atores) e pode consequentemente corresponder a diferentes interfaces do sistema.

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 a linguagem de programação que será utilizada, para facilitar a migração para a implementação. O texto descreve o que está acontecendo numa parte particular caso de uso, chamada operação. A coluna, portanto o bloco, na qual 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.

13

Borda do Sistema

Painel do Cliente

Receptor de Itens

Base de Recibos

Item de Depósito

Impressora

iniciar

criar

ativar

novo itemItem( )

existe( )

inserir( item)incr

recibo

Imprimir recibo

Imprimir( logo, data)

imprimir

obternome

obter valor

Imprimir( nome, qtd, valor)

destruir

Figura 8: Diagrama de InteraçãoNo diagrama está a representação de um dos casos de uso do sistema de sistema de recebimento de

embalagens, citado anteriormente. O caso de uso começa quando o cliente pressiona o botão “Iniciar”. O bloco painel do cliente então ativa os sensores que são externos ao sistema. Agora o cliente pode iniciar o abastecimento de embalagens retornáveis. Isto é resolvido pelo comando DO...WHILE que termina quando o cliente requisita o recibo. Os itens são checados neste loop. Se o item é aceitável, nós incrementamos o número de 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 deve pegar um bloco e todos os diagramas de interação onde ele aparece, e a partir deles extrair as todas as operações que 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 modelo de 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ódigo fonte, que nas linguagens de programação orientadas a objeto é representada por uma classe. A meta é que as classes sejam robustas e altamente reutilizáveis. Se uma classe oferece funcionalidade similar à outra, elas devem estar relacionadas por herança. As classes devem ter também alto grau de coesão, oferecendo funcionalidades 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ão exatamente esse o caso. O real desenvolvimento é um processo incremental, e freqüentemente muitas iterações devem 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ão custosos, principalmente porque muitos defeitos não são detectados até o desenvolvimento. Uma abordagem bem 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 afinal representam o que é desejado para o sistema. Os testes do sistema são realizados em três níveis, que serão vistos abaixo.

Figura 9: Fase de Teste

14


Teste de Unidade

Teste de Integração

Modelo de Teste

Processo de Teste


Modelo de Projeto

Teste do Sistema

5.1 Teste de Unidade

Este tipo de teste consiste em examinar o sistema a partir de suas menores partes, como as operações de uma 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 de interface de blocos que especifica o comportamento que é esperado para cada unidade de código.

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ão se comunicando e colaborando corretamente para a resolução do caso de uso. Este teste é guiado pelo caso de uso que se está testando no momento, observando a devida descrição que está documentada no modelo de casos de 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 o teste: parte que estava sendo testada, tipo de teste realizado, dados utilizados, resultado obtido e avaliação (falho ou OK). Este modelo é especialmente importante quando o sistema está sendo desenvolvido em equipe. Os outros profissionais (analistas e programadores) poderão consultar o modelo de testes para auxiliar no descobrimento da causa do erro.

Como os testes se iniciam por pequenas partes e vão crescendo com tempo, é perfeitamente possível que esta 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 de caixa preta, aplicando-se diversas técnicas diferentes de teste. Assim se tem uma melhor garantia contra erros.

15

Conclusão

A metodologia de desenvolvimento de software Objectory realmente favorece a produção de um sistema

com as caraterísticas da orientação a objeto, desde a análise até os testes. Porém, a metodologia parece se basear

sempre na construção de um novo sistema, ainda não existente. Ela não oferece uma descrição explícita (pelo

menos 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 tenha

surgido no meio das telecomunicações, onde a maioria dos sistemas é algo novo e inédito. Ele foi

gradativamente adaptado para as áreas de negócios menores. Mas não se pode afirmar que em um dos livros de

autoria do Jacobson, sobre Objectory, não haja alguma descrição de método para adaptação de sistemas

existentes.

Entre tanto, Objectory é uma metodologia que deve ser muito leva em consideração. Devido à sua técnica

de desenvolvimento, sempre centrada nos casos de uso em todas as fases, tende a garantir um sistema consiste e

coerente, que não se desvia de seus objetivos. Além disso, esta metodologia favorece o desenvolvimento em

equipe, pois permite que as fases de desenvolvimento ocorram em paralelo, aumentando a produtividade. Isto se

deve 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 é muito

envolvido, não de forma formal como em entrevistas, mas de forma muito sinérgica, quase como se os usuários

fizessem parte da equipe de desenvolvimento. Isso é possível devido a não utilização de termos técnicos na fase

de análise e sim de termos do usuário. Com esta forma de análise é menor as chances de erros e se acabar

construindo um sistema que não é o desejado pelos usuários.

16

Bibliografia

1. 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.

17

Objectory

Technology

Transcript of Objectory