Abordagem de Projeto de Software Orientado a Objetos

Prévia do material em texto

1/74
CPGEI - Programa de Pós-Graduação em 
Engenharia Elétrica e Informática Industrial
Orientador: Prof. Dr. Paulo Cézar Stadzisz
Membros da Banca:
Profa. Dra. Itana Maria de Souza Gimenes DIN, UEM
Prof. Dr. João Umberto Furquim de Souza DEINFO, UEPG
Prof. Dr. Cesar Augusto Tacla CPGEI, UTFPR
Prof. Dr. Douglas Paulo Bertrand Renaux DAELN, UTFPR
Prof. Dr. Jean Marcelo Simão DAELN, UTFPR
Tese de Doutorado
Andrey R. Pimentel
Uma Abordagem para Projeto de Software Orientado a 
Objetos Baseada na Teoria de Projeto Axiomático
2/74
Tópicos da Apresentação
1. Introdução
2. Objetivos e Justificativa
3. Projeto de Software
4. Teoria de Projeto Axiomático
5. Abordagem Proposta
6. Axioma da Independência
7. Axioma da Informação
8. Estudo de Caso
9. Conclusões
3/74
1. Introdução
• Importância da Engenharia de Software
• Construir software com mais qualidade, dentro dos 
prazos estabelecidos e dentro de um orçamento 
limitado
• A Teoria de Projeto Axiomático se baseia em 
princípios gerais de bons projetos.
• Possui natureza independente de domínio
• Provê critérios para tomada de decisões de projeto
4/74
1. Introdução
“É possível e vantajoso aplicar uma metodologia de 
projeto de engenharia como a Teoria de Projeto 
Axiomático em conjunto com uma metodologia de 
projeto de software Orientado a Objetos como o 
Processo Unificado?”
5/74
2. Objetivos e Justificativa
Objetivos:
• Estudar a aplicabilidade do uso da Teoria de 
Projeto Axiomático ao projeto de software O O
• Desenvolver uma abordagem baseada no Projeto 
Axiomático para o projeto de software O O
• Desenvolver um estudo de caso para avaliação dos 
impactos da aplicação da abordagem em um 
projeto de software O O
6/74
2. Objetivos e Justificativa
• Aprimorar o processo de desenvolvimento de 
software Orientado a Objetos, através da aplicação 
da Teoria de Projeto Axiomático
• Garantir a qualidade do produto de software 
garantindo a qualidade da solução de projeto
• Garantir a rastreabilidade dos componentes do 
software com relação aos requisitos funcionais de 
vários níveis
• Facilitar o enquadramento do projeto em relação à 
normas como a DO - 178 B (aviônica)
7/74
2. Objetivos e Justificativa
• Teoria de Projeto Axiomático:
– provê critérios baseados em princípios gerais de 
bons projetos, para tomada de decisões de 
projeto. 
– Vem sendo aplicada com sucesso na Indústria
– Possui natureza Independente de Domínio
8/74
3. Projeto de Software
• Objetivo da engenharia de projeto: Produzir um 
modelo que gere um produto de qualidade 
(Pressman, 2005)
• Projeto é uma interação entre o que queremos 
alcançar e como nós queremos alcançá-lo 
(Suh,2001)
Necessidades Solução de Projeto Produto
9/74
3. Projeto de Software
• Projetar consiste em dois processos:
Requisitos Solução de Projeto
Solução 1
Solução 2
Solução N
...
Processo Criativo
Diversificação
Processo Analítico
Convergência
Criatividade do 
Projetista e seu 
Repertório de 
Soluções 
Princípios e Critérios 
para Tomada de 
Decisões de Projeto
10/74
3. Projeto de Software
Qualidade 
da Solução 
de Projeto
Qualidade 
do Produto 
Final
11/74
3. Projeto de Software
• A aplicação das metodologias não garante a 
qualidade do projeto e do produto
• Tomada de decisões de projeto depende muito da 
experiência do desenvolvedor.
• Dificuldade na definição dos requisitos
• “...mesmo atualmente, falta para a maioria das 
metodologias de desenvolvimento de software a 
profundidade, flexibilidade e a natureza quantitativa 
que estão normalmente associadas com disciplinas 
de projeto de engenharia mais clássicas” (Pressman, 
2005) 
12/74
4. Teoria de Projeto Axiomático
• Desenvolvida por Nan Pyu Suh
• Departamento de Engenharia Mecânica do 
Massachusets Institute of Technology (MIT)
• Baseada em princípios gerais de bons projetos
13/74
4. Teoria de Projeto Axiomático
• Objetivo Principal da Teoria: 
– ”...estabelecer uma base científica para projeto e 
aprimorar as atividades de projeto provendo ao 
projetista uma fundamentação teórica baseada em 
ferramentas e processos do pensamento lógico e 
racional.” (Suh, 2001) 
• Com isso: 
– Tornar projetistas mais criativos 
– Minimizar o processo iterativo de tentativa e erro 
– Determinar as melhores soluções de projeto entre as 
que foram propostas
14/74
4. Teoria de Projeto Axiomático
• Aplicações da Teoria de Projeto Axiomático:
– Indústria Automobilística: FORD e FIAT 
– Indústria naval militar 
• Em conjunto com outras metodologias:
– TRIZ, Projeto Robusto, QFD, Six Sigma
• Software
– Projeto Axiomático no desenvolvimento do FrontPage, 
dissertação M. Angiulo (1997)
– Desenvolvimento Orientado a Componentes
– Desenvolvimento Orientado a Serviços
15/74
4. Teoria de Projeto Axiomático
• Conceitos básicos:
– Atributos do Cliente (CA)
– Requisitos Funcionais (FR)
– Parâmetros de Projeto (DP)
– Variáveis de Processo (PV)
– Restrições (C)
16/74
4. Teoria de Projeto Axiomático
• Domínios:
Domínio 
Funcional
Domínio
Físico
(de Projeto)
Domínio do
Cliente
Domínio de 
Processo
(de Implementação)
{CAs} {FRs} {DPs} {PVs}
Necessidades 
do Cliente
Funcionalidades 
do Produto
Projeto do 
Produto
Processo para
Realizar o 
Produto
Mapeamento MapeamentoMapeamento
17/74
4. Teoria de Projeto Axiomático
• No princípio eram 12 axiomas, reduzidos para 
apenas 2:
• Axioma 1 (Axioma da Independência) Mantenha 
a independência dos requisitos funcionais (Suh, 
2001).
• Axioma 2 (Axioma da Informação) Minimize o 
conteúdo de informação do projeto (Suh, 2001).
18/74
4. Teoria de Projeto Axiomático
• A Matriz de Projeto:
– Mapeamento entre FR e DP 
– Representa a dependência entre os FRs
• Quando então DPj é usado para satisfazer 
FRi
{FR1FR2FR3}=[
A11 A12 A13
A21 A22 A23
A31 A32 A33]{
DP1
DP2
DP3
}
Aij≠0
19/74
4. Teoria de Projeto Axiomático
• Axioma da Independência
– Projeto Desacoplado
– Projeto Semi-acoplado
– Projeto Acoplado
{FR1FR2FR3}=[
A11 0 0
0 A22 0
0 0 A33]{
DP1
DP2
DP3}
{FR1FR2FR3}=[
A11 0 0
A21 A22 0
A31 A32 A33]{
DP1
DP2
DP3}
{FR1FR2FR3}=[
A11 A12 A13
A21 A22 A23
A31 A32 A33]{
DP1
DP2
DP3}
20/74
4. Teoria de Projeto Axiomático
• Axioma da Independência:
– Exemplo: O projeto de um misturador para água 
quente e fria.
– Duas soluções:
21/74
4. Teoria de Projeto Axiomático
• Independência entre os FR:
– FR1 – Controlar Temperatura
– FR2 – Controlar a vazão
Água Quente
Água Fria
C 1
C 2
C 1Água Quente
Água Fria
C 2
Solução 1
X X
X X
Solução 2
{ } [ ]{FR1FR2 = }Controle C1ControleC2 X 00 X{ } [ ]{FR1FR2 = }Controle C1ControleC2
Matriz de Projeto: Matriz de Projeto:
22/74
4. Teoria de Projeto Axiomático
FR 4.1
FR 4.1.3FR 4.1.2FR 4.1.1
FR 4.1 - Permitir a fixação da buzina ao veículo
FR 4.1.1 - Permitir a fixação da caixa da buzina 
 à haste de fixação
