RUP - Cap. 4 – Processo Centrado na Arquitetura

Slides:



Advertisements
Apresentações semelhantes
Desenvolvimento de Sistemas
Advertisements

Os projetos.
Engenharia de Software
Objetivos do Capítulo Utilizar o processo de desenvolvimento de sistemas delineado neste capítulo e o modelo de componentes de SI, do Capítulo 1, como.
UML no CICLO de DESENVOLVIMENTO
UML Visões – Parte 2.
O Processo Praxis 3.0 Processos de Software 25/03/2017
(Unified Modeling Language)
Rational Unified Process(RUP)
Valéria Maria Lauande Março/2010
Centrado na arquitetura
RUP Rational Unified Process (Processo Unificado de Desenvolvimento da Rational) 1.
Processo Desenvolvimento de Software Tradicional
Análise e Projeto de Sistemas
Análise e Projeto de Sistemas
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
RUP: Fluxo de Análise e Projeto
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Análise e Gerenciamento de Requisitos com Casos de Uso
Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 0 Sobre o Curso.
Classes e objetos Modelagem
Rational Unified Process
RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)
Unibratec Análise e Gerencia de Projetos Profº Henrique Vila Nova
Visão Geral PRO.NET.
Fundamentos de Engenharia de SW
Arquitetura de software
Processos de Desenvolvimento de Software – Parte 2
Fase de Elaboração: Fluxo de Requisitos
IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)
Análise e Projeto de Sistemas
Análise e Desenvolvimento de Software
ANÁLISE E DESENVOLVIMENTO
Técnicas e Projeto de Sistemas
PSBD II Projeto de Sistemas de Banco de Dados II
Projeto de Arquitetura de Software Visão Geral
O Processo de desenvolvimento de software
Especificação em Projeto de Sistemas
Abr-17 Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto Fluxo de análise e projeto.
Análise e Projeto Orientados a Objetos
Bruno Silva Desenvolvido a partir de
O Processo Unificado (UP)
Representação Arquitetural
Engenharia de Software
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Capturando Requisitos com Use Cases Disciplina: Estudo do RUP Autor: Tiago Lima Massoni Orientacao: Augusto Sampaio Paulo Borba.
Engenharia de Software
Engenharia de Software
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Técnicas e Projeto de Sistemas
Engenharia de Software
Engenharia de Software Aula 02 – Introdução Prof. Adriana M. Martins.
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE AULA 5
Abr-17 Projetar Processos Projetar distribuição.
Processo Centrado na Arquitetura
Gestão de projetos de Software GTI-16
Engenharia de Software
Engenharia de Software e Sistemas
Análise e Projeto de Sistemas Unified Modeling Language Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores.
Arquitetura de Software Projetos de Interface
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Aula 02 de Eng. de Requisitos
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
Apresentação Leonardo Brussolo de Paula
/ de Julho de UFPE - Universidade Federal de Pernambuco CIn - Centro de Informática Pós-Graduação em Ciência da Computação Tópicos Avançados.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/41 Análise e Projeto de Sistemas Arquitetura de Software.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

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

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.

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

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.

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.

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.

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

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

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

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.

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.

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.

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á!

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

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

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.

Elaboração da Arquitetura

Elaboração da Arquitetura

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;

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.

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.

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.

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.

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

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

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

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.

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.

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.