UNIVERSIDADE LUTERANA DO BRASIL

COMUNIDADE EVANGÉLICA LUTERANA “SÃO PAULO”

Reconhecida pela Portaria Ministerial nº 681 de 07/12/89 – DOU de 11/12/89
Campus Torres

Objectory

Engenharia de Software II

Aluno: Mauricio Volkweis Astiazara

Aluno: Marcelo Waihrich Souza
Professor: Adriana Roma
Torres, Outubro de 2001 1
Sumário

■ Introdução
■ 1 Histórico
■ 2 Visão geral
■ 3 Análise
■ 4 Construção
■ 5 Teste
■ Conclusão

2
Introdução

■ O desenvolvimento de software Orientado a

Objeto é a grande tendência
■ É necessário uma metodologia de
desenvolvimento que apoie a orientação a
objeto
■ Uma das metodologias orientadas a objeto
existentes: Objectory

3
1 Histórico

■ 1967: O Dr. Ivar Jacobson desenvolve a

abordagem da Arquitetura Cêntrica

4
1 Histórico

■ 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

5
1 Histórico

■ 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
■ 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
6
1 Histórico

■ 1995: A companhia de Jacobson, Objectory

AB, acaba se fundindo com a empresa
Rational Software Corporation
■ Junto Grady Booch e Jim Rumbaugh, ele
desenvolveu UML

7
2 Visão Geral

■ Fases e Modelos
Fase Entrada Processos Saída
Análise Especificação de Análise de Modelo de Requisitos
Requisitos Requisitos Modelo de Análise
Análise Rigorosa
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 Teste do Sistema
Implementação

8
2 Visão Geral

Modelo de Casos
de Uso

Expressado Realizado por Testado em

por
Estruturado Implementado
por por

Modelo de Modelo de Modelo de Modelo de Modelo de

Requisitos Análise Projeto Implementação Teste

9
3 Análise

■ 3.1 Análise de Requisitos / Modelo de

Requisitos
– 3.1.1 Modelo de Casos de Uso
– 3.1.2 Descrição de Interfaces do Usuário
– 3.1.3 Modelo de Domínio de Objetos
■ 3.2 Análise Robusta / Modelo de Análise
– 3.2.1 Os Três Tipos de Objetos
– 3.2.2 Subsistemas

10
3 Análise

■ Especificar e definir o sistema que será

construído
■ A base para esta modelagem são os
requisitos dos clientes ou usuários finais
■ Orientados para a aplicação e não para o
ambiente de implementação

11
3 Análise

Análise

Especificação Análise dos Análise

dos Requisitos Requisitos Rigorosa

Modelo dos Modelo de

Requisitos Análise

12
3.1 Análise dos Requisitos / Modelo
dos Requisitos
■ Delimita o sistema e define quais as suas
funcionalidades
■ É visão do desenvolvedor do que o cliente
quer
■ É essencial que este modelo seja legível por
pessoas leigas

13
3.1.1 Modelo de Casos de Uso

■ Baseado em atores e casos de uso

■ Atores representam tudo o que interage com
o sistema
■ Cada caso de uso é uma maneira específica
de utilizar o sistema
■ Os casos de uso são realizados por atores no
sistema

14
3.1.1 Modelo de Casos de Uso

Sistema de Recebimento de Embalagens

Receber Imprimir
Embalagens Relatório
Cliente

Recolher Embalagens Operador

Depositadas

15
3.1.2 Descrição de Interfaces do
Usuário
■ Protótipos de interface facilitam a
comunicação com os usuários
■ Mostram o que os usuários verão quando
estiverem executando o caso de uso
■ Reduz a possibilidade de um
desentendimento entre o que o usuário quer
e o que o analista projeta

16
3.1.2 Descrição de Interfaces do
Usuário

17
3.1.3 Modelo de Objetos do Domínio

■ Defini os conceitos com o a qual o sistema

deve trabalhar
■ Mostra instâncias de objetos, classes e
associações

Cliente

Venda

18
3.2 Análise Robusta / Modelo de
Análise
■ Processo mais voltado à estrutura lógica
interna do sistema
■ Independe do ambiente de implementação
■ Distribui os comportamentos dos casos de
uso entre os objetos no modelo
■ O modelo de análise representa a mais
estável e manutenível estrutura do sistema

19
3.2.1 Os Três Tipos de Objetos

■ Objeto Entidade
– informação do sistema que deve ser armazenada
por algum período de tempo
– sobrevive depois que o caso de uso é terminado
– estão presentes no modelo de objetos do domínio

20
3.2.1 Os Três Tipos de Objetos

■ Objeto de Interface
– através desses objetos que os atores se
comunicam com o sistema
– descreve a comunicação bidirecional entre o
sistema e seus usuários, estes podem ser
humanos ou outros sistemas

21
3.2.1 Os Três Tipos de Objetos

■ Objeto de Controle
– Modela funcionalidades que não estão
naturalmente ligadas aos outros tipos de objetos
– consiste em operar diferentes objetos entidade,
realizar algum processo e retornar o resultado
para um objeto de interface

22
3.2.2 Subsistemas

■ Agrupar os objetos em um ou mais níveis

■ Para obter uma clara visão e entendimento
do modelo
■ Reduzir a complexidade, organizando o
desenvolvimento e manutenção da estrutura
■ A divisão em subsistemas deve ser baseada
na funcionalidade do sistema e no forte
acoplamento entre objetos

23
3.2.2 Subsistemas

Pacote Cliente Pacote Alarme e Impressora