FR 4.1.1.1 - Sustentar e posicionar a caixa 
 em relação à haste
FR 4.1.1.2 – Aumentar a pressão de fixação 
 do parafuso e da porca de fixação 
 da caixa
FR 4.1.1.3 – Apertar o parafuso de fixação 
 da caixa 
FR 4.1.2 - Permitir o posicionamento e a orientação 
 da buzina em relação ao ponto de fixação na 
 carroceria do veículo
FR 4.1.3 - Permitir a fixação da haste à carroceria 
 do veículo
FR 4.1.1.1 FR 4.1.1.2 FR 4.1.1.3
Hierarquia dos Requisitos Funcionais
(Nomenclatura Funcional)
23/74
4. Teoria de Projeto Axiomático
Processo de Ziguezagueamento
DP1
DP11 DP12
DP111 DP112
FR1
FR11 FR12 
FR111 FR112
Domínio Funcional Domínio Físico
24/74
4. Teoria de Projeto Axiomático
Processo de Ziguezagueamento
DP1
DP11 DP12
DP111 DP112
FR1
FR11 FR12 
FR111 FR112
Domínio Funcional Domínio Físico
25/74
4. Teoria de Projeto Axiomático
Processo de Ziguezagueamento
DP1
DP11 DP12
DP111 DP112
FR1
FR11 FR12 
FR111 FR112
Domínio Funcional Domínio Físico
26/74
4. Teoria de ProjetoAxiomático
Processo de Ziguezagueamento
DP1
DP11 DP12
DP111 DP112
FR1
FR11 FR12 
FR111 FR112
Domínio Funcional Domínio Físico
27/74
4. Teoria de Projeto Axiomático
Processo de Ziguezagueamento
DP1
DP11 DP12
DP111 DP112
FR1
FR11 FR12 
FR111 FR112
Domínio Funcional Domínio Físico
28/74
4. Teoria de Projeto Axiomático
• Axioma da Informação
– O Axioma 2 estabelece que “o melhor projeto é um 
projeto funcionalmente desacoplado que tem o conteúdo 
de informação mínimo”
– Em outras palavras, o projeto que tem a maior 
probabilidade de sucesso é o melhor projeto”
I=log  1
p

