Introdução à Engenharia de Software - Marcos Kalinowski

Introdução à Engenharia de SoftwareCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil

Prof. Dr. Marcos Kalinowski

[email protected]

http://www.inf.puc-rio.br/~kalinowski

Apresentação de DisciplinaCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Apresentações

3

• Marcos Kalinowski

– Professor do Departamento de Informática da PUC-Rio

– Orienta Mestrado e Doutorado na área de Engenharia de Software

– Membro da rede de excelência ISERN (International Software

Engineering Research Network)

– Mais informações – http://www.inf.puc-rio.br/~kalinowski

Quem são vocês?

Nome?

Experiência em Engenharia

de Software?

Expectativas?

Ementa e Conteúdo Programático

4

• Introdução à Engenharia de Software: Motivação e Importância [1 hora]

• Processos de Software [3 horas]

– Processo Unificado

– Métodos Ágeis

• Engenharia de Requisitos [10 horas]

• UML e Projeto de Software [14 horas]

– UML

– Princípios de Projeto

– Padrões de Projeto

• Refatoração e Modularização de Aplicações [4 horas]

• Arquitetura de Software [4 horas]

– Visões e Padrões Arquiteturais

– Componentes e Frameworks

• Verificação e Validação de Software [10 horas]

– Inspeções

– Teste de Software

• Gerência de Configuração de Software [2 horas]

• Fundamentos de Qualidade de Software [5 horas]

– Modelos de Qualidade do Processo e do Produto

• Avaliação escrita [2 horas]

Avaliação

5

• Avaliação 1 = Prova sem consulta

• Avaliação 2 = Trabalho em grupo sobre Engenharia de Requisitos

• Avaliação 3 = Trabalho em grupo sobre Projeto de Software

• Nota Final = (Av 1 + (Av 2 + Av 3)/2)/2

Atividades Práticas

6

• Trabalhos em grupo

– Elaboração de uma especificação funcional (requisitos)

– Elaboração de uma especificação técnica (projeto)

• Atividades práticas em grupo

– Diversas no decorrer do curso

• O grupo deve ser o mesmo durante todo o curso

– Até 3 participantes

Bibliografia

7

• Com uma participação ativa é possível acompanhar as aulas pelos

slides e as atividades práticas, mas os livros são uma boa forma de

aprofundamento nos conteúdos da aula.

– FOWLER, M. UML Distilled: A Brief Guide to the Standard Object Modeling

Language, 3rd Edition, Addison-Wesley, 2003.

– LARMAN, C.; "Utilizando UML e Padrões". 3ª Edição, Bookman, 2007.

– SOMMERVILLE, I. Software Engineering, 10th Edition, Addison-Wesley,

2015.

Introdução à Engenharia de Software: Motivação e Importância

Curso de Aperfeiçoamento Avançado em Guerra EletrônicaMarinha do Brasil


[email protected]


O que é Engenharia de Software?

9

“Engenharia de Software é a aplicação de uma

abordagem sistemática, disciplinada e

quantificável ao desenvolvimento, operação e

manutenção de software”

IEEE Std 610.12 (1990)

“If one end of the software development competency

spectrum is occupied by code-and-fixe development, the

other end is occupied by software engineering...”

[McConnel99]

Necessidade

10

• Por que preciso de Engenharia de Software?

– Programação é parte importante do processo de Engenharia de

Software, mas não é tudo!

• Precisamos também saber...

– o que programar,

– como programar,

– se o que foi programado está certo,

– etc.

Fatores Envolvidos

11

• Fazer software no “mundo real” deve considerar

fatores como:

– Custo

– Prazo

– Qualidade

• Em função do tamanho do software, esses fatores

se tornam difíceis de garantir!

Cenário 1: Agenda Pessoal

12

• Objetivo

– Guardar o nome e o

aniversário de até 50

pessoas

– Quanto custa para fazer?

– Quanto tempo vai levar para

ficar pronto?

– Qual a conseqüência no caso de

defeito?

Cenário 2: Boeing 777

13

• Objetivo

– Controlar todo o hardware

do Boeing 777

– Quanto custa para fazer?

– Quanto tempo vai levar para

ficar pronto?

– Qual a conseqüência no caso

de defeito?

Cenário 2: Boeing 777

14

• Tamanho

– Mais de 4 milhões de linhas de código

– Linguagem dominante (>99%): Ada

• Documentação

– De 100 a 10.000 páginas por sub-

sistema

– Total de 79 sub-sistemas integrados

• Duração

– 4,5 anos de desenvolvimento

• Ampla utilização de Engenharia de

Software

• Em operação desde 1995

Outros cenários extremos...

15

• Toyota Lexus LS460: > 7 MLOCs

• Eclipse Mars: > 18 MLOCs

• SAP: > 250 MLOCs

Mas fazer software não é arte?

16

• Parte arte, parte engenharia...

– Se o cantor/ator/pintor errar, a audiência fica

chateada

– Se o engenheiro civil errar o prédio pode cair

– Se o médico errar o paciente pode morrer

• Se o desenvolvedor de software errar, o que

pode acontecer?

Caso real 1: Therac-25

17

• Máquina de radioterapia controlada por computador

• Problema:– Doses indevidas de radiação emitidas

• Causa:– Interface com usuário inapropriada

– Documentação deficiente

– Software reutilizado sem ser adaptado para o novo hardware

– Software de sensores de falha com defeito

• Conseqüências– Ao menos 5 mortes entre 1985 e 1987

http://sunnyday.mit.edu/papers/therac.pdf

Caso real 2: Ariane 5

18

• Foguete lançador de satélites

• Problema:

– O foguete se auto-destruiu após o lançamento

• Causa:

– Software reutilizado sem ser adaptado para o novo

hardware

– Ausência de testes em solo deste software

– Defeito apresentado em vôo

• Conseqüências

– Prejuízo de mais de US$ 370.000.000,00 em 1996

Dowson, Mark. 1997. The Ariane 5 software failure.

SIGSOFT Softw. Eng. Notes 22, no. 2.

• Custo do projeto: US$ 4.9 bilhões

– 100 mil passageiros por dia

– 1,200 vôos

– 53 milhas quadradas

– 94 portões de embarque e

desembarque

– 6 pistas de pouso / decolagem

• Erros no sistema automático de

transporte de bagagens:

– Atraso na abertura do aeroporto com

custo total estimado em US$360

Milhões

– Altos custos para consertar o sistema

19

Caso real 3: Aeroporto Internacional de Denver

20

Margaret Hamilton, Director of the Software Engineering Division of the MIT

Instrumentation Laboratory, which developed on-board flight software for

the Apollo space program.

Caso bem sucedido: Apollo space program

21

Exercícios de Fixação

Exercícios: Engenharia de Software

22

• Defina em suas próprias palavras:

– O que é Engenharia de Software?

– Por que a Engenharia de Software é

importante?

Processos de Software (Introdução)Curso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Processo de Engenharia de Software

“Tem como objetivo garantir a produção de software de alta qualidade que está de acordo com as necessidades dos seus usuários finais com um cronograma e custo previsível”

24

• Conjunto de atividades,– com modelo de ciclo de vida,

– bem definidas,

– com responsáveis,

– com artefatos de entrada e saída,

– com dependências entre as mesmas e ordem de execução,

– descrição sistemática de como devem ser realizadas.

25

Processo de Engenharia de Software

26

RUP: Exemplo de Processo de um Método Orientado a Planos

27

Scrum: Exemplo de Processo de um Método Ágil

• Modelagem do Negócio

• Requisitos

• Arquitetura & Projeto

• Implementação

• Testes

• Implantação

• Gerenciamento e Planejamento

• Gerencia de Configuração e Mudanças

28

Exemplos de Atividades

• Entender a estrutura e dinâmica da organização.

• Entender os problemas e identificar as melhorias

em potencial.

29

Modelagem do Negócio

• Estabelecer e manter a concordância entre o cliente

e “stakeholders” sobre o que o sistema vai fazer.

• Definir os limites do sistema.

• Prover um base para estimar tempo e custo de

desenvolvimento.

• Frequentemente formalizados em um documento de

especificação funcional.

30

Requisitos

• Exemplo de Especificação Funcional

31

Requisitos

• Definir uma Arquitetura para o Sistema a partir dos

Requisitos.

– Viabilizando o atendimento aos requisitos não

funcionais (segurança, desempenho, usabilidade,

confiabilidade, etc).

• Definir o Projeto para o Sistema a partir dos

Requisitos.

– Seguindo a arquitetura definida e viabilizando o

atendimento aos requisitos funcionais.

32

Arquitetura e Projeto

• Arquitetura.

– Muitas vezes formalizada em um documento de

especificação arquitetural.

• Projeto.

– Muitas vezes formalizado em um documento de

especificação técnica.

33


• Exemplo de Especificação Arquitetural

34


• Exemplo de Especificação Técnica

35


• Definir a organização do código.

• Realizar a escrita do código.

• Testar as unidades.

• Integrar as unidades.

36

Implementação

• Encontrar e documentar falhas.

• Validar se o sistema atende ao que especificado e

às necessidades dos clientes.

• Verificar se o sistema foi construído conforme

projetado.

37

Testes

• Garantir que o sistema está disponível para o

usuário final.

• Controlar os artefatos produzidos no

desenvolvimento do projeto.

• Evita a ocorrência dos seguintes problemas:

– Atualizações simultâneas;

– Múltiplas versões;

– Notificação limitada.

Gerência de Configuração e Mudanças

38

Implantação

• Estabelecer e manter planos que definem as

atividades, recursos e responsabilidades do projeto,

bem como prover informações sobre o andamento

do projeto que permitam a realização de correções

quando houver desvios significativos no

desempenho do projeto.

• Gerenciamento de Riscos.

39

Gerenciamento de Planejamento

40

• Definem as diferentes fases na existência de um

produto de software, além de definir também os

princípios e diretrizes que vão guiar a realização

destas fases

• Definem a estrutura e a filosofia segundo as quais

o processo de software tem que ser executado

Modelos de Ciclo de Vida de Processos

41

• A adoção de um ciclo de vida não é suficiente

para guiar e controlar um projeto de software

na prática. Outras características devem ser

levadas em consideração durante a vida de

um produto de software:

– Organização das atividades do processo

– Recursos humanos, hardware e software

– Procedimentos de operação

– Políticas de desenvolvimento e restrições

– Tipos de software


42

• As características básicas comuns a todos os

modelos são:

– Descrever as principais fases do desenvolvimento

– Definir as principais atividades a serem realizadas

durante cada uma das fases

– Especificar os produtos de cada uma das fases e

insumos para o início das fases

– Fornecer um framework sobre o qual as atividades

necessárias podem ser mapeadas


43

• Principais modelos de ciclo de vida de software:– Modelo Cascata

– Modelo V

– Modelo Incremental

– Modelo Evolutivo

– Modelo Espiral

– Modelo de Ciclo de Vida Associado ao RUP

– Ciclo de Vida do Scrum

IncrementalCascata Espiral

RUP

Evolutivo

...


Scrum

Modelo Cascata

44

• Modelo mais antigo e o mais amplamente usado

na engenharia de software, modelado em função

do ciclo da engenharia convencional.

• Requer uma abordagem sistemática e sequencial

ao desenvolvimento de software

• Adequado em situações nas quais os requisitos

são bem entendidos e o gerente do projeto confia

na capacidade da equipe de desenvolver

utilizando o processo

Modelo Cascata

45

Modelo Cascata

46

• Vantagens:

– A fase única de requisitos leva à especificação

antes do projeto e ao projeto antes da

codificação

– O uso de revisões ao fim de cada fase permite

o envolvimento do usuário

– O modelo permite que se imponha um controle

de configuração

– Cada passo serve como uma base aprovada e

documentada para o passo seguinte

Modelo Cascata

47

• Desvantagens:

– O fluxo sequencial que o modelo propõe geralmente não

é seguido em projeto reais

– Requisitos devem ser estabelecidos de maneira completa,

correta e clara no início de um projeto

– Difícil avaliar o progresso verdadeiro do projeto durante

as primeiras fases

– Uma versão executável do software só fica disponível

numa etapa avançada do desenvolvimento

– Ao final do projeto, é necessário um grande esforço de

integração e testes

• O que fazer em caso de defeitos?

Modelo V

48

• Assim como o modelo cascata o modelo V é

sequencial.

– Cada fase precisa ser completada antes que a

próxima se inicie.

• Testes são enfatizados neste modelo mais do

que no modelo cascata. Os procedimentos de

teste são desenvolvidos cedo no ciclo de vida,

antes da implementação.

Modelo V

49

Modelo V

50

• Vantagens:

– Maior chance de sucesso quando comparado com o

modelo em cascata, devido ao desenvolvimento de

planos de teste desde as fases iniciais.

– Funciona bem para projetos pequenos, onde os

requisitos são facilmente entendidos.

• Desvantagens:

– Muito rígido, assim como o modelo cascata

– Requisitos devem ser estabelecidos de maneira

completa, correta e clara no início de um projeto

– O que fazer no caso de defeitos revelados nos

testes?

Modelo Incremental

51

• Requisitos são segmentados em uma série incremental de

produtos. O processo se repete até que um produto completo

seja produzido.

• A segmentação de requisitos é realizada antes do

desenvolvimento da primeira versão.

• Adotado quando os requisitos são conhecidos no início do

desenvolvimento

• Necessidade de entrega de um produto funcional em pouco

tempo

• A cada incremento é produzida uma versão operacional do

software.

Modelo Incremental

52

Analisar Iteração 1

Implantar

Projeto

Monitoramento e Controle do Projeto

Planejar

Iterações do

Projeto

Gerência de Requisitos

Revisões de Software

Estudar

Viabilidade

do Projeto

Estimar

Projeto

Planejar Testes Iteração 1

Desenhar Iteração 1

Construir Iteração 1

TestarIteração 1

Analisar Iteração 2




TestarIteração 2

Analisar Iteração N

Planejar Testes Iteração N

Desenhar Iteração N

Construir Iteração N

TestarIteração N

HomologarIteração 1


HomologarIteração N

Levantar

Escopo

Detalhado

do Projeto

53

Desenvolvimento Iterativo Incremental: Exemplo 1

Implantar

Projeto

Monitoramento e Controle do Projeto

Planejar

Iterações

Projeto



Estudar

Viabilida

de do

Projeto

Estimar

Projeto




TestarIteração 1




TestarIteração 2

Planejar Testes Iteração N

Desenhar Iteração N

Construir Iteração N

TestarIteração N



HomologarIteração N

Levantar

Escopo

Detalhado

do Projeto

Detalhar

Casos

de Uso

54

Desenvolvimento Iterativo Incremental: Exemplo 2

Modelo Incremental

55

• Vantagens:– Menor custo e menos tempo são necessários para se

entregar a primeira versão

– Riscos associados ao desenvolvimento de incrementos são

menores, devido ao seu tamanho reduzido

– Número de mudanças nos requisitos pode diminuir devido

ao curto tempo de desenvolvimento da primeira versão

• Desvantagens:– Se os requisitos não são tão estáveis ou completos

quanto se esperava, alguns incrementos podem precisar

ser retirados de uso e retrabalhados

– O gerenciamento de custo, cronograma e configuração é

mais complexo

Modelo Evolutivo

56

• Versões parciais são desenvolvidas que atendem

aos requisitos conhecidos inicialmente

• A primeira versão é usada para refinar os

requisitos para uma segunda versão.

• A partir do conhecimento sobre os requisitos,

obtido com o uso, continua-se o desenvolvimento,

evoluindo o produto

Modelo Evolutivo

57

• Vantagens:

– Adequado quando os requisitos não podem ser completamente

especificados de início

– O uso do sistema pode aumentar o conhecimento sobre o

produto e melhorar os requisitos

• Desvantagens:

– Necessária uma forte gerência de custo, cronograma e

configuração

– Usuários podem não entender a natureza da abordagem e se

decepcionar quando os resultados são não satisfatórios

Modelo Espiral

58

• Similar ao modelo incremental, com mais

ênfase na análise de riscos.

• Tipicamente possui quatro fases:

Planejamento, Análise de Riscos, Engenharia

e Avaliação.

• Um projeto de software passa repetidamente

por estas fases em iterações (chamadas

espirais neste modelo).

Modelo Espiral

59

Modelo Espiral

60

• Vantagens

– Muita análise de riscos

– Bom para projetos grandes e críticos

– Software é produzido cedo no ciclo de vida

• Desvantagens

– Pode ser custoso

– Análise de riscos requer experiência

– Não se aplica bem a projetos menores

61

• O RUP (Rational Unified Process) é um framework

de processos de engenharia de software

desenvolvido pela Rational Software (atualmente

IBM) que pode ser adaptado e estendido

• O desenvolvimento de software é feito de forma

iterativa e as iterações são planejadas em

número, duração e objetivos

• Orientado a casos de uso

Modelo de Ciclo de Vida Associado ao RUP

62

Modelo de Ciclo de Vida Associado ao RUP

• Cada fase é dividida em iterações:

Minor Milestones: Releases

Inception Elaboration Construction Transition

Transition

iteration

Preliminary

iteration

Architect.

iteration

Architect.

iteration

Devel..

iteration

Devel..

iteration

Devel..

iteration

Transition

iteration

63

O RUP é Iterativo e Incremental

• Cada iteração: – é planejada;

– realiza uma sequência de atividades (de elicitação de requisitos, análise e projeto, implementação, etc.) distintas;

– resulta em uma versão executável do sistema;

– é avaliada segundo critérios de sucesso previamente definidos.

64

O RUP é Iterativo Incremental

65

• Concepção

– Comunicação e Planejamento

– Entender os requisitos gerais e determinar o escopo do esforço de

desenvolvimento

• Elaboração

– Planejamento e Modelagem

– Planejar as atividades e recursos necessários; especificar as

características e projeto da arquitetura

• Construção

– Construir o produto e evoluir a visão, arquitetura e planos, até que

o produto esteja pronto para entrega

• Transição

– Implantação

– Garantir que o sistema tem o nível correto de qualidade para atingir

os objetivos; realizar correções, treinamento de usuários, ajustes e

adição de elementos que estavam faltando. O produto final é

produzido e entregue.

Fases do RUP

Fases do RUP

66

• Uma passagem pelas quatro fases é um ciclo de

desenvolvimento;

• Cada passagem pelas quatro fases produz uma

geração do software.

• A meta dominante é atingir o consenso sobre

os objetivos do ciclo de vida do projeto.

• Muita importância nos novos

desenvolvimentos, nos quais há muitos riscos

de negócios e de requisitos.

• Em projetos de manutenção

corretiva/evolutiva, a fase de iniciação é mais

rápida.

Concepção (Iniciação)

67

• Artefatos

– Documento de Visão (principais requisitos, características e

restrições)

– Casos de Negócio (definidos e aprovados)

– Lista de Riscos (identificação inicial)

– Plano de Desenvolvimento de Software (fases iniciais)

– Plano de Iteração (para a primeira iteração)

– Casos de Desenvolvimento

– Ferramentas

– Glossário

– Modelo de Caso de Uso (identificação de atores e UCs mais

importantes, fluxos de eventos para casos de uso críticos)

Concepção (Iniciação)

68

• A arquitetura se desenvolve a partir de um exame dos

requisitos mais significativos e de uma avaliação de risco.

• Meta:

– Assegurar que a arquitetura, os requisitos e os planos sejam

estáveis o suficiente e que os riscos sejam suficientemente

diminuídos a fim de determinar com segurança o custo e a

programação para a conclusão do desenvolvimento.

– Tratar riscos arquiteturais significativos.

– Arquitetura estabelecida com base nos cenários mais críticos.

– Demonstrar que a arquitetura de referência suportará os requisitos do

sistema.

Elaboração

69

• Artefatos

– Protótipo Arquitetural

– Lista de Riscos (revisada e analisada)

– Casos de Desenvolvimento

– Ferramentas

– Visão (refinada)

– Documento de Arquitetura

• Modelo de Análise

• Modelo de Casos de Uso (80% concluído)

• Modelo de Projeto

• Modelo de Dados

• Modelo de Implementação

• Modelo de Implantação

– Plano de desenvolvimento de software

– Plano de Iteração (p/ fase de construção e transição)

– Especificações Suplementares

– Conjunto de Testes

Elaboração

70

• Meta é esclarecer os requisitos restantes e concluir o

desenvolvimento do sistema com base na arquitetura.

Construção

• Artefatos

– Software

– Plano de Implantação

– Modelo de Implementação (expandido)

– Conjunto de testes (implementados e executados)

– Materiais de Treinamento (manuais de usuário, etc.)

– Plano de Iteração (para a fase de transição concluído)

– Modelo de Projeto

– Caso de Desenvolvimento

– Ferramentas

– Modelo de Dados

71

• Meta é assegurar que o software esteja disponível

para seus usuários finais.

• A Fase de Transição pode atravessar várias

iterações e inclui testar o produto em preparação

para release e ajustes pequenos com base no

feedback do usuário.

Transição

72

• Artefatos

– Incremento de Software (Build)

– Notas de release

– Artefatos de instalação

– Material para treinamento

– Material de suporte ao usuário final

– Relatório de Testes

– Realimentação geral do usuário

Transição

73

• Implantação

• Monitoração do uso do software

Produção

74

Concepção Elaboração Construção Transição

Documento de Visão

(principais requisitos,

características e restrições)

Casos de Negócio

(definidos e aprovados)

Lista de Riscos

(identificação inicial)

Plano de Desenvolvimento

de Software (fases iniciais)

Plano de Iteração (para a

primeira iteração)

Casos de Desenvolvimento

Ferramentas

Glossário

Modelo de Caso de Uso

(identificação de atores e

UCs mais importantes,

fluxos de eventos para

casos de uso críticos)

Protótipo Arquitetural

Lista de Riscos (revisada e

analisada)

Casos de Desenvolvimento

Ferramentas

Documento de Arquitetura

Modelo de Projeto

Modelo de Dados

Modelo de Implementação

Visão (refinada)

Plano de desenvolvimento

de software

Plano de Iteração (p/ fase

de construção e transição)

Modelo de Casos de Uso

(80% concluído)

Especificações

Suplementares

Conjunto de Testes

Modelo de Análise

Software (componentes)

Plano de Implantação

Modelo de Implementação

(expandido)

Conjunto de testes

(implementados e

executados)

Materiais de Treinamento

(manuais de usuário, etc)

Plano de Iteração (para a

fase de transição

concluído)

Modelo de Projeto

Caso de Desenvolvimento

Ferramentas

Modelo de Dados

Documentos de apoio

(manuais de usuário,

instalação)

Incremento de Software

(Build)

Notas de release

Artefatos de instalação

Material para treinamento

Material de suporte ao

usuário final

Relatório de Testes (beta)

Realimentação geral do

usuário

RUP: Fases e Artefatos

75

• Artefatos:

– Glossário de Negócios

– Regras de Negócio

– Modelos de Casos de Uso

– Modelo de Objetos do Negócio

– Avaliação da Organização Alvo

– Visão do Negócio

– Documento de Arquitetura do Negócio

– Especificação Suplementar do Negócio

Disciplina: Modelagem de Negócio

76

• Artefatos:

– Plano de Gerenciamento de Requisitos

– Glossário

– Visão

– Especificação de Requisitos

– Especificações Suplementares

– Modelo de Casos de Uso

– Classes de Fronteira

– Pacotes

– Protótipo de Interfaces

Disciplina: Requisitos

77

• Artefatos:

– Modelo de Implantação

– Documento de Arquitetura do Software

– Modelo de Análise e Projeto

– Modelo de Dados

– Arquitetura de Referência

– PoC p/ arquitetura

Disciplina: Análise e Projeto

78

• Artefatos:

– Componente

– Subsistema

– Build

– Plano de Integração

– Modelo de Implementação

Disciplina: Implementação

79

• Artefatos:

– Plano de Testes

– Scripts de Teste

– Casos de Teste

– Resultado dos Testes

– Arquitetura p/ automatização dos testes

– Guia de Testes

– Ambiente de Testes

Disciplina: Teste

80

• Artefatos:

– Plano de Implantação

– Lista de Materiais

– Notas de Release

– Produto

– Materiais de Treinamento

– Material de Suporte ao Usuário

Disciplina: Implantação

81

• Artefatos:

– Repositório do Projeto

– Registro de Auditoria de Configuração

– Solicitação de Mudança

Disciplina: Gerência de Configuração e Mudança

82

• Artefatos:

– Plano de Desenvolvimento de Software

– Plano de Iteração

– Plano de Gerenciamento de Riscos

– Lista de Riscos

– Plano de Aceitação do Produto

– Plano de Métricas

– Plano de Garantia da Qualidade

– Avaliação da Iteração

– Avaliação de Status

– Planos de Ação Corretiva

– Ordem de Trabalho

Disciplina: Gerência de Projetos

83

• Artefatos:

– Infraestrutura de desenvolvimento

– Guias

– Templates

– Ferramentas

Disciplina: Ambiente

84

85

Modelo de Ciclo de Vida Associado ao SCRUM

• SCRUM é um framework iterativo e incremental para

gerenciamento de projetos bastante aplicado no contexto de

desenvolvimento ágil de software.

• O ciclo de vida do SCRUM utiliza tempo fixo – sprints (ao invés

de escopo fixo) para determinar seus incrementos.

• O Scrum é facilitado por um Scrum Master, que tem como

função primária remover qualquer impedimento à habilidade

de uma equipe de entregar o objetivo do sprint.

• Cada sprint corresponde a uma iteração que segue um ciclo

(PDCA – Plan-Do-Check-Act) e entrega incremento de

software pronto.

86

Modelo de Ciclo de Vida Associado ao SCRUM

• Um backlog é conjunto de requisitos, priorizado pelo Product

Owner (responsável por conhecer as necessidades do cliente);

• Entregas de conjunto fixo de itens do backlog ocorrem em

série de iterações curtas ou sprints;

• Os itens do backlog para um sprint (iteração) são definidos em

uma sessão de planejamento;

• Durante o sprint, ocorrem breves reuniões diárias, em que

cada participante fala sobre o progresso conseguido, o

trabalho a ser realizado e/ou o que o impede de seguir

avançando;

• Ao final de um sprint, ocorre a retrospectiva, na qual todos os

membros da equipe refletem sobre o sprint passado.

87

Dinâmica do Modelo de Ciclo de Vida Associado ao SCRUM

Exercícios: Ciclos de Vida

88

• Discuta os ciclos de vida vistos em sala. Para cada ciclo, sua discussão deverá abranger pelo menos: uma breve descrição, suas principais vantagens e desvantagens (ou potenciais problemas).

• Uma pesquisa recente indica que empresas na prática combinam abordagens ágeis e orientadas a plano. Qual seria uma motivação interessante para esta combinação?

Leituras Sugeridas

89

• Capítulo sobre ciclos de vida do livro texto

da disciplina.

• Artigos relacionados:– KALINOWSKI, M.; BIFFL, S.; SPÍNOLA, R.; REINEHR, S. “From

project-oriented to service-oriented software development: an

industrial experience guided by a service reference model”.

Journal of Software Engineering Research and Development,

v.2, p. 1-21, 2014.

Engenharia de RequisitosCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


91

“All systems change during their life cycles.

This must be borne in mind when

developing systems expected to last

longer than the first version.”

Ivar Jacobson

Requisitos de Sistemas

92

• Definições:

– Para Pfleeger (2004), um requisito é uma característica do

sistema ou a descrição de algo que o sistema é capaz de

realizar para atingir os seus objetivos.

– Para Sommerville (2015), as descrições das funções e

restrições são os requisitos do sistema.

– No SWEBOK (2004), um requisito é descrito como uma

propriedade que o software deve exibir para resolver algum

problema no mundo real.

93

Requisitos doUsuário

Requisitos do Sistema

Projeto do Sistema/ Arquitetura

Mundo SistemaDesenvolvido

… precisam ser pensados de maneiras diferentes

satisfaz

satisfaz

Resultados Desejadospara superar problemas

no Mundo

SoluçõesDesenvolvidas

utilizando sistemasnovos e existentes

(Alexander, 2001)

Tipos Diferentes de Requisitos

94

• Estudo feito pelo Standish Group (apud Pfleeger, 2004)– 350 companhias e 8.000 projetos de software

– Resultados: • 31% dos projetos cancelados antes de estarem completos

• Em pequenas companhias, somente 16% dos projetos foram entregues no prazo e no orçamento inicialmente estabelecidos

• Em grandes companhias, apenas 9% atenderam esses critérios

Importância dos Requisitos

• Standish Group descreveu 3 categorias de projetos:– Sucesso (16.2%)

• Cobre todas as funcionalidades em tempo e dentro do custo previsto

– Problemático (52.7%)• Não cobre todas as funcionalidades exigidas, custo

aumentado e está atrasado.

