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

2
 Sumário
Lista de Tabelas e Figuras.........................................................................................................................................4

MERGEFORMAT....................................................................................................................................................5

MERGEFORMAT....................................................................................................................................................6

1 Histórico.................................................................................................................................................................7

2 Visão Geral.............................................................................................................................................................7

3 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.........................................................................................................................12
4 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...............................................................................15
5 Teste / Modelo de Teste.......................................................................................................................................15

5.1 Teste de Unidade........................................................................................................................15

5.2 Teste de Integração....................................................................................................................16
5.3 Teste do Sistema........................................................................................................................16
Conclusão................................................................................................................................................................17

Bibliografia.............................................................................................................................................................18

3
Lista de Tabelas e Figuras

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

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

6
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í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 Sistema

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.

7
 Modelo de
Casos de Uso

Expressado por Realizado por Testado em

Estruturado por Implementado

por

Modelo de Modelo de Modelo de Modelo de Modelo de

Requisitos Análise Projeto Implementação Teste

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.
Análise

Especificação Análise dos Análise

dos Requisitos Rigorosa
Requisitos

Modelo dos Modelo de

Requisitos Análise

Figura 2: Fase de Análise

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

Sistema de Recebimento de Embalagens

Receber Imprimir
Embalagens Relatório
Cliente

Recolher Embalagens Operador

Depositadas

Figura 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 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
9
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.

CONTROLE PATRIMONIAL - Mombelli & Cia Ltda

TÍTULOS

MENSAGENS

TECLAS DE FUNÇÕES

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

3.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 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
10
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.

Objeto Entidade Objeto de Interface 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.
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.
11
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.

Pacote Cliente Pacote Alarme e Impressora

Receptor de Itens Dispositivo de Alarme

Painel do Cliente Impressora

Figura 6: Divisão do Modelo em Subsistemas

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

Processo de Construção

Modelo de
Requisitos

Projeto Implementação

Modelo de
Análise

Modelo de Modelo de
Projeto Implementação

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

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.
13
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.
Borda do Painel do Receptor de Base de Item de Impressora
Sistema Cliente Itens Recibos Depósito

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
 No 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.
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 Teste

Figura 9: Fase de Teste

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.

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

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

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

18