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

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

RUP - Cap. 4 – Processo Centrado na Arquitetura

Apresentações semelhantes


Apresentação em tema: "RUP - Cap. 4 – Processo Centrado na Arquitetura"— Transcrição da apresentação:

1 RUP - Cap. 4 – Processo Centrado na Arquitetura
Disciplina: ESOF2 Prof. Adriana M. Martins

2 Introdução Conceitos Chave do RUP: - Dirigido por Casos de Uso
- Centrado na Arquitetura - Iterativo e Incremental Lembrando que: A arquitetura representa a forma, enquanto que os casos de uso representam a funcionalidade.

3 Introdução Casos de Uso podem conduzir o desenvolvimento de software, porém não são suficientes. A arquitetura de um sistema pode ser definida como sendo: “Uma visão comum na qual todos os participantes concordem ou pelo menos aceitem.”

4 Introdução A arquitetura deverá descrever os elementos mais importantes do modelo. A arquitetura é construída durante a fase de elaboração. O objetivo é criar uma base arquitetural para que a fase de construção seja iniciada com um fundamento sólido para a construção completa do sistema.

5 O que é a Arquitetura para um Sistema?
“O arquiteto é especialista na integração de todos os aspectos de uma construção, mas não é especialista em todos os aspectos.” Exemplo: arquiteto civil. Sistemas de software são apresentados através de diferentes perspectivas (visões), que juntas compõem a arquitetura do sistema.

6 restrições econômicas e tecnológicas.
O que é a Arquitetura para um Sistema? A arquitetura lida com algumas decisões importantes como: a organização do sistema; os elementos estruturais e interfaces entre si, e também o seu comportamento e composição em subsistemas maiores; o estilo arquitetural que guiará a organização dos elementos, interfaces, colaborações e composições. Envolve também decisões sobre uso, funcionalidade, performance, reuso, compreensibilidade, estética, robustez, restrições econômicas e tecnológicas.

7 O que é a Arquitetura para um Sistema?
A arquitetura também pode ser representada como visões de modelos (modelo de visão 4 + 1): Visão Lógica Visão de Processo Implementação Implantação Usuário Final Funcionalidade Pacotes Subsistemas Classes Analistas/Testadores Comportamento - Testes, processos, iterações Integradores de Sistemas Desempenho Escalabilidade Processamento Programadores Gerenciamento de Software Módulos estáticos Camadas Gerenciamento de configurações Engenharia de Sistema Topologia, entrega, instalação, comunicação Caso de Uso Cenários Chave

8 Porque é Necessária a Arquitetura?
Para desenvolver sistemas complexos é necessário um arquiteto e desenvolvedores. São sistemas que não existem no mundo real, geralmente são únicos e inexistentes. “O design e a implementação vão além de algoritmos e estruturas de dados de computação: projetar e especificar toda uma estrutura dessas emerge como um novo tipo de problema.”

9 Porque é Necessária a Arquitetura?
A arquitetura é necessária para: Entendimento do sistema Organização do desenvolvimento Estímulo ao reuso Evolução do sistema

10 Porque é Necessária a Arquitetura?
Entendimento do Sistema: tornar sistemas complexos compreensíveis é um desafio por várias razões: Comportamento complexo; Ambiente de operação complexo; Tecnologia complexa; Combinação de computação distribuída, produtos e plataformas comerciais, componentes e estruturas reusáveis; Satisfação de demanda de indivíduos e de organizações; Dificuldade de gerenciamento; Constantes mudanças.

11 Porque é Necessária a Arquitetura?
Organização do Desenvolvimento: redução da intensa necessidade de comunicação entre membros de uma equipe maior e viabilização do trabalho em paralelo. Estímulo ao Reuso: a base do reuso são os componentes. Quando estes são bem projetados há redução de tempo e custo durante a construção do sistema. Evolução do Sistema: o sistema deve ser capaz de suportar bem as mudanças, sem causar impactos indesejáveis ao projeto e implementação existentes.

12 Casos de Uso x Arquitetura
Restrições e facilitadores: Casos de Uso Experiência Arquitetura - Arquiteturas prévias - Padrões arquiteturais Software do sistema Middleware Sistemas de legado Padrões e políticas Requisitos não funcionais Necessidade de distribuição dirigem guia Casos de Uso com Valor: alta performance, qualidade e usabilidade.

13 Casos de Uso x Arquitetura
Restrições e facilitadores para definição da Arquitetura: Software do sistema: quais produtos serão usados – BD e SO? Middleware: quais os produtos de interface serão usados entre camadas? Sistemas Legados: sistemas já existentes serão usados? Serão melhorados? Padrões e políticas da empresa: serão usadas, adaptadas? Requisitos não-funcionais: qual a disponibilidade, tempo de restauração, memória? Necessidade de distribuição: como o sistema estará organizado, distribuído fisicamente? Este é um entendimento geral de como o sistema funcionará!

14 Casos de Uso x Arquitetura
A arquitetura é desenvolvida em interações durante a fase de elaboração; Abordagem incremental com resultado sendo uma arquitetura estável; Durante a fase de construção, os casos de uso são implementados baseados nos requisitos dos usuários e dos clientes, sendo também influenciados pela arquitetura selecionada na fase de elaboração. Entradas dos usuários Entradas do cliente Casos de Uso Arquitetura

