Laboratório de Programação Laboratório de Programação Projeto de Software – Eng. De Requisitos e

UML

George Cabral

Definindo o Sucesso do Software

Clientes satisfeitos

Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamentoO Sucesso começa comO Sucesso começa coma Gerência de Requisitos !!a Gerência de Requisitos !!

Como os Projetos podem ter sucesso?

Análise do Problema Entenda o problema

Obtenha concordância dos envolvidos Levantamento dos Requisitos

Identifique quem usará o sistema (atores) Descubra como o sistema será usado (casos de uso)

Gerência de Requisitos Especifique os requisitos completamente Gerencie expectativas, mudanças e erros Controle o aumento do escopo Defina a equipe e a mantenha informada

Fatores de Falha dos Projetos

Objetivos não estavam clarosObjetivos não estavam claros IIgnorar um grupo de clientes

OOmitir um grupo de requisitos

PPermitir inconsistências entre grupos de requisitos

AAceitar um requisito ambíguo e inconsistente

Requisitos e especificações incompletosRequisitos e especificações incompletos

Requisitos e especificações instáveis (mudanças)Requisitos e especificações instáveis (mudanças)

AAceitar requisito inadequado, incorreto, indefinido, ou impreciso

Mas o que são Requisitos?

Os requisitos de um sistema de computação constituem uma especificação das características e propriedades do sistema ou

Uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como das suas restrições de operação.

É importante ressaltar que os requisitos descrevem "o que o sistema deve fazer"- e também "o que ele não deve fazer"- sem dizer "o como fazer".

Requisitos e Especificação

Requisito (IEEE) Uma condição ou capacidade necessitada por um usuário

para resolver um problema ou alcançar um objetivo Uma condição ou capacidade que deve ser satisfeita por

um sistema para satisfazer um contrato ou um padrão Especificação:

descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar

processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida

Importância da Especificação Correta

Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor

Análise de Requisitos

Entendimentodo domínio

Coleta derequisitos

Classificação

Definição eespecificaçãode requisitos

Resoluçãode conflito

Atrib. Prioridade

Validaçãodos requisitos

Entrada doprocesso

Documentode requisitos

1

2

3

4

5

6

7 8

Entendimento do Domínio

Desenvolver sistemas envolve domínios além de software e hardware

Podemos ter que entender sobre Contabilidade Saúde Supermercados Mercado Etc.

Coleta de Requisitos

A coleta de requisitos é feita através de técnicas

Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados

Resulta em documento preliminar (draft)

Classificação dos Requisitos

Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias bem-definidos

Por exemplo Requisitos Funcionais: descrevem o

comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema.

Requisitos não funcionais: expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc.

Problema da Análise de Requisitos

Stakeholders em geral não sabem o que querem

Stakeholders expressam requisitos em sua terminologia

Stakeholders diferentes podem gerar requisitos conflitantes

Problema da Análise de Requisitos

Fatores políticos e organizacionais podem influenciar os requisitos do sistema

Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho muda

Resolução de Conflitos

É normal que ocorram requisitos conflitantes

Por exemplo R-23: O sistema deve ... R-45: O sistema não deve ...

Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades)

Atribuição de Prioridade

Alguns requisitos são mais urgentes que outros

É essencial determinar a prioridade dos requisitos junto ao cliente

Requisitos de maior prioridade são considerados em primeiro lugar

Prioridade

Requisitos podem ser vistos em três classes distintas Essenciais Importantes Desejáveis

Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis

Exemplo de Prioridade [RF001] Consulta X ao B.D. deve

retornar dados A, B, C Prioridade: Essencial

[RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y Prioridade: Importante

[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados Prioridade: Desejável

Validação dos Requisitos

Será que realmente entendi o que o cliente deseja?

Devo me certificar de que não houve falha em nossa interação (comunicação)

Há diversas técnicas de validação

Validação de Requisitos

Demonstrar que os requisitos definem o sistema que o cliente realmente deseja

Custos com erros de requisitos são altos Consertar um erro de requisitos após

entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação

Técnicas de Validação de Requisitos

Revisões de Requisitos Análise manual sistemática dos requisitos

Prototipação Uso de modelo executável do sistema para

avaliar requisitos

Geração de Casos de Teste Desenvolver testes específicos para os

requisitos para avaliá-los

Gerenciamento de Requisitos

Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante O processo da engenharia de

requisitos E desenvolvimento do sistema

Gerenciamento de Requisitos Requisitos são inevitavelmente

incompletos e inconsistentes 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

Responsável por dependências entre requisitos, suas origens e projeto do sistema

Rastreamento de Origem Associação entre requisitos e

stakeholders que propuseram tais requisitos

Rastreamento

Rastreamento de Requisitos Associação entre requisitos dependentes

Rastreamento de Projeto Associação dos requisitos com o projeto

Usar hipertexto ou referência cruzada Ou matriz de rastreamento

Estrutura de um Documento de Requisitos 1. Introdução 2. Definição dos Requisitos do Usuário 3. Especificação dos Requisitos do Sistema 4. Arquitetura do Sistema 5. Modelos do Sistema 6. Evolução do Sistema 7. Apêndices 8. Índice

Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 1. Introdução

1.1 Propósito do documento 1.2 Escopo do sistema 1.3 Glossário, acrônimos e

abreviaturas 1.4 Referências 1.5 Descrição do resto do documento

Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 2. Descrição geral

2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos usuários 2.4 Restrições gerais 2.5 dependências

Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 3. Requisitos específicos

requisitos funcionais, não-funcionais, GUI com o usuário:

funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ...

Documento de Requisitos 4. Arquitetura do Sistema 5. Modelos do Sistema

Diagrama de Atores Modelo de Caso de Uso Modelo de Análise Modelo de Projeto Diagrama de Pacotes

6. Evolução do Sistema (Futuro) 7. Apêndices 8. Índice

Abreviações e GlossárioAbreviação Significado Explicação / Condição ou situação no sistema

A Administrador Usuário com maiores privilégios no sistema

AT Auto-treinamento Um dos três perfis de avaliação. O operador/treinando solicita ao sistema uma avaliação que lhe é montada de modo randômico a partir de alguns parâmetros

CT Certificação Técnica Um dos três perfis de avaliação. Os supervisores (RL/RS) agendam com antecedência dia e hora da avaliação. É o teste que certifica o treinando/operador.

O Operador Usuário. Treinando que realiza as avaliações.

RL Responsável Local Usuário. Responsável, na unidade da empresa, por um grupo de operadores. Propõe, elimina e valida questões e avaliações.

RS Responsável Setorial Usuário. Responsável por um setor da empresa. Coordena um ou mais RL. Propõe, elimina e valida questões e avaliações.

TO Treinamento Orientado

Um dos três perfis de avaliação. Serve para os RS/RL diagnosticarem o estágio da aprendizagem dos operadores.

V Validador Usuário. Checa e valida as questões propostas pelos RS/RL.

M Módulo Refere-se aos módulos do sistema.

Backup Refere-se à cópia de dados de um dispositivo para o outro com o objetivo de posteriormente os recuperar (os dados), caso haja algum problema.

Logon É a ação necessária para acessar um sistema computacional restrito inserindo uma identificação, podendo esta ser ou não única para cada usuário, e a senha relacionada a ela. Uma vez logado, o usuário passa a ser identificado no sistema, sendo restringido ou permitido a acessar recursos do sistema.

UML

O que é um modelo?

Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.

Um modelo é uma simplificação da realidade.

Um modelo pode ser estrutural ou comportamental.

O que é um modelo?

O que é um modelo?

Por que modelar software?

Ajuda a ter uma visão geral do sistema

Permite especificar a estrutura e o comportamento do sistema

Proporciona um guia para a construção do sistema

Documenta as decisões tomadas

O que é a UML?

Unified Modeling Language (UML) é...

... uma linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de software.

... resultado da unificação das notações utilizadas nos métodos Booch, OMT (Object Modeling Technique) e OOSE (Object-Oriented Software Engineering).

... adotada por grande parte da indústria de software e por fornecedores de ferramentas CASE como linguagem padrão de modelagem.

… utilizada com qualquer processo de desenvolvimento já que é independente dele.

A UML é uma Linguagem para Visualização

No processo de desenvolvimento de sistemas de software, é quase impossível a visualização de toda a estrutura de um sistema sem o uso de modelos que a represente.

A UML fornece os símbolos gráficos para a representação de artefatos de software.

Por trás de cada símbolo empregado na notação da UML, existe uma sintaxe e uma semântica bem-definidas.

Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu modelo, diminuindo a ambigüidade em sua interpretação.

A UML é uma Linguagem para Construção

Os modelos de UML podem ser diretamente ”traduzidos” para várias linguagens de programação.

Isso significa que é possível mapear os modelos da UML para linguagens de programação tais como, Java, C++ e Visual Basic.

Esse mapeamento permite a realização de uma engenharia de produção: geração de código a partir de um modelo em UML.

O processo inverso, a engenharia reversa, também é possível, com a reconstrução de um modelo a partir de sua implementação.

A UML é uma Linguagem para Documentação

Diagrama de Seqüência

: SIM : AnalisadorMatricula

2: adicionar(a,d )

1: submeterFormulario(f)0..*

1 autor

0..*

0..*

1 dono

0..* 1

usuario

0..*

usaUsuarioBlog

-email:String

+notificarExclusao:void

Conteudo

-dtCriacao:Date-texto:String-autor:UsuarioBlog

+Conteudo+exibirConteudo:void

Blog

-dtCriacao:Date-titulo:String-dono:UsuarioBlog-conteudos:Vector

+criarNota:void+exibirConteudo:void+comentar:void+lerComentarios:Vector+removerConteudo:void+lerNotas:Vector+Blog

Nota

-comentarios:Vector-attribute1:int

+comentar:void+lerComentarios:Vector+finalize:void

Comentario

+finalize:void

Diagrama de Classes

Diagrama de Casos de Uso

blogSystem

Criar Comentario

Ler Conteudo

Remover Conteudo Remover Nota

Remover Comentario

Criar Blog

Ler Comentario

Ler Nota

Criar Nota

Usuario

Dono do blog

<<include>> <<include>>

<<include>>

…

Cada modelo criado é um artefato do software

Uma linguagem de diagramas

Diagramas de Classe

Diagramas de Colaboração

Diagramas de Seqüência

Diagramas de Estado

Diagramas de Atividade

Diagramas de Objetos

Diagrama de Deployment

Diagramas de Componentes

Diagrama de Casos de Uso

Modelos

Ponto de Vista Estático

Ponto de Vista Dinâmico

Casos de Uso

Este caso de uso é responsável por autenticar um usuário do sistema.

Pré-condição: nenhumaPós-condição: um usuário válido é logado e sua sessão é registrada no sistema.

Fluxo de eventos principal1. O cliente informa login e senha.2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).3. O sistema registra o início de uma sessão de uso.

Fluxos secundários- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

Este caso de uso é responsável por autenticar um usuário do sistema.

Pré-condição: nenhumaPós-condição: um usuário válido é logado e sua sessão é registrada no sistema.

Fluxo de eventos principal1. O cliente informa login e senha.2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).3. O sistema registra o início de uma sessão de uso.

