Transcript Semiotic Oriented Autonomous Intelligent Systems Software

O Processo Unified
 Processo de Desenvolvimento de Software
Necessidades
do Usuário
Processo de
Desenvolvimento
 Elementos Participantes
Trabalhadores
Atividades
Recursos Humanos
Artefatos de Software
Sistema de
Software
O Processo Unified
 Ciclo de Vida de um Software
O Processo Unified
O Processo Unified
Modelos
O Começo do Processo
 Pré-Projeto
antes de começar o projeto de um software, (ou seja, antes de
começarmos as iterações) é necessário fazermos um
planejamento prévio de como esse desenvolvimento se dará
 Visão do Problema
Compreensão do Problema - descrição verbal do domínio do
problema - elicitação das necessidades dos investidores
Proposta de Solução de Software - descrição verbal
propondo como se pode visualizar um sistema de software para
resolver o problema
estabelecimento de metas e objetivos
Visão Geral dos Pré-Requisitos
funções do sistema - o que se supõe que o sistema faça
atributos do sistema - o que se supõe que o sistema seja
O Começo do Processo
 Planejamento Logístico
Equipes de Trabalho - pessoas envolvidas no projeto
Grupos Afetados - grupos afetados pelo projeto
Fatos Presumidos - fatos que se presumem verdadeiros antes
de se iniciar o projeto
Riscos - coisas que podem levar ao fracasso ou atrasos no
projeto - potenciais consequências do fracasso ou do atraso
Dependências - outros parceiros, sistemas ou produtos dos
quais o projeto depende para sua implementação
 Glossário (Vocabulário) de Termos
levantamento dos principais termos utilizados para descrever as
características do problema
Modelo Conceitual de Domínio
 Modelo Conceitual
ilustra conceitos significativos de um domínio - aquilo que
devemos estar cientes a respeito do domínio
representa coisas do mundo real, NÃO componentes de
software
obtido a partir da Análise do Domínio
 Conteúdo
conceitos, expressos em um diagrama de classes
associações entre os conceitos
atributos dos conceitos
 Análise Estruturada x Análise Orientada a Objetos
Análise estruturada enfoca em processos ou funções
Análise orientada a objetos enfoca em conceitos
Modelo Conceitual de Domínio
 Lista de Categorias de Conceitos
objetos físicos ou tangíveis
especificações ou descrições de coisas
lugares
transações
ítens sendo transacionados
papéis de pessoas
coisas que contém outras coisas
coisas que são contidas em outras coisas
regras e políticas
eventos
catálogos de coisas
etc...
Modelo Conceitual de Domínio
 Lista de Associações Comuns
A
A
A
A
A
A
A
A
A
A
A
A
é uma parte física de B
é uma parte lógica de B
está fisicamente contido em B
está logicamente contido em B
é uma descrição para B
é um ítem transacionado por B
é armazenado em B
é membro de B
utiliza ou gerencia B
se comunica com B
possui ou é possuído por B
está próximo de B
Modelo Conceitual de Domínio
PagerMessage
get
String
Listener
show
Character
receives
PhoneNumber
has
IncomingCall
opens
uses
dials
Channel
Digit
Ring
has
ConfidentialPhoneNumber
VibraCall
Dialer
feed
search
Catalog
receives
DialingRequest
Password
ConfidentialCatalog
MainCatalog
VoiceRegister
Name
EmergencyCatalog
PreviousDialedMemory
Especificação dos Requisitos
Encontrar Atores e
Casos de Uso
Encontrar Atores e
Casos de Uso
 Objetivo
iniciar o processo de especificação dos requisitos,
desenvolvendo cenários genéricos descrevendo a interação
entre o(s) usuário(s) e o sistema
 Nesta Atividade
Explora-se a descoberta de diferentes possíveis casos de uso
Casos de uso devem envolver todos os tipos de interações
desejadas entre o sistema e os usuários
 Caso de Uso
Narrativa genérica de um caso de interação entre o(s)
usuário(s) e o sistema
 Resultado
