1

UNIVERSIDADE LUTERANA DO BRASILCOMUNIDADE 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

2

Sumário

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

3

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

Introdução

4

1 Histórico

1967: O Dr. Ivar Jacobson desenvolve a

abordagem da Arquitetura Cêntrica

5

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

6

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

7

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

8

2 Visão Geral

Fases e ModelosFase Entrada Processos Saída

Análise Especificação deRequisitos

Análise deRequisitosAnálise Rigorosa

Modelo de RequisitosModelo de Análise

Construção Modelo de RequisitosModelo de Análise

ProjetoImplementação

Modelo de ProjetoModelo deImplementação

Teste Modelo de RequisitosModelo de ProjetoModelo deImplementação

Teste de UnidadeTeste de IntegraçãoTeste do Sistema

Modelo de Teste

9

2 Visão Geral

Modelo de Casosde Uso

Modelo deRequisitos

Modelo deAnálise

Modelo deProjeto

Modelo deImplementação

Modelo deTeste

Expressadopor

Estruturadopor

Realizado por

Implementadopor

Testado em

10

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

11

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

12

3 Análise

Especificaçãodos Requisitos

Análise dosRequisitos

AnáliseRigorosa

Modelo dosRequisitos

Modelo deAnálise

Análise

13

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

14

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

15

3.1.1 Modelo de Casos de Uso

Cliente

ReceberEmbalagens

ImprimirRelatório

Recolher EmbalagensDepositadas

Operador

Sistema de Recebimento de Embalagens

16

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

17

3.1.2 Descrição de Interfaces do Usuário

18

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

19

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

20

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

Objeto Entidade

21

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

Objeto de Interface

22

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

Objeto de Controle

23

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

24

3.2.2 Subsistemas

Pacote Cliente Pacote Alarme e Impressora

Painel do Cliente

Dispositivo de Alarme

Impressora

Receptor de Itens

25

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

26

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

27

4 Construção

Modelo deRequisitos

Projeto Implementação

Modelo deProjeto

Modelo deImplementação

Processo de Construção

Modelo deAnálise

28

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

29

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

30

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

31

4.1.2 Diagrama de Interação

Borda doSistema

Painel doCliente

Receptorde Itens

Base deRecibos

Item deDepósito

Impressora

iniciar

criar

ativar

novo itemItem( )

existe( )

inserir( item)incr

obternome

obter valor

32

4.1.2 Diagrama de Interação

recibo

Imprimirrecibo

Imprimir( logo, data)

imprimir

Imprimir( nome, qtd, valor)

destruir

33

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

34

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

35

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

36

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

37

5 Teste

Modelo deRequisitos

Teste deUnidade

Teste deIntegração

Modelo deTeste

Processo de Teste

Modelo deImplementação

Modelo deProjeto

Teste doSistema

38

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

39

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

40

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

=

41

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

42

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