DDSSCCDDSSCC Engenharia de Software Engenharia de Software Processo Unificado de Desenvolvimento de...

of 40/40
D D S S C C Engenharia de Software Engenharia de Software Processo Unificado de Desenvolvimento de Soft Processo Unificado de Desenvolvimento de Soft Lab. Engenharia de Software Lab. Engenharia de Software O Processo Unificado (PU) O Processo Unificado (PU) de Desenvolvimento de de Desenvolvimento de Software Software Francilene Procópio Garcia, D.Sc. [email protected]
  • date post

    07-Apr-2016
  • Category

    Documents

  • view

    226
  • download

    5

Embed Size (px)

Transcript of DDSSCCDDSSCC Engenharia de Software Engenharia de Software Processo Unificado de Desenvolvimento de...

Aula 05 - Eng. SW IILab. Engenharia de Software
Francilene Procópio Garcia, D.Sc.
Processo Unificado de Desenvolvimento 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...
D S C
Engenharia de Software
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.
D S C
Engenharia de Software
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!
D S C
Engenharia de Software
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
D S C
Engenharia de Software
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
D S C
Engenharia de Software
Processo Unificado de Desenvolvimento de Software
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?
D S C
Engenharia de Software
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.
D S C
Engenharia de Software
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 + ...
Arquitetura de S/W
D S C
Engenharia de Software
Casos de Uso Vs. Arquitetura
Casos de Uso
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
Camadas Possíveis na Arquitetura: os seus Subsistemas
Aplicações Específicas
Middleware
Sistemas de S/W
cada Caso de Uso especificado é detalhado e transformado em termos de subsistemas, classes e componentes.
Dependem do
Processo Unificado de Desenvolvimento de Software
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...
D S C
Engenharia de Software
Processo Iterativo e Incremental
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.
D S C
Engenharia de Software
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
OK
Modelo
Os Quatro Ps no PU: Pessoas, Projeto, Produto e Processo
Processo
Pessoas
Projeto
Produto
Tools
Template
Participantes
Resultado
Automação
Quem participa? Como é o proc. de desenvolvimento?
Sistema
Usuários
Testadores
Projetistas
Analistas
Gerente
Projeto
Arquiteto
Analista
Sistema
Arquiteto
Projetista
Capturando os Requisitos Funcionais: aplicando Casos de Uso
Requisitos: Pessoas Vs. Artefatos
Requisitos: Atividades do Processo
Analista
Sistema
Arquiteto
Projetista
Um exemplo: Modelo de Sistema de uma ATM
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.”
Diagrama de Caso de Uso
Cliente
Banco
Retirada
Dinheiro
Depósito
Dinheiro
Tranferência
O Projeto de uma Idéia: Modelo de Análise
Análise: Pessoas Vs. Artefatos
Análise: Atividades do Processo
Arquiteto
Projetista
Exemplo: Modelo de Análise
Modelo de Análise
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.
Cliente
Banco
Exemplo: Modelo de Análise
Diagrama de Colaboração
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.
Textos estruturados ou pseudo-código podem ajudar na documentação da interação entre os objetos!
Cliente
Banco
Exemplo: Subsistemas propostos
Processo Unificado de Desenvolvimento de Software
Estabelecendo o Vocabulário do Problema e de sua Solução: Modelo de Projeto
Projeto: Pessoas Vs. Artefatos
Projeto: Atividades do Processo
Estabelecendo o Vocabulário do Problema e de sua Solução: Modelo de Projeto
Arquiteto
Projetista
Exemplo: Modelo de Projeto
Exemplo: Modelo de Projeto
Diagrama de Classe
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.
Tela
Teclado
Leitor
Cartão
Sensor
Gaveta
Enchedor
Gaveta
Contador
Cédulas
Gerente
Cliente
Saque
Gerente
Transação
Conta
Classe
Persistente
Gerente
Conta
Exemplo: Modelo de Projeto
Diagrama de Sequência
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)
:Tela
:Teclado
: Leitor
Cartão
:Contador
Cédulas
:Gerente
Cliente
:Gerente
Transação
:Cliente
Banco
Valor
Processo Unificado de Desenvolvimento de Software
Modelo de Projeto: Organizando as Classes - Uma visão da estrutura estática
Tela
Teclado
Leitor
Cartão
Sensor
Gaveta
Enchedor
Gaveta
Contador
Cédulas
Gerente
Cliente
subsistema
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.
D S C
Engenharia de Software
Implementação: Pessoas Vs. Artefatos
Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação
Integrador
Sistema
Arquiteto
Modelo
Desdobramento
Modelo
Implementação
Modelo
Desdobramento
Engenheiro
Componente
Componente
Implementação
Subsistema
Interface
Implementação: Atividades do Processo
Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação
Arquiteto
Integrador
Sistema
Engenheiro
Componente
Implementação
Arquitetural
Integração
Sistema
Implementa
Subsistema
Executa
Modelo de Desdobramento: Uma visão arquitetural dos nodos físicos
Três Nós Vs. Três Subsistemas
Client
ATM
Server
Application
ATM
Data
Server
ATM
Internet
Intranet
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.
Estabelecendo as partes necessárias para montar e liberar o sistema: Implementação
Contador
Cédulas
Gerente
Cliente
Sensor
Gaveta
Enchedor
Gaveta
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.
D S C
Engenharia de Software
Teste: Pessoas Vs. Artefatos
Estabelecendo os caminhos para validar e verificar o sistema: Teste
Engenheiro
Componente
Teste
Componente
Teste: Atividades do Processo
Estabelecendo os caminhos para validar e verificar o sistema: Teste
Eng. Teste
Teste: Um Exemplo do Caso de Uso Retirada
Entrada:
O cliente da conta se identifica corretamente
O cliente solicita um saque de $200
Existe caixa suficiente na ATM
Saída:
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