Apresentação monografia - Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção de Dependência - UFMG

Monografia de Final de Curso

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

Proposta de uma Arquitetura para Customização de Sistemas usando Introdução
Mecanismos de Injeção de Dependência

Independente de seu porte ou ramo de negócio, as
empresas possuem necessidades particulares

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


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)


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.


“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)

Proposta de uma Arquitetura para Customização de Sistemas usando Problema

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

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

Proposta de uma Arquitetura para Customização de Sistemas usando Objetivo Geral

Analisar as formas de customização utilizadas por

algumas empresas do setor

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.

Proposta de uma Arquitetura para Customização de Sistemas usando Objetivo Específico

Pesquisar e comparar as formas utilizadas por diversas

empresas de software para a adaptação de seus
produtos, elicitando seus pontos positivos e
negativos.

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.

Proposta de uma Arquitetura para Customização de Sistemas usando Objetivo Específico

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.

Apresentar a arquitetura proposta e como desenvolvê-la.

Proposta de uma Arquitetura para Customização de Sistemas usando Metodologia

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

Proposta de uma Arquitetura para Customização de Sistemas usando Leis da Evolução de Software
Mecanismos de Injeção de Dependência Referencial teórico

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).


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).


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).

Proposta de uma Arquitetura para Customização de Sistemas usando Padrões de Projetos

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

Proposta de uma Arquitetura para Customização de Sistemas usando Inversão de Controle

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).

Proposta de uma Arquitetura para Customização de Sistemas usando Inversão de Controle

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)

Proposta de uma Arquitetura para Customização de Sistemas usando Injeção de Dependência

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)

Proposta de uma Arquitetura para Customização de Sistemas usando Reflexão para Instanciação de Classes

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)

Proposta de uma Arquitetura para Customização de Sistemas usando Pesquisa
Mecanismos de Injeção de Dependência Proposta de Arquitetura

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)


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.

Proposta de uma Arquitetura para Customização de Sistemas usando
Pesquisa

Versionamento

Incidência de erros
Proposta de Arquitetura

Impactos
Complexidade


Branchs

Prós Contras
O produto se torna mais atraente para o cliente A complexidade aumenta com regras de negócios
quando pode ser customizado à sua vontade. específicas de cada customização.
Redução do custo total de desenvolvimento do Precisam ser feito mais testes e um longo processo de
software e qualidade final é alta após processo de QA. Mas a qualidade final é alta.
QA.
Mantém um possível problema isolado a um cliente É preciso manter várias versões de um mesmo código.
específico.
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 Uma implementação feita em um cliente deve ser
softaware. replicada para todos os clientes caso se queira essa
funcionalidade.
Facilidade de correção Gerenciar muitas branchs

Pesquisa

Versionamento

Impactos

Complexidade


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 Funcionalidades que atendem a menos
evolução do produto e com isto a clientes são implementadas por último
conquistar mais clientes

Facilidade de manutenção

Pesquisa

Fluxos Condicionais

Impactos

Complexidade


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

Pesquisa

Uso de linguagem de programação

Impactos

Complexidade


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.

Proposta de uma Arquitetura para Customização de Sistemas usando Proposta

Identificação do contexto

O sistema deve possuir um contexto de execução que
identifique o que trataremos por CustomizationType


Identificação do contexto

O gerenciador de contexto da aplicação será tratado
com o nome AppContext


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


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.AccessType;

Type newType = Type.GetType(newTypeName);


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


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;
}


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


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


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



Para customizar a classe de validação de empresa
(CompanyValidator), adicionando novas validações
específicas para um cliente, teremos por exemplo



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;
}
}
}

Proposta

Organização das Customizações

Proposta de uma Arquitetura para Customização de Sistemas usando Resultados

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


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.


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.


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.

Proposta de uma Arquitetura para Customização de Sistemas usando Conclusão

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

Proposta de uma Arquitetura para Customização de Sistemas usando Referências
1/2

ALEXANDER, 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.

Proposta de uma Arquitetura para Customização de Sistemas usando Referências
2/2

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.

Apresentação monografia - Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção de Dependência - UFMG

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Apresentação monografia - Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção de Dependência - UFMG

Similar a Apresentação monografia - Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção de Dependência - UFMG (20)

Más de Charles Fortes

Más de Charles Fortes (20)

Apresentação monografia - Proposta de uma Arquitetura para Customização de Sistemas usando Mecanismos de Injeção de Dependência - UFMG