diagrama de casos de uso
Diagrama de Casos de Uso
 Exemplo: Casos de Uso para um Telefone Celular
User
Delete Number in Memory
Program Number in Memory
<<extends>>
Search Memory
<<extends>>
Dial Confidential Phone Number
Check Password
<<include>>
Validate User
Dial Number in Memory
Dial Phone Number
Voice Validation
Priorização dos Casos de Uso
Priorização dos Casos de Uso
 Objetivo
coletar subsídios para a priorização dos casos de uso,
determinando quais deles devem ser desenvolvidos (i.e.
analisados, desenhados, implementados, etc) nas primeiras
iterações e quais podem ser desenvolvidos nas iterações
posteriores
 Resultados
capturados na visão arquitetural do modelo de casos de uso
esta visão é considerada pelo gerente de projeto e utilizada para
o planejamento do que deve ser desenvolvido na iteração
este planejamento leva em consideração também aspectos nãotécnicos, tais como aspectos políticos ou estratégicos
visão arquitetural deve destacar os casos de uso que descrevem
funcionalidades críticas ou importantes
Detalhamento de Casos de Uso
Detalhamento de Casos de Uso
 Objetivo
descrever de maneira detalhada os caso de uso selecionados na
etapa anterior, referenciando de maneira minuciosa o fluxo de
eventos entre os atores e o sistema, incluindo-se como o caso
de uso começa, termina e quais as atividades realizadas tanto
pelos atores como pelo sistema
 Descrição de Caso de Uso
pode ser realizada por meio de diferentes tipos de artefatos de
software:
texto (sumarizada ou detalhada)
diagrama de estados
diagrama de atividades
a escolha do artefato ideal depende do grau de complexidade
do caso de uso
Exemplo de Descrição
(Sumária) de Caso de Uso
 Caso de Uso
 Atores
 Propósito
DialPhoneNumber
Usuário
Descrever o processo de discagem de
um número
 Fluxo de Eventos O Usuário informa ao dispositivo que
deseja fazer a discagem de um
número, entra com uma sequência de
n dígitos, informa ao sistema que
terminou o número e o sistema inicia
o processo de discagem
 Tipo
Primário e Conceitual
Variações na Descrição de
Casos de Uso
 Descrição de Caso de Uso
pode se tornar bem intrincada
 Estratégia Básica
descrever um fluxo de eventos básico, do começo ao fim, e
acrescentar as excessões que podem aparecer a cada instante
todas as alternativas, desvios ou excessões devem ser
colocadas, para que se possa dizer que o caso de uso está
especificado
 Elementos Essenciais
pré-condições: condições necessárias para que o caso de uso
possa se iniciar
pós-condições: condições que determinam que o caso de uso
tenha realmente se encerrado
Detalhamento de um Caso de Uso
por Diagrama de Atividades
Prototipação da
Interface com o Usuário
Prototipação da
Interface com o Usuário
 Objetivos
construir um protótipo da interface com o usuário
essa interface não será a interface definitiva, mas deve conter
as informações necessárias para a efetivação dos casos de usos
descritos nas etapas anteriores
 Etapas
observação dos casos de uso e abstração das informações
necessárias a serem implementadas pelas interfaces, para cada
ator
criação física de protótipos de interfaces com o usuário que
ilustram como o sistema poderia implementar os casos de uso
 Resultado Final
conjunto de sketches e protótipos de interface com o usuário,
que servirão de inspiração posteriormente na fase de design
Estruturação do Modelo de
Casos de Uso
Estruturação do Modelo de
Casos de Uso
 Objetivo
reestruturar os elementos do modelo de casos de uso
capturados anteriormente (que podem ter sido capturados de
maneira independente entre si) e gerar um modelo que seja
homogêneo, consistente e simples de ser interpretado
 Identificando Descrições Compartilhadas de
Funcionalidade
relação de generalização
 Identificando Descrições Adicionais ou Opcionais de
Funcionalidade
relação de extensão
 Identificando Descrições Repetidas de Funcionalidade