I=log  system range
tolerance

p é a probabilidade de se atingir os FR
29/74
5. Abordagem Proposta
• Objetivos da Abordagem proposta:
– Ser tão próxima quanto possível das metodologias 
de desenvolvimento de software Orientadas a 
Objetos
– Estabelecer critérios para tomada de decisões de 
projeto:
• Escolher o conjunto mais apropriado de requisitos 
funcionais a ser realizado
• Escolher a melhor solução de projeto entre as 
possíveis alternativas para satisfazer o conjunto de 
requisitos.
30/74
5. Abordagem Proposta
• Foram definidos:
– Correspondências entre os conceitos básicos do Projeto 
Axiomático e os conceitos básicos do Processo 
Unificado 
– Correspondência entre os domínios do Projeto 
Axiomático e as fases do Processo Unificado
– Etapas e atividades da abordagem proposta e suas 
relações com as fases e fluxos de processos do Processo 
Unificado. 
31/74
5. Abordagem Proposta
• Foram definidos:
– Ziguezagueamento para o desenvolvimento O O. 
– Arcabouço para a decomposição funcional, específico 
para o desenvolvimento O O. 
– A aplicação do Axioma da Independência em projetos de 
software O O. 
– Arcabouço para o cálculo do conteúdo de informação 
para para projetos de software O O 
32/74
5. Abordagem Proposta
Concepção ConstruçãoElaboração Transição
Modelagem 
de negócios
Requisitos
Analise e Projeto
Implementação
Testes
Domínio 
Funcional
Domínio
Físico
Domínio do
Cliente
Domínio de 
Processo
{CAs} {FRs} {DPs} {PVs}
Relação entre os domínios do projeto Axiomático e 
as fases do processo Unificado
33/74
5. Abordagem Proposta
Requisitos Análise Projeto Implementação Testes
Caso 
de uso
Abordagem de Projeto 
proposta usando Projeto 
Axiomático
Fluxos de processo básicos do UP
para a realização de um caso de uso
A abordagem proposta na realização de casos de uso 
no processo Unificado
34/74
5. Abordagem Proposta
...
... ...
Casos 
de Uso
Serviços 
Técnicos
Subcasos de Uso 
independentes
1o nível
2o nível
4o nível
3o nível
FRs independentes 
de características 
técnicas da solução
Subcasos de Uso 
dependentes
FRs dependentes 
de características 
técnicas da solução
Níveis da Hierarquia
Funcional Proposta
35/74
5. Abordagem Proposta
• Definições:
– (Casos de Uso) Um caso de uso é a especificação de um 
conjunto de ações que representa uma utilização completa do 
sistema por um ou mais atores.
– (Subcasos de Uso) Um subcaso de uso é a especificação de um 
conjunto de ações que representa uma utilização não completa 
do sistema ou subsistema. Um subcaso de uso representa uma 
parte de uma utilização completa do sistema, ou seja, parte de 
um caso de uso. 
36/74
5. Abordagem Proposta
– (Subcasos de uso independentes) Um subcaso de uso 
independente de características técnicas é a especificação de 
um conjunto de ações que um sistema executa que representa 
uma utilização não completa do sistema que é especificada sem 
levar em consideração características técnicas empregadas na 
solução. 
– (Subcasos de uso dependentes) Um subcaso de uso dependente 
de características técnicas é a especificação de um conjunto de 
ações que um sistema executa que representa uma utilização 
não completa do sistema que é especificada considerando 
fortemente características técnicas empregadas na solução. 
37/74
5. Abordagem Proposta
– (Serviços Técnicos) Um serviço técnico é um serviço esperado 
por um objeto, classe ou componente do sistema de outro objeto, 
classe ou componente do sistema.
38/74
5. Abordagem Proposta
Requisitos Funcionais (FR) Parâmetros de Projeto (DP)
1 Casos de uso Colaborações e seus papéis
2 Colaborações e seus papéis
3 Colaborações e seus papéis
4 Serviços técnicos Objetos e Classes
Nível de 
abstração
Subcasos de uso independentes de 
características técnicas
Subcasos de uso dependentes de 
características técnicas
Requisitos Funcionais e Parâmetros de 
Projeto para Desenvolvimento O O 
39/74
5. Abordagem Proposta
Domínio
Funcional
Domínio
Físico
... ...
... ... ... ..
.
... ... ...
... ...
... ... ... ...
... ... ...
1a. Etapa
Casos de Uso
2a. Etapa 
Subcasos 
Independentes
4a. Etapa
Serviços Técnicos
Requisitos 
Funcionais (FRs)
Parâmetros de 
Projeto (DPs)
FR1112
FR 1
FR 11 FR 12
FR 111 FR 112
FR1111 FR 1121 FR 1122
FR 11121 FR 11122 DP 11122
DP 1
DP 11 DP 12
DP 111 DP 112
DP 1111 DP 1112 DP 1121 DP1122
DP 11121
... ... ... ... ... ... ... ...
FR 111211 FR 111212 DP 111212DP 111211
3a. Etapa 
Subcasos 
Dependentes
Ziguezagueamento na Abordagem Proposta
40/74
5. Abordagem Proposta
1a. Etapa da Abordagem Proposta
41/74
5. Abordagem Proposta
Decompor FRs
42/74
5. Abordagem Proposta
Criar DPs
43/74
5. Abordagem Proposta
Mapear FR x DP
44/74
5. Abordagem Proposta
Aplicar os Axiomas 
45/74
5. Abordagem Proposta
2a. Etapa da Abordagem Proposta
46/74
5. Abordagem Proposta
Decompor FRs
47/74
5. Abordagem Proposta
Criar DPs
48/74
5. Abordagem Proposta
Mapear FR x DP
49/74
5. Abordagem Proposta
Aplicar os Axiomas 
50/74
5. Abordagem Proposta
3a. Etapa da Abordagem Proposta
51/74
5. Abordagem Proposta
4a. Etapa da Abordagem Proposta
52/74
6. Axioma da Independência
• “De duas soluções de projeto aceitáveis, a melhor é 
a que tiver maior independência funcional.”
• Identifica a solução com a menor dependência entre 
os FRs
• Reangularidade e semangularidade
• Ajuda a evitar:
– Projetos com acoplamento
– Projetos com matrizes não quadradas (acoplados ou 
redundantes)
53/74
6. Axioma da Independência
• Projeto Orientado a Objetos totalmente acoplado
54/74
6. Axioma da Independência
• Matriz de projeto com acoplamento entre 
Requisitos Funcionais
Acoplamento
Indesejável
FRs
DPs
55/74
6. Axioma da Independência
• Cálculo da Reangularidade
R= ∏
i=1, n−1
j=1i , n1− ∑k=1
n
Aki Akj
2
∑
k=1
n
A ki
2 ∑
k=1
n
A kj
2  
1 /2
R=0,25
56/74
7. Axioma da Informação
• “o melhor projeto é um projeto funcionalmente 
desacoplado que tem o conteúdo de informação 
mínimo” (Suh, 1990)
• Conteúdo de Informação para software é dado pela 
razão entre: 
– o valor obtido pela métrica de complexidade e 
– o valor estimado para esta métrica com base no histórico 
da organização ou valor de referência.
I M i=log 
valor M i obtido
valor M i estimado