– Fracasso (31.1%)• Cancelado durante o desenvolvimento

16%

53%

31%

Sucesso Problemático Fracasso

95

Algumas Estatísticas

Fatores de Projetos Críticos % Resp.

1. Requisitos Incompletos 13.1%

2. Falta de Envolvimento do Usuário 12.4%

3. Falta de Recursos 10,6%

4. Expectativas Irreais 9,9%

5. Falta de Apoio Executivo 9,3%

6. Mudança de Requisitos e Especificações 8,7%

7. Falta de Planejamento 8,1%

8. Sistema não mais necessário 7,5%

96

Requisitos estão envolvidos na maioria das causas!

Causas para os Projetos Fracassados

97

• Segundo Boehm e Papaccio (Pfleeger, 2004), o

custo relativo para o conserto de um problema de

requisitos em cada fase de desenvolvimento de

sistema, em relação a cada dólar investido,

comumente é:

– $1 na fase de análise de requisitos

– Até $5 na fase de projeto do sistema

– Até $10 na fase de codificação

– Até $20 na fase de teste de unidade

– Até $200 após a entrega do sistema

Custos de Problemas em Requisitos

• Gasta-se cada vez mais na manutenção e teste dos sistemas

• 85% dos erros são causados por defeitos inseridos durante a análise de requisitos e o projeto do sistema

98

Cenário Atual de Desenvolvimento


99


100

• Outros custos não facilmente mensuráveis:

– perda de oportunidades

– perda da confiança de clientes

– perda de clientes

– correção do erro

• os erros mais caros são aqueles cometidos

no processo de requisitos e descobertos pelo

usuário!

Requisitos e Análise de Sistemas

101

• Desafios no Desenvolvimento de Sistemas

– Compreensão do domínio do problema

– Comunicação efetiva com reais usuários do

sistema

– Evolução contínua dos requisitos do sistema

Importância dos Requisitos

102

• Uma especificação de requisitos é importante por

que:

– Estabelece uma base de concordância entre o cliente e o

fornecedor sobre o que o software fará.

– Fornece uma referência para a validação do produto final.

– Uma especificação de requisitos de alta qualidade é pré-

requisito para um software de alta qualidade.

– Reduz o custo de desenvolvimento.

Engenharia de Requisitos

103

• Conceito

– Para Sommerville (2003), engenharia de requisitos pode

ser descrito como o processo de descobrir, analisar,

documentar e verificar as funções e restrições do sistema

– Segundo Carvalho e Chiossi (2001), engenharia de

requisitos é: “Entender o que se deseja construir antes de

começar a fazê-lo”

• Compreende produzir e gerenciar os requisitos

Engenharia de Requisitos – Visão Geral

104


Gerência de RequisitosProdução de Requisitos

Levantamento

Registro

Validação

Verificação

Controle de Mudanças

Gerência de Configuração

Rastreabilidade

Gerência da Qualidade de

Requisitos

Engenharia de Requisitos – Visão Geral

105

Requisitos

LevantarRequisitos

RegistrarRequisitos

ValidarRequisitos

Controlar Mudanças

Gerenciar Configuração

Implementar Rastreabilidade

Gerenciar Qualidade

Produção de Requisitos Gerência de Requisitos

VerificarRequisitos

Conceitos de Engenharia de Requisitos

106

• A Engenharia de Requisitos consiste de dois grupos de

atividades relacionadas:

– Desenvolvimento/Produção de Requisitos (Elicitação, Análise e

Modelagem)

– Gerência de Requisitos (Identificação, Configuração, Priorização,

Rastreabilidade)

107

Elicitação, Análise e Modelagem


Novos requisitos elicitados

Versões aceitas, rastreabilidade,

progresso

O Desenvolvimento de Requisitos cria e interpreta os requisitos

A Gerência de Requisitos organiza e mantém registro dos mesmos


108

Engenharia de Requisitos no SWEBoK


109

• Objetivos:

– estabelecer uma visão comum entre o cliente e a equipe de

projeto em relação aos requisitos que serão atendidos pelo

projeto de software

– registrar e acompanhar requisitos ao longo de todo o

processo de desenvolvimento

• Metas:

– documentar e controlar os requisitos alocados para

estabelecer uma baseline para uso gerencial e da

engenharia de software

– manter planos, artefatos e atividades de software

consistentes com os requisitos alocados


110

O que acontece se....

• o usuário mudar de idéia em relação a uma

funcionalidade?

• o ambiente mudar?

• o usuário perceber novas possibilidades na

automação?

• o engenheiro de requisitos (ou analista) não

entendeu corretamente a necessidade do usuário?


111

• É preciso gerenciar as mudanças!!!!

• Mudanças em requisitos ao longo do processo de

desenvolvimento de software fazem parte do

processo

• Alterações em requisitos podem implicar em

mudanças em planos e artefatos de projeto, de

código, casos de testes, etc.

Gerenciamento de Requisitos

112

• Gerenciamento de requisitos é o processo de controlar as

mudanças dos requisitos durante

– O processo da engenharia de requisitos

– E desenvolvimento do sistema

• Requisitos são inevitavelmente incompletos e inconsistentes

(possuem defeitos)

– Requisitos novos surgem durante o processo de acordo com

mudanças nas necessidades do negócio e um entendimento

melhor do sistema é desenvolvido

– Diferentes pontos de vista têm diferentes requisitos e esses

geralmente são contraditórios

Rastreamento

113

• Responsável por dependências entre requisitos, suas origens e

os demais artefatos (projeto do sistema, casos de teste, etc).

• Rastreamento de Origem

– Associação entre requisitos e stakeholders que propuseram tais

requisitos

• Rastreamento de Requisitos

– Associação entre requisitos dependentes

• Rastreamento de Projeto

– Associação dos requisitos com o projeto

Rastreamento

114

1.Rastrear requisitos do usuário nos do sistema

2.Rastrear requisitos no projeto

3.Rastrear requisitos nosprocedimentos de teste

4.Rastrear requisitos nadocumentação do usuário

Projeto

Modelos Suítes Teste

Teste

2 3

Req A

1

Requisitos

Produto

(Caracter.)

Requisitos

Detalhados

(Casos de Uso)

Req B

Documentação

Doc. Usuário

4

Rastreamento: Análise de Impacto

115

No caso de mudanças ligações dos requisitos devem

ser marcadas como “revisar”

Ligações “revisar” devem ser analisadas

Req A antes

“if return value > $5”

Req B

Req C

“if return value > $2”

Req A depois

Req C

Req B

• Problemas de comunicação e de terminologia

116

Problemas Clássicos da Engenharia de Requisitos

• Requisitos incompletos ou implícitos

117


• Requisitos inconsistentes

118


• Requisitos ambíguos que permitem diversas interpretações

119


• Responsabilidades não claramente definidas

120


• Apoio insuficiente do cliente

121


• Apoio insuficiente do gerente

122


• Interessados com dificuldades em separar o problema de

soluções previamente conhecidas

123


• “Moving targets” (mudanças nos objetivos de negócio)

124


• “Gold plating” (implementação de funcionalidades além dos

requisitos)

125


• Requisitos não funcionais não mensuráveis

126

Amigável Rápido

Portável, Flexível, Seguro, Pequeno,

...


Estado da Evidência Empírica em Engenharia de Requisitos

127

• A maioria das investigações em ER são isoladas

– Generalizações são extremamente difíceis

• Surveys disponíveis além de ER não são confiáveis,

reproduzíveis e nem suficientemente detalhados

(e.g., Chaos Report)

NaPiRE (Naming the Pain in RequirementsEngineering) www.re-survey.org

128

Reação à falta de uma base empírica para pesquisa em Engenharia de Requisitos

18 Países!Openness!

Transparency!

Anonymity!

Accuracy and

Validity!

129

Problemas Contemporâneos

130

Problemas Contemporâneos

131


Exercícios: Engenharia de Requisitos

132

• Defina Engenharia de Requisitos.

• Cite exemplos de problemas de Engenharia de Requisitos.

• Comente a seguinte frase: “Defeitos inseridos na fase de requisitos e detectados com o software são críticos e devem ser evitados”.

• Quais são as atividades de engenharia de requisitos envolvidas na produção de requisitos (i.e., no desenvolvimento de requisitos)?

• Quais são as atividades de engenharia de requisitos envolvidas na gerência de requisitos?

• O que é e pra que serve a rastreabilidade de requisitos?

Leituras Sugeridas

133

• MENDEZ FERNÁNDEZ, D.; WAGNER, S.; KALINOWSKI, M. et al. Naming the Pain in

Requirements Engineering: Contemporary Problems, Causes, and Effects in

Practice. Empirical Software Engineering Journal, vol. 22 (5), pp. 2298-2338, 2017.

• MENDES, T. S.; SOARES, H. F.; FARIAS, M. A. F.; MENDONCA, M.; KALINOWSKI, M.;

SPINOLA, R. O. Impacts of Agile Requirements Documentation Debt on

Software Projects: A Retrospective Study. In: ACM Symposium on Applied

Computing (ACM SAC), p. 1300-1306, Pisa, Italy, 2016.

• KALINOWSKI, M.; FELDERER, M.; CONTE, T.; SPINOLA, R. O.; PRIKLADNICKI, R.;

WINKLER, D. Preventing Incomplete/Hidden Requirements: Reflections on

Survey Data from Austria and Brazil. Lecture Notes in Business Information

Processing, p. 1-16, Vienna, Austria, 2016. (Best Paper Award).

• MÉNDEZ FERNÁNDEZ, D.; WAGNER, S.; KALINOWSKI, M.; SCHEKELMANN, A.;

TUZCU, A.; CONTE, T.; SPINOLA, R. O.; PRIKLADNICKI, R. Naming the Pain in

Requirements Engineering: Comparing Practices in Brazil and Germany.

IEEE Software, v. 32 (5), p. 16-23, 2015.

Tipos de RequisitosCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Tipos de Requisitos

135

• Requisitos Funcionais

• Requisitos Não Funcionais

• Requisitos do Domínio (Regras de Negócio)

Requisitos Funcionais

136


– Requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar

– Um requisito funcional descreve uma interação entre o sistema e seu ambiente

– Exemplo: “O sistema deve permitir que o administrador emita um relatório com os resultados dos testes clínicos de um paciente”

Requisitos Funcionais

137


– Regra de formação (boa prática)

– O software deve permitir que o [responsável

pela ação] + [ação]

– Exemplo: O software deve permitir que o setor

finaceiro libere o pagamento dos funcionários.

Exemplos de Requisitos Funcionais

138

• [RF001] O software deve permitir que o gerente

pesquise os dados cadastrais de um cliente

• [RF002] O software deve permitir que usuários

visualizem documentos cadastrados

Exercício

139

• Forneça 3 exemplos de Requisitos Funcionais para:

– Sistema da padaria de pequeno porte;

– Sistema de internet banking;

– Sistema de alocação docente.

Requisitos Não Funcionais

140

• São requisitos que expressam condições que o

software deve atender ou qualidades específicas

que o software deve ter

• Em vez de informar o que o sistema fará, os

requisitos não-funcionais colocam restrições no

sistema

• Exemplo: “As consultas ao sistema devem ser

respondidas em menos de três segundos”


141

• Definem propriedades e restrições do sistema

(tempo, espaço, etc)

• Requisitos de processo também podem especificar o

uso de determinadas linguagens de programação,

método de desenvolvimento

• Requisitos não-funcionais podem ser mais críticos

que requisitos funcionais. Não satisfaz, sistema

inútil.


142

• Devido à sua própria definição, requisitos não-

funcionais devem ser mensuráveis

• Assim, deve-se associar forma de medida a cada

requisito não-funcional elicitado

• Requisitos devem ser verificáveis

143

Medidas de Requisitos Não Funcionais

Propriedade Medida

Velocidade Transações processadas por segundoTempo de resposta de uma transação

Tamanho Bytes ocupados em discoBytes ocupados da memória RAM

Facilidade de Uso Tempo de treinamentoNo de quadros de ajuda

Confiabilidade Tempo médio entre falhas

Robustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha

Portabilidade Percentual de declarações dependentes do destinoSistemas destino

Algumas palavras levam a requisitos impossíveis de serem verficados

144

Requisitos Inverificáveis

Palavras nãoverificáveis

Possíveis substitutos

Amigável Número máximo de passos

Lista de funcionalidades presentes em outrasaplicações

Portável Requisitos mínimos de hardware

Sistemas operacionais em que deve funcionar

Pequeno Dimensões aceitáveis (em número de Bytes)

Flexível Variáveis que podem acomodar uma gama de mudanças de valores

Funções que implementam uma de váriaspossibilidades

Classificação de Requisitos Não Funcionais

145

• Requisitos do Produto– Produto deve comportar-se de forma particular (velocidade

de execução, confiabilidade, etc.)

• Requisitos Organizacionais– Conseqüência de políticas e procedimentos organizacionais

(padrões de processo usados, requisitos de implementação, etc.)

• Requisitos Externos– Conseqüência de fatores externos ao sistema e ao processo

de desenvolvimento (legislação, etc.)


146

• Requisitos do produto

– requisitos que especificam características desejáveis que um sistema (sub-sistema) deve possuir

– incluem:

• requisitos de usabilidade

– e.g., usuários experientes devem ser capazes de

utilizar todas as funções do sistema após duas horas

de treinamento


147

• requisitos de confiabilidade– e.g., o sistema deve estar disponível 99% das

vezes;

• requisitos de segurança– e.g., o acesso ao dados deve ser protegido

• requisitos de desempenho– e.g., o sistema deve processar X requisições por

segundo

• requisitos de capacidade– e.g., o sistema deve suportar X usuários

concorrentemente

• requisitos de portabilidade– e.g., o sistema deve rodar nas plataformas X e Y


148

• Requisitos organizacionais

– são procedentes de políticas e procedimentos nas

organizações do cliente e do desenvolvedor

– incluem:

• requisitos de entrega

– e.g., um relatório de progresso deve ser entrege a cada

duas semanas

• requisitos da implementação

– e.g., o sistema deve ser implementado na linguagem

C++

• requisitos de padrões e métodos de desenvolvimento

– e.g., uso de métodos orientados a objetos;

desenvolvimento utilizando a ferramenta X


149

• Requisitos externos

– requisitos impostos tanto ao produto quanto ao

processo de desenvolvimento em função do

ambiente no qual o sistema é desenvolvido

– incluem:

• requisitos de interoperabilidade

– e.g., o sistema deve interagir com os sistemas X e Y

• restrições éticas

– e.g., o sistema não deverá revelar aos operadores

nenhuma informação pessoal dos clientes

• restrições legais

– e.g., o sistema deverá armazenar as informações de

acordo com a lei nro XXYY.ZZ

Exercício

150

• Forneça 1 exemplo de R.N.F. para cada tipo de

requisitos não funcional de produto para:




Requisitos NãoFuncionais

Requisitos deProcesso

Requisitos deProduto

Requisitos Externos

requisitos deentrega

requisitos deusabilidade

requisitos deeficiência

requisitos de confiabilidade

requisitos deportabilidade

requisitos deimplementação

requisitos parapadrões

requisitos deespaço

requisitosde custo

requisitos deinteroperabilidade

requisitoslegais

requisitos de performance

Sommerville

151

Taxonomia

Requisitos de Domínio

152

• Derivados do domínio da aplicação e descrevem

características do sistema e qualidades que refletem

o domínio

• Podem ser requisitos funcionais novos, restrições

sobre requisitos existentes ou computações

específicas

• Se requisitos de domínio não forem satisfeitos, o

sistema pode tornar-se não prático


153

• Problemas

– Entendimento• Requisitos são descritos na linguagem do domínio da

aplicação

• Não é entendido pelos engenheiros de software que vão desenvolver a aplicação

– Implicitude• Especialistas no domínio entendem a área tão bem que

não tornam todos os requisitos de domínio explícitos


154

• Exemplo:

– A desaceleração do trem pode ser obtida pela fórmula

Dtrem=Dcontrole+Dgradiente

onde ...

– A retenção dos impostos de uma nota fiscal é calculada da

seguinte forma: ...

– O despacho dos caminhões ocorre sempre após a conclusão do

carregamento

Exercício

155

• Forneça alguns exemplos de requisitos de domínio

para:




Visões para Requisitos

156

• Requisito = Declaração em alto nível ou Definição

detalhada?

– Requisitos do usuário: declarações, em linguagem natural e

também em diagramas, sobre as funções que o sistema

deve fornecer e as restrições sob as quais deve operar

– Requisitos de sistema: estabelecem detalhadamente as

funções e as restrições de sistema

Requisitos de Software e de Sistema

157

• Sistema– Combinação interativa de elementos (hardware,

software, firmware, pessoas, informações, técnicas, facilidades, serviços...) para realizar um objetivo definido

• Requisitos de Sistema– São os requisitos do sistema como um todo

• Requisitos de Software– São os requisitos dos componentes de software

derivados dos requisitos do sistema

Visões para Requisitos

158

Requisitos

Não-funcionais

Organização

Funcionais Domínio

Produto Externo

SistemaUsuário =df

159


Exercício: Tipos de Requisitos

• Cenário

Permitir que os coordenadores de projeto possam realizar

solicitações relativas ao cadastro de pessoas físicas, pagamento de

pessoas físicas, transferência de recursos entre projetos, solicitação

de passagem aérea, diárias e suprimentos através de formulários

disponíveis na web, viabilizando, assim, a realização de um controle

mais efetivo sobre os dados fornecidos nessas solicitações e sobre a

própria solicitação. Além disso, o produto deverá permitir que os

colaboradores, responsáveis por atender essas solicitações, tenham

acesso on-line às mesmas para que seja dado andamento nos

processos solicitados, aumentando o controle sobre as operações

realizadas e os dados envolvidos, bem como diminuindo o tempo de

resposta aos usuários solicitantes.

160

Exercício: Tipos de Requisitos

• Considerando o cenário apresentado:

– Elabore a lista de requisitos funcionais do

software

– Elabore a lista de requisitos não funcionais de

produto para o software

161

Elicitação de RequisitosCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


163

Usuários

Atores

Stakeholders

Sistemas

O Ambiente das Organizações

Stakeholders

164

• Stakeholders

– Um stakeholder pode ser definido como alguém que ganha ou perde algo como resultado do projeto:

• Funcionalidade

• Rendimento

• Status

• Conformidade com regras e/ou leis

• ...

– Qualquer pessoa que terá alguma influência direta ou indireta sobre os requisitos do sistema

Stakeholders

165

• Exemplos típicos de stakeholders:– Usuários – grupo que irá usar o software– Clientes – grupo que encomendou o software ou

que representa o público alvo do mesmo– Analistas de mercado – para casos de produtos

que precisam da análise de mercado– Autoridades de regulamentação – para aplicações

com regulamentações próprias, como transporte público

– Desenvolvedor/Engenheiro de Software– Outros engenheiros de software – em casos

como reuso de componentes

Identificando Stakeholders

166

• O contato inicial normalmente indica pessoas com quem se deve falar, seus papéis e seus interesses

• Stakeholders incluem usuários diretos do sistema e interessados indiretos também

• Stakeholders podem sugerir outras pessoas que devem ser consultadas …

Diferenças de Visão: Desenvolvedores x Usuários (Pfleeger, 2004)

Visão Desenvolvedor Visão Usuário

Usuários não sabem o que querem Desenvolvedores não entendem

necessidades operacionais

Usuários não conseguem expressar o

que querem

Desenvolvedores enfatizam demais os

aspectos técnicos

Usuários têm necessidades

motivadas por razões políticas

Desenvolvedores querem nos dizer

como fazer nosso trabalho

Usuários querem tudo agora Desenvolvedores estão sempre

atrasados

Usuários não conseguem priorizar

necessidades

Desenvolvedores dizem ‘NÃO’ o tempo

todo

167

169

Stakeholder Motivação Expertise

Cliente Introduzir mudança com

benefício máximo

Estratégias de negócio,

tendências

Usuário Introduzir mudança com

interrupção mínima

Processo de negócio,

procedimentos oper.

Gerente de Projeto Completar o projeto c/ sucesso

(c/ recursos dados)

Gerência de projeto,

processo de software

Analista Especificar requisitos no

tempo e no prazo previstos

Técnicas e ferramentas

de ER

Desenvolvedor Produzir um sistema

tecnicamente excelente

Tecnologias de prog.,

métodos de projeto

SQA Assegurar conformidade a

padrões

Processo de SW,

padrões

Stakeholders: o que querem e o que oferecem

170

• Exemplos de problemas específicos:

– Comprometimento

• Falta de compromisso com tempo e orçamento para

requisitos

– Habilidade

• Stakeholders (técnicos e de negócios) sem

habilidades necessária para elicitar requisitos

– Descoberta

• Não é possível descobrir os stakeholders apropriados

Tipos de problemas com Stakeholders(Alexander & Robertson, 2004)

Elicitação e análise de requisitos

171

• Equipe de desenvolvimento trabalha com

o cliente e usuários finais para descobrir

informações sobre o domínio,

funcionalidades, restrições, etc

Desafios no processo de elicitação de requisitos

172

• Falta de conhecimento do usuário das suas reais

necessidades

– Usuário com vaga noção do que precisa e do que um

produto de software pode oferecer

– Mudança das necessidades ao longo do tempo

(volatilidade)

• Falta de conhecimento do analista/desenvolvedor

do domínio do problema

– Desenvolvedor sem conhecimento adequado do domínio, o

que leva a decisões erradas

• Falta de comprometimento ou disponibilidade dos

envolvidos


173

• Domínio do processo de elicitação de requisitos

pelos desenvolvedores

– Desenvolvedor não ouve o que os usuários têm a dizer e

força suas próprias visões e interpretações

• Comunicação inadequada entre os desenvolvedores

e usuários

– Usuários incapazes de expressar suas necessidades

apropriadamente

– Significados diferentes a termos comuns


174

• Dificuldade do usuário tomar decisões

– Falta de entendimento sobre as consequências das

decisões ou as alternativas possíveis

– Conflitos entre os interesses de diferentes usuários

• Problemas de comportamento

– A elicitação de requisitos é um processo social

– Conflitos e ambiguidades nos papéis que os usuários e

desenvolvedores desempenham

• Questões técnicas

– Complexidade crescente dos sistemas atuais

• Fatores políticos, econômicos e de negócios


175

• Atividades do processo

– compreensão do domínio

– coleta de requisitos através da interação com

os stakeholders

– classificação em grupos estruturados

– resolução de conflitos advindos das diferentes

visões dos stakeholders

– definição de prioridades

– verificação de requisitos (completos e

consistentes)


176

Compreensão

do domínio

Verificação de

requisitos

Definição de

prioridades

Resolução de

conflitos

Classificação

Coleta de

requisitos

Documento

de requisitos

Especificação

de requisitos

177

Um grau de retrabalho é normal durante

as atividades de ER!

Processo Típico de Elicitação

Possíveis Fontes de Requisitos

178

• Entrevistas com usuários

• Ambiente do sistema

• Objetivos de negócio

• Requisitos de mercado

• Obrigações contratuais

• Trabalho no ambiente do usuário

• Sistemas existentes ou análogos

• Modificações propostas pelos usuários

• Reuniões dos usuários

• Workshops

• Protótipos

• Estudos

• Questionários

• Consultores

• Observação

179

• Entrevistas

• Brainstorming

• Questionários

• Workshop de Requisitos

• Etnografia

• Jogo de Funções

• Prototipação

• Casos de Uso e Cenários

Técnicas para Elicitação de Requisitos

Entrevistas

180

• Técnica mais comum

– Porém nem sempre bem utilizada

• Deve ser planejada e preparada cuidadosamente

– Saber quem será entrevistado e porque

– Definir o(s) objetivo(s) da entrevista

– Preparar antecipadamente as questões que serão

formuladas (ou parte delas)

Entrevistas

181

• Atenção!– Entrevistar não é somente fazer perguntas!– Requer habilidade de ouvir– Desejável: Conhecimento de técnicas de entrevistas

• Desafio: evitar que o nosso background interfira com o entendimento do problema

• Inclui quatro etapas:– Identificação dos candidatos para entrevista– Preparação– Condução– Finalização

Entrevistas

182

• Preparação

– Estude material disponível e elabore um roteiro (Pré-

reunião).

– Permita que os entrevistados se preparem para a

entrevista.

• Condução

– Não queira anotar todos os detalhes durante a entrevista

(use um gravador, se possível).

– Solicite exemplos de formulários, relatórios, situações, ...

• Finalização

– Transcreva imediatamente após a entrevista.

Entrevistas

183

• Questões nas Entrevistas:

– TIPO de Questões:• Perguntas Abertas• Meta Perguntas• Perguntas Específicas

Entrevistas

• Perguntas Abertas– Quais são os problemas?– Por que eles precisam ser resolvidos?– Existem outras razões para eles serem resolvidos?– Quais os benefícios esperados de uma solução bem

sucedida?– Como esses problemas são resolvidos hoje? Qual é a

situação atual?– Qual seria a situação desejada, ou seja, como você gostaria

de resolver os problemas?– Como essa atividade é realizada?– O que ela gera como resultado? Para quem?– Quais são as dificuldades para a sua realização?– O que tornaria a sua realização mais fácil ou mais

eficiente?

184

Entrevistas

185

• Meta Perguntas– Estou fazendo perguntas demais?– Minhas perguntas lhe parecem relevantes?– Existem outras pessoas que poderiam responder essas

perguntas?– Posso voltar a fazer outras perguntas mais tarde?– Existe alguma outra questão que você julgue relevante e

que não tenha sido abordada?– Existe alguma pergunta que você queira me fazer?– Podemos observar o ambiente no qual o produto será

utilizado?– Você gostaria de participar da revisão dos requisitos?

Entrevistas

186

• Perguntas Específicas– Exploram informações mais específicas sobre: (i)

atividades/navegação; (ii) informações e campos; (iii) regras de negócio e de validação; (iv) exceções; e (v) outras informações específicas que julgar relevantes.

– Exemplos:• O que exatamente ocorre após o registro das operações

no sistema (... elas necessitam aprovação da gerência?) ?• Seria interessante realizar a autenticação dos usuários

com base no CPF?• Quais dados são relevantes (/ vocês registram

atualmente) para o cadastro dos fornecedores? (Você possui algum exemplo?)

• Quais informações devem estar contidas no relatório de operações financeiras? (Você possui algum exemplo?)

• De que maneira é calculado o imposto retido de uma despesa de serviço? (Você possui algum exemplo?)

• O que deveria ocorrer se o fornecedor não tiver a pontuação exigida para prestar o serviço?

Entrevistas

187

• Perguntas Inadequadas

– Indução

• Você precisa de uma tela maior, não é isso?

– Perguntas de controle / Interrupção

• O que você está falando é interessante, mas podemos voltar

às minhas perguntas?

– Perguntas muito longas ou muito complexas

• Eu tenho uma questão que se divide em três partes, a

primeira ….?

Entrevistas

188

Inicie a entrevista com perguntas abertas!

Ouça com atenção!

Recapitule o seu entendimento de tempos em tempos.

Não apresse o entrevistado.

Entrevistas

189

• Diretrizes para realização de entrevistas

– Desenvolva um plano geral de entrevistas

– Obtenha autorização para entrevistar

– Planeje o tempo

– Descubra o interesse do usuário

– Use o estilo adequado de entrevista

189

190

• Brainstorming

– Técnica básica para geração de idéias

– Reuniões onde as pessoas sugerem e exploram idéias –

sem que sejam criticadas!

– Uma sessão consiste em duas fases:

• Geração de idéias

• Consolidação

– Processo relativamente não estruturado

• pode não produzir a mesma qualidade ou nível de detalhe

de outros processos

Brainstorming

Brainstorming

191

• Regras:

– Estabeleça o objetivo da sessão;

– Gere quantas idéias for possível;

– Deixe sua imaginação livre;

– Não admita críticas ou debates;

– Ajuste e combine as idéias.

Questionários

192

• Aplicabilidade a mercados específicos

– Onde perguntas são bem definidas

• Hipóteses

– Perguntas relevantes podem ser decididas

antecipadamente;

– Leitor ouve da maneira desejada;

– Suprime o que é bom sobre análise.

• Úteis após uma entrevista inicial

Workshops de Requisitos

193

• Idealizado para encorajar o consenso acerca dos

requisitos da aplicação e acerca das ações a serem

tomadas em um curto intervalo de tempo

• Formato: reunião intensiva (1 ou 2 dias) com

pessoas chaves visando criar ou revisar as

principais funcionalidades do sistema em

desenvolvimento, com a participação de um

mediador


194

• Benefícios:

– ajuda na construção de espírito de equipe

– todos os interessados no projeto participam das

discussões

– ajuda a estabelecer consenso

– ajuda a expor e resolver questões políticas

– como resultado imediato, uma descrição

preliminar do sistema é obtida


195