relação de inclusão
Análise
 Análise dos Requisitos: aprofundamento das
investigações, detalhamento e refinamento das
especificações dos requisitos
 Objetivos
obter uma melhor compreensão dos requisitos, mantendo uma
descrição dos requisitos que seja compreensível e auxilie no
posterior design do sistema
transladar as especificações dos requisitos que se encontram na
“linguagem do cliente” para uma representação que use uma
“linguagem do desenvolvedor”
passar de um modelo de casos de usos para um modelo de
análise
 Principal Desafio: manter um nível abstrato de
investigação, sem entrar em questões de design
Classes Estereotipadas
 Classes Boundary
utilizada para modelar a interação
entre o sistema e os atores
interação envolve o recebimento e
apresentação de informações
 Classes Control
representam a coordenação,
sequenciamento, transações e
controle de outros objetos
derivações e cálculos
 Classes Entity
modela informações (dados) de
longa duração, frequentemente
persistentes
Análise
Análise Arquitetural
Análise Arquitetural
 Objetivo
gerar um outline do modelo de análise e da arquitetura por
meio da identificação dos pacotes de análise, das classes de
análise e de requisitos especiais necessários
 Sub-Tarefas
Identificação dos Pacotes de Análise
Identificação de Classes Óbvias do tipo “Entity”
Identificação de Requisitos Especiais
persistência, distribuição ou concorrência, restrições de segurança,
tolerância a falhas e gerenciamento de transações
Análise dos Casos de Uso
Análise dos Casos de Uso
 Objetivos
identificação das classes de análise cujos objetos são
necessários para implementar o fluxo de eventos de um caso de
uso em particular – diagrama de classes estereotipadas
distribuição do comportamento em um caso de uso por um
conjunto de objetos interagindo entre si – diagrama de
colaboração ou sequência
captura dos requisitos especiais relativos à realização de um
caso de uso em particular
Análise de Casos de Uso
 Exemplo de Diagrama de Classes de Análise
Análise de Casos de Uso
 Exemplo de Diagrama de Colaboração da Análise
Análise de uma Classe
Análise de uma Classe
 Objetivos
identificação e formalização das responsabilidades de uma
classe de análise – contrato
identificação e formalização dos atributos e relacionamentos
de uma classe de análise – enriquecimento do diagrama de
classes
captura de requisitos especiais
 Identificação de Responsabilidades
Responsabilidades: papéis que objetos da classe assumem
em diferentes realizações de casos de uso
Associadas às mensagens que uma classe pode receber
Análise de uma Classe
 Descrição de Responsabilidades por meio de Contratos
Contratos: descrevem as responsabilidades de uma determinada
classe, em termos de quais mudanças no estado do objeto são
realizadas quando este recebe mensagens (ou invocações)
descrevem O QUE o objeto deve fazer, sem explicar COMO ele o
faz
 Para cada mensagem aparecendo em um diagrama de
colaboração, deve haver um contrato correspondente
 Seções de um Contrato
Um contrato está dividido em seções
Cada seção provê informações sobre uma parte específica do
contrato
Nem todas as seções são obrigatórias, devendo aparecer
quando necessário
Análise de uma Classe
 Seções de um Contrato
Nome: nome da operação e eventualmente seus parâmetros
Responsabilidades: uma descrição informal das
responsabilidades que a operação deve implementar
Tipo:conceitual, classe de software ou interface
Referências Cruzadas: outras classes que utilizam o mesmo
contrato, etc.
Notas: informações adicionais, algoritmos, etc.
Exceções: casos excepcionais
Saídas Secundárias: saídas não relacionadas à interface com
o usuário, e.g. mensagens de erros, logs, etc.
Pré-Condições: condições referentes ao estado do sistema
antes da execução da operação
Pós-Condições: estado do sistema após a conclusão da
operação
Analisando Pacotes
Analisando Pacotes
 Objetivos
