s O documento descreve a metodologia Objectory para desenvolvimento de software orientado a objetos. s A metodologia inclui fases de análise, construção e teste. s Na fase de análise, os requisitos são modelados em casos de uso, interfaces e domínio de objetos. Objetos são categorizados e agrupados em subsistemas.
1. 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
2. Sumário
s Introdução
s 1 Histórico
s 2 Visão geral
s 3 Análise
s 4 Construção
s 5 Teste
s Conclusão
2
3. Introdução
s O desenvolvimento de software Orientado a
Objeto é a grande tendência
s É necessário uma metodologia de
desenvolvimento que apoie a orientação a
objeto
s Uma das metodologias orientadas a objeto
existentes: Objectory
3
4. 1 Histórico
s 1967: O Dr. Ivar Jacobson desenvolve a
abordagem da Arquitetura Cêntrica
4
5. 1 Histórico
s 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
6. 1 Histórico
s 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
s 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
7. 1 Histórico
s 1995: A companhia de Jacobson, Objectory
AB, acaba se fundindo com a empresa
Rational Software Corporation
s Junto Grady Booch e Jim Rumbaugh, ele
desenvolveu UML
7
8. 2 Visão Geral
s 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
9. 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
10. 3 Análise
s 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
s 3.2 Análise Robusta / Modelo de Análise
– 3.2.1 Os Três Tipos de Objetos
– 3.2.2 Subsistemas
10
11. 3 Análise
s Especificar e definir o sistema que será
construído
s A base para esta modelagem são os
requisitos dos clientes ou usuários finais
s Orientados para a aplicação e não para o
ambiente de implementação
11
12. 3 Análise
Análise
Especificação Análise dos Análise
dos Requisitos Requisitos Rigorosa
Modelo dos Modelo de
Requisitos Análise
12
13. 3.1 Análise dos Requisitos / Modelo
dos Requisitos
s Delimita o sistema e define quais as suas
funcionalidades
s É visão do desenvolvedor do que o cliente
quer
s É essencial que este modelo seja legível por
pessoas leigas
13
14. 3.1.1 Modelo de Casos de Uso
s Baseado em atores e casos de uso
s Atores representam tudo o que interage com
o sistema
s Cada caso de uso é uma maneira específica
de utilizar o sistema
s Os casos de uso são realizados por atores no
sistema
14
15. 3.1.1 Modelo de Casos de Uso
Sistema de Recebimento de Embalagens
Receber Imprimir
Embalagens Relatório
Cliente
Recolher Embalagens Operador
Depositadas
15
16. 3.1.2 Descrição de Interfaces do
Usuário
s Protótipos de interface facilitam a
comunicação com os usuários
s Mostram o que os usuários verão quando
estiverem executando o caso de uso
s Reduz a possibilidade de um
desentendimento entre o que o usuário quer
e o que o analista projeta
16
18. 3.1.3 Modelo de Objetos do Domínio
s Defini os conceitos com o a qual o sistema
deve trabalhar
s Mostra instâncias de objetos, classes e
associações
Cliente
Venda
18
19. 3.2 Análise Robusta / Modelo de
Análise
s Processo mais voltado à estrutura lógica
interna do sistema
s Independe do ambiente de implementação
s Distribui os comportamentos dos casos de
uso entre os objetos no modelo
s O modelo de análise representa a mais
estável e manutenível estrutura do sistema
19
20. 3.2.1 Os Três Tipos de Objetos
s 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
20
21. 3.2.1 Os Três Tipos de Objetos
s 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 21
22. 3.2.1 Os Três Tipos de Objetos
s 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
Objeto de Controle
23. 3.2.2 Subsistemas
s Agrupar os objetos em um ou mais níveis
s Para obter uma clara visão e entendimento
do modelo
s Reduzir a complexidade, organizando o
desenvolvimento e manutenção da estrutura
s A divisão em subsistemas deve ser baseada
na funcionalidade do sistema e no forte
acoplamento entre objetos
23
24. 3.2.2 Subsistemas
Pacote Cliente Pacote Alarme e Impressora
Receptor de Itens Dispositivo de Alarme
Painel do Cliente Impressora
24
25. 4 Construção
s 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
s 4.2 Implementação / Modelo de
Implementação
25
26. 4 Construção
s 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
27. 4 Construção
Processo de Construção
Modelo de
Requisitos
Projeto Implementação
Modelo de
Análise
Modelo de Modelo de
Projeto Implementação
27
28. 4.1 Projeto / Modelo de Projeto
s Adaptação do sistema ao ambiente de
implementação que será utilizado
s Refinar o modelo de análise o suficiente para
que ele facilite a escrita do código fonte
s Mudanças ocorrem devido a um banco de
dados relacional, um ambiente distribuído,
requisitos de desempenho ou processos
concorrentes
28
29. 4.1.1 Diagrama de Blocos
s Um bloco é um objeto de projeto
s Diferentes tipos de blocos podem ser usados
s Inicialmente, cada objeto da análise é
simplesmente transformado em um bloco
Cliente Venda
29
30. 4.1.2 Diagrama de Interação
s Descrever como cada caso de uso é
manipulado pela interação dos objetos
s Interação é o envio ou recebimento de um
estímulo de um bloco para outro
s Diferentes objetos colaboram para a
resolução de um caso de uso
30
31. 4.1.2 Diagrama de Interação
Borda do Painel do Receptor Base de Item de Impressora
Sistema Cliente de Itens Recibos Depósito
iniciar
criar
ativar
novo item
Item( )
existe( )
inserir( item)
incr
obter
nome
obter valor
31
recibo
32. obter
nome
4.1.2 Diagrama de Interação obter valor
recibo
Imprimir Imprimir( logo, data)
recibo
imprimir
Imprimir( nome, qtd, valor)
destruir
32
33. 4.1.3 Modelo de Interface de Blocos
s Apresenta toda a funcionalidade que cada
bloco deve oferecer
s Um retrato completo de cada bloco
s Extrair as todas as operações que são
requisitadas
s Examinar todos os diagramas de interação
33
34. 4.2 Implementação / Modelo de
Implementação
s É feita a codificação do sistema
s A base para a implementação é o modelo de
projeto
s O modelo de implementação consiste do
código fonte acompanhado de seus
comentários
s Transformação de cada bloco do modelo de
projeto em uma ou mais unidades de código
fonte
34
35. 5 Teste
s 5 Teste
– 5.1 Teste de unidade
– 5.2 Teste de integração
– 5.3 Teste do sistema
– 5.4 Modelo de Teste
35
36. 5 Teste
s Verifica se o sistema que está sendo
construído está correto
s Os testes também são guiados pelos casos
de uso
s Uma abordagem bem organizada e
disciplinada é necessária para aumentar a
qualidade do sistema
36
37. 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
38. 5.1 Teste de Unidade
s Examinar o sistema a partir de suas menores
partes
s Essas partes são operações de uma classe,
e as próprias classes
s A base para estes dois testes é o modelo de
projeto, em especial o modelo de interface de
blocos
38
39. 5.2 Teste de Integração
s Reunir todas as classes envolvidas num
determinado caso de uso, testadas no teste
de unidade
s Verificar se os objetos envolvidos estão se
comunicando e colaborando corretamente
para a resolução do caso de uso
s Este teste é guiado pelo caso de uso que se
está testando no momento
39
40. 5.3 Teste do Sistema
s Os casos de uso são testados em conjunto
s Verifica se casos de uso que se relacionam
estão de acordo
s É o teste final do sistema
=
40
41. 5.4 Modelo de Teste
s Resultado documentado dos testes
s Relata todo o teste: parte que estava sendo
testada, tipo de teste realizado, dados
usados, resultado obtido e avaliação (falho
ou ok)
s Importante quando o sistema está sendo
desenvolvido em equipe
41
42. Conclusão
s Realmente favorece a produção de um
sistema com as caraterísticas da orientação a
objeto
s Centrada nos casos de uso em todas as
fases, tende a garantir um sistema consiste e
coerente
s Esta metodologia favorece o
desenvolvimento em equipe, pois permite
que as fases ocorram em paralelo
42
43. Ícones Voltar
s Cliente ou Usuário Final
– Pessoa que irá interagir com o sistema que
está sendo desenvolvido
s Desenvolvedor
– Pessoa da equipe de desenvolvimento
– Pode ser Analista, Projetista, Programador ou
Gerente de Projeto
s Sistema
– Sistema operacional
– Ou Sistema que está sendo desenvolvido 43
44. Ícones Voltar
s Banco de Dados
– Banco de dados relacional ou de outro tipo
– Ou arquivo para armazenamento de dados
s Ferramenta de Desenvolvimento
– Linguagem de programação
– Ferramenta case
s Arquivo de Código Fonte
– Código do sistema
– Código de partes do sistema (classes, etc.)
44
45. Ícones Voltar
s Classes e Objetos
– Arquitetura baseada em componentes
– Possui reusabilidade e extensibilidade
s Requisitos de Desempenho
– Tempo máximo para realizar uma tarefa
– Capacidade de armazenamento e
manipulação de dados
s Modelo de Teste
– Relatório sobre determinado teste
– Descrição e resultado dos testes 45
46. Empresas Voltar
s Rational > www.rational.com.br
– UML > www.rational.com/worldwide/brazil/port_uml.jsp
– Jacobson > www.rational.com/media/news/presskit
/amigos_bios.pdf
s Ericsson > www.ericsson.com
s SDL > www.sdl.com
46