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

Processo de Desenvolvimento de Software – RUP

3. Análise & Projeto

Márcio Aurélio Ribeiro [email protected]://si.lopesgazzani.com.br/docentes/marcio/

Márcio Moreira 3. Análise & Projeto – slide 2Processo de Desenvolvimento de Software - RUP

Evolução da análiseDécada Análise Abordagens Ferramentas

60-70 Tradicional Funcional •Textos e Fluxogramas

80

Estruturada(Cris Gane, Tony de Marco e Yourdan)

FuncionalDados

•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)

FuncionalDadosControle

•Lista de Eventos e DFD•Diagrama Entidade-Relacionamento (DER)•Diagrama de Transição de Estados (DTE)•Mini-especificações e Normalização•Dicionário de Dados

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.


Objetivos da disciplina de análise & designTransformar 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.


Fluxo de trabalho de análise & design


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: Realizar síntese arquitetural


A: Definir uma sugestão de arquitetura


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ínioDomínio de

Negócio


A: Modelagem de serviço de meta


A: Análise de recurso existente


A: Analisar comportamento 1


A: Analisar comportamento 2


A: Refinar a arquitetura 1


A: Refinar a arquitetura 2


A: Projetar componentes 1


A: Projetar componentes 2


A: Projetar banco de dados


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çoTeste 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


A: Executar análise de subsistema


A: Executar especificação de componente


Essência da análise & projeto

Est

rutu

rar o

so

ftwar

e

Esp

ecifi

car o

S

oftw

are

Arquitetura do Software

Projeto de sub-sistemas

Projeto de sub-sistemasProjeto de interfaces

Descrição Arquitetural eM. de Análise e de Serviços

Casos de Uso Análise de realização dosCasos de Uso

Modelo de Análise

Pacotes de Análise

Classes de análiseMapa de navegação

Projeto Arquitetural

Descrição Arquitetural eM. de Projeto e Implementação

Projeto de Classes

Modelo de DadosClasses de Projeto e TestesComponentes de Serviços

Projeto de Casos de Uso

Projetos de realizaçãodos Casos de Uso


P: Modelo de análisepd Visão Niv elada de Pacotes de Análise

Uso Específico da Aplicação

Uso Específico do Negócio

«analysis-package»Acompanhamento Promocional

«analysis-package»Planejamento

«analysis-package»Organização de Produtos

«analysis-package»Gestão de Suprimentos

«analysis-package»Coletor de Fatos

«analysis-package»Análise de Mercado

«analysis-package»Planejamento e Controle de Produção

«analysis-package»Vendas

«analysis-package»Distribuição de Materiais

Name:Package:Version:Author:

Visão Nivelada de Pacotes de Análise«view» Análise1.0


P: Modelo de serviçosFeasibility Check & Reservation - Context Diagram

Siebel

1. Generate Quote2. Determine Order Feasibility

5. Authorize Credit

7. Allocate Service SpecificParameter

10. Negotiate Sales (Contract)11. Allocate Service SpecificParameter

14. Issue Customer Order

SOA

3. Create Feasibility Order(Business Rule to define if is necessary Feasibility Order)

6. Invoke Authorize Credit(in Gestor Serasa)

8. Create Reservation Order (Business Rule to define moment of reservation)

12. Create Order Reservation (Business Rule to define moment of reservation)

15. Create ProvisioningOrder

OSM

4. Call Feasibility Flow4.1. Infrastructure Feasibility4.1a. Network Feasibility4.1b. Workforce Feasibility4.1c. S/P Feasibility [Last Mile]

9. Call Reservation Flow(If is the moment of reservation)

13. Call Reservation Flow(If is the moment of reservation)

16. Call Provisioning Flow17. …


P: Projeto de serviços

Siebel

Metasolv’sProducts

Oracle ESB(Virtualization,

Transformation andRouting) Oracle BPEL Manager

callBackClient

Kenan

SubmittedOrder

ProvisioningOrder

CompletedOrder

CompletedOrder

UpdateCustomerOrder ActivateBilling

Siebel XML To

SID XML

Oracle ESB(Virtualization,

Transformation andRouting)

1. Submit Order

SID XML To

Siebel XML

2. Response Submit Order

SID XML To

P6 XML

3. Execute Order

P6 XML To

SID XML

SID XML To

Kenan XML

5b. Activate Billing5a. Close Order SID XML To

Siebel XML

4. Retun Resp Execute Order