Receptor de Itens Dispositivo de Alarme

Painel do Cliente Impressora

24
4 Construção

■ 4.1 Projeto / Modelo de Projeto

– 4.1.1 Diagrama de blocos
– 4.1.2 Diagrama de interações
– 4.1.3 Modelo de interface de blocos
■ 4.2 Implementação / Modelo de
Implementação

25
4 Construção

■ Existem três razões principais para o

processo de construção:
– O modelo de análise não é formal o suficiente.
devemos refinar os objetos
– Deve ser feita uma adaptação para o atual
ambiente de implementação
– Fazer a validação interna do resultado da análise

26
4 Construção

Proc
Modelo de
Requisitos

Projeto

Modelo de
Análise
27
4.1 Projeto / Modelo de Projeto

■ Adaptação do sistema ao ambiente de

implementação que será utilizado
■ Refinar o modelo de análise o suficiente para
que ele facilite a escrita do código fonte
■ Mudanças ocorrem devido a um banco de
dados relacional, um ambiente distribuído,
requisitos de desempenho ou processos
concorrentes

28
4.1.1 Diagrama de Blocos

■ Um bloco é um objeto de projeto

■ Diferentes tipos de blocos podem ser usados
■ Inicialmente, cada objeto da análise é
simplesmente transformado em um bloco

Cliente Venda

29
4.1.2 Diagrama de Interação

■ Descrever como cada caso de uso é

manipulado pela interação dos objetos
■ Interação é o envio ou recebimento de um
estímulo de um bloco para outro
■ Diferentes objetos colaboram para a
resolução de um caso de uso

30
4.1.2 Diagrama de Interação

Borda do Painel do Receptor

Sistema Cliente de Itens

iniciar

criar
ativar

novo item
Item( )
31
 ativar

4.1.2 Diagrama
novo item de Interação
Item( )

inserir(

32
4.1.3 Modelo de Interface de Blocos

■ Apresenta toda a funcionalidade que cada

bloco deve oferecer
■ Um retrato completo de cada bloco
■ Extrair as todas as operações que são
requisitadas
■ Examinar todos os diagramas de interação

33
4.2 Implementação / Modelo de
Implementação
■ É feita a codificação do sistema
■ A base para a implementação é o modelo de
projeto
■ O modelo de implementação consiste do
código fonte acompanhado de seus
comentários
■ Transformação de cada bloco do modelo de
projeto em uma ou mais unidades de código
fonte

34
5 Teste

■ 5 Teste
– 5.1 Teste de unidade
– 5.2 Teste de integração
– 5.3 Teste do sistema
– 5.4 Modelo de Teste

35
5 Teste

■ Verifica se o sistema que está sendo

construído está correto
■ Os testes também são guiados pelos casos
de uso
■ Uma abordagem bem organizada e
disciplinada é necessária para aumentar a
qualidade do sistema

36
5 Teste

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

37
5.1 Teste de Unidade

■ Examinar o sistema a partir de suas menores

partes
■ Essas partes são operações de uma classe,
e as próprias classes
■ A base para estes dois testes é o modelo de
projeto, em especial o modelo de interface de
blocos

38
5.2 Teste de Integração

■ Reunir todas as classes envolvidas num

determinado caso de uso, testadas no teste
de unidade
■ 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

39
5.3 Teste do Sistema

■ Os casos de uso são testados em conjunto

■ Verifica se casos de uso que se relacionam
estão de acordo
■ É o teste final do sistema

=
40
5.4 Modelo de Teste

■ Resultado documentado dos testes

■ Relata todo o teste: parte que estava sendo
testada, tipo de teste realizado, dados
usados, resultado obtido e avaliação (falho
ou ok)
■ Importante quando o sistema está sendo
desenvolvido em equipe

41
Conclusão

■ Realmente favorece a produção de um

sistema com as caraterísticas da orientação a
objeto
■ Centrada nos casos de uso em todas as
fases, tende a garantir um sistema consiste e
coerente
■ Esta metodologia favorece o
desenvolvimento em equipe, pois permite
que as fases ocorram em paralelo
42
Ícones Voltar

■ Cliente ou Usuário Final

– Pessoa que irá interagir com o sistema que está
sendo desenvolvido
■ Desenvolvedor
– Pessoa da equipe de desenvolvimento
– Pode ser Analista, Projetista, Programador ou
Gerente de Projeto
■ Sistema
– Sistema operacional
– Ou Sistema que está sendo desenvolvido
43
Ícones Voltar

■ Banco de Dados
– Banco de dados relacional ou de outro tipo
– Ou arquivo para armazenamento de dados
■ Ferramenta de Desenvolvimento
– Linguagem de programação
– Ferramenta case
■ Arquivo de Código Fonte
– Código do sistema
– Código de partes do sistema (classes, etc.)
44
Ícones Voltar

■ Classes e Objetos
– Arquitetura baseada em componentes
– Possui reusabilidade e extensibilidade
■ Requisitos de Desempenho
– Tempo máximo para realizar uma tarefa
– Capacidade de armazenamento e manipulação de
dados
■ Modelo de Teste
– Relatório sobre determinado teste
– Descrição e resultado dos testes
45
Empresas Voltar

■ Rational > www.rational.com.br

– UML > www.rational.com/worldwide/brazil/port_uml.jsp
– Jacobson > www.rational.com/media/news/presskit
/amigos_bios.pdf

■ Ericsson > www.ericsson.com

■ SDL > www.sdl.com

46