• Recomendações para um workshop:

– venda o conceito (benefícios) do workshop para a

organização

– garanta a participação das pessoas chaves

– não despreze os problemas de logística

– prepare material para ser distribuído para os

participantes se prepararem para o workshop

• Põe todos os stakeholders juntos por um período intensivo (focado)

• Facilitador conduz a reunião

• Todos têm sua vez de falar

• Resultados são disponíveis imediatamente

• Provê um ambiente para aplicar outras técnicas de elicitação

196


Etnografia (Observação)

197

• Parte do pressuposto que sistemas de software são

utilizados dentro de um contexto social e

organizacional

– requisitos do sistema são derivados e/ou limitados por este

contexto

• Etnografia é uma técnica de observação que pode

ser utilizada para compreender requisitos sociais e

organizacionais


198

• Analista se insere no ambiente de trabalho onde

sistema será utilizado

• Trabalho diário é observado e tarefas reais em que

os participantes estão envolvidos são anotadas

– idéia é capturar os processos reais ao invés dos processos

formais

• Realizar observação após um primeiro

entendimento do que será observado.

• Combinar com perguntas específicas

– – E se …? Em alguma situação você …?


199

• Técnica é eficaz na descoberta de dois tipos de

requisitos

– requisitos derivados da maneira como as pessoas

trabalham (trabalho real x trabalho formal)

– requisitos derivados da cooperação e conscientização das

atividades de outras pessoas

• Captura de detalhes que podem ser esquecidos em uma

entrevista (Requisitos ‘inconscientes’).

Jogo de Funções

200

• O Engenheiro de Requisitos desempenha as

Funções do Cliente

• Engenheiro de Requisitos

– Assume a função do usuário ou cliente

• Entender o domínio do problema

• Cliente

– Assume a função do usuário

• Entender os problemas que podem passar

Prototipação

201

• Usuários podem descobrir quais são as suas

reais necessidades através do exame de um

protótipo

• Processo de prototipagem

– Estudo preliminar dos requisitos do usuário

– Construção do protótipo

– Avaliação junto dos usuários

• A prototipação é benéfica somente se o protótipo

puder ser construído bem mais rápido que o

sistema real

Protótipos

202

• Protótipos são modelos do software

– Não precisam ser completos

– Construídos para permitir a avaliação pelo cliente

e pelo desenvolvedor

• Paradigmas de prototipagem

– Finalidade aberta – Protótipo descartável

• Serve apenas para demonstrar requisitos

• Normalmente mais úteis para elicitação

– Finalidade fechada – Protótipo evolutivo

• O protótipo é a primeira evolução do software

Protótipos (Exemplo Industrial de Levantamento Real)

203

Cenários

• Criação de um conjunto de cenários que identifica uma linha de uso para o sistema a ser construído

• Os cenários, que compõem um caso de uso, fornecem uma descrição de como o sistema será usado

• O analista deve identificar os ‘atores’ para cada caso de uso– Atores ≠Usuários

• O cenário descreve um modo pelo qual o ator interage com o sistema

204

Casos de Uso e Cenários

• Questões a serem respondidas ao se identificar casos de uso e cenários:– Que tarefas ou funções são desempenhadas pelo

ator?– Que informações do sistema o ator vai adquirir,

produzir ou modificar?– Que informação o ator deseja do sistema?– O ator vai ter que informar o sistema sobre

alterações do ambiente externo?– O ator deseja ser informado sobre modificações

inesperadas?

205


206

• Representações para Cenários e Casos de Uso:

– Descrições textuais contínuas

– Descrições numeradas

– Tabelas Ator x Sistema

• Falaremos mais de casos de uso na aula sobre especificação

de requisitos

207

• Não envolver os stakeholders apropriados.

• Baixa participação dos stakeholders.

• Solução desenvolvida a partir de visões pessoais

dos desenvolvedores (“achismos”).

Problemas Comuns no Levantamento

208


Exercício 1: Levantamento de Requisitos

• Discuta as principais técnicas para levantamento de

requisitos de sistemas. Para cada técnica, sua

discussão deverá abranger pelo menos: uma breve

descrição, suas principais vantagens e

desvantagens (ou potenciais problemas).

• No final da sua discussão, aborde a seguinte

questão: “Por que devemos combinar essas

técnicas, e não utilizar apenas uma delas

isoladamente no processo de levantamento de

requisitos?”.

209

• Prepare um conjunto de perguntas para uma entrevista com

um dos interessados, o patrocinador. Este interessado possui

uma visão geral das atividades dos processos de negócio da

organização, dos responsáveis por desempenhar estas

atividades e do escopo de atuação destes responsáveis.

• Objetivo Global :

Permitir a gestão dos usuários do sistema *XYZ* e dos direitos de

acesso desses usuários às diversas funcionalidades disponibilizadas

pelo sistema, de forma que cada usuário tenha acesso somente às

funcionalidades necessárias para cumprimento das suas atividades.

Permitir que os diversos usuários do *XYZ* possam realizar a

manutenção de seus dados pessoais e a gestão de seus substitutos

sem a necessidade de intervenção dos administradores do *XYZ*.

210

Exercício 2: Entrevista Inicial

• Preparação (~15 min):

– Explicar como funcionará a preparação (instrutor);

– Ler cenário do projeto de software a ser desenvolvido (individual - aluno);

– Preparar sugestões de funcionalidades para o sistema (individual - aluno);

– Distribuir post-it (instrutor).

• Reunião de Brainstorming (~30 min):

– Explicar como funcionará a reunião (instrutor):

• Sugestão de funcionalidades para o software (individual - aluno);

• Sugestões devem ser anotadas no post-it e colocadas no quadro da reunião (individual –aluno/instrutor);

• Gerar quantas ideias for possível;

• Deixar sua imaginação livre;

• Não admitir críticas ou debates;

– Ler cenário do projeto de software a ser desenvolvido (instrutor);

– Executar a reunião de brainstorming (aluno, instrutor);

• Ajuste dos Resultados (~15 min):

– Agrupamento das funcionalidades sugeridas (aluno, instrutor);

– Eliminação de funcionalidades repetidas, fora do escopo do software (aluno, instrutor);

– Definição da lista final de funcionalidades.

211

Exercício 3: Brainstorming

• Cenário

– Permitir que os coordenadores de projeto possam realizar solicitações

relativas ao cadastro de pessoas físicas, pagamento de pessoas físicas,

transferência de recursos entre projetos, solicitação de passagem aérea,

diárias e suprimentos através de formulários disponíveis na web,

viabilizando, assim, a realização de um controle mais efetivo sobre os

dados fornecidos nessas solicitações e sobre a própria solicitação. Além

disso, o produto deverá permitir que os colaboradores, responsáveis por

atender essas solicitações, tenham acesso on-line às mesmas para que

seja dado andamento nos processos solicitados, aumentando o controle

sobre as operações realizadas e os dados envolvidos, bem como

diminuindo o tempo de resposta aos usuários solicitantes.

• Definição da Atividade

– Executar uma reunião de brainstorming para apoiar a definição das

principais funcionalidades de um módulo de solicitação e protocolo de um

sistema de informação.

212

Exercício 3: Brainstorming

Exercício 4: Teatro de Elicitação

213

• Entrevista Detalhada

– Entrevista de levantamento detalhado com os responsáveis pela execução dos processos de negócio.

• Preparação:

– Explicar como funcionará a preparação (instrutor);

– Dividir a turma em 4 grupos A, B, C, D (3 componentes cada) (instrutor);

• Grupos A e B: Cenário de Levantamento 1; Material de Apoio;

• Grupos C e D: Cenário de Levantamento 2; Material de Apoio.

• Etapa 1: Grupos A e B ENTREVISTAM Grupos C e D.

– Ler cenário do projeto de software a ser desenvolvido (Grupos A, B, C, D);

– Analisar protótipos (Grupos C, D)

– Preparar material para reunião de entrevista (Grupos A, B).

• Etapa 2: Grupos C e D ENTREVISTAM Grupos A e B.

– Ler cenário do projeto de software a ser desenvolvido (Grupos A, B, C, D);

– Analisar protótipos (Grupos A, B)

– Preparar material para reunião de entrevista (Grupos C, D).

214

• Objetivo Geral

– Executar entrevistas para identificar informações de apoio à especificação de 4 casos de uso para um módulo de solicitação de um sistema de informação.

– Material de Apoio: informações a serem levantadas:

– Seguir as instruções específicas do exercício.

Exercício 4: Teatro de Elicitação

Tipos de Informação Perguntas

Atividades / Navegação

Campos / Informações

Regras

Exceções

Outras observações

Especificação de RequisitosCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Casos de Uso

216

• Um Caso de Uso especifica o comportamento de um sistema

ou parte dele. É também uma descrição do conjunto de

passos que o sistema executará para desempenhar suas

funções.

• Um caso de uso é baseado em um cenário descritivo de como

a entidade externa interage com o sistema. Ele identifica

eventos que podem ocorrer e descreve a resposta do sistema

para estes eventos.

Um caso de uso descreve um conjunto particular de

funcionalidades do sistema, modelando o diálogo que

uma entidade externa, chamada ator, realiza com o

sistema.

Casos de Uso

217

• Quando combinados, os casos de uso constituem

todas as formas de uso do sistema.

• Casos de uso fornecem uma visão do sistema

focada na funcionalidade.

• Eles possibilitam um formato de apresentação

compreensível que pode ser utilizado para aprimorar a

comunicação, especialmente entre os projetistas da

aplicação e os clientes.

• Eles são úteis para fases posteriores do ciclo de vida,

ajudando na identificação dos objetos, desenvolvimento

de planos de teste e documentação.

AtendenteConsultar Livro

218

Associação

Casos de Uso

• Atores:

– Entidades do meio ambiente (externas

ao sistema) que interagem com o

sistema para obter alguma

funcionalidade.

– Podem ser: humanos, outros sistemas,

organizações, dispositivos externos,

etc, que interagem com o sistema.

• Alguns atores dão início a eventos

enquanto outros interagem com o sistema

em decorrência do resultado de outros

eventos.

Atendente

219

Casos de Uso

• Casos de Uso:

– Utilizado para representar as

funcionalidades do sistema.

– representa o que o sistema

faz. (não como)

Consultar Livro

220

Casos de Uso

Atores e Casos de Uso

221

Função

Emissor

Passo 1Passo 2…Passo N

Descrição

Exemplo de Ator e Casos de Uso

222

• Cliente de banco pode usar um caixa automático para

– sacar dinheiro, transferir dinheiro ou consultar o saldo da conta

• Ator: Cliente

• Use cases: Sacar dinheiro, transferir dinheiro e consultar saldo

Exemplo de Ator e Casos de Uso

223

Cliente

Transferirdinheiro

Sacardinheiro

Consultarsaldo

Casos de Uso

224

• Relacionamento entre Casos de uso

– Generalization: um caso de uso generaliza outro(s);

– Include: o caso de uso base incorpora o

comportamento do caso de uso incluído;

– Extend: caso de uso base incorpora o

comportamento de um outro caso de uso em local

especificado. Utilizamos este relacionamento quando

é necessário modelar parte do caso de uso que o

usuário pode ver como comportamento opcional do

sistema.

Inclusão

225

• O caso de uso base incorpora o comportamento do caso

de uso incluído

• Normalmente utilizado para representar reutilização ou

para reduzir a complexidade dos casos de uso

– Poucos casos de uso muito complexos X Muitos casos de

uso menos complexos

• Ex: Os casos de uso Obter Extrato, Realizar Saque e

Realizar Transferência podem incluir o caso Fornecer

Identificação

Extensão

226

• Use case pode ser estendido por outro

– Extensão de funcionalidade/Caso excepcional

• Extensão ocorre em pontos específicos

– Pontos de extensão

Extensão

227

• Há também inclusão de texto (fluxo de eventos)

– Porém sob condições particulares

• Pode ser usada para

– Simplificar fluxos de eventos complexos

– Representar comportamentos opcionais

– Lidar com exceções

Especialização

228

• Use case pode especializar outro

– Adição/refinamento do fluxo de eventos original

• Especialização permite modelar comportamento de estruturas

de aplicação em comum

• Comum também entre atores

Casos de Uso - Relacionamentos

229

Casos de Uso – Relacionamentos Possíveis ?

230

Entre

atores

Entre casos de

uso

Entre ator e

caso de uso

Comunicação

Inclusão

Extensão

Generalização

Casos de Uso - Exemplos

231


232

Consultar Livro

Validar Usuário

Atendente

Reservar Livro

<<include>>

<<include>>

Senha

Retina


233

Casos de Uso

234

• Identificando atores nos requisitos:

– Que grupos de usuários utilizam o sistema para realizar uma

tarefa?

– Que grupos de usuários são necessários para o sistema executar

suas funções?

– Quais são os sistemas externos que utilizam o sistema para

realizar suas tarefas?

– Quais são os sistemas externos que são gerenciados ou utilizados

pelo sistema executar suas tarefas?

– Quais são os sistemas externos ou grupo de usuários que enviam

informação para o sistema?

– Quais são os sistemas externos ou grupo de usuários que

recebem informação do sistema?

Observação: Misuse e Abuse Cases

235

• Utilizados para explorar questões de Requisitos

Não Funcionais de Segurança.


236

• Exemplo de Caso de Uso e Cenário:– “Emitir Saldo em um terminal eletrônico”

– Cenário (fluxo) principal:1. O sistema realiza a leitura do cartão magnético do

correntista

2. O sistema solicita a digitação da senha.

3. O correntista digita a senha

4. O sistema valida a senha

5. O correntista seleciona a opção de saldo

6. O sistema questiona o tipo de saldo (conta corrente, poupança, ...)

7. O correntista informa o tipo de saldo

8. O sistema processa e mostra o saldo do cliente ...


237

• Exemplo de Cenários (fluxos) Alternativos:

– Alternativa: Problema na leitura do cartão magnético

• 1a) Se o sistema não conseguir ler os dados do cartão

magnético, tentar nova leitura por, no máximo, duas vezes.

Caso persista o problema, encerrar caso de uso

– Alternativa: Senha Inválida

• 4a) Se a senha digitada pelo correntista não for igual a senha

cadastrada no sistema, informar ao mesmo e solicitar nova

digitação. Repetir esse processo por, no máximo três

tentativas (incluindo a primeira). Caso persista o problema, a

conta do usuário deve ser bloqueada e o caso de uso

encerrado.

Descrevendo Casos de Uso

238

• Estrutura– Nome– Objetivo– Atores– Prioridade– Freqüência de uso– Criticalidade– Pré-condições– Condição de Entrada– Fluxo Principal– Fluxo Alternativo– Fluxo de Exceção– Pontos de Extensão– Pós-condições– Regras de negócio

Exemplo 1

239

Exemplo 1 (continuação)

240

Exemplo 2

241

Exemplo 2(continuação)

242

Exemplo 2(continuação)

243

244


RF1: O sistema deve permitir à secretaria cadastrar cursos.

RF2: O sistema deve permitir à secretaria cadastrar disciplinas de cursos.

RF3: O sistema deve permitir à secretaria cadastrar alunos.

RF4: O sistema deve permitir ao departamento de recursos humanos (RH) cadastrar professores.

RF5: O sistema deve permitir à secretaria abrir turmas de disciplinas de cursos.

RF6: O sistema deve permitir aos coordenadores de curso alocar professores a determinadasturmas.

RF7: O sistema deve permitir à secretaria matricular alunos em turmas.

RF8: O sistema deve permitir aos professores lançar avaliações dos alunos das turmas que estejam sob sua responsabilidade.

RF09: O sistema deve permitir aos alunos consultar suas avaliações.

RF10: O sistema deve permitir à secretaria emitir diários de classes de turmas.

RF11: O sistema deve permitir à secretaria emitir históricos escolares de alunos.

RF12: O sistema deve efetuar o cálculo da aprovação de alunos em turmas, sendo que, para ser aprovado, deve-se ter frequência mínima de 75%. Além disso, para aprovação sem verificação suplementar, a média das notas parciais deve ser maior ou igual a 6,0. Para reprovação direta, esta média deve ser menor que 4,0. Médias entre 4,0 (inclusive) e 7,0 (exclusive) colocam o aluno em verificação suplementar. Se a nota da verificação suplementar for menor que 6,0, o aluno está reprovado, caso contrário, aprovado.

RF13: O sistema deve controlar a situação de um aluno, podendo estar matriculado, trancado, formado, ou ter abandonado o curso. 245

Sistema 1: Sistema de Controle Acadêmico

Exercício 1: Diagrama de Casos de Uso

Nome: <definir o nome do caso de uso>

Objetivo: <descrever o objetivo do caso de uso>

Requisitos: <identificação dos requisitos sendo atendidos pelo caso de uso>

Atores: <listar os atores que interagem com o caso de uso>

Trigger: <definir que evento dispara a execução desse caso de uso>

Fluxo Principal: <descrever passos numerados do fluxo principal do caso de uso>

Fluxo Alternativo <descrever os passos dos fluxos alternativos do caso de uso, indicando que evento dispara cada um deles>

Regras denegócio:

<listar as regras de negócios que devem ser respeitadas na execução do caso de uso>

246

Forneça a descrição para o caso de uso “Alocar Professor”. Faça uso dos requisitos levantados (slide

anterior) e do protótipo fornecido (visível ao acionar a opção “Alocação de Professores” da tela inicial do

sistema). Utilize o template de descrição fornecido a seguir.

Protótipo da tela. Template para descrição de casos de uso.

Exercício 2: Especificação de Caso de Uso

247

Sistema 2: Sistema de Reserva de Passagens Aéreas

RF1: Sistema deve permitir que o usuário efetue seu cadastro.

RF2: Sistema deve permitir que o usuário se autentique no sistema.

RF3: Sistema deve validar o pagamento junto com a operadora do cartão.

RF4: Sistema deve permitir que o cliente consulte o trecho da viagem.

RF5: Sistema deve enviar para os clientes cadastrados e-mails promocionais.

RF6: Sistema deve permitir que o cliente consulte as datas disponíveis de ida e volta.

RF7: Sistema deve permitir que o cliente defina a forma de pagamento.

RF8: Sistema deve permitir que o cliente consulte CEP.

RF09: Sistema deve permitir que o cliente solicite a reserva on-line.

RF10: Sistema deve gerar código de reserva.

RF11: Sistema deve emitir e-mail para o cliente confirmando a reserva com dados.

RF12: Sistema deve permitir que o cliente cancele a reserva.

RF13: Sistema deve permitir que o Administrador emita relatório de reservas confirmadas.

RF14: Sistema deve permitir que o Administrador emita relatório de reservas canceladas.

RF15: Sistema deve permitir que o cliente edite seus dados pessoais.

RF16: Sistema deve permitir que o Administrador emita relatório de usuários cadastrados.


248

Sistema 3: Sistema de Solicitações

RF1: O software deve permitir que usuários do tipo Avaliador sejam associados a um ou mais tipos de solicitação sobre os quais ele atuará.

RF2: O software deve permitir que o coordenador solicite Diárias.

RF3: O software deve permitir que o coordenador solicite a Inclusão de uma nova PF.

RF4: O software deve apresentar, de acordo com a modalidade de pagamento, a lista de documentos necessários para conclusão da solicitação de inclusão/alteraçao de PF.

RF5: O software deve permitir que os colaboradores incluam ou alterem os documentos necessários para aprovação da inclusão/alteração de PF.

RF6: O software deve permitir que os colaboradores incluam ou alterem as modalidades de pagamento.

RF7: O software deve permitir que os colaboradores associem os documentos cadastrados com as modalidades de pagamento existentes.

RF8: O software deve permitir que o coordenador solicite a Alteração de dados de uma PF.

RF9: O software deve permitir que o coordenador solicite Passagem Aérea.

RF10: O software deve permitir que o coordenador solicite inclusão, exclusão ou alteração de Pagamentos à bolsistas.

RF11: O software deve permitir que o coordenador solicite Suprimentos.

RF12: O software deve permitir que o coordenador solicite Transferência de Recursos entre Projetos.

RF13: O software deve permitir que os colaboradores incluam ou alterem as moedas (unidades monetárias).

RF14: O software deve enviar email para os solicitantes e coordenadores sobre a aprovação ou reprovação de suas solicitações.


249

Sistema 4: Módulo de Controle de Acesso

RF1: O software deve identificar e validar todos os usuários que desejarem acessá-lo, identificando o seu perfil.

RF2: O software deve disponibilizar ao usuário identificado: as funcionalidades associadas ao seu perfil e ao seu papel no sistema, as funcionalidades de acesso restrito e as funcionalidades de acesso público.

RF3: O software deve disponibilizar ao usuário não identificado somente as funcionalidades públicas.

RF4: O software deve permitir ao usuário recuperar a sua senha, caso a esqueça.

RF5: O software deve permitir que o administrador inclua, altere ou exclua usuários.

RF6: O software deve permitir que o administrador inclua, altere ou exclua perfis de acesso.

RF7: O software deve permitir que o administrador associe as funcionalidades disponíveis nos módulos aos perfis cadastrados ou exclua dos perfis as funcionalidades previamente associadas.

RF8: O software deve permitir que o administrador associe um usuário a um único perfil de acesso.

RF9: O software deve permitir ao administrador consultar as funcionalidades associadas a um perfil ou usuário.

RF10: O software deve permitir ao administrador consultar os usuários associados a um determinado perfil.

RF11: O software deve permitir que todos os usuários façam a manutenção de seus dados pessoais.

RF12: O software deve permitir que os administradores reenviem a senha de qualquer usuário e que os usuários reenviem a própria senha.

RF13: O software não deve permitir o acesso de nenhum administrador ou outro usuário às senhas cadastradas.

RF14: O software deve gerar senhas temporárias, válidas somente no primeiro login, quando as senhas forem reenviadas pelos administradores ou pelos próprios usuários.

RF15: O software deve solicitar a troca de senha, após o login, para todas as senhas que já expiraram.


250

Sistema 4: Módulo de Controle de Acesso

Exercício 5: Diagrama de Casos de Uso (Solução)

251

Em relação aos requisitos do slide anterior, forneça a descrição concreta do caso de uso que permitirá a um usuário o acesso ao

sistema. Faça uso do protótipo fornecido (visível a partir da tela inicial do sistema). Utilize o template de descrição fornecido a

seguir.

Template para a descrição do caso de uso.

Nome: <definir o nome do caso de uso>

Objetivo: <descrever o objetivo do caso de uso>

Requisitos: <identificação dos requisitos sendo atendidos pelo caso de uso>

Atores: <listar os atores que interagem com o caso de uso>

Trigger: <definir que evento dispara a execução desse caso de uso>

Fluxo Principal: <descrever passos numerados do fluxo principal do caso de uso>

Fluxo Alternativo <descrever os passos dos fluxos alternativos do caso de uso, indicando que evento dispara cada um deles>

Regras denegócio:

<listar as regras de negócios que devem ser respeitadas na execução do caso de uso>

Protótipo da tela de acesso ao sistema.

Exercício 6: Especificação de Casos de Uso

Nome: Entrar no Sistema

Objetivo: Permitir a autenticação do usuário e disponibilizar funcionalidades de acordo com o seu perfil.

Requisitos: RF1, RF2, RF3, RF4, RF13, RF14, RF15

Atores: Usuário.

Trigger: O ator acessa a tela inicial do sistema.

FluxoPrincipal:

1. O sistema exibe os campos ‘Usuário’ e ‘Senha’, as opções ‘Entrar’ e ‘Esqueci minha Senha’ e um menu com as funcionalidades públicas [RN1].

2. O ator preenche os campos e seleciona a opção ‘Entrar’ [A1].3. O sistema valida as informações de acesso [A3][A4].4. O sistema identifica o perfil do usuário e apresenta um menu com as

funcionalidades associadas ao seu perfil e as funcionalidades de acesso público [RN2].

Fluxos

Alternativos:[A1] O ator seleciona a opção ‘Esqueci minha Senha’.1. O sistema apresenta uma tela com o campo ‘e-mail’ e a opção ‘Reenviar Senha’.2. O ator preenche o campo e seleciona a opção ‘Reenviar Senha’.3. O sistema verifica se o e-mail está cadastrado, gera e envia a nova senha [A2].4. O sistema apresenta a mensagem ‘Senha enviada para o e-mail <e-mail>’5. O sistema retorna para o passo 1 do fluxo principal.

[A2] E-mail não cadastrado.1. O sistema apresenta a mensagem ‘e-mail não cadastrado’ e retorna para o passo 1 do fluxo A1.

[A3] Usuário e/ou senha inválidos.1. O sistema apresenta a mensagem ‘Informações de acesso inválidas’.2. O sistema retorna para o passo 1 do fluxo principal. 252

Exercício 6: Solução

253

FluxosAlternativos(cont.):

[A4] Senha expirada.1. O sistema informa que a senha expirou.2. O sistema exibe os campos ‘nova senha’ e ‘confirmação da nova senha’ e a opção ‘Salvar’.2. O ator preenche os campos e seleciona a opção ‘Salvar’3. O sistema valida o formato da senha [RN3] [A5]4. O sistema informa que a senha foi alterada e retorna para o passo 4 do fluxo principal.

[A5] Senha com formato inválido ou diferente da confirmação.1. O sistema informa se a senha não está em formato válido ou se a confirmação não bate com a senha fornecida.2. O sistema retorna para o passo 2 do fluxo alternativo A4.

Regras de negócio:

[RN1] O software deve disponibilizar ao usuário não identificado somente as funcionalidades de acesso público.[RN2] Caso o usuário identificado não possua nenhum perfil associado o software deve disponibilizar somente as funcionalidades de acesso público.[RN3] Senhas devem ter entre 6 e 8 caracteres e possuir letras e dígitos.

Exercício 6: Solução

254

• Especifique detalhadamente os 4 casos de uso

do exercício do teatro de elicitação (da aula

sobre elicitação de requisitos), com base nos

protótipos e nas informações levantadas.

Exercício 7: Especificação de Casos de Uso

Leituras Sugeridas

255

• Custo de Requisitos Ágeis

– MENDES, T. S.; SOARES, H. F.; FARIAS, M. A. F.; MENDONCA,

M.; KALINOWSKI, M.; SPINOLA, R. O. Impacts of Agile

Requirements Documentation Debt on Software Projects: A

Retrospective Study. In: ACM Symposium on Applied

Computing (ACM SAC), p. 1300-1306, 2016, Pisa, Italy.

Visão Geral da UMLCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Modelagem

Modelos são úteis para:

◦ o entendimento de problemas.

◦ comunicação entre as pessoas envolvidas em um

projeto.

◦ promover a melhor compreensão dos requisitos do

projeto.

◦ promover a difusão deste conhecimento entre os

envolvidos.

◦ Avaliar diferentes soluções através da modelagem da

solução.

Exemplos de Modelos

258

• Maquetes de edifícios

• Maquetes de aviões

• Plantas de circuitos

• Modelos de sistemas

Modelos e Complexidade

259

• Modelos muitas vezes são criados devido a limitação

do ser humano em lidar com a complexidade

• Complexidade progressiva

– Construir uma parede

– Construir uma casa

– Construir um edifício

– Construir um arranha-céu

UML

Histórico da UML

◦ Década de 90 – Muitas Metodologias diferentes.

◦ Três delas se destacavam

OMT (James Rumbaugh) – Forte em Análise e fraco em design.

Grady Booch – Forte em design e fraco em análise.

OOSE (Ivar Jacobson) – Forte em comportamento de análise.

◦ Em 1994 Booch e Rumbaugh se uniram para formar a Rational

Software, com a intenção de unir seus métodos e criar um padrão.

◦ Em 1995 a Rational compra a Objectory, anunciando a união com Ivar

Jacobson.

◦ Em 1997 a Rational lança a versão 1.0 da UML(Unified Modeling

Language), com a sua proposta para OMG(Object Management

Group).

◦ Fim da guerra dos métodos e criação da Unified Modeling Language

(UML), com a adoção da versão 1.1 como padrão oficial da OMG.

◦ ...

◦ Versão atual: 2.x.

O que é UML?

• Visualizar: facilita entendimento dos modelos projetados;

• Especificar: permite construir modelos precisos, não ambíguos

e completos;

• Construir: por possuir semântica, os elementos da UML

podem estar associados a linguagens de programação;

• Documentar.

É uma linguagem para visualizar,

especificar, construir e documentar

artefatos de sistemas de software.

UML

UML é apenas uma notação e não propõem/define

como organizar atividades de um projeto. Por isto,

pode ser ajustada para satisfazer diferentes

situações de desenvolvimento e ciclos de vida.

UML

• UML pode ser utilizada para:

– Especificar o escopo do sistema e suas principais funções através do Diagrama de Casos de Uso

– Representar estruturas estáticas de um sistema através dos Diagramas de Classe

– Ilustrar o comportamento dos casos de uso através dos Diagramas de Interação