15 Elaboração da Arquitetura
Quais os casos de uso serão arquiteturalmente significantes? Os que ajudam a mitigar riscos mais sérios; Os que são considerados mais importantes para os usuários do sistema; Os que ajudam a cobrir as funcionalidades mais importantes do sistema. Geralmente são 80% dos Casos de Uso

16 Elaboração da Arquitetura
O resultado da fase de elaboração será uma base arquitetural – um esqueleto do sistema com poucos “músculos”. Depois desta etapa haverão poucas mudanças na arquitetura. Base Arquitetural: agregação dos modelos do sistema que representem os casos de uso mais importantes, com uma perspectiva arquitetural e uma descrição da arquitetura. O papel da descrição da arquitetura é guiar toda a equipe de desenvolvimento durante os ciclos de vida do sistema. Se a arquitetura for estável, o padrão desta também se tornará estável.

17 Elaboração da Arquitetura

18 Elaboração da Arquitetura

19 Elaboração da Arquitetura
A descrição da Arquitetura: É basicamente a uma extração sobre os modelos do sistema; Apresenta apenas componentes arquiteturalmente significantes; Contém as 5 visões: casos de uso, análise, projeto, implantação e implementação;

20 Elaboração da Arquitetura
A descrição da Arquitetura: deve sempre ser atualizada, mas não deve “crescer” durante o ciclo de vida do projeto. As atualizações podem incluir: a) descoberta de novas interfaces e classes; b) adição de funcionalidades aos subsistemas já existentes; c) atualização de versão dos componentes utilizados; d) reorganização da estrutura do processo. Pode ainda conter: requisitos não-funcionais, detalhes sobre plataforma, sistemas legados e comerciais utilizados, documentação de padrões utilizados. É uma visão de alto nível: trata com detalhes apenas subsistemas que são significantes no ponto de vista da arquitetura.

21 Elaboração da Arquitetura
Utilizando Padrões de Arquitetura: Padrões de projeto são as “soluções já consagradas para problemas recorrentes”. Trata de uma perspectiva arquitetural do sistema, portanto mais abrangente. No UP a solução é descrita na forma de interações e colaborações entre subsistemas e até mesmo entre sistemas. Exemplos de padrões: Broker, Cliente-Servidor, Three-Tier, Ponto-a-Ponto, Camadas. Obs: mais de um padrão poderá ser usado no sistema, porém um deles deverá ser o predominante.

22 Elaboração da Arquitetura – Modelo em Camadas
Modelos, classes, bibliotecas específicas do negócio. Subsistemas não específicos para a aplicação, permitem reuso por outras aplicações do mesmo domínio do negócio. Não consideram detalhes específicos do negócio.

23 O Arquiteto Cria a Arquitetura
A arquitetura é criada pelo arquiteto, juntamente com outros desenvolvedores; Deve buscar um sistema com alta performance, qualidade, funcionalidade, amigável, robusto, … Objetivo: implementar as funcionalidades da aplicação em um custo adequado com eficiência desejada, agora e no futuro. Arquiteto: conhecimento do domínio no qual trabalha e de desenvolvimento de software. Uma boa arquitetura = diminuição do tempo total de desenvolvimento de projeto.

24 A Descrição da Arquitetura – Exemplo
Visão Arquitetural do Modelo de Caso de Uso – Caixa Eletrônico: Apresenta atores e casos de uso mais importantes. Apresenta descrição completa do caso de uso. É totalmente implementado durante a fase de elaboração. Depósito Transferência Saque Saque

25 A Descrição da Arquitetura – Exemplo
Visão Arquitetural do Modelo de Projeto – Caixa Eletrônico: Apresenta os classificadores mais importantes do modelo de projeto (subsistemas, interfaces, classes, classes ativas) e as realizações dos casos de uso mais importantes. 1. Diagrama de classes das classes ativas do Caso de Uso 2. Diagrama de classes mostrando os subsistemas e interfaces 3. Diagrama de colaboração 4. Descrição do fluxo de realização do Caso de Uso Gerenciador do Cliente da Transação da Conta

26 A Descrição da Arquitetura – Exemplo
Visão Arquitetural do Modelo de Implementação – Caixa Eletrônico: Define a arquitetura física do sistema em termos de nós conectados; Os nós e conexões do modelo de implantação e a alocação de objetos ativos aos nós podem ser descritos em diagramas de implantação. Gerenciador Cliente Servidor da Aplicação Servidor de Dados Internet Intranet nós

27 A Descrição da Arquitetura – Exemplo
Visão Arquitetural do Modelo de Implantação – Caixa Eletrônico: Será o mapeamento direto do modelo de projeto para o modelo de implantação.

28 Três Conceitos Importantes
O que é Arquitetura? Especificação feita pelo arquiteto na descrição da arquitetura; Permite controle do desenvolvimento; Contém elementos estruturais do sistema, interfaces e suas colaborações; Dirigida pelos Casos de Uso; Compreensível, suportar reuso e modificações. Como é obtida? Desenvolvida interativamente durante a fase de elaboração. Construção de uma base da arquitetura. Como é descrita? Visão dos modelos do sistema que contém os componentes mais interessantes arquiteturalmente e mais importantes a serem entendidos pela equipe e interessados.

29 Visão Geral As necessidades dos usuários relativas aos requisitos não podem ser implementadas todas de uma vez, elas serão refinadas em sucessivas iterações.


Carregar ppt "RUP - Cap. 4 – Processo Centrado na Arquitetura"

Apresentações semelhantes


Anúncios Google