Download
1 / 37
380 likes | 516 Vues
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.
E N D
Metodologia de Desenvolvimento de Software – RUP3. Análise & Projeto Márcio Aurélio Ribeiro Moreira marcio.moreira@uniminas.br http://si.uniminas.br/~marcio/
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.
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.
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.
A: Decomposição de domínio Domínio de Negócio
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.
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
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
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
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
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?
