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

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

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

Apresentações semelhantes


Apresentação em tema: "Metodologia de Desenvolvimento de Software – RUP 3. Análise & Projeto"— Transcrição da apresentação:

1 Metodologia de Desenvolvimento de Software – RUP 3. Análise & Projeto
Márcio Aurélio Ribeiro Moreira

2 Evolução da análise Década Análise Abordagens Ferramentas 60-70
Tradicional Funcional Textos e Fluxogramas 80 Estruturada (Cris Gane, Tony de Marco e Yourdan) Dados Diagrama de Fluxo de Dados (DFD) Diagrama de Estrutura de Dados (Modelo Conceitual) Mini-especificações e Normalização Dicionário de Dados 90 Essencial (Peter Chen, Stephen McMenamin & John Palmer) Controle Lista de Eventos e DFD Diagrama Entidade-Relacionamento (DER) Diagrama de Transição de Estados (DTE) 2000 Orientada a Objetos (Booch, Rumbaugh & Jacobson) Todos os aspectos do negócio e do sistema Equivalentes aos anteriores Modelos de casos de uso, análise e projeto Modelos de distribuição, implementação e de testes Diagramas de seqüência, estado, atividades, etc.

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 Pacotes de Análise Classes de análise Mapa de navegação Estruturar o software Casos de Uso Análise de realização dos Projeto Arquitetural Descrição Arquitetural e M. de Projeto e Implementação Projeto de Casos de Uso Projetos de realização dos Casos de Uso Especificar o Software Projeto de Classes Modelo de Dados Classes de Projeto e Testes Componentes de Serviços Projeto de sub-sistemas Projeto de interfaces

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
Modelo de Caso de Uso Modelo de Análise Modelo de Projeto Descrito na linguagem do cliente Usa diagramas de análise (modelo lógico) Usa diagramas de projeto (modelo físico) Visão externa do sistema Visão interna estrutural do sistema Visão interna comportamental do sistema Estruturado pelos casos de uso (1 página) Estruturado por sub-sistemas, pacotes e classes (interface, controle e persistência) genéricas do projeto (poucas camadas) Estruturado por componentes e dependente da linguagem de implementação (várias camadas) Contrato entre o cliente e o desenvolvedor (escopo) Usado pelos analistas para entender como o sistema deve ser estruturado Contrato entre analistas e desenvolvedores do comportamento do sistema Pode conter redundâncias, inconsistências, etc. Não deve conter redundâncias, inconsistências, etc. Deve ser objetivo, claro e limpo Captura funcionalidades do sistema, inclusive arquiteturais Esboça como realizar as funcionalidades Funciona como primeiro corte do projeto Detalha a realização das funções do sistema até o nível necessário para desenvolve-las Define os casos de uso que integrarão o Modelo de Análise Define as realizações dos casos de uso e as necessidades de projeto Define as realizações do Modelo de Análise Raramente modificado Muda pouco no ciclo de vida do projeto Muda bastante e deve ser atualizado

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

35 Apresentação Controle Persistência View Control Model 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 Sigla Referência BOO98
G. Booch, J. Rumbaugh e I. Jacobson, UML User Guide. Addison-Wesley Longman. DEM89 DeMARCO, Tom. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989. JAC98 Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process Addison Wesley Longman. KRO03 Per Kroll e Philippe Kruchten The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman. KRU95 Philippe Kruchten 1995, "The 4+1 view model of architecture," IEEE Software. 12(6), 1995. KRU98 P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. MAR05 Márcio Moreira. Resumo do livro Unified Process. Márcio. Uberlândia (MG) MAR06 Márcio Moreira. Engenharia de Software - RUP . Uniube - Universidade de Uberaba - Uberlândia (MG) MCP91 MCMENAMIN, Stephen & PALMER, John. Análise essencial de sistemas. São Paulo : McGraw-Hill, 1991. PRE95 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books RUP08 IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects IBM Rational. SUM07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall YOU92 YOURDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, 1992.


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

Apresentações semelhantes


Anúncios Google