57/74
7. Axioma da Informação
• Métricas de complexidade e tipos de requisitos 
funcionais
• Estas métricas foram adotadas por duas razões:
– São métricas de complexidade de software bem 
conhecidas
– Possuem formas bem estabelecidas para serem 
computadas, facilitando o cálculo
Etapa da Abordagem Tipo de Requisito funcional Métrica de complexidade
Casos de uso
Subcasos independentes
Subcasos dependentes Pontos por função
Serviços técnicos Conjunto de Métricas C K
1a Etapa Use case points
2a Etapa Use case points
3a Etapa
4a Etapa
58/74
7. Axioma da Informação
• Conjunto de métricas Orientadas a Objetos de 
Chidamber e Kemerer (1994): 
– Métodos ponderados por classe
– Profundidade da árvore de herança
– Número de subclasses 
– Acoplamento entre objetos 
– Respostas para a classe
– Falta de coesão nos métodos
59/74
7. Axioma da Informação
I FRi= log
ucpci
eucpi
 I=log  pfc
epf

I classei=I WMC iI DIT iI NOCiI CBO iI RFC iI LCOM i
I WMC i=log 
WMCi
EWMC
 I DIT i=log 
DIT i
EDIT

I NOCi=log NOC i
ENOC
 I CBO i=log 
