Universidade Federal do Paraná
Setor de Ciências Exatas
Departamento de Informática
ESPECIALIZAÇÃO EM INFORMÁTICA
Análise e Projeto de Sistemas
Setembrino Soares Ferreira Jr.
03 - Modelos para especificação de sistemas de
software
10/06/2010
03 - Modelos para especificação
1
Conteúdos
1. Considerações iniciais
1.1. Especificação
1.1.1. Tipos
1.1.2. Estágios
1.1.3. Verificação e validação
1.1.4. Qualidade x grau de formalidade
2. Modelos e princípios da E. S.
2.1. Um exemplo
10/06/2010
03 - Modelos para especificação
2
Conteúdos (cont.)
3. Modelos do mundo real
3.1. O modelo de função
3.2. O modelo de dados
3.3. O modelo comportamental
3.4. O modelo de objetos
3.5. O modelo formal
3.6. O modelo dinâmico
3.7. Dicionário de dados
10/06/2010
03 - Modelos para especificação
3
Conteúdos (cont.)
4. Modelos de projeto
4.1. Modelos para projeto geral
4.2. Modelos para projeto detalhado
5. Modelos para teste de programas
6. Modelos de planejamento do projeto
6.1. Modelos de custo
6.2. Modelos de programação de projetos
10/06/2010
03 - Modelos para especificação
4
Conteúdos (cont.)
7. Metodologias, métodos e ferramentas
7.1. Métodos estruturados
7.2. Métodos orientados a objetos
7.3. Métodos formais
8. Comentários finais
9. Exercícios
10/06/2010
03 - Modelos para especificação
5
1. Considerações iniciais
“Um modelo de sistema de software é uma representação
em miniatura de uma realidade complexa, que reflete
certas características específicas do sistema que está
sendo representado.”
(CARVALHO; CHIOSSI, 2001)

Modelos


Ferramentas úteis para representar especificações
Especificação - dois estágios / processos


Construção de modelos
Transmissão de mensagens entre grupos
10/06/2010
03 - Modelos para especificação
6
1. Considerações iniciais (cont.)
Objetivos do uso de modelos na especificação
das diferentes fases do desenvolvimento

Representar visão do ambiente antes da automação
 Indicar diferentes alternativas de solução
 Apontar necessidades futuras
 Permitir avaliação / refinamento de características
 Representar componentes como partes bem definidas
e com dependência mínima entre elas
 Permitir o trabalho gradual com a complexidade
 Fornecer informações quantitativas sobre escopo /
complexidade de um projeto

10/06/2010
03 - Modelos para especificação
7
1.1. Especificação

Desenvolver sistemas = obter e organizar dados


Volume  (dimensão + complexidade)
Princípios auxiliadores


Abstração - filtro dos aspectos relevantes a cada fase
Decomposição


10/06/2010
Reflexo das propriedades do sistema em suas partes
Paradigmas: decomposição em fases / associação de tarefas
03 - Modelos para especificação
8
1.1. Especificação

Especificação

Duas classes gerais de atores: produtor e consumidor

Atores e objetivos da especificação variáveis = f(contexto)
Especificação ...
 ... de requisitos: desenvolvedor + cliente
 ... de projeto geral: projetista + implementador
 ... de projeto detalhado (de módulos):
programadores implementadores + programadores
usuários
 => propósito: criar ponte de comunicação entre os
diversos tipos de pessoas envolvidas

10/06/2010
03 - Modelos para especificação
9
1.1.1. Tipos de especificação
Considerado o enfoque dado aos atributos do
sistema


Especificação operacional
Representa o comportamento desejado do sistema utilizando
modelos abstratos que, de alguma forma, simulem seu
comportamento
 Auxilia na verificação direta dos requisitos


Especificação descritiva
Busca declarar as propriedades desejadas do sistema de
forma puramente descritiva
 Representa as propriedades de maneira formal


Exemplo: trajetória de um satélite


10/06/2010
Especificação operacional: desenho de uma circunferência
Especificação descritiva: x2 + y2 + c = 0
03 - Modelos para especificação
10
1.1.2. Estágios da especificação
Após a fase inicial de extração e análise de
requisitos

Contrato entre cliente e desenvolvedor
 Documento: Declaração de objetivos e restrições do
projeto (DORP)



Antecede o Plano preliminar de projeto (detalhes adiante)
1o. Estágio: Especificação de requisitos

Com base nos objetivos da DORP
Descrição precisa e não ambígua do comportamento
desejado para o sistema (o que é esperado?)


Com base nas restrições da DORP

10/06/2010
Delimitações do sistema especificadas como propriedades
03 - Modelos para especificação
11
1.1.2. Estágios da especificação (cont.)

2o. Estágio: Especificação de projeto




Características operacionais
Estrutura do sistema
=> Como o sistema deve ser implementado
Mais detalhes que a E. R.


Dados, ações, controle e execução
Passos
Especificação do projeto geral (÷ sistema em subsistemas,
definir relações entre eles, ÷ subsistemas em módulos)
 Especificação do projeto detalhado (lógica dos módulos)
 Especificação das interfaces do sistema

10/06/2010
03 - Modelos para especificação
12
1.1.2. Estágios da especificação (cont.)

3o. Estágio: Especificação de programas
Deve garantir a correta tradução das decisões de
projeto
 Decisões inclusas: escolha de algoritmos


Outros estágios



Garantem a qualidade
Permitem o acompanhamento e controle do projeto
Exemplos


10/06/2010
Especificação de planos para o projeto
Especificação de testes
03 - Modelos para especificação
13
1.1.3. Verificação e validação

F(natureza das especificações)




Várias possibilidades de haver erros
Provável não traduzirem exatamente as necessidades
=> Todas devem ser verificadas
Pode ser necessário


Modificar especificações existentes
Incluir novas especificações
Podem ser utilizadas técnicas diferentes para a
validação em cada estágio

10/06/2010
03 - Modelos para especificação
14
1.1.4. Qualidade x grau de formalidade

Durante o desenvolvimento




Várias especificações
Cada uma em uma fase
Cada uma com um determinado fim
Dirigida a públicos diferentes


Projetista, implementador, usuário final, gerente, etc.
=> Propósitos diferentes
Especificação de requisitos: auxiliar usuário a entender suas
necessidades / validar produto final / tomar decisões de
projeto e conferir implementação (desenvolvedor)
 Especificação de projeto: avaliar impactos de modificações /
controlar e redirecionar recursos (gerente)

10/06/2010
03 - Modelos para especificação
15
1.1.4. Qualidade x grau de formal. (cont.)
Fatores que influenciam a qualidade das
especificações





Fatores dependem do grau de formalidade


Ambigüidade
Consistência
Omissão
F(criticidade de propriedades / componentes)
Formalismos muitas vezes são evitados
F(consumo de tempo, custo, dificuldade de
comunicação, falta de domínio de métodos formais,
necessidade de treinamento, etc.)

10/06/2010
03 - Modelos para especificação
16
2. Modelos e princípios da E. S.