– Modelar o comportamento de objetos através do Diagrama de Estados

– Planejar como os componentes do sistema estarão distribuídos e serão implantados através dos Diagramas de Componente e Implantação

Diagramas UML

• Diagramas da UML:

– Estrutural

– Comportamental

• Visão estática (estrutural):

– 1.Diagrama de classes

– 2.Diagrama de objetos

– 3.Diagrama de componentes

– 4.Diagrama de pacotes

– 5.Diagrama de estruturas compostas

– 6.Diagrama de implantação

– 7.Diagramas de perfis

265

• Visão dinâmica (comportamental):

– 1. Diagrama de casos de uso

– 2.Diagrama de sequência

– 3.Diagrama de comunicação

– 4.Diagrama de gráfico de estados

– 5.Diagrama de atividades

– 6.Diagrama de temporização

– 7.Diagrama de visão geral da interação

Diagramas UML

266

Diagrama de Classes e PacotesCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Classe é uma descrição de um conjunto de objetos que

compartilham os mesmos atributos, operações,

relacionamentos e semântica.

Principal bloco de construção de um sistema orientado a objeto;

Notação:

Atributos

Operações

Nome

268

Classe

Convenções

• O nome da classe deve começar por letra

maiúscula.

• O nome do atributo deve iniciar por minúsculo,

porém o segundo nome deve ser maiúsculo

(camelCase).

• O nome da classe deve ser no singular.

269

Convenções

270

• Nome

– Na prática, os nomes das classes são substantivos ou

expressões breves, definidos a partir do vocabulário do

sistema cuja modelagem está sendo feita.

Nome

271

Nome da Classe

• Um atributo é uma propriedade nomeada de uma classe.

• Uma classe pode ter qualquer número de atributos ou

mesmo nenhum atributo.

Atributos

Exemplo:

Todo funcionário possui nome, data

de nascimento, sexo…

272

Atributos

Operações

• Uma operação é a assinatura de uma

implementação de algum serviço (e.g., método)

prestado pela classe.

• Uma classe pode ter qualquer número de operações

ou até não ter nenhuma.

• Muitas vezes (mas nem sempre), a chamada a uma

operação em determinado objeto altera os dados ou

o estado do objeto.

273

Operações

• As operações podem ser representadas das

seguintes formas:

– Somente o seu nome;

– Sua assinatura – nome, tipo e valor padrão dos parâmetros

e (no caso de funções) o tipo a ser retornado.

274

Na prática, o nome de uma operação é um verbo ou uma locução verbal breve,

representando algum comportamento da classe correspondente.

Tipicamente, aparece com maiúsculo o primeiro caractere de cada palavra existente

no nome da operação, exceto a primeira letra, como em mover e setaAlarme.

Classe - Visibilidade

Visibilidade é uma propriedade cujo valor

(public, protected, or private) denota como

o elemento poderá ser visto externamente:

◦ + public: significa que qualquer objeto que se relacione

com a classe pode acessar os atributos ou operações da

classe.

◦ # protected: atributos e operações de uma classe são

acessíveis apenas por ela mesma e suas subclasses.

◦ - private: atributos e operações de uma classe são

acessíveis apenas pela própria classe.

275

• Concreta: pode ser

instanciada

• Abstrata: não pode

ser instanciada.

Classe Abstrata

276

Classes Concretas e Abstratas

Classe – Algumas Considerações

Toda classe deve representar uma abstração

conceitual do domínio do problema ou da solução.

Assim, uma classe bem estruturada deve:

◦ Ser uma abstração de um conceito presente no domínio do

problema ou da solução;

◦ Ser fortemente coesa;

◦ Possuir baixo acoplamento;

277

Heurística para identificação de classes

278

• Por exemplo, se o

requisito é referente a

“um sistema de reserva e

venda de ingressos para

apresentações em

diferentes teatros”

• A tentativa de classes

e atributos poderia

ser:

– Sistema, ingresso,

apresentação, teatro.

Heurística para identificação de operações

279

• Por exemplo, se o

requisito é referente a

“um sistema de reserva e

venda de ingressos para

apresentações em

diferentes teatros”

• A tentativa de

comportamentos

(operações) poderia

ser:

– Reservar ingressos,

vender ingressos

Relacionamento

• Especifica como as classes se relacionam;

• Podem ser de três tipos:– Generalização: relaciona classes generalizadas

com suas especializações.

– Associação: representa relação estrutural entre duas classes.• Associação simples.

• Agregação: faz parte.

• Composição: é membro de.

– Dependência: relação usa.

280

Relacionamento – Generalização (herança)

281

Relacionamento: é um tipo de.

Classe Base

Generalização

Classes Folha

Associação

• Uma associação é uma conexão semântica bidirecional entre

classes.

• Indica que existe uma ligação entre objetos das classes

associadas.

• A notação UML de uma associação é mostrada como uma linha

conectando classes associadas.

• Exemplo : Vendedor vende Produto.

282

Vendedor ProdutoVende

Associação

Navegação

◦ Considerando uma associação simples entre duas classes,

como Livro e Biblioteca, é possível navegar de objetos de

um tipo até objetos de outro tipo. A menos que seja

especificado o contrário, a navegação é bidirecional.

◦ Para indicar a direção da navegação, podemos incluir setas

indicando a direção a ser seguida.

283

Associação X Generalização

284

Associação

Generalização

Agregação

• É uma forma especializada de associação, na qual uma classe

“faz parte” da outra.

• A notação UML de uma agregação é uma associação com um

diamante próximo a classe que representa o agregador (todo).

285

Relacionamento – Agregação

• Um tipo de associação que representa a

relação todo-parte.

• Utilizado quando:

– As partes são “parte” do agregador;

– Ou o agregador é formado de partes;

286

Relacionamento – Composição

287

É um tipo forte de

agregação.

◦ Se o objeto agregador for

destruído, suas partes

também o serão.

◦ O objeto parte só existe

para “compor” o agregador.

“É membro de”.

Relacionamento – Composição

Exemplos:

288

Indicador de Multiplicidade

• Embora a multiplicidade seja especificada para

classes, ela define a quantidade de objetos que

participam de um relacionamento.

289

Relacionamentos Reflexivos

290

• Múltiplos objetos pertencentes à mesma classe podem

precisar comunicar-se uns com os outros. Isso é mostrado

no diagrama de classe como uma associação ou agregação

reflexiva.

• Exemplo: Disciplinas de um curso de graduação, algumas

delas necessitam de pré-requisitos para serem cursadas.

Classes Associativas

291

• São conceitos que são relacionados com

associações.

• São representados como classes ligadas a

associações através de linhas pontilhadas.

• Exemplo:

Relacionamentos: Exemplo

292

Diagrama de Classe - Notação

293

Exemplo de Aplicação das Heurísticas

• Descrição dos Requisitos:

Uma locadora de veículos deseja um sistema para facilitar o atendimento a seus

clientes. O processo de aluguel de carros atual é confuso e está gerando

insatisfação entre os clientes. A locadora é composta basicamente pelos seus

funcionários e carros para aluguel. Os funcionários são identificados por cpf,

nome, endereço, telefone. Já os carros estão divididos em diversos tipos:

popular, luxo, utilitário, etc. As informações importantes sobre os carros a

serem armazenadas são: código (chapa do carro), tipo, modelo, ano, cor,

chassis, km e valor do aluguel (diárias e semanais).

Os funcionários serão responsáveis pelo cadastro dos clientes e dos carros

adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e

dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os

especiais possuem uma taxa de desconto e um valor de quilometragem extra

para seus aluguéis. Qualquer cliente é identificado por rg, nome, cpf, telefone,

endereço, cidade.

294

Descrição dos Requisitos (cont.):

Desta forma, o cliente poderá solicitar o aluguel de carros a um funcionário da

locadora. Os tópicos abaixo descrevem as funcionalidades do sistema.

– Alugar Carro: cliente deve solicitar ao funcionário o aluguel do carro. O

sistema verifica se o carro solicitado pelo cliente está disponível. Caso

esteja, o processo de locação é concluído e o carro passa a estar

indisponível. A data de aluguel deve ser guardada para calculo do valor do

aluguel na devolução.

– Dar Baixa: cliente faz devolução do carro para o funcionário e solicita

nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel.

O funcionário coloca o status do carro novamente como disponível, solicita

ao sistema para calcular o valor a ser pago e emite o recibo para o

cliente.

– Cadastrar Cliente: cliente solicita ao funcionário que o cadastre na

locadora. O funcionário recebe os dados e cadastra-o.

– Cadastrar Carro: funcionário cadastra o carro adquirido.

295

Sequência de Atividades Sugeridas

• Identifique um primeiro conjunto de classes;

• Adicione atributos e comportamentos;

• Encontre generalizações;

• Adicione associações;

• Reveja o modelo construído adicionando ou

removendo classes, atributos, associações ou

generalizações

296


297

Extraindo Substantivos

• cliente• nome• cpf• telefone• endereço• Locadora• Veículo• sistema• carros• popular• luxo• utilitários• Modelo• tipo• Ano• Contato• Status• recibo • cor• código

298

• chassis• quilometragem• valor do aluguel diária• valor do aluguel semanal• clientes especiais• clientes comuns• taxa de desconto• valor de quilometragem• Aluguel• Data de aluguel• nota fiscal• quilometragem percorrida• valor do aluguel• funcionário• código• nome• endereço• telefone• cidade


299

Classificando os Substantivos

• Classes Candidatas– Locadora– Veículo– Cliente– Clientes Especial– Clientes Comum– Sistema– Carros– Popular– Luxo– Utilitários– Funcionário– Aluguel

• Atributos– nome– cpf– telefone– endereço – Modelo

300

– tipo– Ano– Contato– Status– quilometragem percorrida– valor do aluguel – cor– codigo– chassis– quilometragem– valor do aluguel diária– valor do aluguel semanal– taxa de desconto– valor de quilometragem– Data de aluguel

• Informação Estranha– Nota fiscal

• Redundância– Recibo

Classificando os Substantivos

• Classes Candidatas– Locadora– Cliente– Clientes Especial– Clientes Comum– Carro– Popular– Luxo– Utilitários– Funcionário– Aluguel

• Atributos– nome– cpf– telefone– endereço – Modelo– tipo– Ano

301

– Contato– Status– quilometragem percorrida– valor do aluguel – cor– codigo– chassis– quilometragem– valor do aluguel diária– valor do aluguel semanal– taxa de desconto– valor de quilometragem– Data de aluguel

• Informação Estranha– Nota fiscal– Sistema

• Redundância– Recibo– Veículo

Locadora

302

303


• Alugar

• Emitir nota fiscal

• Calcular preço

• Cadastrar carro

• Cadastrar cliente

• Alterar Disponibilidade

• Verificar Disponibilidade

• Pegar o valor do aluguel do carro

• Pegar a data do aluguel

• Pega valor de desconto do cliente

• Pega valor de quilometragem extra

• Confirmar Aluguel

304


Onde colocar os Comportamentos?

Locadora

305

Classes Definidas

306

Identificando Generalizações

307

Generalização Identificada

308

Identificando Generalizações

309

Generalização Identificada

310

Modelo Momentâneo

311

Identificando Associação

• Começar com as classes consideradas mais centrais e importantes.

• Decidir quais os relacionamentos destas com as outras.

– Uma associação existe se uma classe:

• Possui;

• Controla;

• Está conectada para;

• Está relacionada para;

• É parte de;

• Tem como parte;

• É membro de;

• Tem como membro.

– Alguma outra classe no modelo.

• Evite adicionar muitas associações a uma classe. O acoplamento fica muito

alto.

• Especifique a multiplicidade.

312

Acrescentando Associações

313

Acrescentando Associações

314

Interface

Coleção de operações que especificam os serviçosde uma classe ou componente.

Descreve os comportamentos que podem ser acessados externamente.

É similar a uma classe entretanto,◦ Não possui estado;

◦ Os métodos não estão implementados.

Declarando a interface, você pode estabelecer o comportamento desejado de uma abstraçãoindependente de qualquer implementação destainterface.

316

Interface

• Notação

– Uma interface é representada graficamente como

um círculo.

317

ISensor IValidação IBusca

Na prática, os nomes das interfaces são curtos ou expressões nominais definidas a

partir do vocabulário do sistema que está sendo modelado.

Para diferenciar Interface e uma classe podemos utilizar a letra I antes do nome de

cada Interface.

Interface

• Quando visualizamos a interface como um círculo, suprimimos

a exibição das operações, caso seja necessário, podemos

representar a interface como uma classe estereotipada(*),

listando as suas operações no compartimento apropriado.

318

<<interface>>

ITrataURL

abreConexao ( )

analisaURL ( )

setaURL ( )

Interface

319

Realização (ou

implementação) da

Interface

Interface (Outra Notação)

320

Interfaces Requeridas

Interfaces Implementadas

(Realização)

Pacote

321

Pacote é um mecanismo cujo objetivo é organizar

elementos de modelagem em grupos.

Visualizar, especificar, construir e documentar sistemas grandes

envolve a manipulação de uma grande número de classes,

interfaces, componentes....

Utilizado para:

Organizar elementos de modelagem;

Manter elementos com afinidade semântica próximos;

Pacotes bem estruturados são fracamente acoplados e fortemente

coesos.

Diagrama de Pacotes

Produto Servico

Cliente

322

Nome

Dependência

Pacote

Pacote

Utilizado para quebrar um sistema em pequenos

pedaços mostrando a dependência entre classes

dos diferentes pacotes.

Uma dependência existe entre dois elementos se

modificações na definição de um elemento pode

provocar modificações no outro

◦ Dependências possíveis entre duas classes:

uma classe envia uma mensagem para outra

uma classe possui outra como parte de seus dados

uma classe menciona outra como um parâmetro para uma

operação

323

Modelo do Domínio do Sistema X Modelo do Sistema

• O Modelo do Domínio do Sistema omite as classes de suporte.

• Modelo do Sistema é o diagrama de classes de baixo nível. Além do modelo do domínio do sistema, é composto também por:

• Classes de interface com o usuário;

• Classes arquiteturais;

• ...

324

Elaboração do Diagrama de Classes do Domínio

Exemplo:

◦ Identifique um primeiro conjunto de classes;

◦ Adicione atributos e comportamentos;

◦ Encontre generalizações;

◦ Adicione associações;

◦ Reveja o modelo construído adicionando ou removendo

classes, atributos, associações ou generalizações.

325

Categorização BCE

• Para auxiliar a aplicação da análise de casos de uso, podemos

usar a categorização BCE (boundary/control/entity).

• Essa categorização:

– Serve de “arcabouço” para identificar os objetos participantes da

realização de cada caso de uso.

– Agrupa objetos de acordo com o tipo de responsabilidade a eles

atribuída.

326

Categorização BCE

• Objetos de entidade: representam

conceitos do domínio do problema.

Associados a informações persistentes.

• Objetos de fronteira: atores interagem com

esses objetos

• Objetos de controle: intermediários entre

fronteiras e entidades; definem o

comportamento de um caso de uso

específico.

327

Categorização BCE

328

Exemplos Reais

• Mostrar alguns exemplos reais.

• Elaboração de um modelo de domínio de

sistema a partir de um recorte de um

documento de requisitos real.

329

Leituras Sugeridas

• Larman, C., Utilizando UML e Padrões, 3ª edição,

Editora Bookman, 2007, Capítulos 6, 9 e 16.

• Leituras Complementares

BEZZERRA, E., "Princípios de Análise e Projetos de Sistemas com Uml",

2007.

BOOCH, G., RUMBAUGH, J., JACOBSON, I., "UML 2.0-Guia do Usuário",

Editora Campus, 2005.

FOWLER, M., "UML Essencial", 3ed, Editora Bookman, 2005.

WASZLAWICK, R.S., "Análise e Projeto de Sistemas de Informação

Orientados a Objetos", Editora Campus, 2004.

330


331

Diagrama de Classes do Domínio

• Desenhe um diagrama de classes com relacionamentos,

nomes de papéis e multiplicidades para as seguintes

situações:

– Uma Pessoa pode ser casada com outra Pessoa;

– Uma Disciplina é pré-requisito para outra Disciplina;

– Uma Peça pode ser composta de diversas outras Peças.

332


• Desenhe um diagrama de classes com relacionamentos,

nomes de papéis e multiplicidades para as seguintes

situações:

– Uma Pessoa pode ser casada com outra Pessoa;

– Uma Disciplina é pré-requisito para outra Disciplina;

– Uma Peça pode ser composta de diversas outras Peças.

333


• Uma estação ferroviária é composta por 1 ou mais linhas ferroviárias. Em uma linha

ferroviária podem estar estacionados diversos recursos ferroviários. Recursos ferroviários

são vagões, locomotivas ou trens. Um trem é formado por vagões e locomotivas. Podem

existir vagões e locomotivas estacionadas em uma linha sem estarem na formação de um

trem. Uma estação ferroviária tem uma sigla e uma descrição (que não precisa

obrigatoriamente possuir um valor). Uma linha ferroviária tem um número (que a

diferencia de outra linha dentro da mesma estação), uma extensão em metros e uma

descrição (que não precisa obrigatoriamente ter um valor). Um vagão é descrito por um

número de série, tipo, capacidade de carga (valor default igual a 3000 ton), comprimento

entre testeiras e comprimento dos engates (um único valor correspondendo aos dois

lados). Uma locomotiva é descrita por um número de série, capacidade de tração e

comprimento. Um trem é descrito por um prefixo (ex: NAG1010) e data/hora de

formação.

• Um trem é formado em uma estação ferroviária de origem e tem como destino, uma

outra estação ferroviária, ou seja, a estação de origem não pode ser igual à estação de

destino. Todo trem é formado por pelo menos uma locomotiva e um vagão. A cada 40

vagões, um trem tem que ter uma locomotiva adicional. Um trem não pode ter mais do

que 150 recursos (vagões e locomotivas).

• Elabore um diagrama de classes do domínio, ilustrando os conceitos (classes, atributos e

relacionamentos) e restrições mencionados no texto.

334


• Restrições:

– Um trem é formado por vagões e locomotivas estacionados na mesma linha.

– Podem existir vagões e locomotivas estacionadas em uma linha sem estarem na formação de um trem.

– A estação de origem não pode ser igual à estação de destino.

– A cada 40 vagões, um trem tem que ter uma locomotiva adicional.

335


• Considere o diagrama de classes a seguir. Modele

uma alternativa para este mesmo diagrama fazendo

uso de uma classe associativa.

336


• Considere o seguinte discurso relativo a um sistema

de partidas de tênis: "Num torneio de tênis, cada

partida é jogada entre 2 jogadores. Pretende-se

manter informação sobre o nome e idade dos

jogadores; data da partida e atribuição dos

jogadores às partidas. O máximo de partidas que

um jogador poderá realizar é 6 e o mínimo 1.”

• Desenhe o diagrama de classes correspondente.

337


• Considere o seguinte discurso relativo a um sistema

de partidas de tênis: "Num torneio de tênis, cada

partida é jogada entre 2 jogadores. Pretende-se

manter informação sobre o nome e idade dos

jogadores; data da partida e atribuição dos

jogadores às partidas. O máximo de partidas que

um jogador poderá realizar é 6 e o mínimo 1.”

• Desenhe o diagrama de classes correspondente.

338


• Identifique classes e/ou relacionamentos a partir das

seguintes regras do negócio:

a) Pedidos são compostos de vários itens de pedido.

b) Um item de pedido diz respeito a um e exatamente um produto.

c) Um pedido pode conter até 20 itens.

339


• Identifique classes e/ou relacionamentos a partir das

seguintes regras do negócio:

a) Pedidos são compostos de vários itens de pedido.

b) Um item de pedido diz respeito a um e exatamente um produto.

c) Um pedido pode conter até 20 itens.

340


• Considere um sistema de software para controlar um hotel.

Normalmente, um hóspede ocupa um quarto por estadia. Mas,

suponha que uma nova regra foi criada no negócio: agora, um

hóspede pode utilizar até três quartos. Desenhe o diagrama de

classe para essas duas situações.

– a) um hóspede ocupa um quarto

– b) um hóspede ocupa até três quartos

341


• Considere um sistema de software para controlar um hotel.

Normalmente, um hóspede ocupa um quarto por estadia. Mas,

suponha que uma nova regra foi criada no negócio: agora, um

hóspede pode utilizar até três quartos. Desenhe o diagrama de

classe para essas duas situações.

– a) um hóspede ocupa um quarto

– b) um hóspede ocupa até três quartos

342


343

• Modelar a situação: “Uma pessoa ao longo da vida, tem vários empregos, em

empresas diferentes. Para a Previdência, é importante saber a data de

admissão e a data de rescisão de contrato com cada uma dessas Empresas”.

• Modelar a situação: “Um empregado pode trabalhar em vários projetos. Para

fins de cálculo da remuneração é preciso saber quantas horas ele trabalha em

cada projeto. Os empregados podem se ligar ou se desligar de um projeto a

qualquer momento, mas é preciso guardar o histórico de participação dos

empregados nos projetos”.


• Modelar a situação: “Uma pessoa ao longo da vida, tem vários empregos, em

empresas diferentes. Para a Previdência, é importante saber a data de

admissão e a data de rescisão de contrato com cada uma dessas Empresas”.

• Modelar a situação: “Um empregado pode trabalhar em vários projetos. Para

fins de cálculo da remuneração é preciso saber quantas horas ele trabalha em

cada projeto. Os empregados podem se ligar ou se desligar de um projeto a

qualquer momento, mas é preciso guardar o histórico de participação dos

empregados nos projetos”.

344


RF1: O sistema deve permitir à secretaria cadastrar cursos.

RF2: O sistema deve permitir à secretaria cadastrar disciplinas de cursos.

RF3: O sistema deve permitir à secretaria cadastrar alunos.

RF4: O sistema deve permitir ao departamento de recursos humanos (RH) cadastrar professores.

RF5: O sistema deve permitir à secretaria abrir turmas de disciplinas de cursos.

RF6: O sistema deve permitir aos coordenadores de curso alocar professores adeterminadas turmas.

RF7: O sistema deve permitir à secretaria matricular alunos em turmas.

RF8: O sistema deve permitir aos professores lançar avaliações dos alunos das turmas que estejam sob sua responsabilidade.

RF09: O sistema deve permitir aos alunos consultar suas avaliações.

RF10: O sistema deve permitir à secretaria emitir diários de classes de turmas.

RF11: O sistema deve permitir à secretaria emitir históricos escolares de alunos.

345

Sistema de Controle Acadêmico

• Elabora um diagrama de classes do domínio para o seguinte conjunto de requisitos funcionais (classes e relacionamentos).

Atividade Prática (Opcional)

346

• Elabore uma especificação técnica para o recorte de especificação funcional (requisitos e casos de uso) real fornecido.

– Neste momento foque em elaborar o diagrama de classes do domínio, incluindo classes, atributos e relacionamentos.

Diagramas de InteraçãoCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Modelagem Comportamental: Cenários

• Definição

– Um cenário é um caminho entre os fluxos de um caso de

uso

• Um caso de uso é uma coleção de cenários

– Um cenário é uma instância de um caso de uso

– Casos de uso são compostos de um fluxo principal e sub-

fluxos

– Sub-fluxos também podem se ramificar em sub-fluxos

– As ramificações de fluxos e sub-fluxos formam uma árvore

– Um cenário é um caminho da raiz até um nó folha da

árvore de fluxos e sub-fluxos de um caso de uso

348

Fluxos e Sub-Fluxos

349

Cenários

350

• Um cenário é um caminho da raiz até uma folha da árvore

de ramificações de um caso de uso.

Cenários

• No desenvolvimento de um sistema, o

analista usualmente começa sua

investigação pelos cenários primários (fluxo

principal dos casos de uso);

• Cenários secundários são progressivamente

agregados.

351

Diagramas de Interação

• Esses diagramas representam mensagens trocadas

entre objetos para a execução de cenários dos

casos de uso do sistema.

– Tipicamente, cada diagrama de interação está relacionado

a um cenário do caso de uso.

• A construção desses diagramas é uma consolidação

do entendimento dos aspectos dinâmicos do

sistema.

352

Diagramas de Interação

353

: lender : librarian

: index : assitant

1: BookRequest

2: look up

3: 4: get

5:

6:

Interações podem ser modeladas de duas maneiras:

(1) enfatizando a colaboração dos objetos;

(2) enfatizando a seqüência das mensagens enviadas;

(1) (2)

Diagrama de Sequência

• Os objetos são organizados horizontalmente no diagrama.

• Um objeto é representado como uma caixa no topo de uma

linha vertical tracejada (linha de vida do objeto).

• O ator que inicia a interação é geralmente colocado na

esquerda superior do diagrama.

• A dimensão vertical representa o tempo.

354

Mensagem

• O princípio básico da interação entre objetos é o conceito de

mensagem.

• O fato de um objeto “precisar de ajuda” indica a necessidade

de este enviar mensagens.

• Na construção de diagramas de interação, mensagens de um

objeto a outro implicam em operações que classes devem ter.

355

Uma mensagem implica na existência de uma operação

no objeto receptor. A resposta do objeto receptor ao

recebimento de uma mensagem é a execução da

operação correspondente.

Mensagem

umUsuário: Usuário

validar(in id : String, in senha : String) : bool

loginsenha

Usuário

validar(id, senha)

: ControladorAcesso

356

Mensagens são representadas por setas entre as caixas de ativação.

Tipos de mensagens

Tipos de mensagem definidos pela UML:◦ mensagem síncrona: indica que o objeto remetente

espera que o objeto receptor processe a mensagem antes de recomeçar o seu processamento.

◦ mensagem assíncrona: objeto remetente não espera a resposta para prosseguir com o seu processamento.

◦ mensagem de retorno: indica o término de uma operação.

357

Síncrona

Assíncrona

Retorno

Forma geral de diagramas de sequência

Objeto1 Objeto2 Objeto3

mensagem1

mensagem2

Atormensagem0

mensagem3

Classe

Ator Objeto

Foco decontrole

Mensagem

Classe

Linha devida

358

: : :

Retorno de uma mensagem

359

Duas formas de mostrar o valor de retorno de uma

mensagem

Forma geral de diagramas de sequência

Objeto1 Objeto2

Objeto3

1*[i := 1..2]: m1()

1.1: criar()

1.2 *[i:=1..3]: r := r + m2()

destruir()

[r == 3]: m3()

[r < 3]: m4()

Iteração

Guarda

Mensagemreflexiva Mensagem

de retorno

Destruição

Mensagemassíncrona

Mensagemsimples

m5() Mensagemsíncrona

360

: :

:

Frames em Diagramas de Sequência (UML 2)

361

Loops

Loops na especificação UML 1.x

362

Mensagens Condicionais

363

Mensagens condicionais na UML 1.x

364

Mensagens condicionais mutuamente exclusivas

365

Percorrendo uma coleção

366

Usando uma notação explícita

Usando uma notação implícita

Percorrendo uma coleção

367

Mensagens síncronas e assíncronas

368

Identificando Diagramas de Sequência

• Utilizar:

– Diagrama de casos de uso e, principalmente, sua

descrição (cenários);

– Diagrama de classes caso já tenha sido

projetado.

369

Modelo de interação

Fornece cenários

Modelo de

Casos de Uso

Modelo de Interações

(diagramas de colaboração ou de sequência)

Fornece objetos

Valida responsabilidades

e fornece detalhes sobre objetos

Valida as interações

Modelo de Classes

370

Diagrama de Comunicação

: lender : librarian

: index : assitant

1: BookRequest

2: look up

3: 4: get

5:

6:

371

• Um objeto é representado como uma caixa.

• Linhas representam os linksentre os objetos.

• Setas indicam as mensagens enviadas.

• A seqüência de mensagens é indicada através de numeração das mensagens.

• Da ênfase à maneira como os objetos estão estaticamente conectados!!!


372

Diagrama de Seqüência


Correspondente

Utilizar Diagrama de Sequência ou Comunicação?

• Diagramas de Sequência– Foco na ordem em que os objetos interagem.

– São mais facilmente extraídos a partir da descrição dos casos de uso

– Desta forma, utilizar diagramas de sequência é uma escolha natural quando você está construindo diagramas de interação a partir de casos de uso

– É útil para verificação da descrição dos casos de uso.

– É útil para verificação dos diagramas de classe

373

Utilizar Diagrama de Sequência ou Comunicação?

• Diagramas de Comunicação

– Pode ser visto como uma projeção do diagrama de classes

– Desta forma, pode ser escolhido caso os diagramas de

interação sejam construídos a partir do diagrama de

classes

– É útil para validação dos diagramas de classe

374


375

Exemplo de Realização de Casos de Uso

376

Nome do Caso de Uso: _Efetuar Aluguel ____________________________________

Ator: _Funcionário ______________________________________________________