CBO i
ECBO

I RFC i=log 
RFCi
ERFC
 I LCOM i=log 
LCOM i
ELCOM

60/74
8. Estudo de Caso
• O objetivo geral deste estudo de caso é aplicar a 
abordagem proposta a um projeto de software 
Orientado a Objetos, passando por todas as etapas e 
avaliar a aplicação da abordagem de projeto 
proposta nesta tese.
• Sistema embarcado de tempo real 
• Placa de avaliação eSysTech eAT55
• Arquitetura ARM
61/74
8. Estudo de Caso
Placa de avaliação eSysTech eAT55
62/74
8. Estudo de Caso
1a. etapa da abordagem - Identificação dos casos de uso 
63/74
8. Estudo de Caso
1a. etapa da abordagem - Identificação dos casos de uso 
64/74
8. Estudo de Caso
2a. etapa da abordagem - Identificação dos subcasos Independentes
65/74
8. Estudo de Caso
2a. etapa da abordagem - Identificação dos subcasos Independentes
Reangularidade da solução R = 0,08156
66/74
8. Estudo de Caso
2a. etapa da abordagem - Identificação dos subcasos Independentes
Solução Alternativa
67/74
8. Estudo de Caso
2a. etapa da abordagem - Identificação dos subcasos Independentes
Solução Alternativa
Reangularidade da solução alternativa R = 0,15932
Reangularidade maior, solução mais independente
68/74
8. Estudo de Caso
3a. etapa da abordagem - Identificação dos subcasos dependentes
69/74
8. Estudo de Caso
3a. etapa da abordagem - Identificação dos subcasos dependentes
Solução Alternativa
70/74
8. Estudo de Caso
4a. etapa da 
abordagem - 
Serviços técnicos
71/74
8. Estudo de Caso
Classes criadas para a solução original 
72/74
CLASSE WMC EWMC DIT EDIT NOC ENOC CBO ECBO RFC ERFC LCOM ELCOM
CCtrlVisOpData 1 1 0 0 0 0 2 2 1 1 0 0
COpData 2 2 0 0 0 0 0 0 2 2 0 0
CBuffer 3 2 0 0 0 0 0 0 3 3 0 0
CIntDisplay 4 2 0 0 0 0 3 3 4 2 0 0
CIntKeyboard 1 1 0 0 0 0 2 2 1 1 0 0
CCtrlVisEvents 1 1 0 0 0 0 3 3 1 1 0 0
CIntFlash 2 2 0 0 0 0 0 0 2 2 0 0
COpEvent 2 2 0 0 0 0 0 0 2 2 0 0
CCtrlChangeConf 1 1 0 0 0 0 4 4 1 1 0 0
CConfiguration 4 2 0 0 0 0 0 0 4 4 0 0
CCtrlReadSerialPort 1 1 0 0 0 0 3 3 1 1 0 0
CIntRS232 2 2 0 0 0 0 1 1 2 2 0 0
CCtrlRegEvent 1 1 0 0 0 0 3 3 1 1 0 0
CCtrlReset 1 1 0 0 0 0 2 2 1 1 0 0
CIntDigInput 1 1 0 0 0 0 0 0 1 1 0 0
8. Estudo de Caso
I
soluçãoOrig
 = 1,556