garantir a independência entre diferentes pacotes
garantir que um pacote de análise implementa seu propósito de
realizar classes de domínio ou casos de uso
descrever dependências entre pacotes, de tal forma que o efeito
de mudanças futuras possa ser estimado
 Guidelines para a Análise de Pacotes
definir e formalizar as dependências entre pacotes, dependendo
das classes que estes contiverem
garantir que os pacotes contenham as classes corretas. Deve-se
tentar manter os pacotes coesos, por meio da inclusão somente
de objetos que estejam funcionalmente correlacionados
tentar limitar as dependências entre pacotes - deve-se
considerar a relocação de classes que criem muitas
dependências entre pacotes
Design
 Objetivos do Design
Requisitos não-funcionais e restrições relacionadas a:
linguagens de programação, reuso de componentes, sistemas
operacionais, tecnologias de distribuição e concorrência,
tecnologias de bancos de dados, tecnologias de interface com o
usuário, tecnologias de gerenciamento de transações, etc ...
Definição de subsistemas, interfaces e classes
Decomposição do trabalho entre equipes de trabalho
Interfaces entre subsistemas
arquitetura do software, para a sincronização entre diferentes
equipes de trabalho
Especificação de elementos lógicos
Abstração objetiva da implementação do sistema
implementação seja um mero refinamento para o design
geração automática de código
Patterns e Design Patterns
 Patterns
desenvolvedores de software orientado a objetos experientes
acumularam um repertório de princípios gerais e soluções que
os guiam frequentemente em suas decisões no desenvolvimento
de novos softwares
esses princípios são formalizados/compilados, dando origem aos
chamados Patterns (padrões)
patterns codificam um conhecimento comum sobre princípios
de como resolver problemas que aparecem repetidamente
 Formato
par problema/solução que pode ser aplicado em novos
contextos, acompanhados de conselhos sobre como devem ser
aplicados
nomes sugestivos: enraízam o conceito do pattern em nossa
memória e promovem seu uso, sempre que possível
Patterns e Design Patterns
 Origem dos Patterns
“Design Patterns: Elements of Reusable Object-Oriented
Software” de Erich Gamma, Richard Helm, Ralph Johnson e
John Vlissides (Gang of Four - GoF)
Vários diferentes domínios:
organizações, processos, ensino, arquitetura, etc….
Atualmente: arquitetura e design de software, outras fases do
desenvolvimento de software (análise, etc…)
Outros livros:
Pattern-Oriented Software Architecture: A System of Patterns”
(POSA book), de Frank Buschmann, Regine Meunier, Hans Rohnert,
Peter Somerlad e Michael Stal (Siemens Gang of Five - GoV)
Pattern Languages of Program Design and PLPD 2 - selected
papers from 1st and 2nd conferences on Patterns Languages of
Program Design
Frameworks
 Frameworks de Software
são mini-arquiteturas reutilizáveis que provêm a estrutura
genérica e comportamento para famílias de abstrações de
software, junto com um contexto de metáforas que especificam
sua aplicação e uso dentro de um dado domínio
correspondem a um conjunto de classes cooperantes que
permitem uma reutilização de design para uma classe de
software específica. Um framework provê uma orientação
arquitetural, definindo quais as responsabilidade e colaborações
entre objetos. Um designer customiza um framework para uma
aplicação em particular, normalmente por meio do subclasseamento e geração de instâncias de classes derivadas das
classes do framework
reutilização do design por meio da reutilização do código
implementação de um sistema de design patterns
Design
Design Arquitetural
Design Arquitetural
 Objetivo
desenvolver um outline dos modelos de design e de distribuição,
bem como sua arquitetura, identificando-se os seguintes:
nós computacionais envolvidos e arquitetura de rede
subsistemas e suas interfaces
classes de design arquiteturalmente significativas, tais como
classes ativas
mecanismos genéricos de design que garantam a implementação
dos requisitos especiais sobre persistência, distribuição,
desempenho, etc.
 Reuso
nesta atividade, considera-se as diferentes possibilidade de
reuso, tais como o reuso de partes, componentes, subsistemas,
etc...
Design Arquitetural
 Sistemas de Software