Começo: _Funcionário inicia o processo de locação ____________________________

Funcionário Sistema

Iniciar aluguel

Verificar disponibilidade do carro

Confirmar Aluguel

Alterar disponibilidade do carro

378

Descrição do Caso de Uso


379

Nome do Caso de Uso: _Cadastrar Cliente ___________________________

Ator: _Funcionário_______________________________________________________

Começo: _Funcionário insere os dados do cliente ______________________________


Digita os dados do cliente

Cadastra cliente


380


381

Nome do Caso de Uso: _Cadastrar Carro ___________________________________


Começo: _Funcionário insere dados do carro _________________________________


Digita dados do carro

Cadastra carro

382



383

Nome do Caso de Uso: _Encerrar Aluguel Cliente Comum ______________________


Começo: _Funcionário solicita emissão de Nota Fiscal __________________________


Solicita Nota Fiscal

Pega o valor do aluguel do carro

Pega a data do aluguel

Calcula Preço

Altera Disponibilidade do Carro

384



385


Solicita Nota Fiscal

Pega valor de desconto do cliente

Pega valor de quilometragem extra

Pega o valor do aluguel do carro

Pega a data do aluguel

Calcula Preço

Altera Disponibilidade do Carro

Nome do Caso de Uso: _Encerrar Aluguel Cliente Especial______________________


Começo: _Funcionário solicita emissão de Nota Fiscal __________________________

386



387


388

Diagramas de Estados e AtividadesCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Diagrama de Estado

Mostra os estados possíveis de um objeto, os eventos que

podem induzir a transição de um estado para outro e as ações

resultantes das trocas de estados.

Representam a visão dinâmica do modelo de uma simples

classe ou do sistema como um todo.

Normalmente, são somente elaborados para as classes

cujas instâncias são muito dinâmicas.

Estado do Objeto = Valor dos Atributos e Relacionamentos

Eventos = Mensagens

390

Estado

Situação na vida de um objeto. É função dos valores dos atributos e (ou) das ligações com outros objetos.◦ O atributo reservado deste objeto livro tem valor verdadeiro.

◦ Uma conta bancária passa para o vermelho quando o seu saldo fica negativo.

◦ Um professor está licenciado quando não está ministrando curso algum durante o semestre.

◦ Um tanque está na reserva quando nível de óleo está abaixo de 20%.

◦ Um pedido está atendido quando todos os seus itens estão atendidos.

Estados podem ser vistos como uma abstração dos atributos e associações de um objeto.

391

Estados inicial e final

392

• Notação da UML para estados:

Transições

Os estados estão associados a outros pelas

transições.

Uma transição é mostrada como uma linha

conectando estados, com uma seta apontando para

um dos estados.

Transições possuem a seguinte notação:

393

evento (lista-parâmetros) [guarda] / ação

Diagrama de Estado - Transições

394

• Uma transição pode estar associada a:

– Uma ação, que indica um método do objeto que será

executado quando a transição de estado se realizar;

– Uma condição, também conhecida como guarda, que indica

quando a transição de estado deve ocorrer;

– Ambos são apresentados junto ao nome do evento na

transição, como na figura abaixo.

– Ambos são opcionais.

Eventos

• Uma transição possui um evento associado.

• Os eventos relevantes a um sistema de software

podem ser classificados nos seguintes tipos.

1.Evento de chamada: recebimento de uma mensagem de

outro objeto.

2.Evento de sinal: recebimento de um sinal.

3.Evento temporal: passagem de um intervalo de tempo

predefinido.

4.Evento de mudança: uma condição que se torna verdadeira.

395

Tipos de Evento

• Evento de chamada

– Corresponde ao recebimento de uma mensagem de outro

objeto.

• Evento de sinal

– Corresponde ao recebimento de uma mensagem assíncrona

de outro objeto.

• No evento de sinal, o objeto remetente continua o seu

processamento após ter enviado o sinal.

396

Tipos de Evento

Evento de temporal◦ Corresponde à passagem de um intervalo de tempo predefinido.

◦ É especificado com a cláusula after seguida de um parâmetro que especifica um intervalo de tempo.

after(30 segundos): indica que a transição será disparada 30 segundos após o objeto ter entrado no estado atual.

Evento de mudança◦ Corresponde a uma condição que se torna verdadeira.

◦ É representado por uma expressão de valor lógico (verdadeiro ou falso) e é especificado utilizando-se a cláusula when.

when(saldo > 0): significa que a transição é disparada quando o valor do atributo saldo for positivo.

◦ Eventos temporais também podem ser definidos utilizando-se a cláusula when.

when(data = 13/07/2002)

when(horário = 00:00h)

397

Exemplo (Conta Bancária)

398

• No compartimento adicional de um retângulo de

estado podem-se especificar ações ou atividades a

serem executadas.

• Sintaxe geral: evento / [ação | atividade]

• Há três cláusulas predefinidas: entry,exit,do

• Cláusula entry

– Pode ser usada para especificar uma ação a ser realizada no

momento em que o objeto entra em um estado.

399

Clausulas

• Cláusula exit

– Serve para declarar ações que são executadas sempre que o

objeto sai de um estado.

• Cláusula do

– Usada para definir alguma atividade a ser executada quando o

objeto passa para um determinado estado.

400

Clausulas

Exemplo (Terminal ATM)

Inicializando

Parâmetros

Mantenedor inicializa Terminal ATM

Ocioso

Com

Dinherio

Sem Dinheiro

entry/ Mensagem de Erro

Estados do Objeto

Sistema ATM

Com

Dinherio

Sem Dinheiro

entry/ Mensagem de Erro

[ com dinheiro ][ sem dinheiro ]

Ativo

entry/ Ler Cartão

Autorizando

Efetuando

Transação

Autorizando

Efetuando

Transação

[ cliente não autorizado ][ autorização ok ] / iniciar transação

Cliente Insere Cartão( codBanco, numCartão, dataExpira )

401

Diagrama de Atividades

• Podem ser usados para a modelagem do fluxo dos

procedimentos da atividade.

• Muitas vezes utilizados para modelar graficamente

a descrição de Casos de Uso.

402

Diagrama de atividade: Notação

EstadoAção1 EstadoAção2

EstadoAção4EstadoAção3

[x < 0][x = 0]

EstadoAção5

[x > 0]

EstadoAção6 EstadoAção7

Estadoinicial

Ponto deramificação

Estadoação

Bifurcação

JunçãoEstado final

Ponto deunião

403

Diagrama de Atividades

• Concorrência

– Bifurcações, junções;

• Swimlanes (Raias)

– Os diagramas de atividades geralmente

representam as atividades de um conjunto de

classes. A divisão das atividades por classe pode

ser explicitamente mostrada através de

swimlanes (Raias).

404

Exemplos

Seguradora OficinaSegurado

Acionar Seguro Recolher Automóvel

Consertar Automóvel

[else]

[perda total]Depositar Valor Segurado

Pagar Franquia Cobrar Fraquia

Avaliar Danos

406

Exemplos

407

Uso do diagrama de atividades

• Quando usar:

– Analisar um caso de uso;

– Entender um workflow;

– Processamento paralelo.

408

• Quando não usar:

– Colaboração entre objetos;

– Comportamento de objetos durante seu ciclo de

vida;

– Representar uma lógica condicional complexa.

409

Uso do diagrama de atividades


410

Exercício de Diagrama de Estados

• Um relógio digital simples tem um mostrador e dois botões

para o operar, o botão A e o botão B. O relógio possui dois

modos de operação, visualizar as horas e minutos ou

inicializar as horas e minutos. No modo de visualização, as

horas e minutos são visualizadas separadas por dois pontos

intermitentes. O modo de inicialização possui dois submodos,

inicializar as horas e inicializar os minutos. O botão A é

utilizado para seleccionar os modos. Cada vez que é

pressionado, o modo muda na sequência: visualização,

inicialização das horas, e inicialização dos minutos. Nos

submodos, o botão B é utilizado para avançar as horas e

minutos de cada vez que é premido. Os botões devem ser

largados antes de poder gerar outro evento. Prepare um

diagrama de estados para o relógio.

411

Exercício de Diagrama de Estados

• Um sistema desenvolvido por uma imobiliária gerencia apartamentos disponíveis para aluguel e venda. Todo apartamento que a imobiliária recebe passa por um processo de validação da documentação e verificação de seu estado. Se o apartamento estiver em mau estado de conservação, o apartamento entra em manutenção.

• Uma vez a documentação validada e feita a conferência do bom estado do apartamento, o apartamento passa a ficar disponível. Quando o apartamento é vendido o sistema guarda a informação de que o apartamento está vendido e este não volta a ficar disponível no sistema. Quando o apartamento é alugado, o sistema guarda a informação da situação do apartamento. Quando o inquilino sai do apartamento, é necessário fazer a verificação do estado do apartamento antes de deixar o apartamento disponível novamente.

• Faça um diagrama de estados para representar os estados e as transições entre os estados do apartamento do sistema acima.

412

Exercício Diagrama de Atividades

• Leia, interprete a descrição do caso de uso abaixo e complemente a sua

especificação através de um Diagrama de Atividades.

– Nome: Manter Aluno

– Descrição: Este caso de uso permite a inclusão, exclusão, alteração e consulta de alunos, pela

atendente

– Ator: Atendente

– Fluxo Principal:

• 1. A Atendente informa o código do aluno [A1]

• 2. A Atendente solicita a busca

• 3. O sistema pesquisa os dados do aluno

• 4. O sistema exibe os dados do aluno [A2]

• 5. A Atendente edita os dados do aluno [A3]

• 6. A Atendente solicita a gravação dos dados

• 7. O sistema valida os dados informados

• 8. O sistema grava os dados do aluno [A4]

• 9. Fim do caso de uso

– Fluxos Alternativos:

• A1. Novo Aluno

• 1. A Atendente solicita a inclusão de um novo aluno

• 2. O sistema solicita os dados do novo aluno

• 3. A Atendente informa os dados do aluno

• 4. Vai para o passo 6 do fluxo principal

• A2. Aluno não encontrado

• 1. O sistema informa a situação à atendente

• 2. Vai para o passo 1 do Fluxo Principal 413

Exercício Diagrama de Atividades

• Leia, interprete a descrição do caso de uso abaixo e complemente a sua

especificação através de um Diagrama de Atividades (cont.).

– Fluxos Alternativos (cont.):

• A3. Exclusão de Aluno

• 1. Atendente solicita exclusão do aluno

• 2. O sistema solicita confirmação da exclusão

• 3. [se confirmação positiva] Sistema exclui aluno


• A4. Dados inválidos

• 1. Se algum dado do aluno estiver em desacordo com as regras de validações e restrições, o

sistema informa situação à Atendente


– Restrições e Validações:

• 1. Nenhum campo poderá ser deixado em branco

• 2. O campo CPF deverá ser preenchido somente com números

• 3. O ano de nascimento deverá ser informado com 4 dígitos

414

Leituras Sugeridas


Editora Bookman, 2007, Capítulos 10, 15, 28 e 29.


BEZZERRA, E., "Princípios de Análise e Projetos de Sistemas com Uml",

2007.

BOOCH, G., RUMBAUGH, J., JACOBSON, I., "UML 2.0-Guia do Usuário",

Editora Campus, 2005.

FOWLER, M., "UML Essencial", 3ed, Editora Bookman, 2005.

WASZLAWICK, R.S., "Análise e Projeto de Sistemas de Informação

Orientados a Objetos", Editora Campus, 2004.

415

Outros Diagramas da UMLCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Existem outros diagramas na UML?

417

Object Diagram

418

Composite Structure Diagram

419

Component Diagram

420

Deployment Diagram

421

Timing Diagram

422

Interaction Overview Diagram

423

Bibliografia

• OMG, Unified Modeling Language (UML) Specification, Version

2.5, http://www.omg.org/spec/UML/2.5/

• http://www.uml-diagrams.org

424

Visões Arquiteturais: Especificações Arquiteturais e Técnicas



[email protected]


Definição da arquitetura

• Recomendações do IEEE 1471-2000– Necessidade de documentar as diferentes perspectivas (visões):

para cada visão deve-se definir os modelos, elementos, notação e diretrizes para auxiliar a construção dos modelos da visão.

• Princípios de Clements (2002)– Sugere a criação de 4 visões arquiteturais

426

Visões arquiteturais

Visões definidas em Clements (2002):

• Visão Modular

• Visão Dinâmica

• Visão de Alocação

• Visão de Contexto Geral

427

Visão Modular

• Representa os elementos responsáveis por realizar um conjunto de atividades, e as dependências entre eles

• Elementos que compõem a visão– módulos, componentes, interfaces de comunicação e as

dependências

• Notação da UML:– Diagramas: Classes, Pacotes e Componentes

– Elementos: Pacotes, Classes, Componentes, Interfaces, Portas, Conectores, etc.

– Relacionamentos: Generalização, Associação, Agregação, Dependência e Implementação.

428

Visão Dinâmica

• Descreve o comportamento dos elementos arquiteturais durantes os fluxos de execução

• Elementos que compõem esta visão– Componentes que tem representatividade relevante em

tempo de execução

• Notação da UML:– Diagramas: Sequência, Comunicação, Atividades e Estados– Elementos: classes e objetos– Relacionamentos: mensagens

429

Visão de Alocação

• Esta perspectiva busca representar o mapeamento das unidades de software para elementos físicos do ambiente (hardware, arquivos do sistema, equipe de desenvolvimento).

• Notação da UML:– Diagramas: Implantação (com Componentes)– Elementos: nós e conexões (e Componentes)– Relacionamentos: conexões

430

Visão de Contexto Geral

• Essa perspectiva tem como objetivo representar uma visão geral dos principais componentes que formam a arquitetura do software e de como ele se relaciona com os elementos externos ao seu contexto (atores e sistemas externos)

• Notação da UML:– Não possui, seria uma mistura de um diagrama de

implantação com um diagrama de casos de uso.

431

Visão de Contexto Geral

• Exemplo

432

Representando as Visões Arquiteturais

• Sugestão, capturar as visões relevantes

através da definição de templates para:

– Especificação Arquitetural

– Especificação Técnica

433

Especificação Arquitetural

434

Especificação Técnica

435

Leituras Sugeridas

• CLEMENTS, P. et al., “Documenting Software Architectures: Views

and Beyond”, 2nd Edition, 2010.


GORTON, I., “Essential Software Architecture”, Springer, 2006.

436

Princípios de Projeto de SoftwareCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Unified Modeling Language (UML)

InterfaceX

Abstract

ClassX

...

«interface»

InterfaceX

operation1()

ClassA ClassBAssociation-name

role-1 role-2

1 1

zero or

more;

"many"

one or

more

one to

forty

exactly

fiveClass ClassClass Class* 1..*1..40 5

Whole

Part

1

*

AssociationClass

Composition

Multiplicity:

Associations:

ClassX

classAttribute

+ publicAttribute

- privateAttribute

attributeWithVisibilityUnspecified

attribute1 : type

burgers : List of VeggieBurger

attribute2 : type = initial value

finalConstantAttribute : int = 5 { frozen }

/derivedAttribute

classMethod()

+ «constructor» ClassX(int)

«signal» CaughtException1()

methodWithVisibilityUnspecified()

methodReturnsSomething() : Foo

abstractMethod()

abstractMethod2() { abstract } // alternate

+ publicMethod()

- privateMethod()

# protectedMethod()

~ packageVisibleMethod()

finalMethod() { leaf }

methodWithoutSideEffects() { query }

synchronizedMethod() { guarded }

exceptions

ThrownException1

AlternateUMLFor

AbstractClass

{abstract}

...

ClassY

operation1()

...

generalizationinterface

implementation

AlternateUMLFor

ImplOfInterfaceX

operation1()

FinalClass

{leaf}

...

438

Apenas uma notação para diagramação orientada a

objetos.

Trivial e relativamente pouco importante sem estar

aliada a princípios que promovam seu bom uso.

Não é um método, processo ou guia de projeto.

UML: O que é importante?

439

Saber como ler e

desenhar diagramas

UML é essencial, mas

apenas um primeiro

passo para elaborar

bons projetos

orientados a objeto.

Importante mesmo são habilidades de

projeto de objetos, não saber

desenhar os diagramas UML ou

conhecer ferramentas CASE.

PGR: Projeto Guiado por Responsabilidades

Uma habilidade crítica é projetar e pensar em objetos. Isto

pode ser praticado com base em princípios explicáveis.

Projeto de objetos normalmente é feito do ponto de vista da

metáfora de:

◦ Objetos possuem responsabilidades;

◦ Objetos colaboram.

Em PGR fazemos o projeto de objetos de modo que

perguntamos questões como:

◦ Quais são as responsabilidades deste objeto?

◦ Com quem este objeto colabora?

440

Padrões

441

Padrões são pares nomeados de problema-solução, para

problemas comuns, tipicamente mostrando uma solução

popular e robusta.

◦ “Facade” (Fachada) “Information Expert” (Especialista na

Informação) …

Proveem um vocabulário de projeto.

http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0130925691/reader/2/002-3439525-6842407#reader-link




Padrões

Padrões são um modo de denominar e explicar

ideias de projeto OO.

◦ GRASP para princípios de Projeto OO;

◦ GoF para ideias mais avançadas de projeto.

‘Novo Padrão’ é uma contradição.

◦ O termo padrão sugere algo longamente repetido;

◦ O propósito de padrões de projeto não é expressar ideias

novas de projeto;

◦ Grandes padrões tentam codificar conhecimentos e

princípios existentes, testados e verdadeiros.

442

Padrões GRASP

Que princípios nos guiam e ajudam a atribuir

responsabilidades?

Estes princípios são capturados nos padrões

GRASP.

◦ General Responsibility Assignment Software Patterns.

◦ Princípios fundamentais e básicos de projeto de objetos.

443

Os 9 Padrões GRASP

1. Especialista na Informação (Information Expert)

2. Criador (Creator)

3. Controlador (Controller)

4. Baixo Acoplamento (Low Coupling)

5. Alta Coesão (High Cohesion)

6. Polimorfismo (Polymorphism)

7. Invenção Pura (Pure Fabrication)

8. Indireção (Indirection)

9. Variações Protegidas (Protected Variations)

444

Padrão: Especialista na Informação

• Problema: Qual o princípio geral mais básico a

respeito de atribuição de responsabilidades?

• Solução (Sugestão): Atribua a responsabilidade à

classe que tenha informação necessária para

satisfazê-la.

– “Quem tem a informação realiza o trabalho.”

445

Exemplo:

• Que objeto de software calcula a taxa de venda?

1. Que informação é necessária para fazer isto?

2. Que objeto tem a maior parte desta informação?

446

Outro Exemplo do Padrão Especialista da Informação: Banco Imobiliário

447

Outro Exemplo do Padrão Especialista da Informação: Banco Imobiliário

448

Que classe deverá conter o método

getSquare(name)?

Padrão: Criador

Problema: Que objeto cria um objeto X?

◦ Ignore padrões de casos especiais como Factory.

Solução (Sugestão): Escolha um objeto C, tal que:

◦ C contém ou agrega X de forma composta;

◦ C registra X;

◦ C utiliza X de maneira muito próxima;

◦ C tem os dados para inicializar X.

449

Exemplo do Padrão Criador: Banco Imobiliário

450

Exemplo do Padrão Criador: Banco Imobiliário

451

Que classe deverá criar a classe

Square?

Padrão: Baixo Acoplamento

• Problema: Como reduzir o impacto de modificação?

• Solução (Sugestão): Atribuir responsabilidades de

modo que acoplamento permaneça baixo. Use esse

princípio para avaliar alternativas.

452


• Utilizado tanto para escolher entre novas

alternativas como para avaliar projetos existentes.

• Todo o resto permanecendo igual, deveríamos

preferir um projeto cujo acoplamento é mais baixo

do que as alternativas.

453


454


455

A classe cão (outra classe arbitrária) teria que colaborar com a classe tabuleiro para obter a coleção de todas as casas de um tabuleiro.

Acoplamento baixo tende a reduzir o esforço e defeitos na modificação de software.

Especialista apóia o acoplamento baixo.◦ Porque?

Padrão: Controlador

Problema: Qual é o primeiro objeto, além da IU,

que recebe e coordena uma operação do sistema?

Solução (Sugestão): Atribuir a responsabilidade a

um objeto que representa uma das escolhas:

◦ Representa todo o sistema, um objeto raiz, um dispositivo

dentro do qual o software está sendo executado, ou um

subsistema importante (todas essas são variações de um

controlador fachada);

◦ Representa um caso de uso dentro do qual a operação do

sistema ocorre (um objeto para controlar o caso de uso).

456

Padrão: Controlador

457

• Porque não utilizar a própria IU?

– Princípio de separação entre modelo-visão.

– Porque esse princípio é bom?

Controlador: Exemplo

458


459

A janela (JFrame) precisa delegar a mensagem

recebida do ator para um objeto da camada de

domínio.

Para qual?


460


461


462

A solução dada é razoável se existem apenas

poucas operações no sistema...

Caso contrário é melhor utilizar classes que

representem ou controlem o caso de uso.

Normalmente tais classes recebem nomes com

prefixos como “Tratador”, “Controlador”, “Caso”...

TratadorJogarBancoImobiliário

Padrão: Alta Coesão

Problema: Como manter os objetos focados,

inteligíveis e gerenciáveis e, como efeito colateral,

apoiar Baixo Acoplamento?

Solução (Sugestão): Atribuir responsabilidades de

modo que a coesão permaneça alta. Use isto para

avaliar alternativas.

463


Coesão mede informalmente quão relacionadas

funcionalmente as operações de uma classe.

Uma classe com 100 métodos e 2000 linhas está

fazendo muito mais do que uma classe com 10

métodos e 200 linhas;

◦ Se a classe “grande” está cobrindo diferentes áreas de

responsabilidade (acesso a bancos de dados, cálculo de

taxas, etc) então esta possui pouca coesão funcional.

464


465


• Baixa coesão e acoplamento alto estão fortemente

relacionados.

– Porque?

466

Os 9 Padrões GRASP

1. Especialista na Informação (Information Expert)








9. Variações Protegidas (Protected Variations)

467


468

Padrões GRASP: Exercícios

• Criador.

• No diagrama a seguir, quem deve ser responsável pela criação

de uma instância de SalesLineItem?

469


Sale

time

Sales

LineItem

quantity

Product

Description

description

price

itemID

Described-by*

Contains

1..*

1

1

470


• Especialista da Informação.

• Quem deve ser responsável por conhecer o total geral de uma

venda?

471


472

Sale

time

Sales

LineItem

quantity

Product

Description

description

price

itemID

Described-by*

Contains

1..*

1

1


Classe de Projeto Responsabilidade

Sale Sabe o total da venda

SalesLineItem Sabe o subtotal da linha de item

ProductDescription Sabe o preço do produto

473


• Especialista da Informação.

• Discussão;

– Especialista expressa a intuição comum de que objetos fazem

coisas relacionadas à informação que têm.

474


• Controlador.

– No exemplo do slide a seguir, de uma registradora de

vendas quem deveria controlar a execução da operação

enterItem?

475


Which class of object should be responsible for receiving this

system event message?

It is sometimes called the controller or coordinator. It does not

normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from

the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain

Layer

system operation message

476


Register

id

ItemStore

name

address

Sale

dateTime

/ total

CashPayment

amountTendered

Sales

LineItem

quantity

Cashier

id

Customer

Product

Catalog

Product

Description

itemID

description

price

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-

completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-

accounts-

for

1

1

477


Representa o “sistema” global,

“objeto raiz”, dispositivo ou

subsistema

Registradora

Representa um receptor ou

tratador de todos os eventos do

sistema em um cenário de caso

de uso

TratadorDeProcessarVenda

SessãoDeProcessarVenda

478

• Pelo controlador:


• Coesão Alta.

• Discussão;

– Coesão alta é um princípio de avaliação que o projetista aplica

quando avalia decisões de projeto.

– Coesão Alta e Baixo Acoplamento, o yin e yang da engenharia de

software?

479

Os 9 Padrões GRASP

1. Especialista na Informação (InformationExpert)








9. Variações Protegidas (ProtectedVariations)

480

Polimorfismo

• Problema: Como tratar alternativas com base no

tipo? Como criar componentes de software

interconectáveis?

• Solução: Quando alternativas ou comportamentos

relacionados variam segundo o tipo (classe):

– Atribua a responsabilidade pelo comportamento aos tipos

para os quais o comportamento varia, usando operações

polimórficas.

481

Polimorfismo

482

• Corolário: Não teste o tipo

de um objeto e use lógica

condicional (if, case, etc)

para executar alternativas

que variam com base no

tipo.

Polimorfismo

• Exemplos

– Banco Imobiliário:

• Como projetar diferentes ações de casa?

• Há ações diferentes ao atingir diferentes casas do

tabuleiro.

–Como tratar isto?

483

• O que não fazer:

• A classe Casa poderia ter um atributo tipo e o seguinte método:

