SlideShare une entreprise Scribd logo
1  sur  18
Télécharger pour lire hors ligne
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                  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             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                       Operado
                                                 Depositadas                               r


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

Contenu connexe

Similaire à Objectory

O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...Rogério Batista
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLAnnkatlover
 
The framework and refinement - About Face II
The framework and refinement - About Face IIThe framework and refinement - About Face II
The framework and refinement - About Face IIArthur Jacobsen Klas
 
Monografia eng soft1_halan
Monografia eng soft1_halanMonografia eng soft1_halan
Monografia eng soft1_halanHalan Ridolphi
 
Design Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e FlexívelDesign Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e FlexívelRyan Padilha
 
Aula1 - Modelagem de Sistemas Orientada a Objetos
Aula1 - Modelagem de Sistemas Orientada a ObjetosAula1 - Modelagem de Sistemas Orientada a Objetos
Aula1 - Modelagem de Sistemas Orientada a ObjetosLeandro Rezende
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Softwareelliando dias
 
Fabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.AprendidasFabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.AprendidasAnnkatlover
 

Similaire à Objectory (20)

Objectory
ObjectoryObjectory
Objectory
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Apostila UML
Apostila UMLApostila UML
Apostila UML
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SL
 
The framework and refinement - About Face II
The framework and refinement - About Face IIThe framework and refinement - About Face II
The framework and refinement - About Face II
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Padrões de projeto
Padrões de projetoPadrões de projeto
Padrões de projeto
 
Monografia eng soft1_halan
Monografia eng soft1_halanMonografia eng soft1_halan
Monografia eng soft1_halan
 
Aula 03
Aula 03Aula 03
Aula 03
 
Design Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e FlexívelDesign Pattern MVC – Arquitetura de Software Coesa e Flexível
Design Pattern MVC – Arquitetura de Software Coesa e Flexível
 
Aula1 - Modelagem de Sistemas Orientada a Objetos
Aula1 - Modelagem de Sistemas Orientada a ObjetosAula1 - Modelagem de Sistemas Orientada a Objetos
Aula1 - Modelagem de Sistemas Orientada a Objetos
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Software
 
Análise e Modelagem com UML
Análise e Modelagem com UMLAnálise e Modelagem com UML
Análise e Modelagem com UML
 
O emprego do_rup_na_uml_-_trabalho_poo_2012
O emprego do_rup_na_uml_-_trabalho_poo_2012O emprego do_rup_na_uml_-_trabalho_poo_2012
O emprego do_rup_na_uml_-_trabalho_poo_2012
 
Fabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.AprendidasFabrica.Software.Concepcao.Licoes.Aprendidas
Fabrica.Software.Concepcao.Licoes.Aprendidas
 
Métodos ágeis
Métodos ágeisMétodos ágeis
Métodos ágeis
 

Plus de Mauricio Volkweis Astiazara

Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Mauricio Volkweis Astiazara
 
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Mauricio Volkweis Astiazara
 
Comparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-LearningComparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-LearningMauricio Volkweis Astiazara
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeMauricio Volkweis Astiazara
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeMauricio Volkweis Astiazara
 

Plus de Mauricio Volkweis Astiazara (20)

Como Programar Melhor em Java
Como Programar Melhor em JavaComo Programar Melhor em Java
Como Programar Melhor em Java
 
Sistemas Imunológicos Artificiais
Sistemas Imunológicos ArtificiaisSistemas Imunológicos Artificiais
Sistemas Imunológicos Artificiais
 
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
 
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
 
Comparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-LearningComparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-Learning
 
Classificador de Documentos Naïve Bayes
Classificador de Documentos Naïve BayesClassificador de Documentos Naïve Bayes
Classificador de Documentos Naïve Bayes
 
Visão Computacional
Visão ComputacionalVisão Computacional
Visão Computacional
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre Saúde
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre Saúde
 
Processamento de Imagens
Processamento de ImagensProcessamento de Imagens
Processamento de Imagens
 
Percepção, Movimento e Ação
Percepção, Movimento e AçãoPercepção, Movimento e Ação
Percepção, Movimento e Ação
 
Memória e Aprendizagem
Memória e AprendizagemMemória e Aprendizagem
Memória e Aprendizagem
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
Testes de Sistema
Testes de SistemaTestes de Sistema
Testes de Sistema
 
Telefonia Móvel
Telefonia MóvelTelefonia Móvel
Telefonia Móvel
 
Telefonia Móvel
Telefonia MóvelTelefonia Móvel
Telefonia Móvel
 
Realidade Virtual
Realidade VirtualRealidade Virtual
Realidade Virtual
 
Protótipo de Simulador de Elevadores
Protótipo de Simulador de ElevadoresProtótipo de Simulador de Elevadores
Protótipo de Simulador de Elevadores
 
Protótipo de Simulador de Elevadores
Protótipo de Simulador de ElevadoresProtótipo de Simulador de Elevadores
Protótipo de Simulador de Elevadores
 
Planejamento de Informática
Planejamento de InformáticaPlanejamento de Informática
Planejamento de Informática
 

Objectory

  • 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 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. 2
  • 3. 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
  • 4. Lista de Tabelas e Figuras 4
  • 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 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
  • 6. 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
  • 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 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
  • 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 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
  • 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ã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 Operado Depositadas r 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 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 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
  • 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 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 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. 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
  • 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ã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
  • 17. 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
  • 18. 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