Tuesday, October 30, 2012
S.O.L.I.D.
SOLID é uma sigla que apresenta 5 princípios básicos da programação orientada a objetos:
Estes princípios básicos servem como guias para o desenvolvimento de um código sustentável e eficiente. Para projetos que implementam o TDD e metodologias ágeis de gerenciamento estes princípios são essenciais.
Abaixo, temos uma introdução de cada um dos princípios
Single Responsibility:
"Every class should have a single resposibility. It should have a single puprpouse in the system, and there should be only one reason to change it." - Michael C feathers
Este é o princípio da responsabilidade única, cada classe no sistema deve ter um único objetivo. É um princípio que prega a coesão do sistema:
Coesão
A coesão Mede o quanto que uma classe e seus métodos fazem sentido;
Uma classe com alta coesão possui responsabilidades bem definidas e são difíceis de serem desmembradas em outras classes;
Uma classe com baixa coesão possui muitas responsabilidades, geralmente que pertencem a outras classes, e podem ser facilmente desmembradas em outras classes;
Open Closed:
Introduzido por Bertrand Meyer no seu livro Object Oriented Software Contruction - http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction, este princípo diz que o código do sistema deve ser extensível (voltamos a coesão) e fechado para modificação. Ou seja, uma entidade deve permitir que o seu comportamento se modifique sem que o código seja alterado.
A idéia mais importante é que uma classe só deve ser alterada para correção de erros. Funcionalidades alteradas e novas devem ser criadas em classes novas que implementam o conceito de herança. Evitando modificações, reduzimos a carga de revisão, testes unitários, integrados, etc..
Liskov substitution principle
"Objects of subclasses should be substitutabe for objects of their superclasses througout our code. If they are not, we could have silent errors in our code."
Princípio da substituição de Liskov. Se um objeto B implementa herança do objeto A, então o sistema deve permitir que o objeto A seja substituído por B. Por exemplo:
public class Nota {
int valor;
}
public class DezReais: Nota {
public DezReais()
{
this.valor = 10;
}
}
public class VinteReais: Nota {
public VinteReais()
{
this.valor = 20;
}
}
Neste caso temos as classes DezReais e VinteReais que implementam herança da classe Nota. Podemos então ter uma lista de objetos do tipo Nota, que são substituídos por objetos do outro tipo.
var notas = new List<Nota>();
notas.Add(new DezReais());
notas.Add(new VinteReais());
Interface Segregation principle
O princípio da segregação de interfaces diz que os clientes não devem depender de interfaces que não são usadas por eles, ou seja, nossas interfaces devem ser o mais coesas possível, minimizando o aclopamento do sistema.
O conceito foi introduzido por Robert Martin (vulgo uncle bob), e apresentado através do exemplo de um projeto de software desenvolvido para uma impressora da Xerox.
Neste projeto, os clientes dependiam de uma única classe gigante de job. Para resolver este problema, foi criada uma camada de interfaces entre a classe gigante e os clientes, usando o princípo de inversão de dependência. Agora cada cliente faria acesso a sua própia interface, que é implementada pela classe gigante, escondendo os métodos que não dizem respeito a este cliente.
Dependency inversion principle
O princípio de inversão de dependência diz que as classes do nosso projeto devem depender de abstrações e não de implementações concretas.
Por exemplo:
public class CartaDeBaralho()
{
}
public class Ordenador()
{
public void Ordena( List<CartaDeBaralho>) {}
}
No exemplo de código acima, a classe Ordenador depende da implementação de CartaDeBaralho.
O ideal seria a classe Ordenador depender de uma interface. Isto evita duplicação de código através da reutilização, deixando a lógica de comparação para cada uma das entidades que implementarem a interface (de volta a coesão). Por exemplo:
public interface IOrdenavel()
{
void Compara();
}
public class CartaDeBaralho(): IOrdenavel
{
public void Compara()
{
}
}
public class Ordenador()
{
public void Ordena( List<IOrdenavel>) {}
}
Good stuff:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
http://www.slideshare.net/ydarias/solid-principles-9721480
Labels:
arquitetura,
dependency,
design,
interface,
inversion,
liskov,
mdd,
oo,
pattern,
segregation,
software,
solid,
substitution
Wednesday, October 24, 2012
Introdução ao Domain Driven Design
O que é Domain Driven Design?
Domain Driven Design significa Projeto Orientado a Domínio. É um conjunto de práticas e padrões de desenvolvimento de software que foram apresentados no livro "Domain-Driven Design: Tackling Complexity in the Heart of Software" de Eric Evans, que pode ser obtido gratuitamente no link http://books.google.com.br/books?id=7dlaMs0SECsC&printsec=frontcover&redir_esc=y#v=onepage&q&f=false
Geralmente quando desenvolvemos um software estamos automatizando processos ou solucionando problemas que existem no mundo real. Esses problemas e processos podem ser considerados como o domínio do software. É muito importante compreendermos que o software é originado e extremamente relacionado a este domínio.
Por exemplo: Se vamos construir um sistema web que controla a matrícula dos alunos em uma faculdade, podemos enxergar a faculdade como o nosso domínio. Ele vai refletir todas as regras de negócio e processos que existem na faculdade. Os desenvolvedores não possuem conhecimento dessas regras e para isso precisam entrar em contato com os especialistas do domínio que seriam os diretores, coordenadores, professores e secretários.
Ao iniciar um projeto de desenvolvimento de software não podemos simplesmente sentar e programar. Pode até ser que isto funcione em alguns casos mais simples e triviais, mas para desenvolvermos sistemas complexos, sentar e progamar é condenar o projeto ao fracasso.
Nós devemos manter em foco o domínio ao qual o sistema está relacionado. O software precisa incorporar os principais conceitos e elementos do domínio e os relacionamentos que existem entre estes elementos, ou seja: O Software precisa ser um modelo do domínio.
Quando um sistema é bem desenhado, uma pessoa sem conhecimentos específicos do negócio consegue aprender bastante sobre o domínio através da leitura do modelo. Isso é essencial. Sistemas que não estão fortemente ligados ao domínio não reagem bem a mudança com o passar do tempo.
Quando usamos DDD, o primeiro passo que tomamos em um projeto de software é criar uma abstração do domínio. Nós precisamos aprender o máximo possível sobre este domínio através de entrevistas e conversas com os especialistas do negócio. Esse conhecimento não se transforma em código e elementos do software de maneira simples, é preciso primeiro criar uma abstração que define o modelo do domínio.
O modelo de um domínio não é um diagrama, nem um tipo de documento em particular. Na verdade o modelo do domínio é a idéiaexpressada por N diagramas e documentos do projeto. O modelo de domínio é uma parte essencial do design de software, nós precisamos dele para podermos lidar com a complexidade do sistema.
Quando nós temos um modelo definido, podemos começar a definir o design do código. Não devemos confundir design do código com arquitetura do software. A arquitetura consiste nas coisas que são difíceis de sere alteradas, os componentes principais do sistema enquanto o design de código trata de coisas mais específicas, detalhes pequenos e que provavelmente serão alterados a todo momento. Sem um design de código eficiente, o produto final não vai ser bom nem fácil de manter. Design patterns e boas práticas de progamação são essenciais para se obter um design de código eficiente.
Domain driven design combina design e desenvolvimento e mostra como eles devem trabalhar em conjunto para criar uma solução melhor. Um bom design vai acelerar o desenvolvimento, enquanto o feedback dos desenvolvedores fará com que sejam aplicadas melhorias ao design.
A necessidade de uma linguagem única
Conforme dito acima, é essencial definirmos um modelo de domínio. Este trabalho é feito pelos especialistas de software que trabalham em conjunto com os especialistas do negócio. Geralmente os especialistas do negócio possuem seus própios jargões e gírias enquanto a equipe técnica possui uma linguagem totalmente diferente (vivem pensando em classes, herança, polimorfismo, etc..) Problemas sérios acontecem quando estes dois times não conseguem se comunicar, ou se comunicam em linguagens distintas.
Um dos principios fundamentais do Domain Driven Design é fazer o time se comunicar em uma linguagem única, que é definida a partir do modelo do domínio. Esta linguagem única pe chamada de Linguagem Ubíqua e deve estar presente nas reuniões, documentos e no código do projeto. Ela conecta todas as partes do design e permite que os analistas, desenvolvedores e especialistas do domínio se comuniquem sem que haja ambiguidades, falha de interpretação ou falta de entendimento entre as partes.
Segue abaixo uma lista de sites muito bons para quem quer começar a aprender DDD:
Domain Driven Design significa Projeto Orientado a Domínio. É um conjunto de práticas e padrões de desenvolvimento de software que foram apresentados no livro "Domain-Driven Design: Tackling Complexity in the Heart of Software" de Eric Evans, que pode ser obtido gratuitamente no link http://books.google.com.br/books?id=7dlaMs0SECsC&printsec=frontcover&redir_esc=y#v=onepage&q&f=false
Geralmente quando desenvolvemos um software estamos automatizando processos ou solucionando problemas que existem no mundo real. Esses problemas e processos podem ser considerados como o domínio do software. É muito importante compreendermos que o software é originado e extremamente relacionado a este domínio.
Por exemplo: Se vamos construir um sistema web que controla a matrícula dos alunos em uma faculdade, podemos enxergar a faculdade como o nosso domínio. Ele vai refletir todas as regras de negócio e processos que existem na faculdade. Os desenvolvedores não possuem conhecimento dessas regras e para isso precisam entrar em contato com os especialistas do domínio que seriam os diretores, coordenadores, professores e secretários.
Ao iniciar um projeto de desenvolvimento de software não podemos simplesmente sentar e programar. Pode até ser que isto funcione em alguns casos mais simples e triviais, mas para desenvolvermos sistemas complexos, sentar e progamar é condenar o projeto ao fracasso.
Nós devemos manter em foco o domínio ao qual o sistema está relacionado. O software precisa incorporar os principais conceitos e elementos do domínio e os relacionamentos que existem entre estes elementos, ou seja: O Software precisa ser um modelo do domínio.
Quando um sistema é bem desenhado, uma pessoa sem conhecimentos específicos do negócio consegue aprender bastante sobre o domínio através da leitura do modelo. Isso é essencial. Sistemas que não estão fortemente ligados ao domínio não reagem bem a mudança com o passar do tempo.
Quando usamos DDD, o primeiro passo que tomamos em um projeto de software é criar uma abstração do domínio. Nós precisamos aprender o máximo possível sobre este domínio através de entrevistas e conversas com os especialistas do negócio. Esse conhecimento não se transforma em código e elementos do software de maneira simples, é preciso primeiro criar uma abstração que define o modelo do domínio.
O modelo de um domínio não é um diagrama, nem um tipo de documento em particular. Na verdade o modelo do domínio é a idéiaexpressada por N diagramas e documentos do projeto. O modelo de domínio é uma parte essencial do design de software, nós precisamos dele para podermos lidar com a complexidade do sistema.
Quando nós temos um modelo definido, podemos começar a definir o design do código. Não devemos confundir design do código com arquitetura do software. A arquitetura consiste nas coisas que são difíceis de sere alteradas, os componentes principais do sistema enquanto o design de código trata de coisas mais específicas, detalhes pequenos e que provavelmente serão alterados a todo momento. Sem um design de código eficiente, o produto final não vai ser bom nem fácil de manter. Design patterns e boas práticas de progamação são essenciais para se obter um design de código eficiente.
Domain driven design combina design e desenvolvimento e mostra como eles devem trabalhar em conjunto para criar uma solução melhor. Um bom design vai acelerar o desenvolvimento, enquanto o feedback dos desenvolvedores fará com que sejam aplicadas melhorias ao design.
A necessidade de uma linguagem única
Conforme dito acima, é essencial definirmos um modelo de domínio. Este trabalho é feito pelos especialistas de software que trabalham em conjunto com os especialistas do negócio. Geralmente os especialistas do negócio possuem seus própios jargões e gírias enquanto a equipe técnica possui uma linguagem totalmente diferente (vivem pensando em classes, herança, polimorfismo, etc..) Problemas sérios acontecem quando estes dois times não conseguem se comunicar, ou se comunicam em linguagens distintas.
Um dos principios fundamentais do Domain Driven Design é fazer o time se comunicar em uma linguagem única, que é definida a partir do modelo do domínio. Esta linguagem única pe chamada de Linguagem Ubíqua e deve estar presente nas reuniões, documentos e no código do projeto. Ela conecta todas as partes do design e permite que os analistas, desenvolvedores e especialistas do domínio se comuniquem sem que haja ambiguidades, falha de interpretação ou falta de entendimento entre as partes.
Segue abaixo uma lista de sites muito bons para quem quer começar a aprender DDD:
- http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
- http://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0CFkQFjAJ&url=http%3A%2F%2Fwww.slideshare.net%2Frponte%2Fentendendo-domaindriven-design&ei=VzGIUOmcFqiE0QGUu4DYDw&usg=AFQjCNHOMAeg7y6wBwh8jUxsukU8Yp5Now&sig2=_WGfBn1nLZY_x2YjUL0WdQ&cad=rja
- http://blog.fragmental.com.br/2007/06/22/cuidado-com-domain-driven-design/
- http://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=15&ved=0CIABEBYwDg&url=http%3A%2F%2Fwww.codeproject.com%2FArticles%2F339725%2FDomain-Driven-Design-Clear-Your-Concepts-Before-Yo&ei=VzGIUOmcFqiE0QGUu4DYDw&usg=AFQjCNHzOQQvmkrX8R661RVH7oLB66Ka5Q&sig2=EQJRR7_j0fvDsrzGRJDVwA&cad=rja
Labels:
.net,
arquitetura,
ddd,
Domain Driven Segin,
model
Friday, October 19, 2012
Enviando email através de webservices
Vou demonstrar neste post um exemplo de aplicação ASP.NET MVC que permite o envio de emails a partir de servidores SMTP previamente cadastrados no sistema.
O interessante desta aplicação é que vamos tirar a responsabilidade do envio de email da aplicação web e transferi-la para serviços WCF, que utilizam o mesmo modelo de domínio da aplicação. Misturando DDD e SOA, o sistema adota alguns padrões conhecidos como o Repository, Unity of Work, Abstract Factory, REST...
A topologia da arquitetura é demonstrada abaixo :
- Presentation Layers: Camadas responsáveis pela interface com o usuário.
- Application Control Layer: Camada responsável por fazer a ponte entre as camadas de apresentação e a camada de serviços, delegando o trabalho solicitado pelo usuário aos serviços necessários.
- Services Layer: Realiza o trabalho de fato. Dividida em duas camadas que possuem a mesma finalidade, porém são implementadas de maneira diferentes. (SOAP x REST)
- Data Access Layer: Responsável pela persistência de dados.
- Domain Model Layer: Responsável pela definição dos objetos e regras de negócio do domínio. Possui as entidades mapeadas abaixo:
Resumo do código para envio de email:
1 - Presentation Layer (Web):
2 - Application Control Layer:
3 - Services Layer:
4 - Domain Model Layer (Entidade Mensagem):
http://comprasonline.intcom.com.br/LogIn/
Para o login use email = teste@intcom.com.br e senha = teste
Para download dos arquivos da solução, use o link:
http://comprasonline.intcom.com.br/EmailServicesSample.rar
(Necessários: Visual Studio 2010, ASP NET MVC 3 e Sql Server Compact Edition - O URL estranho é devido a falta de tempo para registrar subdomínios)
Wednesday, October 17, 2012
Como especificar uma porta específica para o deploy de uma Web Application
Estou trabalhando em uma solução de N camadas com arquitetura orientada a serviços Restful. Algo parecido com:
Cada um dos serviços implementa uma injeção de dependência no construtor, para chamar o serviço é necessário um código parecido com:
using( var service = BusinessService.Factory.Service1(string URI))
{
//Do stuff
}
A aplicação web por sua vez, tem no arquivo de configuração a declaração de todas as URIs necessárias, algo parecido com:
<appSettings>
<add key="DataService1" value="http://localhost:1429/Service1/"/>
<add key="BusinessService1" value="http://localhost:2573/Service1/"/>
</appSettings>
Um problema foi encontrado quando o projeto era iniciado em outras máquinas, no ambiente de desenvolvimento: O URI do serviço era alterado e invalidava os dados do arquivo de configuração.
Isso acontecia por quê o Visual Studio definia uma porta aleatória para a aplicação que disponibiliza os serviços. Pesquisando na MSDN, descobri que existe uma maneira de configurar uma porta fixa para cada um dos projetos WEB na solução:
- In Solution Explorer, right-click the name of the Web application project for which you want to specify a Web server, and then click Properties.
- In the Properties window, click the Web tab.
- To choose the Visual Studio Development Server, under Servers, click Use Visual Studio Development Server.
- To use a specific port number with the Visual Studio Development Server, select Specific port and enter the port number. By default, the Auto-assign Port option is selected, and the port number that has been assigned to your application appears.
Segue o Link, que também contém outras dicas: http://msdn.microsoft.com/en-us/library/ms178108(v=vs.100).aspx
Friday, October 5, 2012
Levando o Controle de Alterações na Base de Dados para o Código
Um dos maiores problemas em um projeto de software é o controle de publicação de novas versões. Esse trabalho envolve um longo processo de revisão de código, atualização dos ambientes no qual faremos a publicação, (que pode incluir novos plugins) e um dos maiores problemas: as alterações feitas no modelo de dados da aplicação.
Caso você não esteja usando um framework de persistência que se encarregue de manter o equilíbrio entre o modelo de domínio e a base de dados, você vai precisar adotar algum processo exclusivo para manter o controle das alterações. Como por exemplo:

Hoje em dia é comum vermos equipes pequenas desenvolvendo aplicações orientadas a dados sem a presença de um recurso específico para manter o controle da base e das alterações (o DBA). Geralmente as alterações são documentadas em algum tipo de repositório na rede, ou até mesmo compartilhada por email entre os desenvolvedores (Caso estejam comitando o código e trabalhando com bases locais).
Acontece que a maioria dos processos estabelecidos são sujeitos a falhas e o controle pode se perder, principalmente quando um sistema muito antigo precisa ser atualizado para a última versão (do 1.0 pro 3.4, por exemplo). Pensando nesse problema resolvi passar o controle de documentação e execução das alterações de um determinado projeto para o código, me baseando no EntityFramework Migrations.
O conceito que eu tirei do Migrations é muito simples: Cada alteração feita na base de dados, gera uma nova migration. Essa migration recebe um número sequencial de versão e contém dois scripts diferentes:
Up: Script para publicação da alteração. (Por exemplo, criar uma tabela nova)
Down: Script para desfazer uma alteração. (Por exemplo, um drop de coluna. O script 'Down' é muito importante caso alguma publicação de release precise ser revertida. Ele funciona como um Recovery Plan da alteração)
Abaixo segue o diagrama do processo baseado em código:
Abaixo segue a implementação do código.
Primeiro, as classes que servem de base para as alterações adicionadas.
Sempre que um desenvolvedor da "commit" em uma alteração do banco, ele deve ao invés de encaminhar para o DBA, criar uma nova classe no projeto, com base nesta classe abaixo:
* o maior problema da implementação é que o número da alteração é gerado em hardcode. O desenvolvedor precisa estar atento para não haver duplicidade, mas isso pode ser facilmente resolvido com um pouco mais de capricho.
O namespace também disponibiliza um controlador para acionar a verificação automática de versão da base:
Agora na aplicação web, adicionamos ao arquivo Global.asax a chamada ao controlador, passando as dependências necessárias, a aplicação checa por um número de versão no web.config da aplicação, caso não encontre ele atualiza a base para a última versão com base nas classes adicionadas ao framework DataBaseMigrations.Versoes :
Caso você não esteja usando um framework de persistência que se encarregue de manter o equilíbrio entre o modelo de domínio e a base de dados, você vai precisar adotar algum processo exclusivo para manter o controle das alterações. Como por exemplo:

Hoje em dia é comum vermos equipes pequenas desenvolvendo aplicações orientadas a dados sem a presença de um recurso específico para manter o controle da base e das alterações (o DBA). Geralmente as alterações são documentadas em algum tipo de repositório na rede, ou até mesmo compartilhada por email entre os desenvolvedores (Caso estejam comitando o código e trabalhando com bases locais).
Acontece que a maioria dos processos estabelecidos são sujeitos a falhas e o controle pode se perder, principalmente quando um sistema muito antigo precisa ser atualizado para a última versão (do 1.0 pro 3.4, por exemplo). Pensando nesse problema resolvi passar o controle de documentação e execução das alterações de um determinado projeto para o código, me baseando no EntityFramework Migrations.
O conceito que eu tirei do Migrations é muito simples: Cada alteração feita na base de dados, gera uma nova migration. Essa migration recebe um número sequencial de versão e contém dois scripts diferentes:
Up: Script para publicação da alteração. (Por exemplo, criar uma tabela nova)
Down: Script para desfazer uma alteração. (Por exemplo, um drop de coluna. O script 'Down' é muito importante caso alguma publicação de release precise ser revertida. Ele funciona como um Recovery Plan da alteração)
Abaixo segue o diagrama do processo baseado em código:
Abaixo segue a implementação do código.
Primeiro, as classes que servem de base para as alterações adicionadas.
Sempre que um desenvolvedor da "commit" em uma alteração do banco, ele deve ao invés de encaminhar para o DBA, criar uma nova classe no projeto, com base nesta classe abaixo:
* o maior problema da implementação é que o número da alteração é gerado em hardcode. O desenvolvedor precisa estar atento para não haver duplicidade, mas isso pode ser facilmente resolvido com um pouco mais de capricho.
O namespace também disponibiliza um controlador para acionar a verificação automática de versão da base:
Agora na aplicação web, adicionamos ao arquivo Global.asax a chamada ao controlador, passando as dependências necessárias, a aplicação checa por um número de versão no web.config da aplicação, caso não encontre ele atualiza a base para a última versão com base nas classes adicionadas ao framework DataBaseMigrations.Versoes :
Wednesday, October 3, 2012
O papel do arquiteto de softwares
Hoje estava lendo um artigo escrito por Martin Fowler entitulado "Who needs an architect?" e gostaria de destacar alguns conceitos que pude retirar do texto.
Estes conceitos nos ajudam a compreender qual é o papel de um arquiteto de softwares em um projeto de desenvolvimento e também nos ajudam a definir melhor o conceito "arquitetura de softwares".
O que é arquitetura de software?
De acordo com o RUP (Rational Unified Process) podemos definir arquitetura de softwares da seguinte maneira:
"O conceito de mais alto nível de um sistema. A arquitetura de um sistema de software é a sua organização ou a estrutura dos componentes mais importantes interagindo através de interfaces, sendo que esses componentes, por sua vez, são compostos de componentes e interfaces sucessivamente menores."
Ralph Johnson (http://pt.wikipedia.org/wiki/Ralph_Johnson) se mostra contrário a essa definição pois ele acredita que não existe um conceito de nível mais alto em um sistema, pois esse conceito depende do seu ponto de vista.
Clientes possuem um conceito totalmente diferente dos desenvolvedores do sistema, eles não se importam com a estrutura dos componentes em si, e sim com as funcionalidades do sistema. Tendo isso em mente, ele prefere definir arquitetura da seguinte maneira:
"Na maioria dos projetos de software bem sucedidos os desenvolvedores mais experientes do projeto compartilham um entendimento único do design do sistema. Esse entendimento compartilhado é chamado de 'arquitetura' e inclui a maneira na qual o sistema se divide em componentes interagindo através de interfaces, sendo que esses componentes, por sua vez, são compostos de componentes e interfaces sucessivamente menores.".
Outra boa definição levantada:
"Arquitetura é um grupo de decisões de design que devem ser feitas no início do projeto."
O problema desta última definição é o fato de que é muito difícil acertar todas essas decisões. Então se é muito difícil tomar essas decisões acertadas no início do projeto, por quê que a maioria dos analistas continuam tentando?
A resposta é bastante óbvia. Essas decisões são tomadas pois vão gerar componentes de software que são difíceis de serem alterados. Por exemplo: Se você optou por persistir os dados no SQL Server, e mapeou as entidades com LINQ to SQL, uma vez que a aplicação esteja toda escrita baseada nesse mapeamento objeto-relacional , você provavelmente nunca mais vai se livrar dele.
Tendo isso em mente podemos definir arquitetura como:
"Componentes do software que são muito difíceis de se alterar."
Qual é o papel do arquiteto de softwares?
Uma das tarefas mais importantes de um arquiteto é encontrar maneiras de eliminar irreversibilidade e reduzir a complexidade de um determinado projeto de software. Ele deve ser muito ciente do que está acontecendo no projeto,olhando para questões importantes e deve abordá-las antes que se tornem um problema sério.
A parte mais visível do trabalho de um arquiteto de softwares é a colaboração intensa com os outros recursos do projeto. Pela manhã, um arquiteto pode estar programando junto com um desenvolvedor, enquanto na parte da tarde, o arquiteto participa de uma reunião de requisitos junto aos StakeHolders e clients, ajudando a explicar o impacto e consequência técnica das decisões que estão sendo tomadas.
O arquiteto é um dos mais experientes membros da equipe, e deve atuar como um guia. Responsável por ensinar outros recursos a tomar as melhores decisões e adotar boas práticas para evitar problemas futuros além de ajuda-los tecnicamente em tarefas mais complexas.
Fonte: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Estes conceitos nos ajudam a compreender qual é o papel de um arquiteto de softwares em um projeto de desenvolvimento e também nos ajudam a definir melhor o conceito "arquitetura de softwares".
O que é arquitetura de software?
De acordo com o RUP (Rational Unified Process) podemos definir arquitetura de softwares da seguinte maneira:
"O conceito de mais alto nível de um sistema. A arquitetura de um sistema de software é a sua organização ou a estrutura dos componentes mais importantes interagindo através de interfaces, sendo que esses componentes, por sua vez, são compostos de componentes e interfaces sucessivamente menores."
Ralph Johnson (http://pt.wikipedia.org/wiki/Ralph_Johnson) se mostra contrário a essa definição pois ele acredita que não existe um conceito de nível mais alto em um sistema, pois esse conceito depende do seu ponto de vista.
Clientes possuem um conceito totalmente diferente dos desenvolvedores do sistema, eles não se importam com a estrutura dos componentes em si, e sim com as funcionalidades do sistema. Tendo isso em mente, ele prefere definir arquitetura da seguinte maneira:
"Na maioria dos projetos de software bem sucedidos os desenvolvedores mais experientes do projeto compartilham um entendimento único do design do sistema. Esse entendimento compartilhado é chamado de 'arquitetura' e inclui a maneira na qual o sistema se divide em componentes interagindo através de interfaces, sendo que esses componentes, por sua vez, são compostos de componentes e interfaces sucessivamente menores.".
Outra boa definição levantada:
"Arquitetura é um grupo de decisões de design que devem ser feitas no início do projeto."
O problema desta última definição é o fato de que é muito difícil acertar todas essas decisões. Então se é muito difícil tomar essas decisões acertadas no início do projeto, por quê que a maioria dos analistas continuam tentando?
A resposta é bastante óbvia. Essas decisões são tomadas pois vão gerar componentes de software que são difíceis de serem alterados. Por exemplo: Se você optou por persistir os dados no SQL Server, e mapeou as entidades com LINQ to SQL, uma vez que a aplicação esteja toda escrita baseada nesse mapeamento objeto-relacional , você provavelmente nunca mais vai se livrar dele.
Tendo isso em mente podemos definir arquitetura como:
"Componentes do software que são muito difíceis de se alterar."
Qual é o papel do arquiteto de softwares?
Uma das tarefas mais importantes de um arquiteto é encontrar maneiras de eliminar irreversibilidade e reduzir a complexidade de um determinado projeto de software. Ele deve ser muito ciente do que está acontecendo no projeto,olhando para questões importantes e deve abordá-las antes que se tornem um problema sério.
A parte mais visível do trabalho de um arquiteto de softwares é a colaboração intensa com os outros recursos do projeto. Pela manhã, um arquiteto pode estar programando junto com um desenvolvedor, enquanto na parte da tarde, o arquiteto participa de uma reunião de requisitos junto aos StakeHolders e clients, ajudando a explicar o impacto e consequência técnica das decisões que estão sendo tomadas.
O arquiteto é um dos mais experientes membros da equipe, e deve atuar como um guia. Responsável por ensinar outros recursos a tomar as melhores decisões e adotar boas práticas para evitar problemas futuros além de ajuda-los tecnicamente em tarefas mais complexas.
Fonte: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Subscribe to:
Comments (Atom)













