1 / 37

Metodologia de Desenvolvimento de Software – RUP 3. Análise & Projeto

Metodologia de Desenvolvimento de Software – RUP 3. Análise & Projeto. Márcio Aurélio Ribeiro Moreira marcio.moreira@uniminas.br http://si.uniminas.br/~marcio/. Evolução da análise. Objetivos da disciplina de análise & design.

collin
Download Presentation

Metodologia de Desenvolvimento de Software – RUP 3. Análise & Projeto

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Metodologia de Desenvolvimento de Software – RUP3. Análise & Projeto Márcio Aurélio Ribeiro Moreira marcio.moreira@uniminas.br http://si.uniminas.br/~marcio/

  2. Evolução da análise

  3. Objetivos da disciplina de análise & design • Transformar os requisitos em um design (projeto) do sistema a ser criado. • Desenvolver uma arquitetura sofisticada para o sistema. • Adaptar o design (projeto) para que corresponda ao ambiente de implementação, projetando-o para fins de desempenho.

  4. Fluxo de trabalho de análise & design

  5. Objetivos das atividades • Realizar Síntese Arquitetural (utilizada na Iniciação): • Construir e avaliar uma Prova de Conceito Arquitetural, para demonstrar que o sistema idealizado é factível. • Definir uma Sugestão de Arquitetura: • Criar um esboço inicial da arquitetura de software. • Identificação de Serviço: • Identificar e qualificar serviços candidatos. • Analisar Comportamento: • Transformar descrições comportamentais fornecidas pelos requisitos em um conjunto de elementos, no qual o design possa se basear. • Refinar a Arquitetura: • Concluir a arquitetura para uma iteração. • Projetar Componentes: • Refinar o design do sistema. • Projetar o Banco de Dados: • Identificar as classes de design a serem persistidas em um banco de dados e projetar as estruturas de banco de dados correspondentes. • Especificação de Serviço: • Especificar o comportamento de serviço e identificar os fornecedores de serviços e partições.

  6. A: Realizar síntese arquitetural

  7. A: Definir uma sugestão de arquitetura

  8. A: Identificação de serviço • Esta atividade é composta por outras 3 atividades: • Decomposição do Domínio: • Decomposição guiada por negócio, top-down, para identificar: • Serviços candidatos e Processos de negócios (fluxos de serviços) • Áreas funcionais que identificam limites para subsistemas ( componentes de serviços candidatos para realizar os serviços) • Atributos comuns e variações da funcionalidade de negócios • Modelagem de Serviço de Meta: • Ajuda a descobrir serviços alinhados a negócios e assegura que importantes serviços não tenham sido perdidos durante a decomposição (objetivos  serviços  KPIs, métricas e eventos) • Análise de Recurso Existente: • Avaliar os recursos existentes para projetar serviços que preservem o máximo destes recursos sem a necessidade de mudanças.

  9. A: Decomposição de domínio Domínio de Negócio

  10. A: Modelagem de serviço de meta

  11. A: Análise de recurso existente

  12. A: Analisar comportamento 1

  13. A: Analisar comportamento 2

  14. A: Refinar a arquitetura 1

  15. A: Refinar a arquitetura 2

  16. A: Projetar componentes 1

  17. A: Projetar componentes 2

  18. A: Projetar banco de dados

  19. A: Especificação de serviço • Esta atividade é composta por outras 3 atividades: • Executar Especificação de Serviço: • Definir os limites do serviço e definir as mensagens. • Executar Análise de Subsistema: • Fazer o projeto do subsistema de SOA (Service Oriented Architecture ou Arquitetura Orientada a Serviços). • Executar Especificação de Componente: • Especificar os componentes necessários aos serviços.

  20. A: Executar especificação de serviço • Teste Litmus: • É um tipo de teste para serviços de SOA • Objetivos: • Assegurar que o serviço seja alinhado com os negócios • Assegurar que o serviço possa ser composto • Assegurar que o serviço tenha descrição externa • Assegurar que o serviço seja reutilizável • Assegurar que o serviço seja viável tecnicamente

  21. A: Executar análise de subsistema

  22. A: Executar especificação de componente

  23. Essência da análise & projeto Arquitetura do Software Descrição Arquitetural e M. de Análise e de Serviços Modelo de Análise Classes de análise Mapa de navegação Estruturar o software Casos de Uso Análise de realização dos Casos de Uso Pacotes de Análise Projeto de sub-sistemas Projeto de sub-sistemas Projeto de interfaces Projeto Arquitetural Descrição Arquitetural e M. de Projeto e Implementação Especificar o Software Modelo de Dados Classes de Projeto e Testes Componentes de Serviços Projeto de Classes Projeto de Casos de Uso Projetos de realização dos Casos de Uso

  24. P: Modelo de análise

  25. P: Modelo de serviços

  26. P: Projeto de serviços

  27. P: Realização de casos de uso

  28. P: Mapa de navegação

  29. P: Pacotes de análise

  30. P: Modelo de projeto

  31. P: Projeto de realização

  32. P: Projeto de componentes

  33. Modelos de: casos de uso x análise x projeto

  34. Atividades de Negócio Tarefas Automatizáveis Fluxo de Negócio Transações de Negócio Interfaces & Estruturas Componentes Entidade de Negócio Modelo de Informação Modelo de Dado Do negócio ao software Modelagem de Negócio & Requisitos Análise & Design (Projeto) Arquitetura Diagramas Comportamentais Diagramas Estruturais

  35. Exercício 2: Contexto DataBase • Considerando o mesmo projeto do exercício 1 e mais: • A empresa adquiriu o Siebel, um software pronto, de CRM para ser utilizado no projeto, com base nas seguintes ponderações: • O Siebel é um dos mais utilizados na indústria que a empresa está inserida • O Siebel é compatível com o eTOM e foi desenvolvido na arquitetura MVC (Model View Control ou Persistência, Controle e Apresentação) que facilita a integração via SOA • Para atender as funcionalidades específicas da empresa, serão feitas pequenas customizações no Siebel, priorizando: • As customizações devem ficar restritas à camada de Apresentação • Somente serão permitidas customizações na camada de Controle e de Persistência com autorização dos executivos e da Oracle (fabricante) • Você faz parte de uma equipe constituída para implementar o Siebel e: • Existe uma outra equipe que cuida de arquitetura e da integração via SOA e outra que cuida de processos de negócio • Todas as integrações do Siebel com legados e outros softwares são via SOA • Todas as solicitações da área de negócio são alinhadas à processo

  36. Exercício 2: Questões • Que Atividades e Tarefas de Requisitos e Análise & Design (Projeto) do RUP vocês recomendam que sejam utilizadas neste caso? • Justifique porque vocês incluíram ou excluíram cada Atividade e Tarefa. • Considerando somente as Atividades e Tarefas selecionadas, na construção de quais artefatos o “as-is” de processos poderia ajudar e porque? • A consultoria resolveu fazer o Design (projeto técnico) junto com a Implementação. O que vocês acham disto? Quais as possíveis conseqüências?

  37. Referências

More Related