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

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

Francilene Procópio Garcia, D.Sc.

Apresentações semelhantes


Apresentação em tema: "Francilene Procópio Garcia, D.Sc."— Transcrição da apresentação:

1 Francilene Procópio Garcia, D.Sc. francilene@ieee.org
Lab. Engenharia de Software O Processo Unificado (PU) de Desenvolvimento de Software Francilene Procópio Garcia, D.Sc.

2 Mas, o que é de fato um Processo de Desenovlvimento de Software?
Processo Unificado para Desenvolvimento de Software Um processo baseado em componentes, orientado a Casos de Uso, centrado na arquitetura, iterativo e incremental - explicitado por uma modelagem que faz uso de UML. Mas, o que é de fato um Processo de Desenovlvimento de Software? Um processo deve definir QUEM está fazendo O QUE QUANDO e COMO para que uma dada meta seja alcançada...

3 Processo de Desenvolvimento de Software
Um processo, em engenharia de software, tem como meta a construção de artefatos de software ou a melhoria de um produto existente, através da participação de vários tipos de usuários (cliente, usuário final, desenvolvedor, gerentes, etc), cujos limites dependem de alguns elementos: Tecnologia - LPs, SOs, Networks, etc. Ferramentas - tendo os processos disseminados amplamente, alavanca-se o desenvolvimento de tools. Pessoas - algumas habilidades são necessárias. Organização - modelos virtuais, outsourcing, contratos padrões, parcerias, etc.

4 Maior ajuda … nas fases de requisitos, análise e projeto.
Processo Unificado Vs. UML UML tem sido usada como a linguagem de modelagem padrão do PU ajudando na visualização, especificação, construção e documentação de diferentes artefatos de software. É um meio! Maior ajuda … nas fases de requisitos, análise e projeto.

5 Processo Unificado: Uma resposta à crise do software?
O que buscamos ao desenvolver sistemas de software nos dias de hoje? S/W mais flexível e adaptável às necessidades do mercado - mudanças ... Um processo mais rápido - time to market é um desafio! Não se admite mais o uso dos mesmos métodos - já se vão mais de 25 anos! Um processo que integre as muitas facetas do desenvolvimento de s/w

6 É baseado em componentes
O Processo Unificado É um processo para desenvolvimento de software que suporta um conjunto de atividades necessárias para se transformar “requisitos” num sistema de software Apresenta-se como um framework genérico para uma ampla gama de classes de s/w É baseado em componentes Faz uso intenso de UML Aspectos essenciais: orientação à Casos de Uso, foco na arquitetura, iterativo e incremental

7 O que são Casos de Uso? São usados para captura dos requisitos de um sistema de software, particularmente daqueles baseados em componentes. Algumas definições importantes: Usuário (humanos e outros sistemas que interagem com o sistema em desenvolvimento); Casos de Uso (um aspecto funcional que provê um valor ao usuário - as interações com o sistema). Os Casos de Uso substituem o modelo tradicional de especificação de um sistema de software … o que se espera que o sistema faça … para cada usuário?

8 Por quê centrado na Arquitetura?
Para que serve a arquitetura de um sistema? [Parábola dos homens cegos e o elefante] Define uma estrutura, seus serviços. Ex.: sistemas água e elétrico, etc. Nos ajuda a: entender o sistema, organizar o seu desenvolvimento, acompanhar a evolução do sistema, e atuar em busca do reuso. No caso de sistemas de s/w: procura-se definir aspectos estáticos e dinâmicos de um produto de s/w.

9 Arquitetura de S/W Elementos previstos na arquitetura de um s/w:
a estrutura do sistema (sua organização) os componentes críticos e as interfaces entre eles a composição dos componentes em subsistemas a partir do comportamento de suas funcionalidades A soma de diferentes visões: casos de uso + análise + projeto + ...

10 Experiência (patterns)
Casos de Uso Vs. Arquitetura Casos de Uso (função) Arquitetura (forma) Experiência (patterns) Em geral, as funcionalidades críticas do s/w são representadas por cerca de 5% a 10% dos Casos de Uso. Orientam / Guiam Mapeia

11 Camadas Possíveis na Arquitetura: os seus Subsistemas
Aplicações Específicas (sempre no topo) Aplicação Geral (subsistemas que podem ser reusados em diferentes aplicações) Middleware (frameworks, bibliotecas de classes, etc) Sistemas de S/W cada Caso de Uso especificado é detalhado e transformado em termos de subsistemas, classes e componentes. Dependem do negócio Independem do negócio

12 Processo Iterativo e Incremental? Para quê?
Para lidar com ciclos de desenvolvimento cada vez mais complexos e longos, onde a maturidade só é alcançada após vários mini-ciclos - o PU prevê uma série de mini-projetos (versões do sistema). Cada mini-projeto é uma iteração resultante de passos incrementais ao longo do ciclo de desenvolvimento. As iterações são passos ao longo do fluxo de trabalho; os incrementos são avanços na direção do produto final. A eficácia do processo deve ser buscada com o controle das várias iterações...