Especificações devem seguir os princípios
Abstração: concentração nos aspectos importantes,
sem ater-se a detalhes não relevantes


Conceito geral dos modelos: top-down
Decomposição: divisão de problemas complexos em
menores, independentes, fáceis de entender e
solucionar; representação das relações entre partes

Técnicas descendentes / ascendentes; hierarquias de
programas / classes de objetos; modelagem em rede

Formalidade: modelos formais / semiformais
permitem




10/06/2010
Instituir controles para o desenvolvimento / qualidade
Comunicação mais eficiente
Representação precisa de interfaces entre estágios
03 - Modelos para especificação
17
2. Modelos e princípios da E. S. (cont.)

=> Modelos


Devem permitir alcance dos princípios
Boa prática para sistemas complexos

Modelo do mundo real (para E. R.)



Modelo de dados
Modelo de função
Modelo de comportamento do sistema
Modelo do projeto (para especificação do projeto)
 Modelo do plano de projeto (planejamento do
desenvolvimento)

10/06/2010
03 - Modelos para especificação
18
2.1. Um exemplo

Caso exemplo para especificação com modelos
Subsistema de consulta a bibliotecas de uma
universidade



Entrada: título e/ou autor
(título, autor) informado: pertencente ao acervo?
Sim: verificar a disponibilidade de exemplares / fornecer
localização
 Não: informar que (título, autor) não pertence ao acervo


título informado
Listar ocorrências do título no acervo (títulos iguais com
autores diferentes)


autor informado

10/06/2010
Listar todos os títulos daquele autor pertencentes ao acervo
03 - Modelos para especificação
19
3. Modelos do mundo real

Utilizados para representar sistemas



Representação da especificação de requisitos
Descrição da percepção do sistema a ser
construído
Foco em 3 características diferentes



O que o sistema faz
Que dados o sistema mantém
Como o sistema se comporta
Ilustração 
10/06/2010
03 - Modelos para especificação
20
3. Modelos do mundo real (cont.)
PERCEPÇÕES
FUNCIONAL
DE DADOS
COMPORTAMENTAL
Verificar acervo
Verificar
disponibilidade
Localizar exemplar
Bibliotecas
Exemplares
Títulos
Autores
Aguardando consulta
do usuário
Preparando resposta a
consulta
SISTEMA
Sistema de consulta a bibliotecas: Percepções do mundo real
10/06/2010
03 - Modelos para especificação
21
3.1. O modelo de função

Entende o sistema todo como uma função

Transformador de entradas em saídas

Diagrama de contexto (YOURDON, 1990):
relacionamento do sistema com interfaces externas
Interface
Entrada
SISTEMA
Saída
Interface
Modelo de contexto do sistema
10/06/2010
03 - Modelos para especificação
22
3.1. O modelo de função (cont.)

Decompõe o sistema identificando como
componentes suas principais funções



A função do sistema todo fica constituída por
um conjunto de subfunções conectadas
Cada subfunção é possivelmente formada por
outras subfunções conectadas
... Modelo funcional do sistema


Série de desenhos (rede)
Sucessivas divisões das partes que constituem
o sistema
10/06/2010
03 - Modelos para especificação
23
3.1. O modelo de função (cont.)
Sistema
Função 2
Conexão
Interface
Entrada
Conexão
Função 1
Função 4
Conexão
Saída
Interface
Conexão
Função 3
Modelo funcional: Decomposição
10/06/2010
03 - Modelos para especificação
24
3.1. O modelo de função (cont.)

O modelo de função pode ser considerado
completo quando

Descreve todo o sistema


Decompõe convenientemente o sistema






Mostra as transformações de todas as entradas em saídas
Todos os componentes não particionados são elementares
Cada componente do sistema está ligado
corretamente ao resto da rede
Nenhuma conexão necessária foi omitida
As conexões estão minimizadas
Cada conexão da rede está definida no dicionário de
dados
Todos os elementos que compõem cada conexão
estão definidos
10/06/2010
03 - Modelos para especificação
25
3.1. O modelo de função (cont.)

Diagramas de fluxo de dados – DFD
(DEMARCO, 1979)

Especificação semiformal de funcionalidades



Notação gráfica atrativa e fácil de usar
Descrevem um sistema como uma coleção de
dados manipulados por funções
Dados podem estar
Armazenados em depósitos de dados (estáticos)
 Contidos em fluxos de dados (conexões)
(dinâmicos)



10/06/2010
Fluindo de uma função para outra
Sendo transferidos para / do ambiente externo
03 - Modelos para especificação
26
3.1. O modelo de função (cont.)

DFD – Elementos básicos

Bolhas / cilindros: processos (funções)


Setas: fluxos de dados (conexões)


Meios por onde trafegam pacotes de dados
Caixas abertas: depósitos de dados


Transformadores(as) dos fluxos de dados
Armazenam dados entre processos
Caixas retangulares: entidades externas

10/06/2010
Origem ou destino de transações (/ dados
associados) do sistema
03 - Modelos para especificação
27
3.1. O modelo de função (cont.)

DFD – Exemplo
MR
Exemplares
MR
Disponibilidade
Títulos e Autores
Verifica(r)
disponibilidade
!
Exemplar
disponível
Informações
do acervo
Localiza(r)
exemplar
!
Verifica(r)
acervo
Mensagem 2
MR
Nome da
biblioteca
Título, Autor
Bibliotecas
! = dados de ...
Mensagem 1
Lista Título-Autor
10/06/2010
Usuário
03 - Modelos para especificação
Mensagem 1: Título e/ou autor não
pertence(m) ao acervo
Mensagem 2: Exemplar pertencente
ao acervo mas não disponível
28
3.1. O modelo de função (cont.)

DFD – Limitações




É necessária alguma experiência com o
sistema para poder deduzir certas
informações a partir da figura
O diagrama não especifica claramente como
as entradas são usadas para produzir as
saídas
Sincronização de componentes não
representada
É necessário o uso de um dicionário de dados
para a inclusão dos detalhes não
representados
10/06/2010
03 - Modelos para especificação
29
3.1. O modelo de função (cont.)

DFD – Considerações finais

O desenho pode ser feito com o auxílio de
ferramenta automatizada
Entradas de dicionário de dados são geradas
automaticamente
 Cabe ao desenvolvedor completar as entradas com
os detalhes não especificados

10/06/2010
03 - Modelos para especificação
30
3.2. O modelo de dados

Deve representar




Os dados que precisam ser armazenados
A melhor organização dos dados
O relacionamento entre grupos de dados
Como os dados serão utilizados
“É uma representação concisa dos
requisitos do sistema sob o ponto de vista
de dados”.
(ELMASRI; NAVATHE, 1994)
10/06/2010
03 - Modelos para especificação
31
3.2. O modelo de dados (cont.)

Dados armazenados



Descrevem “coisas” do mundo real
Possibilitam o atendimento dos requisitos
Relação entre dados dentro do sistema e
pessoas ou coisas fora do sistema