Aplicações Monolíticas
Aplicações Multi-Thread
Sistemas Cliente-Servidor
Sistemas Baseados em Componentes
Design Arquitetural
 Identificação de Nós e Configuração de Rede
configuração de rede pode ser fundamental para a aplicação em
desenvolvimento
configurações de rede normalmente utilizam uma arquitetura
em três camadas
aspectos da configuração de rede incluem:
quais nós estão envolvidos e quais suas capacidades
que tipo de conexões há entre os nós e quais protocolos utilizam
quais as características das conexões (capacidade, qualidade, etc)
existe necessidade de processamento redundante, etc..
Conhecendo os limites e possibilidades dos nós e suas
conexões, o arquiteto pode incorporar tecnologias tais como
ORBs (Object Request Brokers), serviços de replicação de
dados, etc ...
Design Arquitetural
 Exemplo de Identificação de Nós e Configuração de
Rede
cada configuração de rede, incluindo configurações especiais
para teste e simulações, deve ser descrita em um diagrama de
distribuição em separado
Design Arquitetural
 Identificando Subsistemas e suas Dependências
Design Arquitetural
 Identificando Interfaces de Subsistemas
interfaces de subsistemas definem operações que são acessíveis
“de fora” do subsistema
essas interfaces são providas por classes ou outros subsistemas
(recursivamente) dentro do subsistema
inicialmente, antes que o conteúdo de um subsistema seja
conhecido
começa-se considerando as dependências entre subsistemas
em seguida, analisa-se as classes dentro dos pacotes de análise
interfaces para os subsistemas de middleware e software de
sistema
interfaces pré-definidas pelo produto utilizado
não basta identificar somente quais são as interfaces
identificar as operações disponibilizadas por cada interface
Design Arquitetural
 Identificando Classes de Design Arquiteturalmente
Significativas
classes de design derivadas de classes de análise
identificação de classes ativas: considerações sobre os requisitos
de concorrência do sistema
requisitos sobre desempenho, throughput, disponibilidade e tempo
de resposta necessários pelos diferentes atores interagindo com o
sistema (e.g. caso o ator demande certo tempo de resposta, devese disponibilizar um objeto ativo somente para a interação)
distribuição do sistema pelos nós (e.g. caso seja necessário
suportar distribuição por diversos nós, cada nó demandará pelo
menos um objeto ativo para gerenciar a comunicação)
outros requisitos, tais como requisitos de inicialização e shutdown,
sobrevivência, evitação de deadlocks, capacidade de
reconfiguração de nós, etc ...
Design Arquitetural
 Identificação de Mecanismos Genéricos de Design
neste passo, estudam-se os requisitos comuns, tais como os
requisitos especiais identificados durante a análise, decidindo-se
como implementá-los, dadas as tecnologias de implementação
disponíveis
resultado é um conjunto de mecanismos genéricos de design,
instanciados em classes de design
tipos de requisitos instanciados
persistência
distribuição de objetos transparente (objetos distribuídos)
requisitos de segurança
detecção e recuperação de erros
gerenciamento de transações
Design de Casos de Uso
Design de Casos de Uso
 Objetivos
identificação das classes de design e subsistemas cujas
instâncias são necessárias para realizar o fluxo de eventos de
um caso de uso
distribuição do comportamento do caso de uso entre objetos de
design interagindo entre si ou com outros subsistemas
definição dos requisitos sobre as operações disponíveis nas
classes de design e/ou subsistemas com interfaces
 Sub-Atividades
identificação das classes de design participantes
descrição das interações entre objetos de design
identificação de subsistemas participantes e suas interfaces
descrição das interações entre subsistemas
captura dos requisitos de implementação para o caso de uso
Design de Casos de Uso
 Identificação das Classes de
Design Participantes
estudo das classes de análise
estudo dos requisitos especiais
diagrama de classes de design
 Descrição das Interações
diagramas de sequência ou de
colaboração
Design de Casos de Uso
 Identificação de Subsistemas e Interfaces