13 Processo Iterativo e Incremental

14 Como definir as iterações?
Para se definir as versões resultantes em cada iteração, deve-se atentar para dois fatores chaves: (1) Cada iteração deve estar associada a um conjunto de Casos de Uso que avançam em termos da usabilidade do produto desenvolvido até então. (2) Cada iteração deve considerar e atacar algum risco crítico, de forma que, ao final, a maioria dos riscos tenham sido atacados. As sucessivas iterações irão resultar nos artefatos de s/w, avançando sempre na direção do produto final.

15 As representações p/ um Produto
Cada mini-ciclo resulta numa versão do sistema. Cada versão é um produto pronto para entrega (algum código fonte na forma de componentes executáveis + manuais + outros artefatos de interesse). OK Modelo Caso de Uso Análise Projeto Desdobramento Implementação Teste Especificado por Transformado Distribuído Implementado Verfiicado Modelos no PU

16 Os Quatro Ps no PU: Pessoas, Projeto, Produto e Processo
Tools Template Participantes Resultado Automação

17 Quem participa? Como é o proc. de desenvolvimento?
Sistema Usuários Testadores Projetistas Analistas Gerente Projeto Arquiteto Analista Sistema Arquiteto Projetista Caso de Uso Interface Define Atores e Casos de Uso Estrutura o Modelo de Casos de Uso Prioriza Casos de Uso Detalha os Protótipo da

18 Requisitos: Pessoas Vs. Artefatos
Capturando os Requisitos Funcionais: aplicando Casos de Uso Requisitos: Pessoas Vs. Artefatos Analista Sistema Modelo Caso Uso Ator Glossário Projetista Caso Uso Interface Protótipo Interface Descrição Arquitetura

19 Requisitos: Atividades do Processo
Capturando os Requisitos Funcionais: aplicando Casos de Uso Requisitos: Atividades do Processo Analista Sistema Arquiteto Projetista Caso de Uso Interface Define Atores e Casos de Uso Estrutura o Modelo de Casos de Uso Prioriza Casos de Uso Detalha os Protótipo da

20 Um exemplo: Modelo de Sistema de uma ATM
Diagrama de Caso de Uso Cliente Banco Retirada Dinheiro Depósito Tranferência entre Contas Observe que os casos de uso são projetados para atender as demandas dos usuários do sistema - capturando todos os requisitos funcionais. “Um caso de uso especifica uma sequência de ações, incluindo suas variantes, que o sistema pode executar resultando em valores para um dado ator.”

21 Análise: Pessoas Vs. Artefatos
O Projeto de uma Idéia: Modelo de Análise Análise: Pessoas Vs. Artefatos Arquiteto Modelo Análise Projetista Caso Uso Engenheiro Componente Análise Classe Pacote Descrição Arqitetura Transformação Caso Uso - Análise

22 Análise: Atividades do Processo
Estabelecendo o Projeto de uma Idéia: Modelo de Análise Análise: Atividades do Processo Arquiteto Projetista Caso de Uso Engenheiro Componente Análise Arquitetural Analisa Casos de Uso Classe Pacote

23 Exemplo: Modelo de Análise
Cliente Banco Gaveta da ÀTM Tela de Interface Receptor ATM Retirada Transferência Conta Depósito O modelo mostra como cada caso de uso é obtido pela estrutura de classes da análise. Por exemplo, as classes Interface, Retirada, Conta e Gaveta são responsáveis pelo Caso de Uso Retirada de Dinheiro. Modelo de Análise

24 Diagrama de Colaboração
Exemplo: Modelo de Análise Textos estruturados ou pseudo-código podem ajudar na documentação da interação entre os objetos! Cliente Banco Gaveta da ÀTM Tela de Interface Retirada Conta 1. Identifica 2. Solicita retirada 3. Valida a retirada 4. Autoriza a saída 5. Libera o dinheiro Este diagrama nos ajuda a descrever como o Use Case Retirada de Dinheiro é obtido através da participação de vários objetos da análise. Na fase de projeto, tal combinação deve ser refinada. Diagrama de Colaboração

25 Exemplo: Subsistemas propostos
Aplicações Específicas Aplicação Geral Middleware Sistemas de S/W Gestão Transação Interface ATM Gestão Conta Java. applet Java. mi Java VM TCP/IP

26 Projeto: Pessoas Vs. Artefatos
Estabelecendo o Vocabulário do Problema e de sua Solução: Modelo de Projeto Projeto: Pessoas Vs. Artefatos Descrição Arqitetura Arquiteto Modelo Projeto Desdobramento Projetista Caso Uso Engenheiro Componente Projeto Classe Subsistema Interface Transformação Caso Uso - Projeto

27 Projeto: Atividades do Processo
Estabelecendo o Vocabulário do Problema e de sua Solução: Modelo de Projeto Projeto: Atividades do Processo Arquiteto Projetista Caso de Uso Engenheiro Componente Projeto Arquitetural Projeta um Casos de Uso Projeta Classe Subsistema