Gera uma espécie de mapa... Pista de como
se deve organizar os dados
Perseguir esta pista significa agrupar itens
associados à mesma entidade do mundo real
10/06/2010
03 - Modelos para especificação
32
3.2. O modelo de dados (cont.)

Ilustração
MUNDO REAL
Cliente
DENTRO DO SISTEMA
Entidade
Propriedade
Cliente:
nome
Relacionamento
endereço
cic
Alugar
Carro
Carro:
marca
cor
nº chassis
Abstração de dados
10/06/2010
03 - Modelos para especificação
33
3.2. O modelo de dados (cont.)

Abstração da entidade Cliente



Propriedades nome, endereço e cic dentro do
sistema
Boa desde que as informações sejam
necessárias e suficientes para representar um
cliente
Relacionamento entre entidades


Representa uma associação essencial ao
sistema
Relacionamento “Alugar”

10/06/2010
Associação entre as entidades “Cliente” e “Carro”
03 - Modelos para especificação
34
3.2. O modelo de dados (cont.)

Modelo entidade-relacionamento – MER
(ELMASRI; NAVATHE, 1994)


Modelo para a especificação dos dados
armazenados pelo sistema
Conceitos
Entidades
 Atributos
 Relacionamentos


Ferramenta gráfica

10/06/2010
Diagrama entidade-relacionamento – DER
03 - Modelos para especificação
35
3.2. O modelo de dados (cont.)

Diagrama entidade-relacionamento – DER:
notações




Retângulos: entidades sobre as quais o
sistema mantém dados
Elipses: atributos (propriedades) das
entidades
Losangos: relacionamentos entre entidades
Linhas: conexões das entidades com atributos
e/ou relacionamentos
10/06/2010
03 - Modelos para especificação
36
3.2. O modelo de dados (cont.)

DER: exemplo
Cliente
nome
10/06/2010
endereço
1
Alugar
cic
m
marca
03 - Modelos para especificação
Carro
cor
nº chassis
37
3.2. O modelo de dados (cont.)

DER exemplo representa

Duas entidades: Cliente e Carro
Cliente aluga carro
 Carro é alugado por cliente


Modelo entidade-relacionamento

Faz especificação descritiva! Apresenta
Propriedades (atributos) das entidades
 Relacionamentos com outras entidades
 Ainda outras características do mundo real



10/06/2010
Participação
Cardinalidade
03 - Modelos para especificação
38
3.2. O modelo de dados (cont.)

Participação (de entidades) em
relacionamentos

Parcial
Nem todos os elementos da entidade participam
 Notação: linha simples ligando a entidade ao
relacionamento
 Ex.: participação de carro no relacionamento
alugar (alguns carros podem não estar associados
a clientes)


Total

10/06/2010
Ex.: Cliente no relacionamento alugar (não
interessa ao sistema clientes que não aluguem
carro)
03 - Modelos para especificação
39
3.2. O modelo de dados (cont.)

Cardinalidade de um relacionamento


Quantidade de instâncias de uma entidade que se
relacionam com instâncias de outra entidade
Relacionamentos




Um para um (1:1)
Um para muitos (1:m)
Muitos para muitos (m:n)
Ex.: Relacionamento alugar


Um para muitos
Significado


10/06/2010
Um cliente pode alugar vários carros (ex.: empresas)
Cada carro pode estar alugado a apenas um cliente
03 - Modelos para especificação
40
3.2. O modelo de dados (cont.)

Limitações

Algumas características do mundo real
(propriedades de entidades) não podem ser
representadas


Ex.: formação do cic
=> notação semiformal
Sintaxe / semântica não precisas
 Necessidade


Comentários informais para completar o modelo
e/ou

10/06/2010
Utilização de um dicionário de dados para detalhar o
modelo
03 - Modelos para especificação
41
3.2. O modelo de dados (cont.)

DER subsistema de consulta a bibliotecas
Biblioteca
1
m
Conter
nº item
Exemplar
n
nome
estado
código
local
Possuir
Observações:
1) Entidade usuário não modelada:
sem interesse
2) Estado (exemplar): disponível,
emprestado, reservado para
disciplina
3) Relacionamentos permitem
verificar existência, disponibilidade
e localização de um título
10/06/2010
título
editora
1
autor
Acervo
data de publicação
edição
área
03 - Modelos para especificação
42
3.3. O modelo comportamental

Sistemas



Tendem a assumir vários estados
Cada estado se caracteriza por responder de
forma única a um determinado conjunto de
estímulos
Análise de estados de um sistema exige
enumerar


Possíveis estados
Eventos: condições e/ou ações que causam
mudança de estado
10/06/2010
03 - Modelos para especificação
43
3.3. O modelo comportamental (cont.)

Modelo de comportamento do sistema
representa


Estados
Eventos que alteram os estados

Condições e ações para mudanças de estados



10/06/2010
Se a condição para a ocorrência de um evento for
verdadeira, a ação correspondente será ativada
Ao longo da realização de determinada ação, o estado do
componente do sistema sendo alterado não é observável
Completada a ação, o componente passa ao estado
determinado pelo evento correspondente
03 - Modelos para especificação
44
3.3. O modelo comportamental (cont.)

Máquina de estados finitos – MEF (ALAGAR;
PERIYASAMI, 1998)

Inclui conceitos





Estados
Cadeias de dados de entrada (eventos)
Ferramenta gráfica para especificações semiformais
Utiliza um grafo para representar o comportamento
do sistema
Sistema descrito como


10/06/2010
Conjunto de estados que se alternam
Em conseqüência de algum evento modelado por dados de
entrada
03 - Modelos para especificação
45
3.3. O modelo comportamental (cont.)

Máquina de estados finitos – MEF:
notações


Elipses: estados
Setas: eventos que causam mudanças de
estados

Podem ser rotuladas para representar

Condições sobre eventos que ocasionam mudanças de
estados
e/ou

10/06/2010
Ações realizadas nas mudanças de estados
03 - Modelos para especificação
46
3.3. O modelo comportamental (cont.)

MEF: exemplo
Estado inicial: disparado por um
evento que não tem origem em outro
estado
Estado 1
Ação 1
(condição 1)
Evento 1
Estado 2
Ação 2
(condição 2)
Evento 2
Estado 3
Ação 3
(condição 3)
Evento 3
Estado 4
Ação 4
(condição 4)
Estado 5
10/06/2010
Evento 4
Estado final: nenhum evento parte
dele
03 - Modelos para especificação
47
3.3. O modelo comportamental (cont.)

MEF: títulos de uma biblioteca
registrar retirada
disponível
emprestado
registrar devolução
cancelar reserva
(final do semestre)
registrar reserva
(área disciplina =
área exemplar)
Observação:
Eventos são representados através de ações
e/ou condições (quando existirem)
reservado para
disciplina
10/06/2010
03 - Modelos para especificação
48
3.3. O modelo comportamental (cont.)

Traço de eventos


Outra ferramenta para modelar comportamento
Utilizado para representar cenários em sistemas
orientados a objetos


Cenários descrevem como o sistema trabalhará quando
estiver em operação
Notação simples



