A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Objectory Engenharia de Software II Aluno: Mauricio Volkweis Astiazara

Apresentações semelhantes


Apresentação em tema: "Objectory Engenharia de Software II Aluno: Mauricio Volkweis Astiazara"— Transcrição da apresentação:

1 Objectory Engenharia de Software II Aluno: Mauricio Volkweis Astiazara
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

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

3 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

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 Modelos

9 2 Visão Geral Modelo de Casos de Uso Modelo de Requisitos Análise
Projeto Implementação Teste Expressado por Estruturado Realizado por Implementado 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ção dos Requisitos Análise dos Requisitos Análise
Rigorosa Modelo dos Modelo de

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 Receber Embalagens Imprimir
Relatório Recolher Embalagens Depositadas 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

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

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

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

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

32 4.1.2 Diagrama de Interação

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 de Requisitos Teste de Unidade Integração Teste
Processo de Teste Implementação Projeto Teste do Sistema

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

43 Ícones Cliente ou Usuário Final Desenvolvedor Sistema
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

44 Ícones Banco de Dados Ferramenta de Desenvolvimento
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.)

45 Ícones Classes e Objetos Requisitos de Desempenho Modelo de Teste
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

46 Empresas Rational > www.rational.com.br
Voltar Rational > UML > Jacobson > Ericsson > SDL >


Carregar ppt "Objectory Engenharia de Software II Aluno: Mauricio Volkweis Astiazara"

Apresentações semelhantes


Anúncios Google