Aula 11
Modelagem da arquitetura
Alessandro Garcia
Danyllo Albuquerque
LES/DI/PUC-Rio
Março 2014
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
1
Especificação
• Objetivos dessa aula
– Apresentar principios de modelagem do sistema (requisitos,
módulos, arquitetura, conceitual e física)
• Referência básica:
– Capítulo 10
– Seção 8.3
– Capítulo 9.4
– Apêndice 2
• Slides adaptados de: Staa, A.v. Notas de Aula em Programação
Modular; 2008.
• Referência complementar
– Silva, R.P.; UML2 em Modelagem Orientada a Objetos; Florianópolis, SC: Visual
Books; 2007
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
2
Sumário
• Requistos
• Arquitetura de Sistema
• Modelo conceitual
• Linguagem de representação gráfica para modelos físicos
• Modelo físico
• Exemplos
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
3
Requisito
• O que é um REQUISITO?
– Em software: “É a CARACTERIZAÇÃO do que
o sistema deverá fazer.”
• Existem vários tipos de requisitos que devem
ser analisados…
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
4
Motivação
• Segundo Brooks*, a ER é a parte mais difícil da
construção de um software.
• Nenhuma outra parte do desenvolvimento causa
tantos danos se feita de forma errada.
• Nenhuma outra
corrigida.
parte é tão difícil
de
ser
*F. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, vol 20(4):10-19, april,1987.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
5
Determina o sucesso…
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
6
Ou o fracasso…
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
7
Um pouco de humor…
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
8
Requisitos - Perspectiva Tecnológica
• Existem vários mecanismos de especificação:
– Linguagem natural;
– UML;
– Prototipação;
– Métodos formais, etc.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
9
Tipos de requisitos
Funcionais - O que o sistema faz para satisfazer as
necessidades de seu usuário.
Não Funcionais - Atributos de qualidade que um
sistema deve possuir para satisfazer as necessidades de
seu usuário.
Restrições - Requisitos globais que o sistema deve
satisfazer, que servem para verificar a correção e a
adequação dos demais requisitos ( devem ser definidos
no início do processo de levantamento de requisitos ).
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
10
Tipos de requisitos - Exemplo
Funcionais
O elevador deve monitorar as chamadas dos passageiros em cada andar
Não Funcionais
O elevador não deve deslocar mais do que 500 kg de carga
Restrições
O Elevador deve minimizar seu custo de funcionamento
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
11
Exemplos de requisitos não funcionais
•Usabilidade (facilidade de uso pelos usuários)
•Confiança ( frequência e resistência a falhas, capacidade de
recuperação, predibilidade, precisão )
•Desempenho (capacidade, taxas em relação ao tempo, de precisão:
velocidade, disponibilidade, tempo de resposta, uso de memória )
•Suporte ( capacidade manter o sistema atualizado, em termos de
testes, manutenção, versões )
•Aparência ( estética, visual, design gráfico )
•Operacional ( o ambiente no qual será usado; ambiente operacional,
condições do usuário, sistemas relacionados)
•Segurança ( confidencialidade, integridade, disponibilidade )
•Cultura e Política ( costumes, preferências, hábitos dos usuários )
•Legal ( leis, regulamentações, normas existentes )
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
12
Jogo de Xadrez?
• Requisitos Funcionais / Não-Funcionais– Como Seria?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
13
Jogo de Xadrez - RF
• Criar Tabuleiro - Cria um tabuleiro para o jogo de xadrez,
este tabuleiro é estruturado como uma lista de listas com
um total de 64 posições onde cada uma possui sua
respectiva lista de ameaçantes, lista de ameaçados, o tipo e
a cor de suas peças.
• Inserir Peça - Uma função que insere uma determinada
peca de tipo e cor especificadas pelo usuário em uma
determinada posição do tabuleiro.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
14
Jogo de Xadrez - RF
• Mover Peça - Move uma peça de uma posição para outra,
seguindo as regras para movimentação de cada peça. Existe
um cuidado em movimentar peças para posições já
ocupadas, se as peças que ocupam a posição de destino
forem de cor diferente da peça que será movida, pode
ocorrer uma captura.
• Retirar Peça - Retira uma peça do tabuleiro a partir de uma
posição especificada pelo usuário.
• Obter Peça - Informa o tipo e a cor da peça de uma
determinada posição, seguindo as mesmas regras de tipo de
peça e cores válidas.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
15
Jogo de Xadrez - RF
• Obter Lista Ameaçante - Retorna para o usuário a lista de
ameaçantes de uma determinada casa (posição) no
tabuleiro.
• Obter Lista Ameaçados - Retorna para o usuário a lista de
ameaçados de uma determinada casa (posição) no
tabuleiro.
• Destruir Tabuleiro - Desaloca os espaços que foram
utilizados pelo programa para que não haja vazamento de
memória.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
16
Jogo de Xadrez - RF
• Devemos agrupar os requisitos do sistema de acordo com
os interesses das funcionalidades.
• A partir desta reunião dos RF podemos constituir os
módulos do sistema.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
17
Jogo de Xadrez - RNF
• Robustez - Os dados de entrada serão validados, evitando
algumas situações de exceção, tal como o uso de
coordenadas inválidas ou peças com denominações
inválidas. No caso disto ocorrer aparece uma mensagem de
erro, permitindo nova entrada, sem interromper todo o
programa.
• Corretude - O uso do arcabouço de testes automáticos
permite o teste de uma série de condições normais de uso,
assim como condições de exceção, com o objetivo de testar
a corretude de várias partes do programa . Adicionalmente,
sempre é testado se existe memória suficiente para a
alocação das estruturas.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
18
Jogo de Xadrez - RNF
• Reutilização - O aplicativo será feito em módulos, com
interfaces bem definidas. Isto permite que os módulos
possam ser posteriormente reutilizados. Um módulo de lista
genérico por exemplo pode ser reutilizado por outros
aplicativos.
• Manutebilidade - O uso de um programa em módulos facilita
a manutenção do aplicativo, pois geralmente fica fácil
determinar em que módulo está o erro, e o problema de
correção fica menor.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
19
Diagrama de módulos (componentes)
• Conjunto de módulos (componentes) de software e suas
relações estruturais
• Definição lógica e independente de tecnologia
• Especificação de interfaces providas e requeridas
• Relações estruturais:
– associações entre interfaces: composição entre módulos
• Dependências entre:
– diferentes módulos
– módulos e suas interfaces, e
– entre interfaces
• Omissão de detalhes de implementação:
– ex. funções internas/auxiliares, estruturas de dados, etc...
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
20
Modelo de Componentes
IGet
Information
IRaising
Exception
IUpdate
Information
IInvocation
Handler
ICooperation
get and update
get
Concurrent
Exception
Handling
Action
get and update
invoke
handler
search
handler
arquivo *.c
Exception
Handling
Strategy
ISearch
arquivo *.h
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
21
Visão Expandida das Interfaces
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
22
Arquitetura de software - Definição
Representa a estrutura estática e comportamental de
um sistema, compreendendo os serviços do sistema,
realizados pelos componentes de software, que rodam
nos processadores disponíveis
Está associada a detalhes internos do software
na medida que esses detalhes manifestam-se
externamente
Não pode ser representada por um simples
diagrama: é multifacetada
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
23
Envolve os seguintes aspectos…
•Composição / Decomposição do Sistema ( Subsistemas / Módulos )
•Componentes e a Interação entre eles
•Níveis / Camadas e a Interação entre eles ( Ordem / Estrutura )
•Organização das partes físicas do software a serem implementadas
•Restrições do software ( naturais ou auto-impostas )
•Descrição geral do software
•Estrutura Estática / Dinâmica de um Sistema
•Estilo que orienta o desenvolvimento e a evolução do software
•Funcionalidade do software
•Outras considerações : reuso, desempenho, escalabilidade
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
24
Requisitos Vs Codigo
• A arquitetura do software desempenha
tipicamente um papel chave como uma ponte
entre requisitos e código.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
25
Uma visão profissional…
Descrição explícita de requisitos funcionais e não-funcionais
Documentação das decisões de
projeto
Requisitos
Boas práticas de
projeto modular
Decisões relacionadas
as estratégias
organizacionais e do
implementar primeiro
Arquitetura
Código
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
26
Todo sistema tem arquitetura?
Todo sistema já criado
tem sua Arquitetura !!!
Ela existe independente do
seu conhecimento pelo
projetista de sistemas
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
27
Por quê usar arquitetura ?
1. Uma abordagem adhoc leva a sistemas difíceis de
mudar ou adaptar
2. Decomposição de sistemas em partes menores
torna o software mais fácil de entender,
administrar, desenvolver, manter
3. Auxilia
no
componentes
4. Auxilia desde
desempenho
desenvolvimento
o
início
na
baseado
administração
em
do
5. Leva a um reuso melhor
6. Influencia a segurança, a testabilidade,
manutenibilidade e a administração do sistema
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
a
28
Em resumo...
• Arquitetura é um conjunto dos módulos essenciais de um
sistema, suas interfaces, e as interdependências entre estes
– devendo satisfazer requisitos funcionais e não-funcionais
• Como representar a arquitetura de sistemas?
– com modelos (representação visual)
• arquitetura poderia ser representada com um simples diagrama de
retângulos e linhas, mas não permite representar interfaces
• Para modelos conceituais da arquitetura, utilizaremos
diagramas da linguagem UML
– arquitetura de software é o conjunto de módulos
(componentes), interfaces, e relacionamentos entre estes
módulos
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
29
Jogo de Xadrez?
• Modelagem da Arquitetura – Como Seria?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
30
Jogo de Xadrez - Arquitetura
• Modelagem da Arquitetura – Como Seria?
?
?
?
?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
31
Jogo de Xadrez - Arquitetura
• Modelagem da Arquitetura – Como Seria?
LISTA
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
32
Jogo de Xadrez - Arquitetura
• Modelagem da Arquitetura – Como Seria?
?
?
Quais funções em cada
módulo e interface?
?
?
?
LISTA
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
33
Jogo de Xadrez - Arquitetura
• Modelagem da Arquitetura – Visão das Interfaces
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
34
Como criar o modelo da arquitetura?
• Identifique nos requisitos os módulos do sistema
– São as abstrações principais
– São usualmente ‘substantivos’ nos requisitos:
• Xadrez: Tabuleiro, Peça, Jogo/Xadrez, Jogador, etc…
• Free Cell: Colunas_Livres, Colunas_Ordenadas, Baralho,
Embaralhamento, etc…
• Identificação das funções das interfaces
– São usualmente ‘verbos’:
• Xadrez: criar tabuleiro, destruir tabuleiro, inserir peça na casa,
mover peça de casas, retirar peça da casa,….
obter cor da peça, obter status da peça, etc…
• Alocação de cada função para cada interface dos módulos
– Como descrobrir qual é a alocação mais apropriada?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
35
Como criar o modelo da arquitetura?
• Identifique nos requisitos os módulos do sistema
– São as abstrações principais
– São usualmente ‘substantivos’ nos requisitos:
• Xadrez: Tabuleiro, Peça, Jogo/Xadrez, Jogador, etc…
• Free Cell: Colunas_Livres, Colunas_Ordenadas, Baralho,
Embaralhamento, etc…
• Identificação das funções das interfaces
(do… Tabuleiro)
– São usualmente ‘verbos’:
• Xadrez: criar tabuleiro, destruir tabuleiro, inserir peça na casa,
mover peça de casas, retirar peça da casa,….
obter cor da peça, obter status da peça, etc…
• Alocação de cada função para cada interface dos módulos
– Como descobrir qual é a alocação mais apropriada?
• As ações (funções) são sempre feitas sobre o sujeito/substantivo
(candidato a módulo)
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
36
Modelo conceitual
• Modelo conceitual
– descreve um conceito sem se preocupar com a forma de sua
implementação
• Exemplo
– um grafo dirigido é uma tupla < V , A , O > formada por
• um conjunto de vértices V,
• um conjunto de arestas dirigidas A e
• um conjunto de origens O  V.
– cada aresta a  A é um par < v1 , v2 > em que v1 , v2  V .
• a direção da aresta é de v1 para v2 .
– neste modelo conceitual, não temos detalhes de uma possível
implementação (modelo físico) de grafos dirigidos na linguagem C
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
37
Representação gráfica do exemplo conceitual
• Figuras (modelos) valem por mil palavras
– uma representação gráfica é muito melhor para a compreensão
humana
• para exemplos utilizam-se em geral representações (ad hoc) que
mais nos convierem
A
C
B
Origens
E
D
– em um modelo conceitual da arquitetura, também poderíamos
analisar propriedades de forma similar: p.e. dependências
entre módulos
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
38
Representação gráfica do exemplo conceitual
• Figuras (modelos) valem por mil palavras
– uma representação gráfica é muito melhor para a compreensão
humana
• para exemplos utilizam-se em geral representações (ad hoc) que
mais nos convierem
A
C É um modelo
de grafo
dirigido?
B
Origens
E
D
– em um modelo conceitual da arquitetura, também poderíamos
analisar propriedades de forma similar: p.e. dependências
entre módulos
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
39
Modelo conceitual baseado em classes
Origem
Origens
vértices
Vértice
Vértices
1..n
0..n
1
1
1
0..n
0..n
sucessores
predecessores
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
40
Modelo conceitual baseado em classes
Origens
vértices
Vértices
1
10..n
1
0..n
Problema: como representar
interfaces?
Mar 2014
0..n
sucessores
predecessores
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
41
UML (Unified Modelling Language)
• UML: foi desenvolvida para...
– modelagem orientada à objetos: classes, objetos, e diferentes
relacionamentos.
– modelagem conceitual: domínio da aplicação (“entidades do
mundo real”).
• Modelagem física com UML requer ligeiras adaptações
– utiliza-se notação semelhante.
• Um modelo físico de uma estrutura de dados descreve todas
as possíveis instâncias desse conceito em memória física.
• Um exemplo físico ilustra exatamente uma dessas possíveis
instâncias.
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
42
Jogo de Xadrez?
• Modelagem conceitual – Como Seria?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
43
Jogo de Xadrez – Modelo Conceitual
Arquivos.h
Arquivos.c
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
44
Jogo de Xadrez – Modelo Conceitual
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
45
Do modelo conceitual para...
• ... modelo físico:
– É o resultado de uma transformação do modelo conceitual,
tornando-o realizável no meio físico alvo
– Estabelecem-se interdependências a serem realizadas no
meio físico escolhido, tais como:
• memória principal, determinada linguagem de programação, ou
determinado sistema de gerência de banco de dados
– Transformações devem preservar as características do modelo
conceitual
Origens
– Exemplo –
Grafo
direcionado
vértices
Vértices
1..n
assertivas
estruturais
1
0..n
1
1
0..n
0..n
sucessores
predecessores
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
46
Como implementar isso?
• Pode-se representar diretamente em memória uma relação
n para n, ou 1 para n?
– não, em memória temos somente ponteiros que são relações
0..1  { NULL , endereço }
– para representar um relação de n elementos precisamos de
alguma estrutura complementar, em geral uma lista
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
47
Linguagem de representação
• Estruturas de dados físicas podem ser modeladas usando uma
representação semelhante a dos diagramas de classes da UML2
– dois tipos básicos de relacionamentos
struct
relacionamento
tpPessoa
Tipo 1
Tipo 1 struct {
1
Nome
0..1
Tipo 2
Referência
tpPessoa Pessoa;
NometpCargo Cargo;
Nome
n
tpSalario Salario;
Tipo 2 } tpEmpregado
Tipo 2
Agregação
Tipo11
Tipo 1
Pessoa
tpCargo
tpEmpregado
Nome 2
Cargo
Tipo 2
Refinamento de
Salario
Nome 3
Tipo 3
tpSalario
Alternativa
nome da referência usado no Tipo 1
(outro exemplo: ponteiros)
• Tipo 1 e Tipo 2 são declarados como 1 ou mais elementos de
dados: ou seja, são estruturas (struct)
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
48
Linguagem de representação física
• Estruturas de dados físicas podem ser modeladas usando uma
representação semelhante a dos diagramas de classes da UML2
- dois tipos básicos de relacionamentos
struct
Tipo 1
Tipo 1
Tipo 1
Tipo 1
1
Nome
0..1
Tipo 2
Nome
n n
Tipo 2
Nome
Nome 2
Tipo 2
Tipopossibilidades:
2
Nome 3
Tipo 3
definido, exemplo: 20
Referência
Agregação
Refinamento
de
restrito,
exemplo:Alternativa
0..20
indefinido, exemplos: *
nome do elemento usado no Tipo 1
+ (1 ou mais)
3..*
• Tipo 1 e Tipo 2 são agregados de 1 ou mais elementos de dados:
ou seja, são estruturas (struct)
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
49
Linguagem de representação física
• Estruturas de dados físicas podem ser modeladas usando uma
representação semelhante a dos diagramas de classes da UML2
– dois tipos básicos de relacionamentos
Tipo 1
Nome
n
Tipo 2
Agregação
struct {
tpPessoa Pessoa;
char nomesCargos[10][X];
// X é o tam. max. de cada string
int valoresSalarios[10];
} tpEmpregado
Pessoa
tpEmpregado
valoresSalarios
tpPessoa
1..10
nomes
Cargos
1..10
char [X]
int
• Tipo 1 e Tipo 2 são agregados de 1 ou mais elementos de dados:
ou seja, são estruturas (struct) ou classes
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
50 /28
50
Outro Exemplo
• Modelando fisicamente a estrutura de uma Arvore
(ignorando a cabeça)
tgNoArvore
typedef struct tgNoArvore {
struct tgNoArvore * pNoEsq ;
/* Ponteiro para filho à esquerda
pNoEsq
tgNoArvore
tgNoArvore
pNoDir
struct tgNoArvore * pNoDir ;
/* Ponteiro para filho à direita
Valor
char
char Valor ;
/* Valor do nó */
} tpNoArvore ;
Mar 2014
Como simplificar
notação?
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
51
Outro Exemplo
• Modelando fisicamente a estrutura de uma Arvore
(ignorando a cabeça)
tgNoArvore
typedef struct tgNoArvore {
struct tgNoArvore * pNoEsq ;
/* Ponteiro para filho à esquerda
pNoEsq
tgNoArvore
tgNoArvore
pNoDir
struct tgNoArvore * pNoDir ;
/* Ponteiro para filho à direita
char Valor ;
/* Valor do nó */
Valor
char
forma concisa de representar um
tipo (struct)
} tpNoArvore ;
tgNoArvore
pEsq
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
Valor
pDir
52
Exemplo: Comparando Referência vs. Agregação
Modelo de árvore binária usando referências
forma concisa de representar um
tipo (struct)
tgNoArvore
pEsq
Valor
pDir
Modelo de árvore n-ária usando agregação
0..3
tgNoArvore
h
pEsq
Valor
pDir
0..3
d
c
Mar 2014
d
a
e
x
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
g
k
53
Se fossem modelar por completo...
... a estrutura de dados
ÁrvoreÁrvore:
pRaiz
pCorrente
Modelo de árvore binária
o que falta neste modelo?
Nó
pEsq
Valor
pDir
pEsq Valor pDir
Uso 1
Uso 2
Uso 3
Árvore 2
Árvore 1
a
c
pCorrente
d
b
c
a ( c *b )
Mar 2014
h
pCorrente
g
i
k
h ( d ( c nil ) *g ( i k ) )
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
54
Cabeça de estrutura
• Cada estrutura de dados deve poder ser tratada como se
fosse uma unidade
– independente da sua complexidade e da diversidade de
componentes
• Para tal pode-se utilizar uma cabeça de estrutura
– todas as referências para a estrutura referenciam a cabeça
– as referências internas à estrutura são desconhecidas ao cliente
• Vantagens
– melhor encapsulamento da estrutura
• a cabeça da estrutura passa a ser uma interface de acesso
• reduz o risco de uso acidental ou deliberadamente incorreto
– permite tratar estruturas vazias
– permite mover as estruturas na memória
• somente a cabeça precisa ficar fixa
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
55
Como representar cabeças de estruturas?
Árvore tgArvore
pRaiz pCorrente
cabeça de
estrutura
Nó
pEsq
Uso 1
Valor
Árvores
pDir
tgNoArvore
Uso 2
Uso 3
Árvore 2
Árvore 1
a
c
pCorrente
d
b
c
a ( c *b )
Mar 2014
h
pCorrente
g
i
k
h ( d ( c nil ) *g ( i k ) )
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
56
Jogo de Xadrez?
• Modelagem física – Como Seria?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
57
Jogo de Xadrez – Modelagem Física
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
(Visão geral)
58
Jogo de Xadrez – Modelagem Física
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
59
Jogo de Xadrez – Modelagem Física
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
60
Andamento dos trabalhos
• Monitor -
2ª. Feira (1630 as 1730)
• [email protected]
• [email protected]
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
61
Dúvidas?
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
62
Próximos encontros...
Mar 2014
Nr
Aula
Data
1
Teste automatizado – parte 1
Conceitos
12/03
2
Teste automatizado – parte 2
Uso e Instalação do arcabouço
17/03
3
Especificação de requisitos de
módulos e de funções
26/03
4
Métodos caixa-preta
de teste de módulos
26/05
5
Exercício
Métodos de teste caixa-preta
28/05
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
63
Fim...
Mar 2014
Danyllo Albuquerque- OPUS Group/LES/DI/PUC-Rio
64