estudo das classes de análise
estudo dos requisitos especiais
diagrama de classes
 Descrição das Interações entre Subsistemas
diagramas de sequência
lifelines denotam subsistemas e não objetos
cada subsistema deve ter sua própria lifeline
mensagens dizem respeito a operações da interface do subsistema
 Captura de Requisitos de Implementação
captura de requisitos (não funcionais) que afetam diretamente a
implementação
Design de Classes
Design de Classes
 Objetivos
criação de classes de design que exercem seu papel na
realização do caso de uso, obedecendo os requisitos nãofuncionais que se aplicam
aspectos sendo detalhados:
operações
atributos
relacionamentos dos quais participa
métodos (como realizar as operações)
estados válidos
dependências para com mecanismos genéricos de design
requisitos importantes para a implementação
realização correta das interfaces com as quais está envolvida
Design de Classes
 Sub-Etapas
criando um outline da classe de design
identificando operações e atributos
identificando associações, agregações e generalizações
descrevendo métodos
descrevendo estados
gerenciando requisitos especiais
Design de Subsistemas
Design de Subsistemas
 Objetivos
garantir que os subsistemas sejam tão independentes quanto
possível de outros subsistemas e suas interfaces
garantir que os subsistemas provêm uma interface adequada
garantir que os subsistemas realizam seu propósito, ou seja,
oferecem uma realização adequada das operações definidas por
suas interfaces
 Sub-Etapas
Gerenciamento das Dependências entre Subsistemas
Gerenciamento das Interfaces providas pelo susbsistema
Gerenciamento do Conteúdo dos subsistemas
para cada interface, associa com as classes de design do
subsistema que provê a funcionalidade
Implementação
 Implementação
utiliza-se os artefatos desenvolvidos no design para implementar
o sistema em termos de seus componentes, ou seja, código
fonte, scripts, binários, executáveis, etc ...
 Objetivos
planejar a integração do sistema necessária na iteração corrente
distribuir o sistema entre componentes executáveis localizados
nos nós do modelo de distribuição
implementação das classes de design e dos subsistemas
especificados no design (geração de código)
teste individual dos componentes e posterior integração em
módulos executáveis
Implementação
 Componentes
possuem diversos estereótipos
«executable», «file», «library», «table», «document»
possuem relacionamentos do tipo «trace» com os elementos do
modelo que implementam
podem implementar individualmente diversos modelos
diferentes
Implementação
Implementação
 Subsistemas de Implementação
package em Java
project em VisualBasic
diretório de arquivos em um projeto C++
subsistema em IDEs tais como o Rational Apex
component view package, em ferramentas de modelagem visual
tais como o Rational Rose
Implementação
Implementação Arquitetural
Implementação Arquitetural
 Objetivo
criar um outline do modelo de implementação
identificação de componentes arquiteturalmente significativos, tais
como componentes executáveis
mapeamento desses componentes em nós da configuração de rede
 Identificação de Componentes arquiteturalmente
significativos
diagrama de componentes
 Identificação dos Componentes Executáveis e seu
Mapeamento nos Nós
diagrama de distribuição, mostrando onde se localizam
componentes
objetos ativos (aqueles com Thread de controle individual)
Integração do Sistema
Integração do Sistema
 Objetivos
criação da um plano de construção integrado, descrevendo as
construções necessárias na iteração corrente e quais os
requisitos que essa construção implementa
definição efetiva de quais componentes serão integrados e
criação de scripts de compilação e linkagem
 Planejamento da Construção
verificação de implementações de iterações anteriores e
eventual reuso de partes já consolidadas
adição de funcionalidades para a construção corrente, por meio
da adição de novos casos de uso
 Integrando a Construção
criação de scripts de compilação e linkagem das versões
corretas dos diferentes componentes sendo integrados
Implementação de Subsistemas
Implementação de Subsistemas
 Objetivos
garantir que a implementação de um subsistema cumpra seu
papel, a cada construção, como estipulado pelo plano de
construção integrada
garantir que os casos de uso e cenários estejam corretos e que as
interfaces estejam corretas
 Gerenciamento do Conteúdo de Subsistemas