Fluxos secundários- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

Descrição Narrativa

Diagrama de Casos de Uso

Estudante

Secretária

<<estende>> Solicitar histórico dosemestre atual

Solicitar histórico detodos os semestres

Solicitarhistórico

<<estende>>

Verificardependências

Matricularaluno

<<inclui>>Sistema de controlede pré-requisitos

Diagrama de Classes

+confirmar()+cancelar()-calcularTotal():CurrencygerarNovoCodigo: String

-codigo: Integer-dataRecebido-total: Currency

Pedido

#creditoPermitido: Currency#nivelCredibilidade()

-nome: String-endereco: String-dataPrimeiraCompra: Date-dataUltimaCompra: Date-totalComprado: Currency

Cliente

-quantidade: Integer-preco: Currency-emEstoque: Boolean

Item de Pedido

nomeContato: Stringtelefones[1..10]: StringCGC: StringFAX[1..3]: String

Cliente pessoa-jurídica

colocarListaNegra()

nome: StringCPF: StringnumCartaoCredito

Cliente pessoa-física

Empregado

Produto

* representantede vendas *

IPessoa

itens

0..*1 faz

Diagrama de Objetos

p2: Professormatricula: "205-6712-09"nome: "Jaelson Castro"

p1: Professor

codCurso: "IF291"descrição: "MPS"codTurma: I7