10/06/2010
Representa os objetos das classes envolvidas em um serviço
do sistema e as interfaces
Traço vertical: classes envolvidas no serviço
Traço horizontal: mensagens trocadas entre as classes
03 - Modelos para especificação
49
3.3. O modelo comportamental (cont.)

Traço de eventos: exemplo biblioteca

Localização de um exemplar


Entrada: (título, autor)
Resposta: nome da biblioteca onde disponível
Acervo
Exemplar
Biblioteca
título,
autor
verifica estado
procura nome
nome da biblioteca
nome da biblioteca
nome da
biblioteca
10/06/2010
03 - Modelos para especificação
50
3.4. O modelo de objetos



Utilizado para representar dados e
processamento; combina aspectos dos
modelos de função e de dados
(RUMBAUGH, 1991)
Permite ainda representar a composição e
a classificação de componentes (objetos)
Na fase de análise


Modelo não inclui detalhes de objetos
individuais
Trata de classes de objetos do mundo real
10/06/2010
03 - Modelos para especificação
51
3.4. O modelo de objetos (cont.)

Classe de objetos


Abstração sobre um conjunto de objetos que
possuem atributos e serviços (operações)
comuns
Modelo representa



Atributos e serviços das classes de objetos
Relacionamentos entre as classes
Utilização de serviços de um objeto por outro
10/06/2010
03 - Modelos para especificação
52
3.4. O modelo de objetos (cont.)

O modelo é usado para análise e projeto

Análise


Identificação de classes que representam o
domínio (coisas ou conceitos) do problema
Projeto
Adiciona informações sobre o domínio da solução
 Pode



10/06/2010
Redefinir e estender objetos da análise
Acrescentar objetos para representar
 Interfaces
 Controles
 Serviços de suporte
03 - Modelos para especificação
53
3.4. O modelo de objetos (cont.)


Utiliza diagrama de classes de objetos
para especificar o sistema
Notações para construção

Retângulo de cantos arredondados: classes de
objetos
Nome
Lista de atributos
Serviços
(operações)
10/06/2010
03 - Modelos para especificação
54
3.4. O modelo de objetos (cont.)

Diagrama de classes de objetos: Notações
para construção (cont.)

Linha (ligando classes)
Associações entre classes de objetos
 Indica haver troca de mensagens (objeto usa
serviços de outro)



Losango: composição de objetos de uma
classe (agregação)
Triângulo: classificação de objetos de uma
classe (generalização / especialização)
10/06/2010
03 - Modelos para especificação
55
3.4. O modelo de objetos (cont.)

Relações entre classes de objetos

Generalização / especialização
Serve para representar que uma classe de objetos
herda todos ou alguns atributos e serviços de uma
classe mais geral, além de poder conter seus
próprios atributos e serviços
 Classe mais geral: superclasse
 Especializações: subclasses


Agregação
Representa a composição de objetos
 Permite representar situações do mundo real em
que um objeto é composto de várias partes

10/06/2010
03 - Modelos para especificação
56
3.4. O modelo de objetos (cont.)

Generalização / especialização e agregação
pessoa
pessoa
empregado
aluno
cabeça
professor
10/06/2010
tronco
membro
funcionário
03 - Modelos para especificação
57
3.4. O modelo de objetos (cont.)

Serviços





Operações associadas aos objetos da classe
Permitem que o estado de um objeto de uma classe
possa ser modificado ou observado
São definidos para uma classe
Ficam disponíveis para cada objeto da classe
Associação entre classes


Permite um objeto obter um serviço de outra classe
Um objeto de uma classe pode enviar mensagens a
objetos de outra classe que possuam o serviço
desejado
10/06/2010
03 - Modelos para especificação
58
3.4. O modelo de objetos (cont.)

Associação entre classes
pessoa
Objetos da classe pessoa podem utilizar
serviços definidos para a classe faculdade:
- para um objeto da classe pessoa é
possível saber, por exemplo, o nome da faculdade;
- associação simples: um objeto da classe
pessoa requer um serviço da classe faculdade e
recebe como resultado no máximo um objeto.
faculdade
10/06/2010
Cada objeto da classe faculdade pode
utilizar serviços que envolvam vários objetos da
pessoa (ponto negro).
03 - Modelos para especificação
59
3.4. O modelo de objetos (cont.)
Acervo
Exemplar
Biblioteca
Título
Nº item
Nome
Data public.
Estado
Local
Editora
Unidade
Assunto
Autor
Verifica título
Verifica estado
Obtém nome
Verifica autor
Localiza item
Obtém local
Verifica disp.
Diagrama de classes de objetos para o sistema de bibliotecas
10/06/2010
03 - Modelos para especificação
60
3.5. O modelo formal



Modelos formais utilizam notações
matemáticas para especificar sistemas
Podem ser usados em qualquer estágio da
especificação
Rejeição!????!!!!!?!

Falta de destreza matemática para notações
formais
Utilização
 Compreensão

10/06/2010
03 - Modelos para especificação
61
3.5. O modelo formal (cont.)

Maioria dos modelos formais: lógica de
predicados

Predicado: expressão booleana
Resultado: verdadeiro ou falso
 Operadores convencionais (relacionais e lógicos)
 Qualificadores: permitem que um predicado seja
aplicado a um ou a todos os elementos de uma
coleção particular de valores

10/06/2010
03 - Modelos para especificação
62
3.5. O modelo formal (cont.)
Descrição
Símbolo Significado
Operadores relacionais <, >, =
≤, ≥, ≠
Operadores lógicos
۸, ۷, ~
Quantificadores
Є, /, 
Outros símbolos
Menor, maior, igual
...
E, ou, não
Existe, para todo
Pertence, tal que, então
Alguns símbolos utilizados em cálculo de
predicados
10/06/2010
03 - Modelos para especificação
63
3.5. O modelo formal (cont.)

Exemplo de uso

Especificar uma função em termos de pré e
pós-condições

Pré-condição



Pós-condição


10/06/2010
O que deve ser verdadeiro para que uma função seja
executada
Uma condição sobre os dados de entrada da função
O que deve ser verdadeiro quando uma função termina
sua execução
Condição sobre os dados resultantes da execução da
função
03 - Modelos para especificação
64
3.5. O modelo formal (cont.)

Exemplo de uso (cont.)

Em resumo

Pré e pós-condições



Predicados sobre entradas e saídas das funções
Operandos da expressão: parâmetros da função
Passos para a especificação formal de uma função
com o modelo de pré e pós-condições

Estabelecer restrições aos valores de entrada



10/06/2010
Domínio de valores; existência de elementos num conjunto que
possuam uma propriedade; uma propriedade desejada para
todos os elementos de um conjunto
Estabelecer restrições aos valores de saída (entrada)
Combinar os predicados em pré e pós-condições
03 - Modelos para especificação
65
3.6. O modelo dinâmico

Sistemas de software de tempo real




Altamente acoplados ao mundo externo
Executam ações em resposta a eventos externos
Escala de tempo ditada pelo mundo real
Necessário representar modificações do sistema
= f(t)

Percepções vistas não servem!