mesmo que o conteúdo de um subsistema já esteja
determinado pelo arquiteto, ele pode requerer pequenos
refinamentos implementados pelo engenheiro de componentes,
a medida que a implementação se desenvolve
à medida que subsistemas contenham outros subsistemas
recursivamente, a metodologia de mapeamento entre
componentes e classes de design é análoga em cada nível
Implementando Classes
Implementando Classes
 Objetivos
implementação de classes de design na forma de componentes
distribuição do código fonte em um ou diversos arquivos
• componentes do tipo «file»
geração do código fonte a partir das classes de design e dos
relacionamentos em que participa
• esqueletos de código podem ser gerados automaticamente
implementação das operações das classes de design em termos de
métodos
• alguns tipos de operações podem também ser geradas
automaticamente, sendo complementadas com edição posterior
verificação de que o componente provê a mesma interface que a
classe de design que implementa
eventualmente, conserto de defeitos, quando a classe já havia sido
implementada em outras iterações
Teste de Unidade
Teste de Unidade
 Objetivos
realização de um teste individual do componente implementado,
sem considerar sua posterior integração
 Tipos de Testes
Teste de Especificação
verifica o comportamento observável externo da unidade, sem
entrar no mérito de como esse comportamento é implementado
focaliza nas entradas e saídas da unidade
Teste Estrutural
verifica a implementação interna da unidade, fazendo com que
cada trecho do código seja executado
Outros Testes
testes de desempenho, uso de memória, escalabilidade e
capacidade
Testes
 Fase de Testes
verificação dos resultados da implementação por meio do teste
de cada módulo do sistema e sua integração
 Objetivos
planejamento dos testes a serem executados em cada iteração
design e implementação dos testes por meio de casos de teste
que especificam o que testar e quais os procedimentos a serem
utilizados para os testes
criação de componentes de teste executáveis para a automação
de testes, quando possível
avaliar sistematicamente os resultados de cada teste e
encaminhar os módulos defectivos para que estes possam ser
retrabalhados
Testes
 Modelos de Teste
descreve como componentes executáveis do modelo de
implementação são testados por meio de testes de integração e
testes de sistema
descreve os aspectos específicos do sistema que serão testados
coleção de casos de teste, procedimentos de teste e
componentes de teste
 Caso de Teste
corresponde a um caso de uso, só que com finalidades de teste
especifica um cenário de teste, incluindo o que testar, com que
entradas e com quais resultados esperados
caso de teste pode estar associado a um caso de uso ou à
realização do caso de uso no design
Testes
 Procedimentos de Teste
especifica como realizar
um ou mais casos de
teste
 Componente de Teste
automatizam um ou mais
procedimentos de teste
linguagens de script ou
linguagens de
programação
Testes
 Tipos de Teste
Testes de Instalação
verificam que o sistema pode ser instalado na plataforma do cliente
e que o sistema opera corretamente após instalado
Testes de Configuração
verificam que o sistema opera corretamente sob diferentes
configurações
Testes Negativos
tentam ocasionar falhas no sistema para revelar suas fraquezas
tenta-se utilizar o sistema de maneiras para as quais ele não foi
projetado, e.g. testando-se configurações de rede defeituosas,
hardware insuficiente ou demanda de uso (carga) intensiva
Testes de Stress
tentam verificar como o sistema se comporta quando os recursos
disponíveis são insuficientes ou estão indisponíveis
Testes
Planejamento de Testes
Planejamento de Testes
 Objetivos
planejar os esforços de teste dentro de uma iteração
descrevendo uma estratégia de testes
estimando os requisitos para o esforço de teste, tais como recursos
humanos e do sistema
criando uma escala de testes a ser executada
 Plano de Testes
são construídos com base nos diversos modelos utilizados nas
fases de especificação, análise, design e implementação
 Estratégia Geral de Testes