public atingida(){if (tipo == 1){ // Casa de partida} if (tipo == 2){ // Casa de imposto de renda}...

}

Polimorfismo

484

Polimorfismo

485

• O que fazer:

Como isso vai funcionar na prática?

Polimorfismo

486

Polimorfismo

487

Polimorfismo

488

Polimorfismo

489

Polimorfismo

490

Polimorfismo (com Interfaces)

• Como criar componentes de software

interconectáveis?

• Exemplo:

– Apoiando calculadores de impostos terceirizados, que

devem ser fornecidos de acordo com uma interface pré-

estabelecida.

491

Polimorfismo

TaxMasterAdapter

getTaxes( Sale ) : List<TaxLineItems>

GoodAsGoldTaxPro

Adapter


«interface»

ITaxCalculatorAdapter


By Polymorphism, multiple tax calculator adapters have

their own similar, but varying behavior for adapting to

different external tax calculators.

<???>Adapter

...

...

492

Polimorfismo

• Vantagens: – Extensões necessárias para novas variações são fáceis de

adicionar.

– Novas implementações podem ser introduzidas sem afetar os clientes.

• Vários padrões GoF (Gamma et al., 1995) se apoiam no polimorfismo.

493

Invenção Pura

• Problema:

– Que objeto deve ter a responsabilidade quando não se

quer violar a Coesão Alta e o Acoplamento Baixo ou outros

objetivos, mas as soluções oferecidas pelo Especialista (por

exemplo) não são apropriadas?

494

Invenção Pura

495

Há situações em que atribuir

responsabilidades apenas a

classes de software da

camada de domínio leva a

problemas em termos de

coesão ou acoplamento

inadequados ou baixo

potencial de reuso.

Invenção Pura

Solução:

Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial ou de conveniência que não represente um conceito no domínio do problema – algo inventado para apoiar coesão alta, acoplamento baixo e reuso.

Idealmente as responsabilidades atribuídas a esta invenção apóiam coesão alta e acoplamento baixo, de modo que o projeto da invenção seja muito “limpo” ou “puro”.

496

Invenção Pura

497

Exemplo:◦ Jogador lançava os dados e fazia a soma dos valores.

Serviço de somar não é generalizável para outros jogadores;

Não era guardado o total do último lançamento da partida.

◦ Por “invenção pura”

Invenção Pura

498

Exemplo: Classe para tratar a Persistência de objetos em um

banco de dados. Com métodos como: inserir (Objeto)

atualizar (Objeto)

...

Essa classe não faz parte do domínio do problema, mas é relativamente coesa, genérica e reutilizável.

Todos os Padrões GoF são invenções puras.

Invenção Pura

499

Indireção

• Problema:

– A quem devemos atribuir a responsabilidade de maneira a evitar

o acoplamento direto entre objetos (ou componentes)?

• Solução:

– Atribuir a responsabilidade de ser o mediador entre outros

componentes e serviços a um objeto intermediário, para que eles

não sejam diretamente acoplados.

• O intermediário cria indireção entre os outros componentes.

500

Indireção

: Sale :TaxMasterAdapter

taxes = getTaxes( s )

t = getTotal

the adapter acts as a level of

indirection to external systems

TCP socket

communication

xxx...

«actor»

:TaxMasterSystem. . .

501

• Exemplo: Uso de um adaptador.

Indireção

• Exemplo 2:

– Classe para tratar a Persistência de objetos em um banco de dados. Com métodos como:• inserir (Objeto)

• atualizar (Objeto)

• ...

– Esta classe é também um exemplo de Indireção, afinal a classe age como intermediário entre as demais classes e o banco de dados.

502

Variações Protegidas

• Problema:

– Como projetar objetos, subsistemas e sistemas de modo que as

variações ou instabilidades nesses elementos não tenham um

impacto indesejável sobre outros elementos?

• Solução:

– Identificar pontos de variação ou instabilidade previsível; atribuir

responsabilidades para criar uma “interface” estável em torno

deles.

503


504

• Este é um princípio fundamental

muito importante de projeto de

software. Quase todo truque de

projeto de software ou arquitetural

trata de tipos de variação

protegida;

• É importante saber que batalhas

de Variações Protegidas vale a

pena travar.


• Variações Protegidas são um princípio básico na

motivação de vários mecanismos e padrões de

programação e de projeto para fornecer

flexibilidade.

505


• Mecanismos motivados por VPs:– Principais mecanismos:

• Encapsulamento dos dados;

• Interfaces;

• Polimorfismo;

• Indireção;

• Normas.

– Projeto dirigidos por dados (data-driven designs)• Configuração do sistema através de dados (arquivos de propriedades, meta-dados para mapeamento objeto relacional, etc).

506


• Mecanismos motivados por VPs (cont.):– Pesquisa de Serviço

• Uso de serviços de atribuição de nomes, como JNDI do Java;

• Negociantes para obter um serviço, como UDDI dos Web Services;

– Projetos dirigidos pelo Interpretador• Uso de interpretadores de linguagens;

• Permite parametrizar o comportamento do sistema por meio de expressões lógicas externas.

– Projetos reflexivos ou de nível meta• Introspecção permitindo descobrir e invocar métodos e atributos de objetos.

507


• Mecanismos motivados por VPs (cont.):

– Linguagens normalizadas

• Normas oficiais, como o SQL, protegem contra uma

proliferação de linguagens variantes.

– Princípio de substituição de Liskow (PSL)

• Uso de interfaces definindo funcionalidades esperadas.

Qualquer classe que tenha os métodos da interface pode

ser utilizada.

– Projeto com ocultação da estrutura

• Aplicação da Lei de Demeter.

508

umObjeto.obterOutroObjeto().executar();

Lei de Demeter, Não fale com estranhos!!

umObjeto.executarNoOutroObjeto();

509

Lei de Demeter


• Vantagens:

– Extensões exigidas para novas variações são mais fáceis de

adicionar;

– Novas implementações podem ser introduzidas sem afetar

os clientes;

– O acoplamento fica mais baixo;

– O impacto ou custo das modificações pode ser diminuído.

• Também conhecido como princípio da ocultação da

informação (information hiding) e do aberto-

fechado (open-closed principle).

510


511

Exercício 1 (Padrões GRASP)

512

Que padrão GRASP está sendo violado na seguinte definição de classes? Como você resolveria este problema?


513

Alta coesão ajuda a obter baixo acoplamento? Justifique.

Baixo acoplamento ajuda a obter alta coesão? Justifique.


cd Logical Model

Animal

- tipo: String

+ fazerBarulho() : void

- miar() : void

- latir() : void

- uivar() : void

- rugir() : void

514

Dada a seguinte classe e o trecho de implementação de seu método público:

public class Animal{

String tipo;

...

public void fazerBarulho(){

if (tipo == “Leão”){

rugir();

}

if (tipo == “Gato”){

miar();

}

if (tipo == “Cachorro”){

latir();

}

...

}

...

}


515

Qual o problema desta solução?

Resolva o problema aplicando um padrão GRASP, deixe explícito qual foi o padrão utilizado.


cd Logical Model

A B C

PersistenciaSerializacao

+ salvar(Object) : void

+ recuperar() : Object

516

Aplique o padrão polimorfismo (utilizando uma interface) para permitir outras formas de persistência para as classes A, B e C.


cd Logical Model

A B C

MudaMuito

+ metodoNomade() : void

+ fazAlgoSempreDeModoDiferente() : void

517

Aplique Indireção no modelo abaixo para evitar a dependência da classe MudaMuito.


518

Sua solução fez uso de uma Invenção Pura?

Como os padrões Invenção Pura e Indireção estão relacionados?


519

Conceitue os 9 padrões GRASP.

Exercício 8 (Lei de Demeter)

cd Logical Model

A

+ trabalha() : void

B

C

+ fazAlgo() : void

520

Forneça uma solução para reduzir o acoplamento do seguinte diagrama de classes. Sabendo que a dependência entra A e C é causada pelo seguinte trecho de código no método trabalha() da classe A:

int resultado = b.getC().fazAlgo();

Como fica o modelo

resultante das

alterações?

(): int


O diagrama de classes a seguir possui acoplamento

acima do ideal, dificultando a manutenção. Você foi

contratado para resolver este problema.

Através de um diagnóstico preliminar você

identificou duas dependências causadas por uma

única linha de código do método

‘cadastraContaCorrente’ da classe ‘Funcionário’.

Remova estas dependências e reduza o

acoplamento aplicando a Lei de Demeter.

521


banco.getAgencia(idAg).getContaCorrente(idCc).cadastraConta();

522

Leituras Sugeridas


Editora Bookman, 2007, Capítulo 25.

523

Padrões de Projeto de SoftwareCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Padrões de Projeto

• Objetivo

– Soluções padronizadas que apresentaram sucesso na

solução de problemas recorrentes no projeto de sistemas

de software

– Transmitem o conhecimento sobre projeto de sistemas e

aprimoram a comunicação entre desenvolvedores

• Características

– Documentam a solução, mas também o problema

– Pode se aplicar a um grande número de problemas

– Se aplicam ao projeto, mas apresentam detalhes em

código

– Pode ser dependente de uma linguagem de programação

525

Padrões de Projeto

• Padrões de solução advém de padrões nos

problemas

– Um padrão representa um equilíbrio de forças

– As forças são as características que afetam um

problema

– O projeto do sistema realiza trade-offs entre

estas forças

– Os padrões de projeto tornam este trade-off

explícito

526

Estrutura dos Padrões GoF

• Problema:

– Determina quando o padrão deve ser utilizado

• Solução:

– Determina o que fazer para resolver o problema

• Contexto:

– Características da situação em que o padrão se aplica

• Forças:

– Vantagens e desvantagens da aplicação do padrão

• Conseqüências:

– Positivas e negativas de aplicação do padrão

527

Padrões de Projeto

528

• Encontrando o equilíbrio entre as forças

http://upload.wikimedia.org/wikipedia/en/0/08/Dooku_yoda.jpg

http://upload.wikimedia.org/wikipedia/en/0/08/Dooku_yoda.jpg

Padrões de Projeto

• Padrões GoF

– Organizações entre classes e a forma com que

estas classes interagem para resolver um

problema recorrente

529

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such

a way that you can use this solution a million times over, without ever doing it the same way twice."

Christopher Alexander

Padrões GoF (Gamma et al.)

• Creational patterns

– Abstract factory

– Builder

– Factory method

– Prototype

– Singleton

• Structural patterns

– Adapter

– Bridge

– Composite

– Decorator

– Facade

– Flyweight

– Proxy

530

• Behavioral Patterns

– Chain of Responsibility

– Command

– Interpreter

– Iterator

– Mediator

– Memento

– Observer

– State

– Strategy

– Template Method

– Visitor

Padrões GoF (Gamma et al.)

• Creational patterns

– Abstract factory

– Builder

– Factory method

– Prototype

– Singleton

• Structural patterns

– Adapter

– Bridge

– Composite

– Decorator

– Facade

– Flyweight

– Proxy

531

• Behavioral Patterns

– Chain of Responsibility

– Command

– Interpreter

– Iterator

– Mediator

– Memento

– Observer

– State

– Strategy

– Template Method

– Visitor

Creational Patterns

532

• Exemplo

– Abstract Factory

Abstract Factory

• Provê uma interface para a criação de famílias de

objetos relacionados ou dependentes sem

especificar suas classes concretas

533

Abstract Factory

• Problema:

– Em diversas situações, um grupo de objetos deve ser

usado em conjunto, como uma família

– Em algumas situações, a aplicação deve estar preparada

para trabalhar com diversas famílias similares (ou

substituir uma família por outra)

– Como instanciar os objetos de uma determinada família?

Como o restante da aplicação trabalha com múltiplas

famílias

• Solução:

– Oferecer uma interface para a criação de famílias de

objetos relacionados ou dependentes sem a especificação

de suas classes concretas

534

Abstract Factory - Estrutura

535

Cliente

Fábricas concretas: Instanciação dos

produtos específicos

Fábrica Abstrata

CriaProdutoA ()

CriaProdutoB ()

FábricaConcreta2

CriaProdutoA ()

CriaProdutoB ()

FábricaConcreta1

CriaProdutoA ()

CriaProdutoB ()

ProdutoAbstratoA

ProdutoConcretoA2

ProdutoConcretoA1

ProdutoAbstratoB

ProdutoConcretoB2

ProdutoConcretoB1

Fábrica abstrata: visibilidade para

o cliente

Abstract Factory

• Implementação

– Isolar as classes concretas

– Criar interfaces para generalizar as classes concretas

– Isolar a instanciação das classes concretas (fábrica)

– Criar uma interface para generalizar a instanciação

– Cliente conhece somente as interfaces

• Consequências

– Isola as classes concretas

– Facilita a troca de famílias de produtos

– Prove consistência entre produtos

– Facilita o suporte a novos tipos de produtos

536

Abstract Factory - Instanciação

537

Produtos concretos:

implementação

FábricaConcreta1

CriaProdutoA ()

CriaProdutoB ()

FábricaConcreta2

CriaProdutoA ()

CriaProdutoB ()

ProdutoAbstratoA

ProdutoConcretoA2

ProdutoConcretoA1

ProdutoAbstratoB

ProdutoConcretoB2

ProdutoConcretoB1

Produtos abstratos:

comunicação com o cliente

Abstract Factory – Exemplo 1

538

Abstract Factory – Exemplo 2

539

Structural Patterns

540

• Exemplo

– Adapter

Adapter

• O Adaptador converte a interface de uma classe em

uma outra interface esperada pelo cliente.

• O Adaptador permite que classes com interfaces

incompatíveis trabalhem em conjunto o que, de

outra forma, seria impossível

541

Adapter

• Problema

– Em diversas situações duas classes precisam ser

integradas, mas não possuem uma interface compatível

– Isto é bastante comum quando pelo menos uma das

classes é reutilizada

• Solução

– Criar uma classe que atua no “meio de campo”, traduzindo

os pedidos de uma classe para a interface da segunda

542

Adapter

• Implementação

– O padrão pode ser implementado por herança ou por delegação,

embora a última seja mais comum

– Por delegação, o adaptador possui uma instância da classe

original, chamando seus métodos quando ativado pela classe

cliente

– Por herança, o adaptador herda a funcionalidade da classe

original, chamando seus métodos quando ativado

• Consequências

– O adaptador pode não funcionar corretamente para subclasses da

classe adaptada (novas funcionalidades)

– Pode haver um custo de conversão, decorrente do processamento

realizado no adaptador

543

Adapter - Estrutura

544

Cliente

Adaptador

Operação ()

ClasseOriginal

OperaçãoEspecífica ()

Operação ()

CO OperaçãoEspecífica ( )

Cliente

Adaptador

Operação ()

ClasseOriginal

OperaçãoEspecífica ()

Operação ()

Implementação por

delegação

Implementação por

herança

O Adaptador

545

O Adaptador

546

O Adaptador

547

Behavioral Patterns

• Exemplo– Strategy

548

Strategy

• Usado quando muitas classes relacionadas diferem

apenas em alguns de seus comportamentos

• O padrão Strategy provê uma maneira de

configurar uma classe com um entre vários

comportamentos possíveis

549

Strategy

• Problema

– Alguns sistemas possibilitam a utilização de uma família de

algoritmos equivalentes

– O algoritmo em particular que irá operar sobre um

conjunto de dados depende de características destes dados

• Solução

– Os algoritmos devem ser encapsulados e facilmente

substituídos

– Os algoritmos podem ser substituídos dinamicamente em

tempo de execução

– Dados específicos de cada algoritmo podem ser mantidos

em suas respectivas implementações

550

Strategy

• Implementação

– Uma classe abstrata implementa a interface de acesso aos

algoritmos

– Classes concretas herdam da classe abstrata,

implementando cada algoritmo da família

• Consequências

– Maior número de objetos

– Clientes precisam estar cientes das diferentes estratégias

551

Strategy

552

Lista Atividades

adicionaAtividade (a)

procuraAtividade (nome)

Estratégia Abstrata

procura (lista, nome)

Estratégia Inicio Fim


Estratégia Fim Inicio


Classe abstrata: representa qualquer

solução para o problema

Classe cliente da estratégia: quer utilizar o serviço independente de sua

implementação

Classes concretas: soluções específicas

para o problema

Strategy

• O padrão Strategy define uma família de algoritmos

intercambiáveis e encapsula cada um deles fazendo

com que eles possam ser permutáveis.

• O padrão Strategy permite que os algoritmos

variem independentemente dos clientes que os

utilizam.

553

Strategy - Exemplo

554

Os 23 Padrões GoF

555

Leituras Sugeridas

• Gamma, E., Helm, R., Johnson, R., Vlissides, J., "Padrões de

Projeto", Editora Bookman, 2000.

• Larman, C., Utilizando UML e Padrões, 3ª edição, Editora

Bookman, 2007, Capítulos 26 e 36.

556

RefatoraçõesCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Refatorações

558

• O livro das Refatorações

– Fowler, M., Refatoração – Aperfeiçoando o

Projeto de Código Existente, Editora Bookman,

2004.

O que é Refatoração?

559

Refatoração é o processo de alteração de um

sistema de software de modo que o

comportamento externo do código não mude,

mas que sua estrutura interna seja melhorada.

É uma maneira disciplinada de aperfeiçoar o

código que minimiza a chance de introdução de

falhas.

Em essência, quando você usa refatoração,

você está melhorando o projeto do código após

este ter sido escrito.

Um catálogo de Refatorações

• Seguem alguns exemplos de Refatorações

560

Subir atributo na hierarquia

• Duas subclasses têm o mesmo atributo

– Mova o atributo para a superclasse

561

Subir método na hierarquia

562

Métodos nas subclasses produzindo resultados

idênticos

Mova-os para a superclasse.

Motivação: Evitar a duplicação de código

Exemplo

563

O método createBill é idêntico para ambas as classes

Exemplo

564

Problema: Não posso

mover o método

createBill na hierarquia

porque o método

chargeFor é diferente

em cada subclasse

Solução: declarar o

método chargeFor

como abstrato na

superclasse

Descer Método na Hierarquia

• Algum comportamento na superclasse é

relevante apenas para algumas de suas

subclasses.

• Mova-o para essas subclasses.

565

Motivação: Um código específico faz sentido apenas em

algumas das subclasses

Descer Método na Hierarquia

566

Extrair Subclasse

• Uma classe tem características que são

usadas apenas em algumas instâncias.

• Crie uma subclasse para esses subconjuntos

de características.

567

Motivação: O principal motivo para usar Extrair Subclasse é

a observação de que uma classe tem comportamento usado

por algumas das instâncias da classe mas não por outras.

Eliminação de IF-TIPADO.

Extrair Subclasse

568

Extrair Subclasse

569

Extrair Superclasse

• Você tem duas classes com características

semelhantes.

• Crie uma superclasse e mova as características em

comum para ela.

• Motivação: Evitar a duplicação de código

570

Extrair Superclasse

571

Extrair Superclasse

572

Condensar Hierarquia

• Uma superclasse e uma subclasse não são

muito diferentes. => Junte as.

573

Substituir Herança por Delegação

• Uma subclasse usa apenas parte da interface de

uma superclasse ou não quer herdar dados.

• Crie um campo para a superclasse, ajuste métodos

para delegarem para a superclasse e remova a

herança.

574


• Motivação

– A subclasse usa somente parte da interface da

superclasse

– Problema conceitual: a subclasse não é do tipo

da superclasse

575


576


577

Substituir Delegação por Herança

• Você está usando delegação e está frequentemente

escrevendo muitas delegações simples para toda a

interface.

• Torne a classe que delega uma subclasse da classe

delegada.

578


• Motivação

– Este é o reverso de Substituir Herança por Delegação. Se você se

encontrar usando todos os métodos da classe delegada e estiver

farto de escrever todos esses métodos de delegação simples,

pode voltar para a herança facilmente.

579


580


581

Leituras Sugeridas

• Fowler, M., "Refatoração - Aperfeiçoando o Projeto

de Código Existente", Editora Bookman, 2004.

582

Testes de Software (Verificação e Validação de Software)



[email protected]


Verificação e Validação

• V&V e Defeitos de Software

– Conceitos Iniciais

• Revisões de Software

• Teste de Software– Conceitos e Definições

– Técnicas de Teste de Software

584


V&V e Defeitos de Software

– Conceitos Iniciais

• Revisões de Software



585

Validação e Verificação

• Relembrando:

– Validação:

• Estamos construindo o produto certo?

– Verificação:

• Estamos construindo certo o produto?

586

Porque Utilizar Métodos de VV?

A utilização destes métodos na indústria têm

mostrado resultados positivos considerando tanto

produtividade quanto qualidade.

Resultados de estudos experimentais evidenciam

benefícios da utilização destes métodos no

desenvolvimento de software.

Diversas evidências relacionadas a VV&T foram

obtidas ao longo dos anos de pesquisa em

engenharia de software.

587

Defeitos de Software

Erro Defeito Falha

◦ Erro

Engano durante o desenvolvimento

◦ Defeito (Falta)

Algum problema em um artefato de software

◦ Falha

Problema encontrado ao executar o software

588


589


• Principal causa:

– Tradução incorreta de informações.

• Quanto antes a presença do defeito for

revelada, menor o custo de correção do

defeito e maior a probabilidade de corrigi-lo

corretamente.

– Solução:

• Introduzir atividades de V&V ao longo de todo o ciclo de

desenvolvimento.

590


Natureza do Defeito Definição

Omissão Informação necessária não incluída

Ambigüidade Informação passível de ter múltiplas interpretações.

Inconsistência Informações conflitantes

Fato Incorreto Informação que não é verdadeira para as condições especificadas.

Informação Estranha Informação desnecessária

591

• Taxonomia definida por Shull (1998) a partir do

padrão IEEE (IEEE 830, 1998) para a natureza

de defeitos em documentos de requisitos:

Natureza dos Defeitos

• Omissão

592


• Ambigüidade

593


• Inconsistência

594


• Fato Incorreto

595


• Informação Estranha

596


• Taxonomia aplicável também a outros artefatos.

597

(Travassos et al., 2001)

A taxonomia para natureza de defeitos instanciada para projeto OO de alto nível.

Natureza do Defeito

Descrição

Omissão Um ou mais diagramas de projeto que deveria conter algum conceito dos requisitos gerais ou do documento de requisitos não contêm uma representação para o conceito.

Fato Incorreto Um diagrama de projeto contêm uma representação errada de um conceito descrito nos requisitos gerais ou no documento de requisitos.

Inconsistência Uma representação de um conceito em um diagrama de projeto não concorda com uma representação do mesmo conceito no mesmo ou outro diagrama de projeto.

Ambigüidade Uma representação de um conceito no projeto não está clara, e poderia levar o usuário do documento (projetista de baixo nível, desenvolvedor, etc.) a interpretar de forma diferente ou não entender o significado do conceito.

Informação Estranha

O projeto inclui informação que, enquanto talvez verdadeira, não se aplica a este problema e não deveria estar incluída no projeto.


598

Informações sobre Defeitos

• Consenso a respeito das informações relevantes a serem coletadas

sobre de defeitos de software de modo a apoiar a análise causal de

defeitos:

– O momento (ou fase) em que o defeito foi introduzido.

– O momento (ou fase) em que o defeito foi detectado.

– Tipo de defeito.

• Outras informações que, dependendo dos objetivos, podem também

se mostrar úteis:

– Esforço de correção, severidade ou impacto;

– Localização (ou módulo);

– Trigger, que indica como o defeito foi detectado;

– Se o defeito foi introduzido durante o desenvolvimento de funcionalidades

novas ou durante a manutenção.

599

“Dimensões para classificar defeitos”

(Card, 1998)

600

Monitorando Introdução & Detecção

0

50

100

150

200

250

300

Requirements Design Implementation Integration AcceptanceTesting

Fielded

Estimado

Introdução

Detecção

Real

Introdução

Detecção


• Consequências:

– Estimativas de esforço e prazo deixam de fazer sentido.

– Desperdício de recursos.

– Produto final não atende as necessidades do usuário;

– Corrigir defeitos após a entrega do produto pode ser até

cem vezes mais caro que corrigi-los nas primeiras fases do

desenvolvimento (em projetos menores, 5:1).

– Em projetos recentes de software, teríamos um esforço de

retrabalho entre 40% e 50% do esforço total.

601

Leituras Sugeridas

• Myers, G., Badgett, T., Sandler, C., The Art of Software Testing, 3a Edição, John Wiley & Sons, 2012.

• Wagner, S., Software Product Quality Control, Springer, 2013.

• Boehm, B., Basili, V., “Software Defect Reduction Top 10 List”, IEEE Software, 2001.

602



Conceitos Iniciais




– Estratégias para Projeto, Execução e Controle dos Testes

– Automatizando os Testes

603

• Definição: Processo ou atividade para leitura de um artefato

de software visando assegurar que ele cumpre sua

especificação e atende às necessidades de seus usuários.

• Objetivo:

– Realizar validação e verificação estática de artefatos de software.

• Pode ser aplicada a qualquer artefato produzido ao longo do

processo de desenvolvimento de software.


604


• Quando e em que tipos de artefato aplicar revisões de software?

Adaptado de Ackerman et al. (1989)

605

Revisão


606

• Utilização na Prática

– De acordo com resultados de um survey:

• Muitas organizações realizam revisões de software.

• Realização pouco sistematizada e potencial raramente é explorado.

• Tipos de Revisão de Software:

– Revisão aos Pares

– Inspeções de Software.

– Walkthroughs.

Inspeções de Software

Tipo particular de revisão.

Tem sido o tipo de revisão de software mais estudado e utilizado(Christiensen et al., 2001)

Processo rigoroso e bem definido, introduzido em (Fagan, 1976).

Evidências Experimentais:◦ Redução do Esforço (Conradi et al., 1999).◦ Aumento da Produtividade (Gilb, Graham, 1993).◦ Redução do Tempo (Gilb, Graham, 1993).◦ Redução dos Custos (Laitenberger, Atkinson, 1999).◦ Capturam em média 60% dos defeitos (Boehm, Basili, 2001)

607

Inspeções de Software

Benefícios e Custo de Inspeções:

◦ Inspeções vêm sendo utilizadas há quase quatro décadas;

◦ Existe evidência experimental de sua usabilidade e

adequabilidade;

◦ Proveem um bom meio para o gerente do projeto monitorar a

qualidade e progresso do projeto;

◦ Apresentam baixo custo devido ao fato do revisor não precisar

investir muito tempo ou mesmo não demandar ferramentas

sofisticadas para realizá-las.

Uma alta taxa de atividades de inspeção ao longo do processo pode

representar de 5% a 10% do esforço de desenvolvimento.

608

Inspeções de Software: Benefícios

• Inspeções em requisitos e projeto, conduzidas no JPL –

Nasa Jet Propulsion Laboratory (Miller,1990);

609

520 520

22 513 535

409 409

4 4

542 513 413 1468

Fase Requisitos

Fase Projeto

Fase Teste Unid.

Fase Teste Sist.

Total

Defeitos Req.

Defeitos Proj. Outros Total

Inspeções de Software: Benefícios

Quantitativos:

◦ Primary Avionics Software System, JPL

Inspeções em requisitos, projeto, código, plano de testes, especificações

e procedimentos.

Taxa de Erros reduzidas de 2.25 para 0.08 defeitos/KSLOC

Qualitativos:

◦ Aprendizado por experiência:

Participantes aprendem padrões de defeitos;

Participantes aprendem bons padrões de desenvolvimento.

◦ No longo prazo ...

Inspeções convencem os participantes a desenvolver software mais fácil

de entender e manter.

610

Processo de Inspeção

611

• O Processo de inspeção de software (Fagan, 1976)


Planejamento◦ Responsável: Moderador.◦ Tarefas:

Definir contexto da inspeção (descrição da inspeção, como a preparação individual deverá ocorrer, documento a ser inspecionado, autor do documento, entre outros);

Selecionar inspetores (recomenda-se utilizar entre 3 e 5 inspetores em uma inspeção);

Distribuir material.

Preparação Individual◦ Responsável: Inspetor.◦ Tarefas:

Estudar os artefatos;

Fazer anotações sobre os artefatos.

612

Reunião de Inspeção◦ Envolvidos: Moderador, Inspetores e Autor.

◦ Tarefas:

Leitura do documento, com a equipe discutindo possíveis defeitos (Duração recomendada 2 hrs);

Produzir uma lista de defeitos;

Em casos de discordância a decisão sobre registrar um defeito ou não (falso positivo) é do moderador.

Retrabalho◦ Responsável: Autor.

◦ Tarefas:

Corrigir os defeitos encontrados.


613


Continuação

◦ Responsável: Moderador.

◦ Tarefas:

Analisar correções do autor e inspeção como um todo;

Re-avaliar qualidade do artefato inspecionado;

Decidir sobre a necessidade de uma nova inspeção.

614

Processo de Inspeção de Humphrey

• Variante do processo tradicional de inspeção:

– Foco da Preparação Individual muda de entender o artefato

para efetivamente encontrar seus defeitos;

– Inspetores entregam lista de discrepâncias para o moderador

antes de a reunião de inspeção se iniciar;

– Objetivo da reunião é discutir as discrepâncias para classificá-

las como defeito ou falso positivo.

615

Walkthroughs

• Alternativa com um processo menos rigoroso do que o de

inspeções de software.

• Papéis sugeridos:

– Líder, Autor, Escrivão e Revisores

• Procedimento:

– Os participantes são guiados através dos artefatos pelo líder (que

eventualmente é o próprio autor) em uma reunião. Durante esta reunião

devem interromper a apresentação caso encontrem defeitos.

– Muitas vezes condições de entrada e saída e decisões são pressupostos

pelo líder que segue sua linha de raciocínio durante a apresentação.

616

Walkthroughs

Possuem custo aproximadamente igual ao de inspeções

mas seus resultados são inferiores (SEI, 2005):

◦ Não providenciam resultados mensuráveis;

◦ Não fornecem base para a aplicação de controle estatístico de

processos, necessário para evoluir na maturidade de processos de

software.

Podem ser utilizados para atividades de brainstorming,

para explorar alternativas de projeto e resolução de

problemas.

◦ Inspeções são mais focadas em encontrar defeitos.

617

Dicas para Realizar uma Boa Inspeção

• Independente da abordagem utilizada, lembre-se:

– Revise o produto, nunca o desenvolvedor.

– Defina uma agenda e cumpra-a rigorosamente.

– Limite o debate e a discussão.

– Mostre onde estão os problemas, mas não tente resolvê-los

durante a inspeção.

– Não tente se lembrar, faça anotações sempre.

618

Dicas para Realizar uma Boa Inspeção

Limite o número de participantes e motive a preparação antecipada da inspeção.

Desenvolva uma lista de tópicos para cada produto que deverá ser revisado.

Aloque recursos e tempo para a inspeção.

Forneça treinamento adequado a todos os revisores.

Se for utilizado apoio ferramental, avalie se ele é adequado.

Aprimore-se: Revise suas revisões anteriores!

619

Exercício Prático

620

Exemplo: Requisitos Funcionais (Recorte)

• Escopo: Permitir que os coordenadores de projeto, ou outros

usuários designados por estes, possam realizar solicitações relativas

à solicitação de passagens aéreas e de diárias através de formulários

na web, viabilizando um controle mais efetivo sobre as solicitações.

• RF2: O software deve restringir a visibilidade do coordenador e de

seus substitutos aos projetos associados a ele.

• RF9: O software deve permitir que o coordenador solicite Passagem

Aérea.

• RF10: O software deve permitir que o coordenador solicite Diárias.

• RF18: O software deve manter um log de todas as solicitações

realizadas, com os respectivos solicitantes e data/hora da solicitação.

621

Objetivo: Permitir ao coordenador agendar uma passagem aérea

Requisitos: RF2, RF9, RF18

Atores: Coordenador, Substituto

Prioridade: Alta

Trigger: O ator aciona a opção de solicitação de passagem aérea

Fluxo Principal: 1. O Sistema apresenta um formulário com as seguintes informações [RN1, RN2]:

- Listas com os projetos e fundos do coordenador

- Nome do passageiro

- Trecho

- Data de embarque

- Data de retorno

- Lista de companhias aéreas

- Código da reserva

2. O ator preenche o formulário.

3. O Sistema critica os dados fornecidos [A1][RN3, RN4], gera um código para a solicitação e a armazena

como “pendente” ou “espera” [RN7]. Em seguida é apresentado o código da solicitação e uma opção para

impressão da mesma [E1].

Fluxo Alternativo: [A1] Dados fornecidos não estão corretos

1. O Sistema mostra uma lista com os erros encontrados seguida do próprio formulário com os dados

previamente fornecidos. Volta para o passo 2 do fluxo principal.

Extensões: [E1] Ator solicita impressão da solicitação

Ver caso de uso “Imprimir Solicitação”

Regras denegócio:

RN1 – O coordenador só poderá visualizar os projetos/fundos dos quais ele é coordenador. Caso essa

funcionalidade seja acessada por um substituto, deverão ser mostrados somente os projetos/fundos do

coordenador associados ao substituto.

RN2 – A seleção do passageiro poderá ser feita pelo CPF ou Nome das PF´s associadas ao coordenador,

através da digitação dessas informações (passageiro avulso) ou pela busca por CPF/Nome por todo o

conjunto de colaboradores cadastrados.

RN3 – Todos os dados do agendamento de passagem aérea são obrigatórios, com exceção da data de

retorno (retorno em aberto).

RN4 – As datas de embarque e retorno deverão ser maiores que a data corrente.

UC01 - Solicitar Passagem Aérea

Lista de Defeitos do UC01

623

UC02 - Solicitar Diárias

Objetivo: Permitir ao coordenador solicitar diárias

Requisitos: RF2, RF10, RF18

Atores:

Prioridade: Alta

Trigger: O ator aciona a opção de solicitação de diárias

Fluxo Principal: 1. O Sistema apresenta um formulário em branco com as seguintes informações [RN1 de UC09, RN1,

RN2, RN3, RN4, RN5, RN6, RN7, RN8, RN9]:

- Lista com os projetos e fundos do coordenador

- Nome do favorecido

- CPF do favorecido

- Trecho

- Tipo de diária (nacional ou internacional)

- Moeda

- Cotação (somente se for moeda estrangeira)

- Número de diárias

- Valor unitário da diária (na moeda selecionada)

- Valor total (em R$)

- Período da viagem (data de início e fim)

- Observações

- Forma de pagamento (cheque ou depósito em CC)

- Dados bancários: número e nome do banco, número e nome da agência, número da conta

corrente, cidade e UF.

- Lista com o local de aquisição da passagem

- Lista com o objetivo da viagem

- Descrição do objetivo da viagem

2. O ator preenche o formulário.

3. O Sistema critica os dados fornecidos [A1], gera um código para a solicitação e a armazena como

“pendente” ou “espera” [RN7]. Em seguida é apresentado o código da solicitação e uma opção para

impressão da mesma [E1].

Fluxo Alternativo:

Extensões: [E1] Ator solicita impressão da solicitação

Ver caso de uso “Imprimir Solicitação”

UC02 - Solicitar Diárias (cont.)

Regras denegócio:

RN1 – Todos os dados da solicitação de diárias são obrigatórios, com exceção Moeda, Observações e

Dados bancários.

RN2 – Os dados bancários só serão obrigatórios se a forma de pagamento for Depósito em CC.

RN3 – O valor total para viagens nacionais deverá ser calculado como Número de diárias -Valor da

diária.

RN4 – O valor total para viagens internacionais deverá ser calculado como Número de diárias x Valor da

diária x Cotação na data corrente.

RN5 – O campo Moeda só é obrigatório para viagens internacionais.

RN6 – A data de início deve ser maior que a data de fim do período de viagem.

RN7 – A seleção do passageiro poderá ser feita pelo CPF ou Nome das PFs associadas ao coordenador,

através da digitação dessas informações (passageiro avulso) ou pela busca por CPF/Nome por todo o

conjunto de colaboradores cadastrados.

RN8 – Tanto o banco quanto a agência devem ser selecionados de uma lista. Caso a agência não exista

na lista, o solicitante deve fornecer o seu código, nome, cidade e UF. Caso a solicitação seja aprovada,

a agência será automaticamente cadastrada.

RN9 – Caso o objetivo da viagem selecionado na lista seja “OUTROS”, o ator deve preencher a

descrição do objetivo da Viagem. Caso contrário essa informação é ignorada.

Lista de Defeitos do UC02

626

Técnicas para Detecção de Defeitos

• Ad-hoc

• Checklist

• Técnicas de Leitura

– Leitura Baseada em Perspectiva (PBR)

– OORTs

627

Ad-hoc

• Inspetor lê o documento de acordo com sua perspectiva.

• Experiência individual afeta o resultado final:

– Foco reside na especialidade do inspetor.

– Produtividade individual.

– Difícil garantir que inspetor leu o documento de forma adequada, pois

cada um aplica “sua própria técnica”.

• Não existe garantia de cobertura do documento como um todo.

• Custo/Eficiência (# defeitos/tempo) pode ser adequado quando

inspetores possuem experiência alta (> custo).

628

Checklist

• Inspetor segue uma lista de itens com características a serem revisadas, mas ainda aplica leitura Ad-hoc para identificar os defeitos

• Resultado final mais direcionado:– Características de qualidade definidas à priori

– Produtividade individual

– Difícil garantir que inspetor leu o documento de forma adequada, mesmo tendo sido definidas as características de qualidade a se procurar

• Cobertura do documento relacionada aos itens do Checklist

• Custo/Eficiência depende do Checklist e dos inspetores

• Checklist pode ser adaptado ou construído para capturar uma determinada especificidade

629

Checklist (Exemplo para Requisitos)

1. Os requisitos exibem a distinção clara entre funções e dados?2. Os requisitos definem todas as informações a ser apresentada aos usuários?3. Os requisitos descrevem as respostas do sistema ao usuário devido à condições

de erro? 4. Cada requisito está descrito claramente, é conciso e está apresentado de forma

não ambígua? 5. O requisito é testável?6. Existem requisitos implícitos ou ambíguos?7. Existem requisitos conflitantes? 8. Existem áreas não tratadas no documento de requisitos que precisam ser

consideradas? 9. Os requisitos de desempenho (tais como tempo de resposta, armazenamento

de dados, etc.) foram definidos? 10. Se os requisitos envolvem a descrição de processos de tomada de decisão

complexos, eles estão descritos de forma a facilitar sua compreensão (i.e., tabelas de decisão, árvores de decisão, etc.)?

630

11. Os requisitos para executar as atualizações do software foram

especificados?

12. Existem requisitos que contêm algum nível desnecessário de detalhe do

projeto?

13. As restrições de tempo-real foram especificadas em detalhe suficiente?

14. A precisão e acurácia dos cálculos foram especificadas?

15. É possível desenvolver um completo conjunto de casos de teste baseado

apenas na informação contida na especificação de requisitos? Se não, que

informação está faltando?

16. As restrições e dependências foram claramente descritas?

17. O documento contém realmente toda a informação prometida em sua

introdução?

631

Checklist (Exemplo para Requisitos)

Técnicas de Leitura

• Motivação:– desenvolvedores são treinados para escrever artefatos de software, mas

raramente possuem habilidades para revisá-lo;

– desenvolvedores confiam em técnicas ad-hoc e não seguem umprocedimento bem definido.

• Objetivos:– fornecer um conjunto de instruções a serem seguidas pelos revisores para

que os defeitos sejam detectados;

– introduzir um formalismo que garanta que o procedimento possa serseguido e repetido, possibilitando a melhoria contínua do processo derevisão;

– reduzir a influência humana nos resultados (aproximar de uma atividadede Engenharia).

632

Técnicas para Detecção de Defeitos

Técnica Notação Sistemático? Focado? Melhoria controlada?

Adaptável? Treinamento necessário?

Ad-Hoc Qualquer Não Não Não Não Não

Checklist Qualquer Parcialmente Não Parcialmente Sim Parcialmente

Técnicas de Leitura

Linguagem Natural

Sim Sim Sim Sim Sim

633

Discussão: Ad-hoc X Checklist X Técnica de Leitura

Leituras Sugeridas


• Wagner, S., Software Product Quality Control – Capítulos 3 – Quality Planning e Capítulo 4 – Quality Control, Springer, 1ª ed., 2013.

• Kalinowski, M., Travassos, G.H., Spínola, R.O., Dias-Neto, A.C., Bott, A., “Inspeções de Requisitos de Software em Desenvolvimento Incremental: Uma Experiência Prática”, VII Simpósio Brasileiro de Qualidade de Software, Porto de Galinhas, Brasil, 2007.

• Kalinowski, M., Travassos, G.H., “A Computational Framework for Supporting Software Inspections”, 19th IEEE International Conference on Automated Software Engineering, Linz, Austria, 2004.

634



Conceitos Iniciais


Teste de Software Conceitos e Definições


635

Teste de Software

“O software sempre será testado. Pode ser testado por você ou

será testado pelo seu cliente/usuário.”

636

Teste e Depuração

• Teste:

– Processo de executar um programa ou sistema com o

objetivo de revelar a presença de falhas; ou, falhando nesse

objetivo, aumentar a confiança sobre o programa

• Depuração:

– é uma consequência não previsível do teste. Após revelada a

presença da falha, o defeito deve ser encontrado e corrigido

Depuração não é teste!

637

Elementos do Teste de Software

Caso de Teste:◦ Descreve uma condição particular a ser testada

Composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.

Procedimento (Roteiro) de Teste:◦ Descreve os passos necessários para a execução de um ou grupos de casos de

teste

Critérios de Cobertura dos Testes:◦ Permitem a identificação de partes do programa que devem ser executadas

para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado.

A Cobertura dos Testes determina o percentual de elementos testados em um programa.

638

Rodada (Bateria) de Teste:

◦ Execução de todos os testes para uma versão do produto em

um determinado ambiente

Uma nova rodada de teste deve ser executada caso o critério de

aceitação do produto não tenha sido atingido

Incidentes de Teste:

◦ Evento ou comportamento diferenciado ocorrido durante a

execução dos testes que requer investigação

Não há garantia que todo incidente seja uma falha, pois ainda precisa

ser analisado

639

Elementos do Teste de Software

Objetivo dos Testes de Software

• Refutar a assertiva de que o produto está correto

– Determinar entradas que façam as saídas obtidas diferirem

das saídas esperadas de acordo com a especificação

• busca de um contra-exemplo

– É um processo destrutivo, sob o ponto de vista psicológico,

contrariamente às demais fases da Engenharia de Software,

onde constrói-se um produto

640

Características dos Testes de Software

Uma das atividades mais onerosas do desenvolvimento

de software

Último recurso para avaliação do produto antes de sua

entrega ao usuário final

Atividade essencial para ascensão ao nível 3 do CMMI e

Nível D do MPS

Atividade relevante para avaliação de produtos de

software (ISO 25010, ISO 14598-5)

641

Princípios de Teste de Software

• Os testes devem ser rastreáveis aos requisitos do

usuário

– devem ser realizados para testar os requisitos do usuário

• Devem ser completamente planejados antes de seu

início

– O planejamento é primordial para sua execução

• Acredita-se que o princípio de Pareto exista de fato

– 80% de todos os erros encontrados a partir das falhas reveladas estarão

concentrados em 20% dos componentes do software

642

Princípios de Teste de Software

• Devem ser aplicados inicialmente em pequena escala e

depois expandidos

• Não é possível aplicá-los exaustivamente

• Para aumentar sua eficácia, deve ser executado por

equipes independentes (quem não desenvolveu o software)

• Para evitar viés na execução, os testadores devem serdiferentes de quem planejou os testes

643

Teste de Software

• O que identifica um bom teste ?

– Possui alta probabilidade de revelar falhas

– Não é redundante

– É abrangente o suficiente

– Possui um nível adequado de complexidade

644

Teste de Software

645

Não ocorrência de falha:

Teste é de Baixa Qualidade?

OU

Sistema de Alta Qualidade?

Teste de Software

Atividade que tipicamente envolve:

◦ Execução do software com entradas representativas para as

futuras condições de operação

◦ Comparação entre saídas produzidas e esperadas

◦ Comparação entre estados resultantes e esperados

◦ Mensuração de características de execução (memória e tempo

consumidos,etc.)

646

Fases de Teste de Software

Fases de Teste

◦ Unidade

◦ Integração

◦ Sistema

◦ Re-Teste Regressão

“Fumaça”

◦ Aceitação

◦ Instalação

647

Unidade

Integração

Alta ordem

código

Projeto

Requisitos

Fases de Teste de Software

648

Unidade

Integração

Perspectiva dos Projetistas e Desenvolvedores

Sistema

Aceitação

Perspectiva dos Clientes e Usuários

Desenvolvimento e Testes

649

Requisitos do Sistema

Requisitos do Software

Modelo de Projeto

Código

Teste de Aceitação

Teste de Sistema

Teste de Integração

Teste de Unidade

Projeto dos Testes Execução dos testes

Teste de Unidade

É a fase do processo de teste em que se testam as menores

unidades de software desenvolvidas

◦ O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo

pequenos trechos de código

Objetivo:

◦ encontrar falhas de funcionamento dentro de uma pequena parte do

sistema funcionando independentemente do todo

Existem situações em que você não terá os recursos para realizar

o teste completo das unidades.

◦ Selecione os módulos críticos e aqueles com alta complexidade e apenas

teste estes módulos

◦ Utilize inspeções de código

650


A partir dos módulos testados no nível de unidade,

construir a estrutura de programa que foi determinada

pelo projeto

Além disso, encontrar falhas provenientes da

integração interna dos componentes de um sistema

Tipos de falhas: envio e recebimento de dados◦ Ex: um objeto A pode estar aguardando o retorno de um valor X ao

executar um método do objeto B, porém este objeto B pode retornar um

valor Y, desta forma gerando uma falha

651


• Aplicar a abordagem “big bang” para integração é uma

estratégia ingênua que está fadada ao fracasso.

– Teste de integração deve ser conduzido de forma incremental

e organizada!

• Tipos de Teste de Integração:

– Top-Down

– Bottom-up

652


• Abordagem Top-Down

– Inicia-se a integração pelo primeiro módulo até o último da hierarquia (de

cima para baixo).

– Vantagem: Testa antes as principais funções de controle.

– Desvantagem: Stubs são necessários

653

Módulo a ser integrado

Stubs necessários


• Abordagem Bottom-Up

– Módulos são integrados partindo-se do último da hierarquia (de baixo

para cima).

– Vantagem: Projeto de Caso de Teste mais fácil pela ausência de stubs

– Desvantagem: O programa não existe como entidade até que o último módulo

seja adicionado. Necessidade de criar drivers (teoricamente mais fáceis que stubs)

654

Módulo a ser integrado

Driver necessário

Teste de Sistema

• Objetivo:

– executar o sistema sob ponto de vista de seu usuário final, varrendo as

funcionalidades em busca de falhas

• Testes executados em condições similares àquelas que um

usuário utilizará no seu dia-a-dia

• Um sistema divide-se em características:

– Funcionais: • Ignora a estrutura do sistema

• Foco na funcionalidade

– Não-Funcionais:• Considera as características de qualidade do sistema: Usabilidade, Portabilidade,

Recuperabilidade, Segurança, Eficiência, ...

655

Sistema = Funcional + Não-Funcional

Teste de Sistema

Tipos específicos de Teste de Sistema:◦ Recuperação

Força o software a falhar numa variedade de situações e verifica a capacidade de recuperação do produto

◦ Segurança Verifica se os mecanismos de proteção construídos para o sistema irão de

fato protegê-lo de alguma utilização ou intrusão imprópria.

◦ Stress Executa o sistema de forma a exigir recursos em quantidade, freqüência ou

volume anormais

◦ Desempenho Avalia o desempenho do software quando integrado ao sistema.

Normalmente está associado ao teste de stress

656

Estratégias para Re-Teste

• Podem ocorrer para qualquer estratégia de teste, em

caso de mudanças no software no planejamento dos

testes

• Dois tipos:– Regressão

– “Fumaça” (smoke testing)

657

Teste de Regressão

• Estratégia importante para redução de “efeitos colaterais”

• Consiste em se aplicar, a cada nova versão do software ou a cada

ciclo, todos os testes que já foram aplicados nas versões ou

ciclos de teste anteriores do sistema.

– Execute testes de regressão toda vez que uma modificação maior é

realizada no software (incluindo a integração de novos módulos)

– Efetue a gerência de configuração

658

Teste “Fumaça” (ou de Sanidade)Smoke Test

• Determina se uma nova versão do software tem

desempenho suficientemente bom para testes mais

aprimorados.

• Evita que sejam desperdiçados recursos de testes

com um build não estável.

659


• Foco nos requisitos – nas características imediatamenteaparentes para o usuário final

• Testes realizados, geralmente, por um grupo restrito de usuários finais do sistema

• Teste conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação definidos pelo cliente– Critérios para Teste de Aceitação

1. A funcionalidade (caso de uso) ou características de desempenho estão de acordo com o especificado e são aceitas

2. Uma variação da especificação é descoberta e uma lista de discrepâncias (deficiências) é criada

660


• Teste Alfa e Beta

– Alfa: executado na instalação do desenvolvedor pelo cliente

– Beta: executado na instalação de um ou mais clientes pelo usuário final do software

661

Teste de Instalação (e Configuração)

• Consiste em instalar o sistema nos locais em que estão os usuários– Dispensado no caso do teste de aceitação ter sido executado

no ambiente do usuário

• Focam:– A integridade do sistema instalado; e

– A verificação quanto a se alguma característica funcional ou não funcional foi afetada pelas condições do local de operação

662


663

• A diferença entre re-teste e teste de regressão é:

a) re-teste procura por efeitos colaterais inesperados; teste

de regressão assegura que a falha original foi corrigida.

b) re-teste assegura que a falha original foi removida; teste