Valores das métricas CK para a solução original 
73/74
8. Estudo de Caso
Classes criadas para a solução alternativa 
74/74
8. Estudo de Caso
CLASSE WMC EWMC DIT EDIT NOC ENOC CBO ECBO RFC ERFC LCOM ELCOM
1 1 0 0 0 0 2 2 1 1 0 0
4 2 0 0 0 0 0 0 4 2 2 1
4 2 0 0 0 0 0 0 4 2 2 1
CIntDisplay 4 2 0 0 0 0 3 3 4 2 0 0
CIntKeyboard 1 1 0 0 0 0 2 2 1 1 0 0
1 1 0 0 0 0 3 3 1 1 0 0
CIntFlash 2 2 0 0 0 0 0 0 2 2 0 0
CCtrlChangeConf 1 1 0 0 0 0 4 4 1 1 0 0
4 2 0 0 0 0 0 0 4 4 0 0
CCtrlReadSerialPort 1 1 0 0 0 0 3 3 1 1 0 0
CIntRS232 2 2 0 0 0 0 1 1 2 2 0 0
1 1 0 0 0 0 3 3 1 1 0 0
CCtrlReset 1 1 0 0 0 0 2 2 1 1 0 0
CIntDigInput 1 1 0 0 0 0 0 0 1 1 0 0
CCtrlVisOpData
COpDataAlt
COpEventAlt
CCtrlVisEvents
CConfiguration
CCtrlRegEvent
I
soluçãoAlt
 = 3,006
