Centrado na arquitetura

Slides:



Advertisements
Apresentações semelhantes
Modelo de Casos de Uso Diagrama de Casos de Uso
Advertisements

Análise e Projeto Orientado a Objetos
Requisitos de Software
Engenharia de Software
APSOO Aula 03.
Redes de computadores I
UML Visões – Parte 2.
(Unified Modeling Language)
Análise e Projeto de Sistemas I
Rational Unified Process(RUP)
Engenharia de Software
Faculdade de Ciências Sociais e Aplicadas de Petrolina – FACAPE
Técnicas eTipos de Requisitos
Análise de Requisitos Use Case Renata Araujo Ricardo Storino
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
Análise e Projeto de Sistemas
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
Análise e Gerenciamento de Requisitos com Casos de Uso
Principios e Conceitos de Projeto
Modelos de Processos de Software
Engenharia de Software
Modelagem para Web Aula de 11/04/2011.
Especificação de Requisitos de Software com Casos de Uso
RUPinho Qualidade de Software
Aula 1 Minicurso: Astah Ministrantes: André Martins; Camila Brondani;
Unibratec Análise e Gerencia de Projetos Profº Henrique Vila Nova
Arquitetura Orientado a Serviços
DIAGRAMA DE CASO DE USO Prof. Fabíola Gonçalves C. Ribeiro.
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Análise e Projeto de Sistemas
Arquitetura do Software
Modelagem de Negócio no RUP
PSBD II Projeto de Sistemas de Banco de Dados II
O Processo de desenvolvimento de software
Especificação em Projeto de Sistemas
Análise e Projeto Orientados a Objetos
Bruno Silva Desenvolvido a partir de
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.
RUP - Cap. 4 – Processo Centrado na Arquitetura
Especificação de Caso de Uso
Laboratório de Programação
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Trabalho de Engenharia de Software II
Requisitos de Software
Modelando Sistemas em UML
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
UML e a Ferramenta Astah
Use Cases e Fluxo de Eventos
Engenharia de Software
Diagramas de Caso de Uso
Engenharia de Software e Sistemas
Processo Dirigido Pelos Use Cases Disciplina: Estudo do RUP Autor: Tiago Lima Massoni Orientação: Augusto Sampaio Paulo Borba.
Engenharia de Requisitos
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.
Diagrama Casos de Uso.
Casos de Usos.
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.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
Engenharia de Software com o RUP - Workflow de Requisitos
UML (Unified Modeling Language) A linguagem unificada de modelagem
Técnicas e Tipos de Requisitos
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
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:

Centrado na arquitetura RUP Centrado na arquitetura

Introdução RUP A arquitetura de software está relacionada não só a estrutura e comportamento mas também a contexto: uso, funcionalidade, desempenho, elasticidade, reutilização, compreensão, restrições e intercâmbios tecnológicos e econômicos, e estéticos. A arquitetura é sobre a estrutura e organização, mas não é limitada para estruturar. Também se trata de comportamento: o que acontece no relacionamento deste software com outros softwares através de interface. Introdução

O Modelo de visão 4+1 da arquitetura RUP Programadores Gerenciamento de Software Usuário final funcionalidade Visão projeto Visão de implementação Visão de caso de uso Visão de processo Visão de implantação Analistas/Provadores Comportamento Engenharia de sistema Topologia de sistema Entrega, instalação Comunicação Introdução Integradores de sistema Desempenho Escalabilidade Processamento

O Modelo de visão 4+1 da arquitetura RUP Visão de projeto Esta visão da arquitetura endereça os requisitos funcionais do sistemas. Visão de processo Mostra o fluxo de controle entre as várias partes, incluíndo mecanismos de concorrência e de sincronização. Visão de implementação Abrange os componentes e os artefatos utilizados para o montagem e fornecimento do sistema físico. Visão de implantação Visão de Implantação Abrange os nós que formam a topologia de hardware em que o sistema é executado. Visão de caso de uso Abrange os casos de uso que descrevem o comportamento do sistema conforme é visto pelos usuários fineis, analistas e pessoal de teste Introdução

Um processo centrado na arquitetura RUP O Rational Unified Process define dois artefatos primários relacionados a arquitetura: A descrição da arquitetura de software (SAD) O protótipo arquitetônico que serve para validar a arquitetura e como linha base para o resto do desenvolvimento Introdução