Modelos estáticos do mundo real
Aspectos de tempo relevantes => modelos dinâmicos
Especificação de sistemas de tempo real

Modelos estático e dinâmico
10/06/2010
03 - Modelos para especificação
66
3.6. O modelo dinâmico (cont.)

Modelo dinâmico


Especifica aspectos de mudança (movimentos) = f(t)
Deve considerar atributos dinâmicos










10/06/2010
Tratamento de interrupções
Mudança de contexto
Tempo de resposta
Taxa de transferência
Taxa de processamento de dados
Alocação de recursos
Manipulação de prioridades
Sincronização de tarefas
Comunicação entre tarefas
Etc.
03 - Modelos para especificação
67
3.6. O modelo dinâmico (cont.)

Modelo dinâmico (cont.)


Cada um dos atributos de desempenho deve
ser especificado
Para Pressman (1992), a análise de sistemas
de tempo real exige modelagem e simulação
que permitam avaliar se
Os elementos do sistema obterão a resposta
desejada
 Os recursos do sistema serão suficientes para
satisfazer os requisitos computacionais
 Os algoritmos de processamento serão executados
com velocidade suficiente

10/06/2010
03 - Modelos para especificação
68
3.6. O modelo dinâmico (cont.)

Modelos como DFD, MER e diagramas de
classes de objetos devem ser
complementados com


Modelos que consigam representar a
alteração dos estados de uma função, dado
ou objeto = f(t)
Modelos de comportamento
Máquinas de estado
 Traço de eventos

10/06/2010
03 - Modelos para especificação
69
3.7. Dicionário de dados


Utilizado para possibilitar o entendimento de
modelos formais e semiformais
Constituição




Conjunto de entradas (componentes dos modelos) em
ordem alfabética
Decomposição de componentes, caso possível
Descrições formais ou informais
Recomendação

Utilizar ferramenta automatizada para a confecção do
DD


10/06/2010
Grande número de entradas
Produtos gerados
03 - Modelos para especificação
70
3.7. Dicionário de dados (cont.)

Notações utilizadas para a descrição de
entradas