: Curso

codCurso: "IF185"descrição: "AER"codTurma: I6

: Curso

matricula: "219846534"nome: "Nelson Mandella"

:aluno

matricula: "562746134"nome: "John Major"

:aluno

: Aluno

: Aluno

: Aluno

: Aluno

c1: Curso

c2: Curso

c3: Curso

Bill

: Aluno: Aluno

Lewinsky

-matrícula: String

-nome: String

Professor

-codDisciplina: String

-descrição: String

-codTurma: String

Curso

-matrícula: String

-nome: String

-período: Integer

Aluno

[0..10]

ministra

[1..5]

*

[1..3]

Diagrama de Sequência

: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas

efetuarLogin(login, senha)

efetuarLogin(login, senha)

existeConta(login, senha)

registraSessao(login)

Diagrama de Colaboração

Janela de entradade pedido

p: Pedido

: ItemPedido :ItemEs toque

:ItemRenov Es toque:ItemEntrega

1: preparar( )

1.1: *[para c ada item do pedido] preparar( )

1.1.1 : emEs toque := v erif ic ar( )1.1.2 : [emEs toque] remov er( )

1.1.2.1: es toqueBaix o := v erif ic Es toqueBaixo( )

1.1.2.2 [es toqueBaix o] <<c riar>>

1.1.3 : [emEstoque] <<c riar>>

Diagrama de Estados

Ocioso

Manutenção

fazerManutenção

Validando

Selecionando Processando

Imprimindo

[continuar]

[não continuar]

H

entry / lerCartão exit / ejetarCartão

cartãoInserido

cancelar

Ativo

Diagrama de atividades

Procurar bebida

[achou café]

H

PessoaH

[sem café] [sem Coca]

[achou Coca]

Pegar latade Coca

Beber

Adicionar água àmáquina

Colocar caféno filtro

Colocar filtrona máquina

Ligar máquina

Filtrar café

Pegarxícara

Colocar café naxícara

Diagrama de Componentes

FormCadastro.html

Cadastro.exe

Principal.html

FormEntrada.html

Autenticacao.exe

<<link>>

<<link>>Banco

Usuários

Senhas

Diagrama de Implantação

servidorWeb

Autenticação.exe

Cadastro.exe

servidorDeArquivos

FormCadastro.html

Principal.html

FormEntrada.html

servidorBancoDeDados

SGBD

O SGBD a serutilizado aindanão foi escolhido.

PC - G309

NestscapeCommunicator

5.0

Atores: Especialização

É possível definir tipos gerais de atores e especializá-los usando o relacionamento de especialização

Cliente

ClienteEspecial

The Unified Modelling Language User Guide (Grady Booch)

The Unified Modelling Language Reference Manual (James Rumbaugh)

The Unified Software Development Process (Ivar Jacobson)

UML Distilled (Martin Fowler)

Bibliografia