O propósito da arquitetura RUP A arquitetura é importante por várias razões, dentre elas destacam-se: Controle Intelectual Consegue-se ganhar e reter o controle intelectual sobre o projeto, gerenciar sua complexidade e manter a integridade do sistema Reutilização A arquitetura fornece uma base efetiva para reutilização Base para o desenvolvimento A arquitetura fornece uma base para o gerenciamento de projeto Introdução

RUP Desenvolvimento baseado em Componentes O RUP suporta desenvolvimento baseado em componentes. O desenvolvimento baseado em componentes é sobre construir sistemas de qualidade que satisfazem rapidamente necessidades do negócio, preferivelmente usando partes em vez de habilidades em todo elemento individual. Um componente é uma parte não-trivial quase independente e substituível de um sistema que cumpre uma função claro no contexto de uma arquitetura bem definida. Um componente conforma e fornece a realização física de um conjunto de interfaces. Introdução

Um processo dirigido a caso de uso RUP Um processo dirigido a caso de uso

Introdução RUP Grande parte do Rational Unfied Process focaliza a modelagem. Os modelos ajudam a entender e modelar o problema que está se tentando resolver. A escolha de modelos e de técnicas usadas para expressá-los tem impacto significante no modo em que se pensa o problema e tentamos modelar a solução Introdução

Caso de uso e ator RUP Um caso de uso é uma sucessão de ações executadas por um sistemas, que rende um resultado observável de valor a um ator em particular. Ator é alguém ou algo fora do sistema, que interage com o sistema. Introdução

Caso de uso e ator RUP Para compreender os escopo de um caso de uso é necessário entender: Ação: é um procedimento computacional ou algoritmo que invocado quando o ator fornece um sinal ao sistema ou quando o sistema adquire um evento de tempo. Seqüência de ações: É um fluxo específico de eventos pelo sistema. Um resultado observável de valor: A seqüência de ações tem que render algo que tenha valor para um ator do sistema. Um ator não deveria ter que executar vários casos de uso para alcançar algo útil. Introdução

Caso de uso e ator RUP A descrição de um caso de uso define o que o sistema faz quando o caso de uso é executado. Transferir Dinheiro Retirar Dinheiro Conferir Saldo Introdução

RUP Fluxo de evento e Cenários O fluxo de eventos descreve a sucessão de acões entre o ator e o sistema Exemplo – Retirar dinheiro. O Caso de uso começa quando o Cliente insere um cartão no BANCO 24 HORAS. O sistema lê e valida a informação no cartão. Os lembretes de sistemas para um número de identificação pessoal (PIN). Cliente entra com o PIN. O sistema valida o PIN. O sistema pergunta qual operação o cliente deseja executar. O cliente seleciona “Retirar Dinheiro”. O sistema solicita a quantia de retirada. O cliente entra com a quantia. O sistema solicita o tipo de conta. O cliente seleciona o tipo de conta ( conta corrente, poupança, crédito) O sistema comunica-se com a rede de BANCO 24 HORAS para validar a ID da conta, o PIN e a disponibilidade da quantia pedida. Introdução

RUP Fluxo de evento e Cenários O sistema pergunta para o Cliente se deseja um recibo. Este passo só é executado se houver papel disponível para imprimir o recibo. O sistema pede para o Cliente remover o cartão. O Cliente remove o cartão. O sistema dispensa a quantia pedida de dinheiro. O sistema imprime um recibo, se pedido, que finaliza o caso de uso Este fluxo que representa o fluxo principal, mas podem ter vários outros fluxo alternativos. No exemplo acima, fluxo alternativos seriam determinado por: Contribuição do ator O estado interno do sistema Interrupções e erros Introdução

RUP Fluxo de eventos e Cenários Não se deve expressar cada possível fluxo alternado em um caso de uso separado; assim agrupa-se todos os fluxos de eventos, que é chamado classe de caso de uso. Um cenário é um fluxo de eventos específico dentro do caso de uso. Introdução

RUP Como identificar casos de uso Frequentemente, é difícil decidir se um conjunto de interações usuário-sistema, um diálogo particular ou um cenário, é um ou vários casos de uso. Casos de uso surgem quando se focaliza nos resultados de valor que um sistema fornece a um ator e quando agrupa as sucessões de ações que o sistema executar para prover esses resultados de valor. Outro modo de se pensar nisto é considerar quer um caso de uso cumpre uma “meta” particular que um ator tem, para ser realizado pelo sistema. Introdução

RUP Casos de uso no processo O Rational Unified Process é uma abordagem dirigida a caso de uso. Isto significa que o caso de uso definido para um sistema é a base para o processo de desenvolvimento inteiro. Introdução