= é composto de
+e
() opcional
{} iteração
[//] seleção (uma das opções acontece)
* comentário
10/06/2010
03 - Modelos para especificação
71
3.7. Dicionário de dados (cont.)

Exemplo: sistema de bibliotecas –
descrição do depósito de dados
Exemplares
exemplares = {exemplar}
exemplar = n_item + estado + nome_título
estado = [emprestado / disponível / reservado_p_disc]
cod_biblioteca = String[2]
n_exemplar = Integer
nome_título = String[60]
10/06/2010
03 - Modelos para especificação
72
4. Modelos de projeto

Modelo de projeto


Representa a especificação do projeto
Deve traduzir
Especificação do sistema (representada com
modelos do mundo real)
 Arquiteturas de dados e módulos


Atividade também chamada de projeto geral
do sistema
10/06/2010
03 - Modelos para especificação
73
4.1. Modelos para projeto geral

Durante o projeto geral, especificar




Decomposição do sistema em subsistemas
Relações entre subsistemas
Decomposição de subsistemas em módulos
Diferentes modelos



Da arquitetura do sistema
De controle do sistema
Da arquitetura de módulos
10/06/2010
03 - Modelos para especificação
74
4.1. Modelos para projeto geral (cont.)

Modelo da arquitetura de sistema

Deve descrever



O sistema como um conjunto de componentes (subsistemas)
que fornecem um conjunto de serviços específicos
A comunicação entre componentes
Modelos mais específicos podem ser utilizados


Compartilhamento de dados
Distribuição dos dados



Modelo de dados centralizado / distribuído
Interfaces entre subsistemas
Exemplo de modelo: cliente-servidor

10/06/2010
Distribuição de dados e processamento entre processadores
03 - Modelos para especificação
75
4.1. Modelos para projeto geral (cont.)
Exemplo:
Arquitetura com base de dados centralizada
Subsistema consulta
Subsistema
catalogação
Base de dados da
universidade
Subsistema
aquisição
Subsistema
empréstimo
10/06/2010
03 - Modelos para especificação
76
4.1. Modelos para projeto geral (cont.)

Modelo de controle do sistema


Especifica as relações de controle entre as
partes do sistema
Duas abordagens utilizadas pelos modelos

Centralizado




Baseado em eventos

10/06/2010
Um subsistema é responsável pelo controle
Pode iniciar e parar outros subsistemas
Pode passar o controle a outro subsistema, mas aguarda
o retorno
Cada subsistema pode responder a eventos externos,
oriundos
 De outros subsistemas
 Do ambiente externo
03 - Modelos para especificação
77
4.1. Modelos para projeto geral (cont.)
Exemplo:
Modelo de controle centralizado
Também pode ser usado para representar:
Sistema de
bibliotecas da
universidade
- arquitetura de módulos;
- controle de funções;
- controle de objetos.
(Operações em objetos =
= procedimentos ou funções)
Subsistema
catalogação
10/06/2010
Subsistema
empréstimo
Subsistema consulta
03 - Modelos para especificação
Subsistema
aquisição
78
4.1. Modelos para projeto geral (cont.)

Modelo de arquitetura de módulos


Deve especificar a decomposição de cada subsistema em
módulos
Dois modelos de decomposição

Orientado a objetos


Funcional


Subsistemas decompostos em um conjunto de objetos que se
comunicam
Subsistemas decompostos em módulos funcionais que
 Recebem dados de entrada
 Transformam em dados de saída
Convenções utilizadas


Retângulos: módulos
Setas com cauda




10/06/2010
Vazia: troca de dados entre módulos
Preenchida: passagem de (dados de) controle entre módulos
Losango negro: decisão
Arco com seta: chamada iterativa
03 - Modelos para especificação
79
4.2. Modelos para projeto detalhado

Aprimoramento da representação
estrutural



Especificação de estruturas de dados
detalhadas
Representações algorítmicas dos módulos
Modelos consagrados


Àrvores / tabelas de decisão
Português estruturado / logicamente
compacto
10/06/2010
03 - Modelos para especificação
80
4.2. Modelos para projeto detalhado (cont.)

Exemplo 1: português estruturado
Módulo: localiza-exemplar;
Recebe: exemplar-disponível;
Usa: BD-biblioteca;
Produz: nome-biblioteca
Procedimento
Início;
código = exemplar-disponível[1]
+ exemplar-disponível[2];
nome-biblioteca = obtém-nome-biblioteca(código);
exibe-biblioteca(nome-biblioteca);
Fim
10/06/2010
03 - Modelos para especificação
81
4.2. Modelos para projeto detalhado (cont.)

Exemplo 2: tabela de decisão – especificação do
módulo verifica-acervo
Entradas
Regras
C1 – recebe autor
C2 – recebe título
1 2 3 4
V V F F
V F V F
Ações
10/06/2010
A1 – chama verifica-título-e-autor
A2 – chama verifica-autor
A3 – chama verifica-título
03 - Modelos para especificação
X
X
X
82
5. Modelos para teste de programas

Visam representar os programas abstraindo
apenas o que for de interesse para a fase de
testes



Visualização dos módulos de forma a



Unitário
De integração
Facilitar a detecção de erros
Permitir o projeto de casos de teste que cubram
diferentes tipos de erros com tempo e esforço mínimos
Modelos úteis para a fase de testes – construídos


Especificação de requisitos
Projeto
10/06/2010
03 - Modelos para especificação
83
5. Modelos para teste de programas (cont.)

Outro modelo bastante utilizado

Modelo de programa


Projeto detalhado do módulo
Grafo de programa
Programa (módulo) representado por seu grafo
 Notação



10/06/2010
Nó: um ou + comandos seqüenciais (exceto decisão /
iteração)
Arco: transferência de controle (ramo ou ponto de
decisão)
03 - Modelos para especificação
84
5. Modelos para teste de programas (cont.)

Exemplo: verifica-disponibilidade (proj. det.)
Módulo: verifica-disponibilidade;
Recebe: informações-do-acervo;
Procedimento:
(1)
início
(1)
consulta-exemplares(informações-do-acervo, lista-deexemplares, n-exemplares, flag);
(2)
se flag = “não-disponível”
(3)
então Exibe-mensagem-2 (informações-do-acervo)
(4)
senão
(5)
enquanto n-exemplares <> 0
(6)
início
(6)
localiza-exemplar(lista-de-exemplares(nexemplares));
(6)
n-exemplares = n-exemplares – 1;
(7)
fim
(7)
fim
10/06/2010
03 - Modelos para especificação
85
5. Modelos para teste de programas (cont.)

Exemplo: verifica-disponibilidade – grafo de programa
1
A especificação de casos de teste através
dos grafos de programa permite garantir
que todos os caminhos de um módulo
sejam exercitados pelo menos uma vez.
2
3
4
5
Caminho: coleção de arcos que vai do
primeiro ao último nó do grafo.
O número de caminhos (Np) é o número
máximo de casos de teste que deve ser
criado para se exercitar todos os
caminhos ao menos uma vez.
Caminhos do grafo:
6
7
10/06/2010
(1, 2, 3, 7), (1, 2, 4, 7), (1, 2,
4, 5, 7) e (1, 2, 4, 5, 6, 5, 7)
Np = 4
03 - Modelos para especificação
86
6. Modelos de planejamento do projeto

Modelos de planos estratégicos da empresa


Modelos de planejamento estabelecem



Guias para escolha de quais projetos têm maior
prioridade na verificação da real necessidade de
software a ser desenvolvido
Tática para o desenvolvimento
Esquema contábil para o controle do esforço do
desenvolvimento
Plano de desenvolvimento

Deve ser



Elaborado antes do início do projeto
Usado para controlar seu andamento
Não é estático

10/06/2010
Deve ser modificado ante novas informações
03 - Modelos para especificação
87
6.1. Modelos de custo

Oferecem previsão (LONDEIX, 1987)



Custo monetário


Estimado = f(m.o. total determinada pelo modelo)
Em geral, utilizam modelos matemáticos para
estimar



Do esforço (custo de mão-de-obra) necessário para o
ciclo de vida de um sistema
Do tempo de desenvolvimento
Esforço = f(tamanho do software)
Tempo = f(esforço, dada uma produtividade média)
Típicos


Putnam (PUTNAM, 1978)
Boehm (BOEHM, 1981)
10/06/2010
03 - Modelos para especificação
88
6.1. Modelos de custo (cont.)

O modelo de Putnam

Utiliza a curva de Rayleigh para estudar a
distribuição de m.o. = f(t)
M(t) = 2 K a t e
-at2
K: esforço total em pessoas-ano (pa)
 a: aceleração
 t: tempo em anos

1
a = ------2 Td2

10/06/2010
Td: tempo de desenvolvimento
03 - Modelos para especificação
89
6.1. Modelos de custo (cont.)

O modelo de Putnam (cont.)
N
º
d
e
p
es
so
as
Moc
Mo -> Pico de mão-de-obra
Td -> Tempo de desenvolvimento
Mob
Moa
c
Tdc
10/06/2010
Tdb
Tda
03 - Modelos para especificação
a
b
tempo
90
6.1. Modelos de custo (cont.)

O modelo de Putnam (cont.)

A equipe de projeto

Deve iniciar com um número de pessoas que deve crescer
até o final do desenvolvimento



Ser reduzido até o final do ciclo de vida do projeto



Operação
Manutenção
Observações

Maior a equipe, maior a aceleração, menor o tempo de
desenvolvimento


Pico de mão-de-obra Mo
Tempo Td (~ 40% da mão-de-obra total)
Há um limite
Oferece outras equações


10/06/2010
Cálculo do esforço = f[tamanho do sistema (LOC)]
Cálculo do pico de mão-de-obra (Mo)
03 - Modelos para especificação
91
6.1. Modelos de custo (cont.)

O modelo de Boehm

Três níveis de detalhes

Modelo básico


Modelo intermediário


Estima esforço e tempo com base em vários fatores do
produto, equipamento, pessoas e projeto
Modelo detalhado


10/06/2010
Equações para estimativas grosseiras de esforço e tempo
no início do projeto
Possibilita maior grau de precisão nas estimativas
A partir da decomposição do produto e do processo
03 - Modelos para especificação
92
6.1. Modelos de custo (cont.)

O modelo de Boehm (cont.)

Equações variam com a complexidade do
produto a desenvolver
Dos mais simples
 Aos mais sofisticados (softwares embutidos em
aparelhos eletrodomésticos)

10/06/2010
03 - Modelos para especificação
93
6.1. Modelos de custo (cont.)

O modelo de Boehm (cont.)

Equações do modelo básico
Produto simples
E = 2.4S1.05 Td =
2.5E0.38
Produto moderado E = 3.0S1.12 Td =
2.5E0.35
Produto complexo E = 3.6S1.20 Td =
2.5E0.32
S: tamanho estimado [KLOC]
 E: esforço estimado [pessoas-mês (pm)]
 Td: tempo de desenvolvimento estimado [meses]

- Modelos para especificação
Ex.: sistema 03
simples,
com S = 15 KLOC
10/06/2010

94
6.1. Modelos de custo (cont.)

Em geral

Os modelos de custo são compostos por um
conjunto de equações matemáticas para a
determinação
Do esforço total E
 Do tempo necessário para o desenvolvimento do
sistema (Td)
 De outras informações úteis para o planejamento e
controle do projeto


Os valores calculados pelas equações dos
modelos devem ser corrigidos com fatores
que, de alguma forma, tenham influência no
esforço estimado para o sistema
10/06/2010
03 - Modelos para especificação
95
6.2. Modelos de programação de projetos

Estimados o esforço e a duração de um projeto, com os
recursos humanos disponíveis é possível estabelecer a
organização das atividades do projeto



Decompor o produto e o processo
Estimar o tempo de cada atividade do processo para cada
componente do produto
Indicar atividades



Recorrer



Paralelas
Seqüenciais
Ao banco de dados de projetos concluídos
À experiência da pessoa que está planejando o sistema
Modelos mais utilizados


10/06/2010
Rede de processos (PERT / CPM)
Diagrama de barras (gráfico de Gantt)
03 - Modelos para especificação
96
6.2. Modelos de programação de projetos (cont.)

PERT / CPM (WIEST; LEVY, 1997)

Base




Atividades
Duração
Dependências
Diagrama representa




Rede de tarefas do início ao fim do projeto
Sincronização de atividades
Dependências entre atividades
Caminho crítico



10/06/2010
Seqüência de atividades que determinam a duração do projeto
Estimativa de duração das atividades
Limites de tempo para as atividades
03 - Modelos para especificação
97
6.2. Modelos de programação de projetos (cont.)

PERT / CPM (cont.)

Questões típicas tratadas
Qual o tempo mais cedo para terminar o projeto?
 Quais as atividades que influenciam para que o
projeto termine na data marcada?
 Qual a interdependência entre as atividades?
 Quais as atividades críticas?

10/06/2010
03 - Modelos para especificação
98
6.2. Modelos de programação de projetos (cont.)

PERT / CPM (cont.)

Diagrama – elementos básicos
1
1
TMC
duração
TMT
(folga)
2
TMC
TMT
evento inicial
TMC
TMT
2
TMC
TMT
evento final
atividade
10/06/2010
03 - Modelos para especificação
99
6.2. Modelos de programação de projetos (cont.)

PERT / CPM (cont.)

Diagrama – elementos básicos (cont.)


Evento: algo que ocorre e dispara uma atividade
TMC / TMT: tempos mais cedo / mais tarde de início da
atividade sem afetar o projeto





Para cada atividade, estimar duração e calcular folga



Quantidade de tempo que uma atividade não crítica pode
superar a duração estimada sem afetar o tempo previsto para o
projeto
Folga = TMT final – TMC inicial – duração
Atividades simuladas podem ser usadas para indicar / coibir
atividades paralelas (não consomem tempo nem recursos)

10/06/2010
TMC = máx. (TMC inicial + duração) para atividades entrantes
TMT = mín. (TMT final – duração) para atividades terminais
TMC = 0 para evento inicial
TMC = TMT para evento terminal
Representação: setas pontilhadas
03 - Modelos para especificação
100
6.2. Modelos de programação de projetos (cont.)

PERT / CPM (cont.)

Conceito bastante utilizado

Caminho crítico







10/06/2010
Caminho de maior duração entre os eventos inicial e final do projeto
Folgas
 Do caminho crítico: sempre iguais
 De outros caminhos >= folgas das atividades críticas
Enfoque principal do controle administrativo
Define atividades onde colocar recursos adicionais
 Encurtando o caminho crítico
 Permitindo o término antecipado do projeto
Folgas do caminho crítico
 >0: excesso de recursos ou prazo acima do necessário
 =0: prazos e recursos adequados
 <0: falta de recursos ou prazo para a conclusão do projeto
Pode haver mais de um caminho crítico em um projeto
 Caminho crítico alternativo
Representação
 Setas mais espessas (“negrito”)
03 - Modelos para especificação
101
6.2. Modelos de programação de projetos (cont.)

Diagrama de barras (ou gráfico de Gantt)


Também bastante utilizado para expor o
relacionamento entre recursos e tarefas
Para cada atividade, o diagrama indica




Responsável
Data prevista de início
Data prevista de término
Pode ser usado para controlar / acompanhar um
projeto


10/06/2010
Registrando os tempos estimados e gastos em cada tarefa
Acrescentando outro tipo de barra para representar as datas
de início e término das atividades
03 - Modelos para especificação
102
7. Metodologias, métodos e ferramentas

Organização do processo de software





Metodologias


Disciplinas utilizadas para produzir diferentes modelos de um
sistema
Métodos


Atividade crítica
Vai do gerenciamento de pessoas
Ao gerenciamento de todos os produtos gerados durante o ciclo
de vida do sistema
Envolve a definição de métodos, ferramentas e suas
combinações dentro de metodologias
Linhas gerais que governam a execução de alguma atividade,
utilizando abordagens rigorosas, sistemáticas e disciplinadas
Ferramentas

Dão suporte à aplicação


10/06/2010
Métodos
Metodologias
03 - Modelos para especificação
103
7. Metodologias, métodos e ferramentas (cont.)

Metodologia de desenvolvimento de software


Detalha as atividades do ciclo de vida
Especifica um conjunto único e coerente






Princípios
Métodos
Linguagem de representação
Procedimentos
Documentação
Permite ao desenvolvedor implementar, sem
ambigüidades

10/06/2010
Especificações advindas das fases do ciclo de vida do
software
03 - Modelos para especificação
104
7. Metodologias, métodos e ferramentas (cont.)

Modelagem de um sistema


Forma barata de estudar aspectos essenciais de um sistema antes de
sua construção
Para cobrir diferentes fases do desenvolvimento, uma metodologia
deve utilizar métodos e ferramentas que permitam conduzir

A fase de análise de requisitos


Especificação resultante = modelo significativo dos requisitos (modelo do
mundo real)
A fase de projeto


Para produzir o modelo interno do sistema
Necessidades





Mecanismos para traduzir a representação do domínio da informação numa
representação do projeto
Notação para representar componentes funcionais e interfaces
Heurísticas para refinamento e divisão em partições
Diretrizes para a avaliação da qualidade do projeto
O planejamento do projeto


Para produzir o plano de projeto (alternativas para a solução do problema,
riscos, decisões tomadas e estimativas de tempo, custo e recursos)
Necessidades



10/06/2010
Registrar as atividades envolvidas no desenvolvimento e sua seqüência
Registrar resultados a produzir
Metodologias a usar em cada fase do ciclo de vida do sistema
03 - Modelos para especificação
105
7. Metodologias, métodos e ferramentas (cont.)

Escolha da metodologia mais adequada






Domínio de métodos e ferramentas



À construção de um produto de boa qualidade
Aos interesses da organização
Ao ambiente de desenvolvimento
Ao tipo de software a ser desenvolvido
Responsabilidade: Gerente ou administrador do desenvolvimento
Permitam construir um produto de boa qualidade
Responsabilidade: desenvolvedor
Métodos principais (análise de requisitos + projeto)



Métodos estruturados
Métodos orientados a objetos
Métodos formais
10/06/2010
03 - Modelos para especificação
106
7.1. Métodos estruturados

Metodologias podem variar quanto ao enfoque
dado às características do mundo real

Enfoque funcional


Mais antigo e popular
Diversas metodologias



Exemplos


10/06/2010
Primeiras: puramente intuitivas
Generalização do conceito de implementação para funções de
nível mais alto
Análise estruturada (GANE; SARSON, 1982) (DEMARCO, 1979)
Metodologias mais atuais
 + (modelagem de dados, extensões para sistemas de
tempo real, comportamento do sistema)
 Análise estruturada moderna (YOURDON, 1990)
 Análise essencial (MCMENAMIN; PALMER, 1984)
 Metodologia de Ward e Mellor (1985)
03 - Modelos para especificação
107
7.1. Métodos estruturados (cont.)

Metodologias podem variar quanto ao
enfoque dado às características do mundo
real (cont.)

Enfoque na assistência ao analista
Na identificação dos principais objetos de
informação e operações
 Na representação da estrutura de informação de
forma hierárquica




10/06/2010
Apresentam um conjunto de passos que levam de uma
estrutura hierárquica de dados a uma estrutura de
programa
Jackson System Development (JSD) (JACKSON, 1983)
Data Structured System Development (DSSD)
(WARNIER, 1981)
03 - Modelos para especificação
108
7.1. Métodos estruturados (cont.)

Principal ferramenta de análise e projeto
estruturados (com enfoque funcional)



Diagrama de fluxo de dados (DFD)
Construído na fase de análise
Pode ter o projeto derivado a partir dele

Diagrama da hierarquia de módulos [diagrama da
estrutura de software (DES)]
(PAGE-JONES, 1980)
10/06/2010
03 - Modelos para especificação
109
7.2. Métodos orientados a objetos


Abordagem mais atual
Principal característica

Utilização de um mesmo modelo em diferentes fases
do desenvolvimento

Análise: identificação e definição de classes de objetos



Projeto: identificação e definição de classes de objetos
adicionais

10/06/2010
Domínio do problema
Responsabilidades do sistema
Domínio da solução – classes de objetos que representam
 Interfaces
 Controle de tarefas
 Suporte do sistema
03 - Modelos para especificação
110
7.2. Métodos orientados a objetos (cont.)

Ao contrário dos métodos estruturados

Resulta em projetos que interligam
Objetos de dados
 Operações de processamento (serviços ou
métodos)


Modulariza não só o processamento
Informação
 Processamento


Objeto encapsula sob o mesmo nome
Dados
 Operações
 Outros objetos

10/06/2010
03 - Modelos para especificação
111
7.2. Métodos orientados a objetos (cont.)

Metodologias mais conhecidas




Rumbaugh (1991)
Coad e Yourdon (1990)
Booch (1986)
Fusion (1984)
10/06/2010
03 - Modelos para especificação
112
7.2. Métodos orientados a objetos (cont.)

Ferramenta mais conhecida para análise e
projeto orientados a objetos

Diagrama de classes de objetos

Retrata objetos relevantes do sistema, a partir de




Atributos
Operações feitas sobre os objetos de uma classe
Relacionamentos entre objetos
Comportamento do sistema
Cenários
 Máquinas de estados


Aspectos funcionais

10/06/2010
Diagrama de fluxo de dados
03 - Modelos para especificação
113
7.2. Métodos orientados a objetos (cont.)

Na fase de projeto

Classes são atribuídas a componentes físicos de
programas (módulos)


Concepção de implementação da arquitetura de programa
Projeto detalhado

Alcançado detalhando-se




Interfaces
Estruturas de dados
Algoritmos
Fase de teste

Pode ser auxiliada pela construção de cenários


10/06/2010
Descrevem diferentes situações de comportamento
esperadas para o sistema
Tornam possível verificar quanto o software está de acordo
com os requisitos
03 - Modelos para especificação
114
7.3. Métodos formais

Compreendem um conjunto de atividades que
permitem

Desenvolvimento e verificação de sistemas de
software


Proporcionam a possibilidade de avaliar




A partir de notações matemáticas rigorosas
Consistência
Inteireza
Exatidão do modelo
Ambigüidades, inconsistências e omissões
descobertas mais facilmente


Não por revisão
Mediante a aplicação de análise matemática
10/06/2010
03 - Modelos para especificação
115
7.3. Métodos formais (cont.)

Na verificação de programas, facilitam



Descoberta
Correção de erros
Metodologias mais conhecidas



Vienna (VDM) (JONES, 1990)
Larch (GUTTAG; HORNING; WING, 1985)
Processos seqüenciais comunicantes (CSP)
(MOORE, 1990)
10/06/2010
03 - Modelos para especificação
116
7.3. Métodos formais (cont.)

Baseados nos conceitos (isolados ou
combinados)




Álgebra
Lógica
Teoria dos conjuntos e relações
Adoção

Maior possibilidade de uso se desenvolvedores
tiverem ferramentas automatizadas para
Especificação
 Verificação

10/06/2010
03 - Modelos para especificação
117
7.3. Métodos formais (cont.)

Especificação


Via linguagem formal
Elementos primários

Semântica


Sintaxe


Define a notação para a representação da especificação
Conjunto de relações


Auxilia na definição de um universo de objetos que será usado
para descrever o sistema
Definem as regras que determinam quais objetos satisfazem
adequadamente a especificação
Exemplos de linguagens formais (GEHANI;
MCGETTRICK, 1986)


10/06/2010
VDL
Z
03 - Modelos para especificação
118
7.3. Métodos formais (cont.)

Verificação

Ferramentas
Permitem que o desenvolvedor construa um
modelo de estado finito do sistema
 Verificam se as propriedades definidas via
linguagem formal de especificação se mantêm
para cada estado ou mudança de estado
 De manipulação algébrica trabalham diretamente
com a sintaxe e a semântica da linguagem de
especificação. Duas categorias



10/06/2010
Ferramentas de verificação de prova (Larch)
Manipuladores lógicos: LCF (GEHANI; MCGETTRICK,
1986)
03 - Modelos para especificação
119
8. Comentários finais

Modelos para especificação


Utilidade incontestável para todas as fases
Facilitam a comunicação entre os diferentes atores
que participam da construção do produto







Clientes
Usuários
Desenvolvedores
Especialistas
Etc.
Possibilitam o registro de informações de maneira
formal ou semiformal
Apoiados por ferramentas automatizadas têm suas
qualidades potencializadas
10/06/2010
03 - Modelos para especificação
120
9. Exercícios
1) Escreva as especificações operacional e descritiva da trajetória em pista
elíptica de um veículo de Fórmula Indy.
2) Considere um sistema de materiais de uma pequena indústria e os
subsistemas “cadastro de materiais” e “retirada de materiais”. Faça o
modelo de dados e o modelo de objetos dos subsistemas.
3) Desenhe um diagrama entidade-relacionamento que represente a matrícula
de um aluno em n disciplinas de um curso.
4) Usando uma máquina de estados, descreva um sistema de iluminação que
consiste de uma lâmpada e dois interruptores ligados em paralelo. Se a
lâmpada estiver apagada, apertando-se qualquer um dos interruptores, o
estado da lâmpada passará para acesa e vice-versa.
5) Descreva os módulos de trabalho envolvidos na construção de uma
residência e mostre como eles estão organizados seqüencial e
paralelamente.
6) Diferentes pessoas que interagem com aplicações de software podem
requerer diferentes abstrações. Comente brevemente que tipos de
abstrações são úteis para o usuário final, o projetista e o pessoal de
manutenção.
7) Desenvolva uma pesquisa sobre a linguagem Z.
10/06/2010
03 - Modelos para especificação
121