28 Exemplo: Modelo de Projeto
Modelo de Análise Interface ATM Gaveta Retirada Conta Tela Teclado Leitor Cartão Sensor Enchedor Contador Cédulas Gerente Cliente Saque Transação Classe Persistente Modelo de Projeto Classes ativas

29 Exemplo: Modelo de Projeto
Introduz mais detalhes que o Diagrama de Classes do modelo de análise. Faz-se necessário ainda mais detalhes sobre as interações entre objetos. Diagrama de Classe Tela Teclado Leitor Cartão Sensor Gaveta Enchedor Contador Cédulas Gerente Cliente Saque Transação Conta Classe Persistente

30 Exemplo: Modelo de Projeto
Mostra como focar o Caso de Uso - começando da esquerda e alcançando cada objeto envolvido, conforme as mensagens são enviadas… (passos 1 e 2 do Diagrama de Colaboração) Diagrama de Sequência :Tela :Teclado : Leitor Cartão :Contador Cédulas :Gerente Cliente Transação :Cliente Banco Inserir cartão Cartão inserido (ID) Solicita a senha Mostra a solicitação Insere a senha Senha Solicita validação senha Pergunta pela soma saque Insere a quantia para saque Valor . . .

31 Modelo de Projeto: Organizando as Classes - Uma visão da estrutura estática
Tela Teclado Leitor Cartão Sensor Gaveta Enchedor Contador Cédulas Gerente Cliente subsistema Interface ATM Saque Transação Gestão Transação serviço subsistema Gestão Saque Conta Classe Persistente Gestão Conta Liberação Transf. Interface

32 Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação
Nesta fase, devemos prover o que for necessário para obtenção do sistema executável: os componentes executáveis, os arquivos do componente (código fonte, scripts, etc), tabela de componentes (elementos da bases de dados), entre outros. Um componente é a parte física e mutável de um sistema que deve suportar a operação conjunta de um grupo de interfaces. Isto é, o modelo de implementação deve ser composto de componentes, incluindo todos os executáveis (ActiveX, Java Beans, etc) para cada classe presente no Modelo de Projeto.

33 Implementação: Pessoas Vs. Artefatos
Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação Implementação: Pessoas Vs. Artefatos Modelo Desdobramento Arquiteto Implementação Integrador Sistema Engenheiro Componente Implementação Subsistema Interface Transformação Casos Uso - Plano Integração

34 Implementação: Atividades do Processo
Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação Implementação: Atividades do Processo Arquiteto Integrador Sistema Engenheiro Componente Implementação Arquitetural Integração Implementa Subsistema Executa Teste Unidade Classe

35 Modelo de Desdobramento: Uma visão arquitetural dos nodos físicos
Três Nós Vs. Três Subsistemas Client ATM Server Application Data Internet Intranet

36 Modelo de Implementação
Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação Contador Cédulas Gerente Cliente Sensor Gaveta Enchedor Modelo de Projeto executável cliente.exe file gaveta.c cliente.c compilação Modelo de Implementação Fazendo uso de uma LP OO, cada classe no projeto corresponde a uma classe na imple-mentação - C++ ou Java, por exemplo. Cada arquivo de componente deve im-plementar várias classes, dependendo da LP.

37 Estabelecendo os caminhos para validar e verificar o sistema: Teste
Nesta fase, devemos verificar se o sistema implementa corretamente suas especificações - desenvolvendo um modelo que consiste de casos de testes e procedimentos para acompanhamento e controle de erros. Um caso de teste consiste de um conjunto de entradas, condições para execução e resultados esperados num dado teste (ex. uma dada funcionalidade do sistema definida num caso de uso). Os procedimentos também podem ser obtidos a partir dos casos de uso - porém, aqui os erros encontrados devem ser analisados e solucionados numa dada ordem de importância.

38 Teste: Pessoas Vs. Artefatos
Estabelecendo os caminhos para validar e verificar o sistema: Teste Teste: Pessoas Vs. Artefatos Avaliação Teste Eng. Teste Modelo Procedimento X Caso Teste Plano Teste Componente Engenheiro Testador Integração Sistema X Erro

39 Teste: Atividades do Processo
Estabelecendo os caminhos para validar e verificar o sistema: Teste Teste: Atividades do Processo Eng. Teste Testador Integração Sistema Plano Teste Implementa Teste Executa Teste Integr. Engenheiro Componente Proj. Teste Teste Sist. Avaliação

40 Teste: Um Exemplo do Caso de Uso Retirada
Entrada: Uma dada conta apresenta um saldo de $250 O cliente da conta se identifica corretamente O cliente solicita um saque de $200 Existe caixa suficiente na ATM Saída: O saldo da conta dreduz para $50 O cliente da conta recebe os $200 da ATM Condições: Nenhum outro caso de uso (instâncias) pode acessar a conta referida durante o caso de teste X Modelo Caso Uso Modelo Teste Retirada Fluxo Básico - Retirada


Carregar ppt "Francilene Procópio Garcia, D.Sc."

Apresentações semelhantes


Anúncios Google