Valores das métricas CK para a solução alternativa 
75/74
• A abordagem proposta nesta tese traz vantagens ao 
projeto de software Orientado a Objetos, como:
– Auxiliar na escolha da melhor solução de projeto entre 
possíveis soluções, para satisfazer o conjunto de FRs.
– Auxiliar a manter o conjunto de FRs do projeto adequado 
ao nível de abstração desejado, durante o projeto.
– Auxiliar a manter alta a probabilidade de que o sistema 
produzido satisfaça os requisitos funcionais.
– Permitir que o nível de abstração da solução de projeto 
se mantenha adequado às necessidades do projetista.
– Auxiliar a manter a rastreabilidade entre os artefatos que 
implementam o sistema e os FRs de alto nível.
Conclusões
76/74
• Adicionalmente o autor também observou que:
• propor uma abordagem para decomposição dos requisitos 
funcionais, criando uma hierarquia que relaciona os 
requisitos funcionais de alto nível com os de baixo nível. 
• Como a aplicação desta abordagem de decomposição, se 
obtém uma qualidade muito maior na definição dos papéis e 
responsabilidades dos componentes de software. 
• A qualidade do projeto pode ser analisada ao longo do 
desenvolvimento e não como uma medida da qualidade 
realizada ao final
• Este trabalho estabelece um fundamento teórico para projeto 
de software Orientado a Objetos 
Conclusões
77/74
• Trabalhos futuros:
– Evolução da fundamentação teórica
– Aplicação da teoria no projeto de testes
– Aplicação da teoria no gerenciamento de projetos
– Aplicação da teoria no desenvolvimento Orientado a 
Aspectos 
– Aplicação da teoria no desenvolvimento de componentes 
reutilizáveis de software
– Aplicação da teoria no desenvolvimento de software 
segundo normas rígidas como a DO - 178 B
Conclusões
78/74
Publicações resultantes do trabalho
• Pimentel, Andrey R. e Stadzisz, Paulo C.. Application of the Independence 
Axiom on the Design of Object-Oriented Software Using the Axiomatic 
Design Theory. Journal of Integrated Design and Process Science. V. 10, n. 
1. p. 57-69, mar. 2006.
• Pimentel, Andrey R. e Stadzisz, Paulo C.. A Use Case Based Object-
Oriented Software Design Approach using the Axiomatic Design Theory. 
Proceedings of ICAD 2006. Florença, Itália.
• Pimentel, Andrey R. e Stadzisz, Paulo C.. Application of the Independence 
Axiom on the Design of Object-Oriented Software Using the Axiomatic 
Design Theory. Proceedings of IDPT 2006. San Diego , EUA.
• Pimentel, Andrey R. e Stadzisz, Paulo C.. Object-Oriented Software Design 
Using the Axiomatic Design Theory. Anais do CONBRATEC 2005. Recife, 
PE.
79/74
Agradecimentos
• Conselho Nacional de Desenvolvimento Científico e 
Tecnológico - CNPq
• CPGEI - UTFPR
• Prof. Dr. Paulo Cézar Stadzisz (Orientador)
• Membros da banca examinadora
• Minha família
• Chris
• Amigos e colegas