P: Realização de casos de usoud Transferir Dinheiro - Realizacoes

(from Auto Servico)

Transferir Dinheiro

«use case realization»

Transferir Dinheiro

«service subsystem»Interface

(from GerenciadorConsole)

«service subsystem»Autenticador

(from GerenciadorConsole)

«service subsystem»RoteadorTransacao

(from GerenciadorTransacao)

«service subsystem»Transferidor

(from GerenciadorTransacao)

«service subsystem»Autenticação

(from GerenciadorConta)

«service subsystem»Conta-corrente

(from GerenciadorConta)

«realize»

«realize»

«realize»

«realize»

«realize»

«realize»

«realize»


P: Mapa de navegaçãosd GED :: Navegação de páginas

Mesma página

Pagina inicial

Inicio

Pesquisa de documento

Resultados da busca

Edição de documento

Fim

Configuracao

View TIFF

Criação de documento

[usuarioADMIN]

{weight=elemento selecionado nalistagem}

[usuarioADMIN]

[usuarioADMIN]

[usuarioADMIN]

{weight=elemento selecionado nalistagem}

«automatic»

[busca detalhada ousimples]

[usuarioADMIN]

[escolha dacontratante]


P: Pacotes de análisecd GerenciadorTransacao


«service subsystem»Sacador


Autorizacao

GerenciadorConta

Movimentacao

Transacao TransacaoAutorizada

«realize»«realize»

«realize» «realize»

«realize»

Name:Package:Version:Author:

GerenciadorTransacao«subsystem» GerenciadorTransacao1.0


P: Modelo de projetopd Design Model

Application Specific

Business Specific

GerenciadorConsole

«service subsystem»Interface

GerenciadorConta

GerenciadorTransacao«service subsystem»DispensadorCedulas

«service subsystem»Autenticação

«service subsystem»Conta-corrente

«service subsystem»Autenticador


«service subsystem»Sacador



P: Projeto de realizaçãosd Transferir Dinheiro

«interface»

TransacaoAutorizada

«interface»

Autorizacao

«interface»

Movimentacao

«service subsystem»

Interface:Correntista

«service subsystem»

Autenticador

«interface»

Transacao

insereCartao

escolheTransferencia

digitaValores

informaSenha

resultado:= Submete(conta, transferencia, senha)

ok:= autentica(conta, senha)

[ok]: submete(contaDestino,data,valor,contaOrigem,tipo)

ok:= debito(documento,historico,valor,data)

ok:= credito(documento,historico,valor,data)


P: Projeto de componentes


Modelos de: casos de uso x análise x projetoModelo 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 funcionalidadesFunciona 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


Do negócio ao software

Negócio Sistema Software

Direcionador de Comportamento

Direcionador de Informações

IdentificarNecessidades

ModelarSolução

ValidarSolução

Fluxo deNegócio

Transaçõesde Negócio

Entidadede Negócio

Atividadesde Negócio

Interfaces &Estruturas

Modelo deInformação

TarefasAutomatizáveis

Componentes

Modelode Dado

ArquiteturaModelagem de Negócio

&Requisitos

Análise&

Design(Projeto)

DiagramasComportamentais

DiagramasEstruturais


Exercício 2: Contexto 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

DataBase

Apresentação

Controle

Persistência

View

Control

Model


Exercício 2: Questões1. Que Atividades e Tarefas de Requisitos e Análise

& Design (Projeto) do RUP vocês recomendam que sejam utilizadas neste caso?

2. Justifique porque vocês incluíram ou excluíram cada Atividade e Tarefa.

3. Considerando somente as Atividades e Tarefas selecionadas, na construção de quais artefatos o “as-is” de processos poderia ajudar e porque?

4. 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?


ReferênciasSigla Referência

BOO98 G. Booch, J. Rumbaugh e I. Jacobson, 1998. 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. 1998. Addison Wesley Longman.

KRO03 Per Kroll e Philippe Kruchten 2003. 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). 2005.

MAR06 Márcio Moreira. Engenharia de Software - RUP . Uniube - Universidade de Uberaba - Uberlândia (MG). 2006.

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. 1995.

RUP08 IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects. 2008. IBM Rational.

SUM07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007.

YOU92 YOURDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, 1992.

http://si.uniminas.br/~marcio/marcio/20060614_invit_uniube_esw_rup.zip

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

Documents

Transcript of Processo de Desenvolvimento de Software – RUP 3. Análise & Projeto Márcio Aurélio Ribeiro...