de regressão procura efeitos colaterais inesperados.

c) re-teste é feito após o conserto das falhas; teste de

regressão é feito antes.

d) re-teste é feito pelos desenvolvedores; teste de

regressão é feito por uma equipe independente.

664

• No contexto de engenharia de software, testes de software

podem ser decompostos numa série de passos que devem ser

executados seqüencialmente. Considerando a arquitetura de

software convencional, o primeiro passo deve ser o teste de

a) estresse.

b) integração.

c) sistema.

d) unidade.

e) validação.

665

Considere a seguinte descrição.

“É uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes para descobrir erros associados à interface e tem como objetivo, a partir de componentes testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto.”

Assinale a seguir o teste descrito.

A) Teste de integração

B) Teste de sistema

C) Teste de unidade

D) Teste de validação

666

• Após uma reunião de projeto de

desenvolvimento de um software, foi decidido

que o software entraria na fase de teste alfa, o

qual é realizado pelo:

(A) analista de teste, no ambiente de desenvolvimento.

(B) analista de teste, no seu próprio ambiente.

(C) cliente, no seu próprio ambiente.

(D) cliente, no ambiente de desenvolvimento.

(E) desenvolvedor, no ambiente do cliente.

667

Processo de Testes de Software

• Objetivo:– Organizar o conjunto de atividades a serem realizadas durante os testes

• Composto de:– Atividades, papéis, critérios de entrada/saída, artefatos

• Benefícios:– Melhor alocação dos recursos definidos para o projeto

– Gerenciamento da equipe de teste

• Atividades:– Planejar os Testes

– Executar os Testes

– Controlar os Testes e Analisar seus Resultados

668

• Gerente de Teste:– Responsável pelo planejamento e controle dos testes

• Projetista de Teste:– Responsável pelo projeto dos testes, incluindo a seleção de

técnicas de teste, identificação e definição de casos e procedimentos de teste

• Testador:– Responsável pela execução dos testes conforme o planejado

visando revelar falhas no produto, e pelo registro dos incidentes ocorridos durante a execução dos testes

669


670

Sub-processo deExecução dos Testes

Sub-processo dePlanejamento dos Testes

Sub-Processo de Planejamento dos Testes

671

Sub-processo de Planejamento dos Testes

1. Planejar Testes

4.Definir Procedimentos de Teste

3.EspecificarCasos de Teste

2. Projetar Testes

Gerentede Teste

Plano de Teste

Especificação deProjeto de Teste

Projetistade Teste

Especificação deCaso de Teste

Especificação deProcedimento de Teste


672

Sub-processo deExecução dos Testes

Sub-processo dePlanejamento dos Testes

Sub-Processo de Execução dos Testes

673

Sub-processo de Execução dos Testes

6. Analisar Resultados dos

Testes

Gerente de Teste

Especificação de Procedimento de TesteTestador 5. Executar Testes

Log de Teste

Relatório de Incidente de Teste

Relatório de Resumo dos Testes

Teste de Software

• Recomendações:– Convide os testadores a participar das revisões dos requisitos e inspeções

– Comece o planejamento do teste em paralelo com a análise de requisitos

– Inclua sugestões de condições de teste e casos de teste para utilizar como

exemplos na especificação de requisitos

– Inclua no documento de requisitos qualquer caso específico que vier a

mente quando estiver analisando os requisitos

– Utilize cenários de negócios e casos de uso para dar exemplos específicos

de como o sistema deveria funcionar

– Identifique critérios mensuráveis para ambos os tipos de requisitos

(funcionais e não funcionais)

674

Leituras Sugeridas


• Wagner, S., Software Product Quality Control – Capítulo 3 – Quality Planning e Capítulo 4 – Quality Control, Springer, 1ª ed., 2013.

Delamaro, M.E., Maldonado, J.C., Jino, M., “Introdução ao Teste de

Software”, Editora Campus, 2007.

675



Conceitos Iniciais



Técnicas de Teste de Software

676


• Projeto de Casos de Teste

• Técnicas de Teste:

– Funcional x Estrutural x Baseada em Defeitos

• Exercícios de Fixação

677

Projeto de Casos de Teste

Projeto de teste pode ser tão difícil quanto o projeto

do próprio produto a ser testado

Projeto de teste é um dos melhores mecanismos para

prevenção de defeitos

O projeto de casos de teste é tão eficaz em identificar

erros quanto a execução dos casos de teste projetados

◦ Funciona como uma forma de revisão!

678

Projeto de Casos de Teste

Esteja certo que você projeta testes com alta cobertura

(todo caminho de tratamento de erro)

◦ Senão, o caminho pode falhar quando ativado, revelando uma

situação nem sempre agradável do sistema

Existem situações nas quais você não terá todos os

recursos para realizar um teste completo das unidades

◦ Selecione os componentes mais críticos e aqueles com alta

complexidade e teste inicialmente estes

679

Técnicas para Teste de Software

• Técnicas (Critérios de Teste):

– Funcional (ou caixa preta/caixa fechada)

– Estrutural (ou caixa branca/caixa aberta)

– Baseada em defeitos

• A questão não está em qual delas utilizar e sim como

combiná-las de forma a maximizar os benefícios das

atividades de teste!

680

Técnica Funcional

• Baseia-se na especificação do software para derivar os requisitos

de teste

• Aborda o software de um ponto de vista macroscópico

• Envolve dois passos principais:

– identificar as funções que o software deve realizar (especificação dos

requisitos, casos de uso)

– criar casos de teste capazes de verificar se essas funções estão sendo

executadas corretamente

681

Técnica Funcional

• Problema:

– Dificuldade em quantificar a atividade de teste - não se pode garantir que partes

essenciais ou críticas do software foram executadas

• Critérios da Técnica Funcional:

– Particionamento em Classes de Equivalência

– Análise do Valor Limite

– Grafo de Causa-Efeito

– Error Guessing

682

Técnica Funcional

Particionamento em Classes de Equivalência

◦ Divide o domínio de entrada do programa em classes de dados

(classes de equivalências)

◦ Uma classe de equivalência representa um conjunto de

estados válidos e inválidos para uma condição de entrada

Tipicamente uma condição de entrada pode ser um valor numérico

específico, uma faixa de valores, um conjunto de valores relacionados,

ou uma condição lógica.

◦ Os dados de teste são derivados a partir das classes de

equivalência

Eventualmente, pode se considerar o domínio de saída como referência

683

Técnica Funcional

• Particionamento em Classes de Equivalência: 2 Passos

1. Identificar classes de equivalência (é um processo heurístico)

• Diretrizes:

– Se uma condição de entrada especifica uma faixa de valores ou requer um valor

específico, uma classe de equivalência válida e duas inválidas são definidas;

– Se uma condição de entrada especifica um membro de um conjunto ou é lógica,

uma classe de equivalência válida e uma inválida são definidas

2. Definir os casos de teste• enumeram-se as classes de equivalência

• casos de teste para as classes válidas

• casos de teste para as classes inválidas

684

Classe de Equivalência: Exemplo

Verificação de uma senha válida:

685

O programa deve determinar se uma senha é válido ou não para um

programa. Uma senha válida deve começar com uma letra e conter

apenas letras ou dígitos. Além disso, deve ter no mínimo 1 caractere e no

máximo 6 caracteres de comprimento.

Exemplo:

acdn25 (válido);

senha*1 (inválido);

1pass (inválido);

a123456 (inválido)

Classe de Equivalência: Exemplo

• Classes de equivalência

686

Tamanho t da senha

Condições de Entrada Classes Válidas Classes Inválidas

1 t 6(1)

Primeiro caractere c é uma letra

Só contém caracteres válidos

t > 6(2)

Sim(3)

Não(4)

Sim(5)

Não(6)

Exemplo de Conjunto de Casos de Teste

T0 = {(acdn1,Válido), (2pass3, Inválido), (P-25, Inválido), (A1b2C3d, Inválido)}

Particionamento por EquivalênciaExercício: Problema do triângulo

• Um programa recebe três valores inteiros como entrada. Estes

três valores são interpretados como o comprimento dos lados

de um triângulo.

• O programa deve mostrar uma mensagem dizendo se o

triângulo definido pelos três valores informados é isósceles,

escaleno ou eqüilátero. Defina um conjunto de casos de teste

que você julgue adequados para testar este programa.

• Defina as classes de equivalência e o conjunto de casos de teste

para verificar o programa acima descrito.

687

• Classes de Equivalência

• Casos de Teste

688

Classe de

Equivalência

x y z Resultado

Esperado

Particionamento por EquivalênciaExercício: Problema do triângulo

Técnica Funcional

• Análise do Valor Limite

– Por razões não completamente identificadas, um grande

número de erros tende a ocorrer nos limites do domínio de

entrada invés de no “centro”

– Análise do Valor Limite é uma técnica de teste que explora os

limites dos valores para preparar os casos de teste

– Está técnica complementa o particionamento em classes de

equivalência

689

Técnica Funcional

• Análise do Valor Limite - Diretrizes

– Se uma condição de entrada especifica uma faixa de valores

limitadas em a (limite inferior) e b (limite superior), casos de

teste devem ser projetados com valores a e b e

imediatamente acima e abaixo de a e b;

• Ex: A={1..10}; Casos de Teste => {0, 1, 10, 11}

– Se uma estrutura de dados interna do programa tem identificados seus limites

(ex. Um vetor com 100 posições), projete um caso de teste para exercitar a

estrutura de dados em seu limite

690

Análise do Valor Limite: Exemplo

• Consideremos a seguinte situação:

• "... o cálculo do desconto de IR por dependente é feito da seguinte forma: a entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5% e dos 22 aos 24 de 3%..."

• Aplicando o teste de valor limite convencional serão obtidos casos de teste semelhantes a este:

{-1,0,12,13,18,19,21,22,24,25}

691

Técnica Funcional

Grafo de Causa-Efeito

◦ Técnica para identificação de casos de teste que explora as

condições lógicas e as ações correspondentes.

◦ Basicamente, 4 passos devem ser executados:

Para cada módulo, Causas (condições de entrada) e efeitos (ações

realizadas às diferentes condições de entrada) são relacionados,

atribuindo-se um identificador para cada um.

Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado.

Neste ponto, transforma-se o grafo numa tabela de decisão.

As regras da tabela de decisão são, então, convertidas em casos de

teste.

692

Grafo Causa-Efeito: Exemplo

Valor Compra >80 >80 <=80

#Produtos <3 >=3 --

Cobrar Frete V V

Frete Grátis V

693

Causa: valor compra > 80 ^ #produtos < 3

Efeito: frete grátis

Valor compra

#produtos

Cobrar Frete

Frete Grátis>80

<=80

< 3

>=3 Árvore de Decisão

Tabela de Decisão

Causa

Efeito

Grafo Causa-EfeitoExercício: Problema da Companhia Telefônica

Uma companhia telefônica define suas tarifas com base em:◦ 3 faixas de horário (F1: 0:00 as 6:00, F2: 6:00 as 18:00 e F3: 18:00 as 24:00)◦ No fato do dia ser "dia útil" ou não.

Valores da tarifa:◦ dias úteis: R$ 0,05 por minuto◦ sábados, domingos e feriados: R$ 0,04 por minuto.

Regra por horário:◦ No horário F1 a tarifa tem um desconto de 1 centavo◦ No horário F2 sofre um acréscimo de 1 centavo◦ No horário F3 não se aplicam descontos ou acréscimos

Elabore o conjunto de casos de teste para o programa que, com base no tipo do dia e na faixa de horário, calcula o custo da tarifa.

694

Error Guessing

• Técnica de teste baseada na experiência do

testador, que deve adivinhar que tipos de falhas

