Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouIsabelle Tomas Alterado mais de 9 anos atrás
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.
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.