que tipos de testes serão executados, como executá-los, quando
executá-los e como avaliar os resultados dos testes
testes custam recursos e tempo, portanto deve-se efetuar uma
solução de testes que tenha uma boa relação custo/benefício
Projeto de Testes
Projeto de Testes
 Objetivos
identificar e descrever casos de teste para cada módulo
identificar e estruturar procedimentos de teste especificando
como realizar os casos de teste
 Sub-Etapas
Projetando casos de teste de integração
Projetando casos de teste de sistema
Projetando casos de teste regressivos
aproveitam casos de teste de iterações anteriores
Identificando e Estruturando Procedimentos de Teste
 Regra Geral
deve-se utilizar um conjunto de testes que requeiram um
mínimo esforço, dado um plano de testes
mínimo “overlap” entre casos de teste
Implementação de Testes
Implementação de Testes
 Objetivos
automatizar procedimentos de teste por meio da criação de
componentes de teste, se possível (nem todos os procedimentos
de teste podem ser automatizados)
 Componentes de Teste
criados utilizando os procedimentos de teste como entrada
quando se utiliza uma ferramenta de automação, um conjunto
de ações são previamente criadas para que o módulo em
questão seja testado. A própria ferramenta se encarrega de
criar os componentes de teste
quando programando os componentes de teste explicitamente,
utiliza-se os procedimentos de teste como uma forma de
especificação para que os componentes de teste sejam
desenvolvidos
Teste de Integração
Teste de Integração
 Objetivos
realizar os testes de integração especificados para cada módulo
do sistema
 Sequência de Testes de Integração
realizar os testes de integração relevantes por meio da execução
manual dos procedimentos de teste para cada caso de teste ou
por meio de algum componente de teste disponível para o
procedimento de teste em questão
comparação dos resultados com os resultados esperados e a
discriminação dos casos que apresentaram resultados
inesperados
relatar os defeitos encontrados ao engenheiro de componentes,
para que estes possam corrigir os componentes defeituosos
relatar os defeitos ao engenheiro de testes, para que este possa
estimar os resultados finais da sequência de testes
Teste de Sistema
Teste de Sistema
 Objetivos
realizar os testes de sistema especificados a cada iteração,
capturando os resultados do teste
 Teste de Sistema
se inicia quando os testes de integração indicam que o sistema
atende as metas de qualidade quanto a integração de seus
componentes para a iteração corrente (e.g. 95 % dos testes de
integração executam com resultado esperado)
são realizados de maneira análoga aos testes de integração (i.e.
seguindo uma sequência de testes análoga ao dos testes de
integração
avaliam o comportamento do funcionamento do sistema como
um todo, e não somente com relação à integração individual
entre alguns de seus componentes
Avaliação de Testes
Avaliação de Testes
 Objetivo
avaliação dos esforços de teste para a iteração corrente
comparação dos resultados com as metas especificadas no
planejamento de testes
criação de métricas que determinem o nível de qualidade do
software, especificando maiores testes que necessitem ser
realizados
 Exemplos de Métricas
Métricas de Completude
derivadas da cobertura dos casos de teste e dos componentes de
teste. Indicam qual a porcentagem de casos de teste que foram
executados e qual a porcentagem de código que foi testada
Métricas de Confiabilidade
baseadas na análise dos defeitos descobertos com relação aos
casos que tiveram um resultado como esperado
Referências Complementares
 The Unified Software Development Process
Ivar Jacobson, Grady Booch, James Rumbaugh
Addison-Wesley, 1999 - ISBN 0-201-57169-2
 UML Distilled, Second Edition: A Brief Guide to the
Standard Object Modeling Language
Martin Fowler, Kendall Scott, Grady Booch
2nd edition, Addison-Wesley, 1999 - ISBN 0-201-65783-X
 Applying UML and Patterns
Craig Larman
Prentice Hall, 1998 - ISBN 0-137-48880-7
 Unified Modeling Language (UML), version 1.5
Norma Técnica da OMG
ftp://ftp.omg.org/pub/docs/formal/03-03-01.pdf