podem ocorrer e projetar casos de teste para

revelar estas falhas.

• Complementa técnicas de teste mais formais.

695

Técnica Estrutural

• É baseada no conhecimento da estrutura interna da

implementação

• Teste dos detalhes procedimentais

• A maioria dos critérios dessa técnica utiliza uma representação

de programa conhecida como grafo de programa ou grafo de

fluxo de controle

696

Técnica Estrutural(Grafo de Programa)

• Detalhes considerados:

– nó

– arco

– caminho:• simples

• completo

• livre de laço

– fluxo de controle

697

Técnica Estrutural

• Critérios de Fluxo de Controle– Todos-Nós (mínimo

esperado):• 1,2,3,4,5,6,7,4,8,9,11

• 1,3,4,8, 10,11

Todos-Arcos:• <1,2>,<2,3>,<3,4>,<4,5>,<5,6>,<6

,7>,<7,4>,<4,8>,<8,9>,<9,11>

• <1,3>,<3,4>,<4,5>,<5,7>,<7,4>,<4,8>,<8,10>,<10,11>

– Todos-Caminhos• ??????

698

Grafo de Programa

• Nós: – blocos “indivisíveis”

• não existe desvio para o meio do bloco

• uma vez que o primeiro comando do bloco é executado, os demais comandos

são executados seqüencialmente

• Arestas ou Arcos: – representam o fluxo de controle entre os nós

699

Grafo de Programa

700

• Nó = Bloco de comandos seqüenciais

• Aresta ou Ramo = Transferência de controle

Grafo de Programa

701

Critérios de Cobertura

• Objetivos

– Geração dos testes

– Avaliação final: indicação do término dos testes

• Tipos

– Cobertura de Instruções

– Cobertura de Decisões

– Cobertura de Condições

– Cobertura de Caminhos

702

Teste de Instruções

• Critério: Cada instrução deve ser

executada pelo menos uma vez.

– Vou preparar casos de teste que me façam

passar por cada nó do grafo pelo menos

uma vez...

703

Teste de Instruções

704

O teste de instrução não te obriga a testar todas as arestas...

Teste de Decisões

• Cada ramo deve ser percorrido pelo

menos uma vez.

– Desta vez o objetivo é procurar casos

de teste que passem por cada aresta

do grafo, testando todas as decisões

para valores verdadeiros e falsos...

705

Teste de Decisões

706

Neste caso, a decisão é testada em partes...

Teste de Decisões/Condições

707

• Todas as condições devem ser testadas para

valores V e F em cada decisão.

Teste de Caminhos

• Critério: Todos os caminhos possíveis do grafo

devem ser percorridos pelo menos uma vez

• Dificuldades:

– Nem todos os caminhos do grafo são executáveis

– Em grafos com ciclos, o número de caminhos pode ser

infinito

• É necessário critérios para delimitar o número de

caminhos

– Teste de caminhos básicos

– Teste de laços

708

Teste de Caminhos Básicos

• Em vez de todos os caminhos, busca os caminhos

independentes:

– Caminho independente: contém pelo menos 1 nova aresta do

grafo de controle

– O nº de caminhos independentes é dado pela complexidade

ciclomática (V(G)) de McCabe

– Uma vez que todos os outros caminhos do grafo são combinações

dos caminhos independentes, então V(G) é o limite superior do nº

de testes de caminhos.

709


• V(G) diz quantos caminhos independentes temos que

percorrer.

– Isso significará o número de casos de teste que devemos

preparar.

• Softwares de boa qualidade técnica possuem valores baixos de

complexidade ciclomática.

– Empresas controlam a complexidade ciclomática

– Utilizam ferramentas automatizadas.

710


• Complexidade ciclomática:

– Dados pelos nós predicados, regiões ou arestas e nós.

– Nó predicado -> onde “sai” mais de uma aresta

– V(G) = no de nós predicados + 1

– V(G) = no de regiões + 1

– V(G) = no de arestas – no de nós + 2

711


• Critério: Cada caminho

independente deve ser percorrido

pelo menos uma vez.

712

Técnicas Baseadas em Defeitos

• Os requisitos de teste são derivados a partir dos erros

mais frequentes cometidos durante o processo de

desenvolvimento do software

• Critérios da Técnica Baseada em Defeitos:

– Semeadura de Defeitos

– Análise de Mutantes (teste de unidade)

– Mutação de Interface (teste de integração)

713

Semeadura de Defeitos & Análise de Mutantes

• Semeadura de Defeitos

– Defeitos são inseridos no programa para avaliar a eficácia e

cobertura dos testes em revelá-los.

• Análise de Mutantes

– Comandos do código fonte sofrem mutações (mudanças).

– É verificado se o código de teste é capaz de revelar estes

defeitos.

714

Técnicas de Teste – Conclusões

• O que é importante observar?

– Custo

• esforço necessário para que o critério seja utilizado

• # de casos de teste para satisfazer o critério

– Strength

• Dificuldade de satisfação

• Dificuldade de satisfazer um critério, tendo satisfeito outro.

– Eficácia

• Capacidade que um critério possui de detectar erros

– Estratégia Incremental de Teste

• Custo benefício da combinação de critérios

715

Técnicas de Teste – Conclusões

• As técnicas de teste atualmente existente são complementares e

podem ser utilizadas em conjunto

– Deve ser feita uma análise de custo-benefício na empresa a respeito da

aplicação de várias técnicas em conjunto.

• Apoio Ferramental é essencial para a aplicação dessas técnicas

como meio para reduzir o esforço e custo de sua implantação

716

Leituras Sugeridas


Delamaro, M.E., Maldonado, J.C., Jino, M., “Introdução ao Teste de Software”, Editora Campus, 2007. Capítulos 2 e 3.

• Wagner, S., Software Product Quality Control – Capítulos 3 – Quality Planning e Capítulo 4 – Quality Control, Springer, 1ª ed., 2013.

717


718

Exercícios

Particionamento por Equivalência - Problema do apart-hotel• Um programa para apart-hotéis deve calcular tanto o custo mensal do apartamento como a

freqüência com a qual devem ser feitos os pagamentos.• As entradas do programa são o número do apartamento (inteiro entre 1 e 500), o número de

inquilinos (inteiro entre 1 e 9) e o limite do cartão de crédito do inquilino responsável (inteiro entre 1 e 100000).

• Regras dos quartos:– Os quartos de 1 a 100 tem 1 dormitório, comportam no máximo 2 inquilinos e custam R$ 100,00 por

mês por inquilino.– Os quartos de números 101 a 300 tem dois dormitórios, comportam no máximo 6 inquilinos e custam

R$ 150,00 por mês por inquilino para até 3 inquilinos e R$ 100,00 por mês por inquilino para mais de 3 inquilinos.

– Os quartos de números 301 a 500 têm 3 dormitórios e comportam até 9 inquilinos. Custam R$ 200,00 por mês por inquilino até 3 inquilinos, R$ 150,00 entre 4 e 6 inquilinos e R$ 100,00 para 7 ou mais inquilinos.

• Quanto à freqüência dos pagamentos:– Se o limite do cartão for inferior a R$ 5000,00 os pagamentos devem ser mensais.– Para cartões com limite entre R$ 5000,00 e R$ 10000,00 os pagamentos podem ser bimensais.– Finalmente para cartões com limite superior a R$ 10000,00 os pagamentos podem ser semestrais.

• O programa deve imprimir o custo do apartamento e a freqüência de pagamento ou uma mensagem de erro caso o número de inquilinos seja inadequado para o apartamento indicado. Determine as classes de equivalência e os casos de teste para este programa.

719

Exercícios

Análise do Valor Limite – Problema do triângulo

Assumindo que os lados do triângulo devem ser restritos aos limites [1;200] gere os casos de teste utilizando a técnica de análise de valor limite para este problema, apresentado como exercício ao longo do curso.

Lembrete: O programa deve mostrar uma mensagem dizendo se o triângulo definido pelos três valores informados é isósceles, escaleno ou eqüilátero.

◦ Informação Extra 1:Escaleno: triângulo de lados desiguais.Isósceles: triângulo que tem dois lados iguais.Eqüilátero: triângulo que tem os lados iguais entre si.

◦ Informação Extra 2:É necessário que a soma de dois dos comprimentos seja maior que o comprimento do lado restante.

720

Exercícios

Grafo Causa-efeito - Problema do custo da ligação telefônica

O programa recebe sobre a chamada as seguintes informações:

◦ tempo em minutos (arredondar para cima), código DDD da origem e do destino, um boleano que indica se a chamada é local ou interurbano, a distância entre as localidades, o horário/data em que se iniciou a chamada.

O cálculo do custo é feito segundo as seguintes regras:

◦ O preço base da chamada local é 4 centavos por minuto. Todos os acréscimos ou descontos são feitos sobre esse valor de forma cumulativa.

◦ Chamadas interurbanas de qualquer distância se for para uma localidade de mesmo DDD tem um acréscimo de 1 centavo por minuto.

◦ Se for para um DDD diferente então são acrescidos 2 centavos por minuto para distâncias de até 100Km e 3 centavos por minuto para distâncias maiores.

◦ Chamadas em horário comercial (8:00 às 12:00 e das 14:00 às 18:00) sofrem acréscimo de 2 centavos por minuto.

◦ Das 12:00 às 14:00 o acréscimo é de apenas 1 centavo por minuto.

◦ Das 18:00 às 24:00 não existe acréscimo pelo horário e, das 0:00 às 8:00 existe um desconto de 1 centavo por minuto.

◦ Sábados e domingos existem um desconto de 1 centavo por minuto. No caso de dias feriados, existe um desconto de um centavo por minuto, também.

721



Conceitos Iniciais




722

Gerência de Configuração de SoftwareCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]



Conceitos Básicos

o Gerência de Mudanças

724

O que é Gerência de Configuração?

• Gerência de configuração (GC) é o

processo de identificar, organizar e

controlar modificações ao software

sendo construído

• A idéia é maximizar a produtividade

minimizando os enganos

725

Objetivos de GC

• Definir o ambiente de desenvolvimento

• Definir políticas para controle de versões,

garantindo a consistência dos artefatos produzidos

• Definir procedimentos para solicitações de

mudanças

• Administrar o ambiente e auditar mudanças

• Facilitar a integração das partes do sistema

726

Benefícios

• Aumento de produtividade no desenvolvimento

• Menores Custos de Manutenção

• Redução de defeitos

• Maior rapidez na identificação e correção de problemas

727

Configuração

• Um projeto de desenvolvimento de software produz

os seguintes itens:

– Programas (código fonte, programas executáveis,

bibliotecas de componentes, etc.)

– Documentação (manuais do usuário, documento de

requisitos, modelo de análise e projeto, etc.)

– Dados (dados de teste e do projeto)

• Esses conjuntos de itens são chamados,

coletivamente, de configuração do software

728

Item de Configuração

• Um conjunto de itens vistos como uma

entidade única para fins de gerência de

configuração

• Um item de configuração está sujeito a

mudanças e essas devem obedecer às

políticas estabelecidas

• Normalmente, um item de configuração é

estabelecido para cada pedaço de software

que pode ser projetado, implementado e

testado de forma independente

729

Baseline

• Uma especificação ou produto que foi formalmente revisado e aceito

– Serve como base para os passos posteriores do desenvolvimento

• A configuração do software em um ponto discreto no tempo

• Só pode ser modificado através de procedimentos formais (solicitações de mudança)

730

Baseline

731

item

tempo

fluxo de desenvolvimento

Razões para Criar um Baseline

• Reproducibilidade: a habilidade de reproduzir

uma versão anterior do sistema

• Rastreabilidade: Estabelece uma relação

predecessor-sucessor entre artefatos do projeto

(projeto satisfaz requisitos, código implementa

projeto, etc.)

• Geração de Relatórios: A comparação dos

conteúdos de dois baselines ajuda na depuração e

criação de documentação

• Controle de Mudanças: referencial para

comparações, discussões e negociações

732

Repositório

• Local (físico e lógico) onde os itens de um sistema são

guardados

• Pode conter diversas versões do sistema

• Utiliza mecanismos de controle de acesso

733

RepositórioDesenvolvedor

Lock

• Resolve a Atualização Simultânea

• Garante que apenas o usuário que detém o lock pode alterar o

arquivo

• Problema: “serializa” o trabalho dos desenvolvedores

734

Check-Out

735

Check-out

Repositóriocliente

Check-Out

• Recupera a (última) versão de um item de configuração guardada no repositório– Escrita

• Verifica que ninguém detém o lock do item de configuração

• Obtém o lock do item

• Cria uma cópia, para edição, no cliente

– Leitura• Verifica que alguém já detém o lock

• Cria uma cópia, apenas para leitura, no cliente

736

Check-In

737

Check-in

Repositóriocliente

Check-In

• Ação de inserir/atualizar um item de configuração no

repositório

– Verifica o lock do item de configuração, caso o mesmo já exista

– Verifica e incrementa a versão do item

– Registra informações das mudanças (autor, data, hora,

comentários)

– Inclui/atualiza o item

738

Build

• Representa uma versão ainda incompleta do

sistema em desenvolvimento, mas com certa

estabilidade

• Costuma apresentar limitações conhecidas

• Espaço para integração de funcionalidades

• Inclue não só código fonte, mas documentação,

arquivos de configuração, base de dados, etc.

• A política de geração dos builds deve ser bem

definida na estruturação do ambiente

739

Geração de Buils através da Integração Contínua

• Geração freqüente (pelo menos diária) de builds do

sistema

– As partes do sistema são integradas constantemente

– Problemas de integração passam a ser encontrados

logo que introduzidos, na maioria dos casos

• Considerada uma das “melhores práticas” no

desenvolvimento de software

• A geração de builds deve ser automatizada e

realizada com freqüência adequada

740

Release

• Identificação e empacotamento de artefatos entregues ao cliente (interno ou externo) ou ao mercado

• Um release implica no estabelecimento de um novo baseline, de produto

• Produto de software supostamente sem erros– Versão do sistema validada após os diversos tipos de teste

– Garantia de que todos os itens de configuração foram devidamente testados, avalidos, aceitos e estão disponíveis no novo baseline

• Processo iterativo/incremental produz, em geral, mais de um release

741

Oportunidades criadas com GC

• Reuso de itens de software

– Artefatos

– Componentes

• Automação de processo

– Construção de builds

– Geração de releases

– Testes

– Integração

• Aumento da produtividade das equipes

• Redução de re-trabalho

• Melhoria do acompanhamento do projeto

742


Conceitos Básicos

Gerência de Mudanças

743

O que é Gerência de Mudanças?

• Gerência de Mudanças é o processo de avaliar, coordenar e

decidir sobre a realização de mudanças propostas a itens de

configuração (ICs)

• Mudanças aprovadas são implementadas nos itens de

configuração e nos dados e documentos relacionados

744

Benefícios

• Controle sobre o escopo do projeto

• Mais produtividade

– cada solicitação será tratada de forma coordenada

– Redução dos problemas de comunicação entre

membros da equipe

• Mais qualidade, uma vez que cada mudança, antes

de ser realizada, tem seu impacto avaliado

• Geração de dados para o acompanhamento

(tracking) do projeto

745

Sobre o Processo de Gerência de Mudanças

• Deve ser definido um documento padrão para que

mudanças possam ser solicitadas

• Esse documento normalmente se chama Solicitação

de Mudança (SM, Em inglês CR)

• A um conjunto de pessoas (CCB), deve ser dada a

autoridade para decidir se uma mudança será ou

não implementada

• O processo é necessário para garantir que apenas

mudanças avaliadas e aprovadas são realizadas em

ICs

746

Solicitações de Mudança

• Algumas informações que podem estar incluídas em

uma SM:

– Identificação única

– Solicitante

– Sistema/Projeto

– Item a ser modificado

– Classificação (melhoria, correção de defeito, outra)

– Prioridade

– Descrição

– Situação (nova, atribuída, finalizada, verificada,

fechada)

747

Processo de Gerência de Mudanças Genérico

748

1. Requisição

da mudança

2. Classificação

da mudança

3. Avaliação

da mudança

4.Negociação sobre

a realização da

mudança

5. Implementação

da mudança

6. Verificação

da mudança

7. Promoção dos

itens modificados

para um novo

baseline

(mudança aceita)

CCB

Correções Emergenciais

• Em algumas situações, não há tempo para seguir os

procedimentos padrão para a realização de

mudanças

• Defeitos não são normalmente processados pelo

CCB, salvo se envolverem algum questionamento

relativo ao escopo do projeto

• Mesmo nessas situações, porém, é muito

importante que seja criada uma solicitação de

mudança

• O objetivo é garantir um mínimo de ordem, mesmo

em uma situação caótica

749

Correções Emergenciais

• Mudanças realizadas nessas circunstâncias podem

comprometer a arquitetura ou inserir bugs

• Decisão:

– Desfazer correção ou

– Transformar a correção: refactoring, acréscimo de novos casos de

teste

750

Ferramentas de Apoio à Gerência de Configuração

• Manter todos os arquivos em um repositório central

• Controlar o acesso a esse repositório, de modo a garantir a consistência dos artefatos

• Automatizar o processo de geração de builds

• Automatizar o processo de submissão e gestão de SMs

751

Ferramenta de Controle de Versões (GIT, SVN, CVS, por exemplo)

Ferramentas de Geração de Builds (Ant, Maven, por exemplo)

Ferramentas de Gestão de Solicitações de Mudanças

(Bugzilla, Mantis, Redmine, JIRA, por exemplo)

Fundamentos de Qualidade do SoftwareCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Aumento da qualidade do produto

Diminuição do retrabalho

Maior produtividade

Redução do tempo para atender o mercado

Maior competitividade

Maior precisão nas estimativas

Qualidade do processo

753

Motivação para o Processo de Software

O interesse no processo de software está

baseado em duas premissas:

a qualidade de um produto de software é fortemente

dependente da qualidade do processo pelo qual ele é

construído e mantido

o processo de software pode ser definido, gerenciado, medido

e melhorado

Um processo definido está descrito em

detalhes de forma a poder ser usado de

forma consistente.

754


A implantação de um Programa de Qualidade

começa pela definição e implantação de um

processo de software

O processo de software deve estar

documentado, ser compreendido e seguido.


755

Características

ad hoc - improvisado

fortemente dependente dos profissionais

indisciplinado

Consequências

pouca produtividade

qualidade de difícil previsão

alto custo de manutenção

risco na adoção de novas tecnologias

Processo Imaturo

756

Características

processo conhecido por todos

apoio visível da alta administração

auditagem da fidelidade ao processo

medidas do produto e do processo

adoção disciplinada de tecnologias

Consequências

papéis e responsabilidades claramente definidos

acompanhamento da qualidade do produto e da

satisfação do cliente

expectativas para custos, cronograma,

funcionalidades e qualidade do produto é

usualmente alcançada

Processo Maduro

757

Pesquisa iMPS

• Pesquisa realizada anualmente para acompanhar e

evidenciar resultados de desempenho nas empresas

de software que adotaram o modelo MPS.

• Disponível em http://www.softex.br/mpsbr/

758

Travassos, G.H., Kalinowski, M. “iMPS 2013: Evidências

Sobre o Desempenho das Empresas que Adotaram o

Modelo MPS-SW”. Campinas: SOFTEX, 2014 (ISBN: 978-

85-99334-75-1), 102p.

Resultados de Desempenho das Empresas que Adotaram o MPS-SW

• Maior satisfação dos seus clientes.

• Maior produtividade.

• Maior capacidade de desenvolver projetos maiores.

• Obtenção do retorno do investimento (ROI).

• Tendência à melhoria de custo e qualidade.

759

Possíveis Ganhos na Evolução nos Níveis de Maturidade do MPS-SW

• Maior número de clientes.

• Maior número de projetos.

• Maior número de funcionários.

• Capacidade de lidar com projetos de maior tamanho.

• Maior precisão nas estimativas de prazo.

760

Momento de Reflexão

• Investir na melhoria do processo garante a

qualidade do produto?

761

Momento de Reflexão

• Diversos fatores influenciam a qualidade do produto

e ela precisa ser avaliada e monitorada também

diretamente. (Wagner, 2013)

Requisitos de qualidade de produtos devem ser definidos e

seu alcance monitorado ao longo da execução do projeto.

762

Normas e Modelos de Referência

• Processo de Software

– Norma ISO 12207

– Modelo CMMI-Dev

– Modelo MPS-SW (Programa MPS.BR)

• Produto de Software

– Norma ISO SQuaRE (25000-25099)

763

Modelos de Capacitação OrganizacionalCurso de Aperfeiçoamento Avançado em Guerra Eletrônica

Marinha do Brasil


[email protected]


Normas e Modelos de Qualidade do Processo

• CMMI-Dev

• MPS-SW

765

CMMI-Dev: Conceitos Fundamentais

• Organizado em Áreas de Processo

– Equivale ao conceito de Processo da ISO/IEC ou do MPS-SW.

• As Áreas de Processo Possuem

– Propósito

– Objetivos Específicos

– Práticas

• Além disso existem Objetivos Genéricos que podem ser

aplicados a todas as área de processo

766

Exemplo: Área de Processo ‘Verificação’

767

Representações

• Em estágios (staged)

– Perspectiva de maturidade da organização.

– Enfatiza conjuntos de áreas de processo que definem

estágios de maturidade do processo.

• Contínua (continuous)

– Perspectiva de capacidade das áreas de processo.

– Mede resultados em cada área individualmente.

768

Processo Realizado

Práticas Genéricas

Nível 2

Processo GerenciadoProcesso Gerenciado


Nível 3

Processo DefinidoProcesso Definido


Nível 4

Processo Gerenciado

Quantitativamente

Processo Gerenciado

Quantitativamente


Nível 5

Processo em Otimização

Cap

acid

ad

e

769

Áreas de Processo agrupadas em Estágios

Nível de Maturidade 2

770


Planejamento do Projeto

Monitoração e Controle do Projeto

Gerência de Acordos com Fornecedores

Medição e Análise

Garantia da Qualidade do Processo e do Produto



Desenvolvimento de Requisitos

Solução Técnica

Integração do Produto

Verificação

Validação

Foco no Processo Organizacional

Definição do Processo Organizacional

Treinamento Organizacional

Gerência de Projeto Integrada

Gerência de Riscos

Integração da Equipe

Análise de Decisão e Resolução

Ambiente Organizacional para Integração

771



Desempenho do Processo Organizacional

Gerência Quantitativa do Projeto


Inovação e Implantação Organizacional

Análise e Resolução de Causas

772


773

Gerenciado

Definido

Gerenciado

Quantitativamente

Em Otimização

1Processo imprevisível,

pobremente controlado e

reativo

2Processo caracterizado para

projetos e muitas vezes

reativo

3Processo caracterizado para

a organização e proativo

4Processo medido e

controlado

5Foco na melhoria do

processo

Inicial

Níveis de Maturidade

Normas e Modelos de Qualidade do Processo

• CMMI-Dev

• MPS-SW

774

MPS.BR

Realidade das Empresas Brasileiras

ISO /IEC 12207

ISO /IEC 15504

CMMI

SOFTEX

Governo

Universidades

Base Técnica

Programa MPS.BR

775

Descrição dos modelos

• O modelo é descrito nos guias do MPS.BR

• Os guias gerais possuem os requisitos que devem ser

atendidos durante a implantação dos modelos

• Os guias de implementação são orientativos

• Todos os guias estão disponíveis em

http://www.softex.br/mpsbr

776

Estrutura do MPS-SW

777

Níveis de maturidade

Capacidade

Resultado

Processo

Propósito Atributo

Gerenciado Quantitativamente

Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização

Níveis de Maturidade MPS-SW

778

Medição - MED / Gerência de Configuração - GCOAquisição - AQU / Garantia da Qualidade - GQAGerência de Portfólio de Projetos - GPP

Avaliação e Melhoria do Processo Organizacional - AMPDefinição do Processo Organizacional - DFPGerência de Reutilização - GRUGerência de Recursos Humanos - GRHGerência de Projetos - GPR (evolução)

Desenvolvimento de Requisitos - DREProjeto e Construção do Produto - PCPIntegração do Produto - ITPVerificação - VER / Validação - VAL

Gerência de Decisões - GDEDesenvolvimento para Reutilização - DRUGerência de Riscos - GRI

G

F

E

D

C

Gerência de Requisitos - GRE

Gerência de Projetos - GPR

A

BGerência de Projetos - GPR (evolução)

(sem processo específico)

779

CAPACIDADE

PROCESSOS

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*,5.1*, 5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento paraReutilização, Gerência de Decisões

1.1, 2.1, 2.2, 3.1,3.2

D Desenvolvimento de Requisitos, Integração doProduto, Projeto e Construção do Produto,Validação, Verificação

1.1, 2.1, 2.2, 3.1,3.2

E Avaliação e Melhoria do Processo Organizacional,Gerência de Projetos (evolução), Gerência deRecursos Humanos, Gerência de Reutilização,Definição do Processo Organizacional

1.1, 2.1, 2.2, 3.1,3.2

F Aquisição, Garantia da Qualidade, Gerência deConfiguração, Gerência de Portfólio de Projetos,Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

* Estes APs capacitam apenas um conjunto de processosselecionado pela organização de acordo com seus objetivos demelhoria. Os demais APs precisam capacitar todos os processos donível pretendido.

Entendendo os Atributos de Processo (Capacidade)

• AP 1.1 O processo é executado– Este atributo é uma medida do quanto o processo atinge o

seu propósito.

• AP 2.1 O processo é gerenciado– Este atributo é uma medida do quanto a execução do

processo é gerenciada.

• AP 2.2 Os produtos de trabalho do processo são gerenciados– Este atributo é uma medida do quanto os produtos de

trabalho produzidos pelo processo são gerenciados apropriadamente.

780

• AP 3.1. O processo é definido

– Este atributo é uma medida do quanto um processo padrão

é mantido para apoiar a implementação do processo

definido.

• AP 3.2 O processo está implementado

– Este atributo é uma medida do quanto o processo padrão é

efetivamente implementado como um processo definido

para atingir seus resultados.

781


• AP 4.1 O processo é medido– Este atributo é uma medida do quanto os resultados de

medição são usados para assegurar que o desempenho do processo apóia o alcance dos objetivos de desempenho relevantes como apoio aos objetivos de negócio definidos.

• AP 4.2 O processo é controlado– Este atributo é uma medida do quanto o processo é

controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos.

782


• AP 5.1 O processo é objeto de inovações– Este atributo é uma medida do quanto as mudanças no

processo são identificadas a partir da análise de causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo.

• AP 5.2 O processo é otimizado continuamente– Este atributo é uma medida do quanto as mudanças na

definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.

783


784

CAPACIDADE

PROCESSOS

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*,5.1*, 5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento paraReutilização, Gerência de Decisões

1.1, 2.1, 2.2, 3.1,3.2

D Desenvolvimento de Requisitos, Integração doProduto, Projeto e Construção do Produto,Validação, Verificação

1.1, 2.1, 2.2, 3.1,3.2

E Avaliação e Melhoria do Processo Organizacional,Gerência de Projetos (evolução), Gerência deRecursos Humanos, Gerência de Reutilização,Definição do Processo Organizacional

1.1, 2.1, 2.2, 3.1,3.2

F Aquisição, Garantia da Qualidade, Gerência deConfiguração, Gerência de Portfólio de Projetos,Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

* Estes APs capacitam apenas um conjunto de processos selecionadopela organização de acordo com seus objetivos de melhoria. Os demaisAPs precisam capacitar todos os processos do nível pretendido.

Leituras Sugeridas

– SOFTEX; "Guias do MPS.BR (Guia Geral e Guias de Implementação do Modelo MPS-

SW)". Disponíveis em www.softex.br/mpsbr

– KALINOWSKI, M.; WEBER, K.C.; SANTOS, G.; FRANCO, N.; DUARTE, V.;

TRAVASSOS, G. “Software Process Improvement Results in Brazil Based on the MPS-

SW Model”. Software Quality Professional Journal, v. 14, no. 4, pp. 15-23, 2015.

– KALINOWSKI, M.; WEBER, K.C.; FRANCO, N.; BARROSO, E.; DUARTE, V.; ZANETTI,

D.; SANTOS, G. “Results of 10 Years of Software Process Improvement in Brazil

Based on the MPS-SW Model”. In: International Conference on the Quality of

Information and Communications Technology (QUATIC), 2014, Guimarães, Portugal.

– TRAVASSOS, G.H., KALINOWSKI, M. “iMPS 2013: Evidências Sobre o Desempenho

das Empresas que Adotaram o Modelo MPS-SW”. Campinas: SOFTEX, 2014 (ISBN:

978-85-99334-75-1), 102p.

785

Introdução à Engenharia de Software - Marcos Kalinowski

Documents

Transcript of Introdução à Engenharia de Software - Marcos Kalinowski