Embed Size (px)
DESCRIPTION
Apresentação monografia - Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção de Dependência - UFMG
Citation preview
Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção
de Dependência
Aluno: Charles Wellington de Oliveira Fortes
Orientador: Prof. Marco Túlio Valente
Monografia de Final de Curso
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so Independente de seu porte ou ramo de negócio, as
empresas possuem necessidades particulares
Introdução
Estas particularidades são muitas vezes repassadas aos softwares que lhes apóiam, seja criando
softwares específicos ou adaptando funcionalidades de softwares vendidos como produto ou serviço
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Introdução
Nesta monografia iremos focar nas formas como estas
necessidades são inseridas nos softwares, caracterizando o que chamamos de customização de softwares
O que significa em resumo, inserir as funcionalidades específicas de uma empresa em um software já existente (COELHO, 2007)
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Introdução
Segundo Otávio P. Coelho – Arquiteto da Microsoft – em seu artigo sobre
técnicas de customização de software os software (COELHO, 2007), a customização de softwares não se limita a introdução de
modificações no sistema, ela acarreta uma série de complexidades e demanda um grande esforça de implementação.
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Introdução
“Quando realizada pela empresa fabricante do
software, a customização pode ser, por vezes, uma fonte de renda, por outras, de prejuízo.”
(COELHO, 2007)
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Problema
Encontrar o melhor caminho para a adaptação de um
software de pouco impacto e de fácil desenvolvimento e manutenção tarefa que
não vem sendo fácil para os arquitetos e engenheiros de software
Mesmo em se tratando de empresas do mesmo ramo/setor, cada uma apresenta situações singulares
decorrente de sua cultura organizacional, fluxo de trabalho, especialização/diferencial dentre outros
Propor uma alternativa de arquitetura que permita que um
software seja adaptado com o mínimo de impacto em sua versão padrão, sendo que a adaptação é simples de ser feita e
fácil de ser mantida.
Objetivo Geral
Analisar as formas de customização utilizadas por algumas empresas do setor
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Pesquisar e comparar as formas utilizadas por diversas empresas de software para a adaptação de seus
produtos, elicitando seus pontos positivos e negativos.
Objetivo Específico
Apresentar os resultados de qualidade e complexidade obtidos por empresas que utilizam as formas mais comuns de
adaptação de software e propor uma alternativa.
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Abordar as técnicas e padrões utilizados na arquitetura proposta, sendo elas
Inversão de Controle com Injeção de Dependência
Reflexão computacional.
Objetivo Específico
Apresentar a arquitetura proposta e como desenvolvê-la.
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
Pesquisa em materiais bibliográficos
Realização de pesquisa online sobre as formas de customização adotadas
Aplicação prática em um projeto real
MetodologiaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Evoluções podem ser feitas para atender a demandas tecnológicas do ambiente (LEHMAN, 2000)
ou as necessidades
específicas de um cliente (COELHO, 2007).
Leis da Evolução de SoftwareP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
Este processo resulta em um aumento da complexidade e
queda da qualidade do código fonte, o que eleva os custos da manutenção do software, podendo ir de 40% do custo de desenvolvimento (BROOKS, 1995)
podendo inclusive excedê-los (SOMMERVILE, 2007).
Leis da Evolução de SoftwareP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
Durante o processo de alteração de um trecho do código fonte de um software, mesmo que para manutenções corretivas,
esbarramos com a probabilidade de 20-50% de criar defeitos, além do aumento dos custos e necessidade de
cobertura dos testes (BROOKS, 1995).
Leis da Evolução de SoftwareP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
Alexander (ALEXANDER, 1979) define que um padrão é uma solução para um problema em determinado
contexto, podendo estes serem combinados para resolver um problema complexo
Padrões de ProjetosP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
foi proposta pois os módulos de alto nível não deveriam depender diretamente dos módulos de implementação.
Passando assim a apontar estas dependências para abstrações e transpassar o controle a eles (MARTIN,
2000).
Inversão de ControleP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
Martin Fowler explica que a inversão de controle é uma característica comum dos frameworks, são um conjunto de “containers que ajudam a montar componentes de projetos diferentes em
uma aplicação coesa” (FOWLER, 2004)
Inversão de ControleP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
a injeção de dependência passa a poder
construir o objeto concreto na
memória conforme o contexto de necessidade para aquela abstração(FOWLER, 2004)
Injeção de DependênciaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
A reflexão computacional fornece objetos que encapsulam assemblies, módulos e tipos, e pode ser usada para criar instâncias de tipos dinamicamente, ligar o tipo a um
objeto existente ou obter as definições de tipagem de um objeto existente
(NET FRAMEWORK DEVELOPER'S GUIDE, 2010)
Reflexão para Instanciação de ClassesP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Referencial teórico
Distribuída de forma Online através do Google Docs
Respondida por 36 profissionais de nível sênior atuantes na área de desenvolvimento ou arquitetura de software
Os profissionais representam uma única empresa, localizadas nas cidades de Belo
Horizonte (MG), São Paulo (SP), Rio de Janeiro (RJ) e Porto Alegre (RS)
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Tipos de Customização segundo (COELHO, 2007)
Branchs: Cópia do código fonte pra cada cliente
Versionamento: Generalização das customizações para atender a todos os clientes, como nova funcionalidade do software
Fluxo condicional: Customização implementada no fonte mas acessada através de uma validação condicional do tipo if (condição) { [...] instruções [...]; }
Uso de linguagem de programação: Uso de linguagem de programação específica do software para extensão.
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Versionamento
Incidência de erros Impactos Complexidade
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Branchs
Prós Contras
O produto se torna mais atraente para o cliente
quando pode ser customizado à sua vontade.
A complexidade aumenta com regras de negócios
específicas de cada customização.
Redução do custo total de desenvolvimento do
software e qualidade final é alta após processo de
QA.
Precisam ser feito mais testes e um longo processo de
QA. Mas a qualidade final é alta.
Mantém um possível problema isolado a um cliente
específico.
É preciso manter várias versões de um mesmo código.
rápida entrega difícil manutenção
Cada cliente recebe o que solicitou. Um erro comum encontrado deverá ser corrigido nos
fontes de todos os clientes.
Cada cliente é independente na customização do
softaware.
Uma implementação feita em um cliente deve ser
replicada para todos os clientes caso se queira essa
funcionalidade.
Facilidade de correção Gerenciar muitas branchs
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Versionamento
Incidência de erros Impactos Complexidade
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Versionamento
Prós Contras
Baixa complexidade do código fonte Clientes que necessitam de situações muito
específicas não são atendidos
As novas funcionalidades ajudam na
evolução do produto e com isto a
conquistar mais clientes
Funcionalidades que atendem a menos
clientes são implementadas por último
Facilidade de manutenção
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Fluxos Condicionais
Incidência de erros Impactos Complexidade
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Fluxos Condicionais
Prós Contras
Facilidade de Implementar Dificuldade de controlar os recursos específicos
e gerais
Entrega rápida Dificuldade de gerenciamento e rastreabilidade
dos requisitos e testes
Erros afetam um grande numero de clientes
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Uso de linguagem de programação
Incidência de erros Impactos Complexidade
PesquisaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Uso de linguagem de programação
Prós Contras
Adequação a regra de negocio do cliente. Dificuldade de manutenção.
Maior facilidade de implementação Pela facilidade de se customizar, esse modelo é
utilizado de forma abusiva carregando o cliente de
customizações desnecessárias.
desacoplamento. Alto custo.
Como os aplicativos são voltados para clientes
específicos o reaproveitamento deles é pequeno.
Mudanças no processo de negócio do cliente
podem afetar as funcionalidades implementadas no
software, podendo gerar necessidade de alterações
nas regras de negócio códigos da aplicação.
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Identificação do contexto
O sistema deve possuir um contexto de execução que identifique o que trataremos por CustomizationType
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Identificação do contexto
O gerenciador de contexto da aplicação será tratado com o nome AppContext
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Inserindo a injeção de comportamento
A solução consiste em alterar o método responsável por resolver as dependências da Inversão de Controle que iremos tratar com o nome resolver
Ele deverá possuir um método “resolve”, que passará a verificar antes qual o tipo está sendo passado no parâmetro e deve tentar localizar o tipo correspondente a ele, baseando-se no CustomizationType dentro do AppContext
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Método Resolver
Quando o método resolve for chamado, a primeira coisa que ele deve fazer é buscar o CustomizationType dentro do AppContext.
De posse do tipo de customização corrente, o resolver irá tentar carregar um tipo, que é o resultado da concatenação do nome do tipo solicitado com o CustomizationType do contexto
var newTypeName = typeof(T).FullName +
AuthContext.CurrentContext.CurrentUser.Company.Parameters.AccessTyp
e;
Type newType = Type.GetType(newTypeName);
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Método Resolver
O tipo customizado deve estar no mesmo espaço de trabalho que o tipo originalmente passado ao método resolve. Após estes passos, caso o newType seja um objeto nulo, o resolver irá recuperar o objeto instanciado baseado no próprio tipo enviado no parâmetro genérico (<T>), caso contrário, ele usa reflection para carregar o objeto customizado
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Método Resolver
private static T Resolve<T>()
{
object obj = null;
var newTypeName = typeof(T).FullName +
AppContext.CurrentCompany.CustomizationType;
Type newType = Type.GetType(newTypeName);
if (newType != null)
obj = _dependencyResolver.GetType()
.GetMethod("Resolve")
.MakeGenericMethod(newType)
.Invoke(_dependencyResolver, null);
if (obj == null)
obj = _dependencyResolver.Resolve<T>();
return (T)obj;
}
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Método Resolver
Neste exemplo, caso o contexto ativo for o de uma empresa “Empresa A” (CustomizationType = “CustomerA”) que possui uma customização para o serviço de usuário (UserService), o método resolve irá procurar por uma classe UserServiceCustomerA no mesmo espaço de trabalho de UserService
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Método Resolver
Neste mesmo exemplo, caso o contexto ativo seja de uma empresa “Empresa B” (CustomizationType = “CustomerB”) que não possui customização em UserService ou uma “Empresa C” que não possui um customizationType, o sistema irá retornar o “UserService” que é o comportamento padrão do sistema
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Criando customizações
As customizações são feitas criando uma nova classe que herde da classe a ser customizada, sendo que seu espaço de trabalho deve ser o mesmo espaço de trabalho da classe a ser customizada, e seu nome seja a junção do nome da classe a ser customizada com o nome do CustomizationType
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Criando customizações
Para customizar a classe de validação de empresa (CompanyValidator), adicionando novas validações específicas para um cliente, teremos por exemplo
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Criando customizações
namespace Sample.Core.Validation
{
public class CompanyValidatorCompanyA : CompanyValidator
{
public override bool ValidateRemove(Company
toBeRemoved,
out IList<string> brokenRules)
{
base.ValidateRemove(toBeRemoved, out brokenRules);
[…]//condições de validação
brokenRules.Add(CompanyAResources.RootCompanyCantBeDeleted);
return brokenRules.Count == 0;
}
}
}
PropostaP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Proposta de Arquitetura
Organização das Customizações
ResultadosP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
Implementado pela empresa Prime Systems em projeto de médio porte de 6 meses de duração
Atuação de 5 profissionais, sendo 3 desenvolvedores sênior e dois arquitetos sênior
A técnica foi usado no sistema para diferenciar o comportamento do software quando este é:
• Empresas de um cliente• A empresa que administra o sistema• Empresas de teste e demonstração
ResultadosP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
O Sistema é um software desenvolvido para a plataforma web e vendido na forma de serviço pela Prime Systems, onde diversas empresas contratam estes serviços.
Ao se cadastrar no Sistema, as empresas ganham um identificador único que é utilizado sempre que um usuário da empresa tem que acessar o Sistema, informando sempre o código da instancia, o nome do usuário e a senha.
O sistema possui um cadastro de empesas, usuários, alguns ativos específicos, monitoramento de operações e diversas configurações, dentre as quais perfis de usuários, permissões de acesso, dentro outros.
ResultadosP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so O modelo foi aplicado para diferenciar, no momento em que o usuário acessa o sistema, qual o tipo de acesso sua empresa possui, baseado em uma característica que foi informada no momento de seu cadastro.
O desenvolvimento inicial, tido como fluxo convencional, foi o do acesso do tipo “Cliente”, sendo utilizadas o modelo para diferenciar a “empresa raiz” (que representa a Prime Systems, administradora do sistema) e a “Empresa Falsa”, que é usada para testes e demonstrações.
ResultadosP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
A técnica foi bem avaliada por todos os envolvidos no projeto, sendo ressaltada a facilidade de implementação e a boa separação dos interesses, pois pode-se obter as mudanças de comportamento necessárias ao tempo em que o código se manteve limpo e com pouco possibilidade de um afetar o outro.
ConclusãoP
ropo
sta
de u
ma
Arq
uite
tura
par
a C
usto
miz
ação
de
Sis
tem
as u
sand
o M
ecan
ism
os d
e In
jeçã
o de
Dep
endê
ncia
Mon
ogra
fia d
e F
inal
de
Cur
so
A proposta de arquitetura não provem a uma solução final para os problemas acerca da customização de software, porém é uma opção funcional e prática que pode ser aplicada e exercitada afim de se refiná-la e aprimorá-la
ReferênciasALEXANDER, C. I. S. . S. M. The Timeless Way of Building. New York: Oxford University Press, 1979. BROOKS, F. P. The mythical man-month: essays on software engineering. 2ª. ed. [S.l.]: Addison-Wesley, 1995. COELHO, O. P. Técnicas para Customização de Software. Microsoft MSDN Brasil, 2007. Disponivel em: <http://www.microsoft.com/brasil/msdn/tecnologias/arquitetura/Customizacao_Software.mspx>. Acesso em: 16 Janeiro 2012. FOWLER, M. Inversion of Control Containers and the Dependency Injection, 2004. Disponivel em: <http://martinfowler.com/articles/injection.html>. Acesso em: 20 Janeiro 2012. GOUSSET, M. et al. Professional Application Lifecycle. 1ª. ed. Indiana: Wiley Publishing, 2012. LEHMAN, M. M. Rules and Tools for Software Evolution Planning and Management. Imperial College - Department of Computing, 2000. Disponivel em: <http://www.doc.ic.ac.uk/~mml/feast2/papers/pdf/611_2.pdf>. Acesso em: 15 Janeiro 2012. LEHMAN, M. M. Feedback, Evolution And Software Technology - Brief Introduction. FEAST, 2001. Disponivel em: <http://www.doc.ic.ac.uk/~mml/feast/>. Acesso em: 15 Janeiro 2012.
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
1/2
Referências
MARTIN, R. C. http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf. Object Mentor, 2000. Disponivel em: <http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf>. Acesso em: 24 Janeiro 2012. NET FRAMEWORK DEVELOPER'S GUIDE..NET Framework Developer's Guide: Reflection Overview. MSDN, 2010. Disponivel em: <http://msdn.microsoft.com/en-us/library/f7ykdhsy(VS.71).aspx>. Acesso em: 2010 julho 10. PRESSMAN, R. S. Engenharia de Software. 3ª. ed. São Paulo: MAKRON Books do Brasil, 1995. SHALLOWAY, A. Design patterns explained: a new perspective on object-oriented design. New York: Addison-Wesley Publishing Co., 2002. SOMMERVILE, I. Engenharia de Software. 8ª. ed. São Paulo: Pearson, 2007.
Pro
post
a de
um
a A
rqui
tetu
ra p
ara
Cus
tom
izaç
ão d
e S
iste
mas
usa
ndo
Mec
anis
mos
de
Inje
ção
de D
epen
dênc
ia
Mon
ogra
fia d
e F
inal
de
Cur
so
2/2
