quinta-feira, 26 de junho de 2008

Jornal de Arquitetura da Microsoft

O jornal de arquitetura da Microsoft, The Architecture Journal, é uma publicação que traz a opinião de Arquitetos da comunidade de Arquitetos da Microsoft. Este jornal trata de assuntos relacionados à arquitetura de aplicações e gestão e infra-estrutua de TI.

Recentemente a Microsoft publicou um leitor para este jornal. O The Architecture Journal Reader é um aplicativo WPF, que apresenta como recursos a sincronização automática com novo conteúdo publicado, índice de leitura, resumos e mecanismo de pesquisa, entre outros.

quarta-feira, 18 de junho de 2008

Mobiltec no CIAB Febraban 2008

A Mobiltec foi novamente premiada com o Melhor Produto Inovador no Espaço Inovação do CIAB Febraban 2008.

O produto apresentado no Congresso foi o Atendente Móvel, que utiliza tecnologia de mobilidade. Com isso os bancos poderão atender seus clientes de forma mais ágil e eficiente, dentro e fora das agências.

A solução é equipada com dispositivo PDA totalmente integrado, com funções de leitora de cartões magnéticos, leitora de código de barras, teclado numérico e impressora térmica.

Informações técnicas:

  • A solução é compatível com dispositivos Windows Mobile 5.0 ou superior
  • A comunicação pode ser realizada através de rede Wi-Fi ou através de redes celular
  • A segurança é garantida pelo uso de comunicação segura HTTPS e certificação digital, padrões da indústria financeira

Middleware de Mobilidade:

A solução tem como alicerce o Middleware de Mobilidade M3, que agrega:

  • Flexibilidade na gerência dos dispositivos móveis
  • Controle das transações realizadas
  • Disponibilidade e a escalabilidade da solução
  • Integração com os sistemas corporativos

Referências:

segunda-feira, 16 de junho de 2008

Papéis no desenvolvimento de software

Há alguns dias fui questionado sobre as atribuições de Arquitetos, Analistas e Engenheiros de sistemas. Este tipo de pergunta é muito freqüente na nossa área.

Embora não seja um consenso, é possível discriminar as atividades de cada um destes papéis.

Analista:

Tem como atribuições levantar e especificar, junto aos usuários, os requisitos funcionais do sistema.

Atividades relacionadas:

  • Reuniões com os usuários (Stakeholders) para levantamento dos requisitos
  • Construção de protótipos
  • Modelagem de casos de uso

Engenheiro:

O engenheiro é o profissional responsável por definir e manter o projeto da infra-estrutura de rede e componentes físicos que darão suporte ao sistema.

Atividades relacionadas:

  • Modelagem de diagramas físicos de implantação
  • Suporte à implantação do sistema

Arquiteto:

Tem como atribuições definir e manter a estrutura organizacional de um sistema. O arquiteto define classes, componentes e subsistemas e suas interações, relações e restrições. A visão do arquiteto é a mais abrangente, dentre os mebros da equipe do projeto.

Segundo o RUP, "o arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos".

Arquiteto de Software - RUP 2003.06.00.06

Atividades relacionadas:

  • Elaboração do Documento de Arquitetura
  • Elaboração dos Guias de Projeto e Programação
  • Modelagem de diagramas de implantação do sistema
  • Modelagem de diagramas de componentes (implementação)

Para quem busca uma classificação mais detalhada e abrangente do perfil de Arquiteto, sugiro a leitura deste link (em inglês):

sexta-feira, 13 de junho de 2008

.NET Remoting no IIS com BinaryFormatter

O .NET Remoting é o mecanismo do .NET Framework que permite o desenvolvimento de aplicações distribuídas.

Na Mobiltec estamos desenvolvendo um sistema distribuído, onde passei pela necessidade de montar a Arquitetura da solução utilizando o Remoting. Neste sistema, os objetos estarão hospedados no IIS, onde a comunicação é efetuada através de HTTPChannel, e será utilizada serialização binária com BinaryFormatter.

A configuração do ambiente do Remoting é cercada de detalhes. A seguir reproduzo um passo a passo desta configuração, com trechos de código e configurações. Os códigos, escritos em C#, não são parte do sistema citado, apenas exemplos.

Definição dos objetos distribuídos

Os objetos distribuídos representam serviços que uma camada de componentes oferece para uma camada de apresentação do sistema. Para viabilizar a criação de Proxies, por parte do .NET Remoting, é necessário que a classe que representa o objeto distribuído faça herança do tipo MarshalByRefObject. Interfaces são aplicadas para que a camada 'consumidora' dos objetos remotos conheça os métodos oferecidos pelo objeto remoto. Segue um exemplo.

public class AccountBLL: MarshalByRefObject, IAccountBLL
{
 Account IAccountBLL.GetAccount(string _accountName)
 {
 ...
 }
}

Definição dos objetos 'transportados'

As classes que representam os objetos a serem transportados são serializadas/desserializadas para a comunicação. O atributo Serializable é utilizado para indicar que uma classe pode ser serializada.

[Serializable]
public class Account
{
 public string Name
 {
 get { ... }
 set { ... }
 }

 public <ListTransaction> Transactions
 {
 get { ... }
 set { ... }
 }
}

Configuração do servidor IIS

A pasta virtual do IIS contém os binários da parte servidora do sistema em uma pasta bin e o respectivo Web.config da aplicação. No Web.config, configuramos as propriedades do .NET Remoting e os objetos que são expostos na rede. O exemplo a seguir utiliza a combinação do canal HTTP com o BinaryFormatter e exporta um objeto exemplo.

<configuration>
 <system.runtime.remoting>
 <application>

 <!-- Canal HTTP com formatação binária -->
 <channels>
 <channel ref='http'>
 <serverProviders>
 <formatter ref='binary'/>
 </serverProviders>
 </channel>
 </channels>

 <!-- Serviços expostos -->
 <service>
  <wellknown mode="SingleCall"
   type="BLL.AccountBLL, BLL"
   objectUri="Account.rem"/>
 </service>

 </application>
 </system.runtime.remoting>
</configuration>

Configuração da aplicação cliente

A aplicação cliente, assim como o servidor, deve indicar o uso do HTTPChannel e BinaryFormatter.

<configuration>
 <system.runtime.remoting>
 <application>

 <!-- Canal HTTP com formatação binária -->
 <channels>
 <channel ref='http'>
 <clientProviders>
 <formatter ref='binary'/>
 </clientProviders>
 </channel>
 </channels>

 </application>
 </system.runtime.remoting>
</configuration>

No início da aplicação, ou em algum outro momento conveniente, deve ser aplicada esta configuração explicitamente (Perceba que no servidor não foi necessário. O próprio ASP.NET se encarregou de aplicar as configurações do Web.config)

RemotingConfiguration.Configure("App.config", false);

Acesso aos objetos remotos

Já estamos prontos para fazer o acesso ao objeto remoto na aplicação cliente. A interface do componente remoto é utilizada para fins de montagem do Proxy do objeto e para acesso aos métodos disponíveis.

IAccountBLL accBLL = (IAccountBLL)
 Activator.GetObject(typeof(IAccountBLL),
 "http://localhost/SampleRemoting/Account.rem");

Account acc = accBLL.GetAccount("Nome");

O .NET Remoting viabilizou o acesso a um objeto remoto, como se fosse uma instância local. Então muito cuidado. É necessário cercar o acesso com tratamentos relacionados à disponibilidade do serviço remoto e também é preciso considerar os impactos de performance.

Diretivas Option Explicit e Option Strict do VBNet (de 06/06/08)

Programadores da linguagem C# percebem claramente que o VBNet traz flexibilidades à programação. O compilador C# é mais rígido com declarações de variáveis e conversões de tipos do que o compilador VBNet.

Para aqueles que gostam da maior rigidez do compilador, existem duas diretivas que ativam validações do compilador VBNet.

Option Explicit On:

Com esta diretiva declarada, todas as variáveis utilizadas devem ser declaradas com Dim ou ReDim. O código a seguir gera erro de compilação com Option Explicit On:

Dim thisVar As Integer
thisVar = 10
thisInt = 10 ' erro de compilação

Option Strict On:

Com esta diretiva declarada, conversões implícitas de tipo, com perda de informação, são rejeitadas pelo compilador. O código a seguir gera erro de compilação com Option Strict On:

Dim thisVar As Integer
thisVar = 1000
thisVar = 123456.789 ' erro de compilação

Esta opção proporciona uma tipagem mais forte, previne conversões com perdas não intencionais e desabilita a late binding, desta forma melhorando o desempenho do código.

Ativação das diretivas

São duas as formas de ativação:

  1. De forma global na IDE, caso esta ofereça (Visual Studio 2005 oferece a ativação de ambas no menu de opções do compilador VBNet)
  2. No código fonte. Estas diretivas devem aparecem logo no início do código fonte

Documentação da arquitetura de um sistema (de 11/02/08)

Durante a fase de elaboração de um projeto baseado no RUP (Rational Unified Process), um artefato chave é o documento de arquitetura do sistema. Este artefato define a estrutura, a comunicação de componentes e endereça requisitos não-funcionais do sistema.

O documento de arquitetura tem como propósito comunicar a estrutura do sistema para as partes interessadas no mesmo, como patrocinadores, vendedores, técnicos, desenvolvedores, usuários e outros. Estes nitidamente com conhecimentos, interesses e foco totalmente distintos uns dos outros. Para isto tipicamente são utilizados diferentes níveis de abstração, onde visões distintas são criadas sobre os componentes da arquitetura e estes componentes são hierarquicamente decompostos para satisfazer diferentes níveis de interesse.

Tipicamente utilizo dois diagramas clássicos da UML para a descrição geral da arquitetura de um sistema:

Visão de componentes:

Aqui utilizo o diagrama de componentes para descrever os elementos significativos da arquitetura e as suas relações. Estes elementos podem ser componentes desenvolvidos no projeto, bibliotecas de terceiros, subsistemas e classes, entre outros.

Dentro da idéia de decomposição, são criados tantos diagramas quantos forem necessários para detalhar componentes complexos.

Visão de implantação:

Nesta visão o diagrama de implantação explora o cenário físico de alocação dos componentes em máquinas e como eles se comunicam através de redes, bancos de dados e arquivos.

Esta visão apresenta o potencial de escalabilidade do sistema, necessidades de hardware, entre outros.

Em interações com usuários e equipes de desenvolvimento, percebi que uma outra visão bastante esclarecedora e muito importante é a Visão de Desenvolvimento.

Esta explora idéias fundamentais da organização do sistema, de particular interesse da equipe de desenvolvimento: A estrutura interna dos componentes do sistema, como os códigos-fonte e outros artefatos são manipulados no ambiente de desenvolvimento e como estes são mantidos em repositórios de controle de versão.

Creio que o sucesso do documento de arquitetura passa por conseguir levar aos diferentes tipos de indivíduos envolvidos os diversos aspectos da estrutura do sistema de forma clara e objetiva.

Rational SW Modeler x Enterprise Architect (de 13/05/07)

No momento, estou envolvido em um projeto de desenvolvimento de um sistema para um grande cliente do Rio de Janeiro. Meu papel no projeto é o de Arquiteto, embora também exerça outros papéis.

Ainda em fase de elaboração, um dos desafios é montar o ambiente de análise do sistema, ou seja, definir a ferramenta Case e o processo de análise. Há de se levar em consideração aspectos relacionados às etapas de Design e codificação, pois é interessante que uma única ferramenta seja utilizada em todo o projeto, a fim de otimizar a comunicação e a integração entre as etapas do ciclo de desenvolvimento.

O sistema em questão será desenvolvido em plataforma .NET, utilizando tecnologias como ASP.Net Web Forms, Ajax, .NET Remoting, ADO.Net e muito provavelmente o Windows Workflow Foundation.

Algumas características do sistema e do ambiente desenvolvimento:

  1. Por exigência do cliente, o sistema será desenvolvido em linguagem VB.NET, visto que a equipe do cliente é especializada nesta linguagem. Isto é fundamental pois a proposta é que a manutenção do sistema seja feita por esta equipe do cliente
  2. A equipe do projeto estará geograficamente dispersa: Analistas dentro das instalações do cliente, no Rio de Janeiro, e demais etapas do desenvolvimento na Fábrica de Software, em Porto Alegre. Os modelos UML são compartilhados entre as equipes.

Por forte recomendação do cliente, que utiliza esta plataforma de modelagem, a primeira opção a ser avaliada é a ferramenta Rational SW Modeler, da IBM. A ferramenta possui integração com repositório de fontes do tipo CVS (Concurrent Version System), que é o habilitador do cenário de compartilhamento dos modelos. A deficiência da ferramenta fica por conta de não oferecer engenharia de código para a linguagem VB.NET. No caso de utilização desta ferramenta, geração de código não existe e sincronização de modelos vira um processo manual. A impressão que fica é que o Rational SW Modeler é um gigante que faz muito pouco.

Outra ferramenta análisada foi o Enterprise Architect, da Sparx Systems. Esta, por sua vez, parece ser uma ferramenta muito mais focada na plataforma .NET. Oferece engenharia de código com VB.NET e integração com repositório de fontes do tipo CVS, VSS (Visual Source Safe) e o TFS (Team Foundation Server). No que se refere a UML, o Enterprise Architect parece muito superior ao SW Modeler. A única questão que não fica muito interessante é que o Enterprise Architect força um mesmo modelo de manipulação do repositório para todos os repositórios (no caso, o modelo de check-out com lock e check-in do VSS). Nisto o SW Modeler é mais flexível.

Embora a tendência a termos que utilizar o SW Modeler, por exigência do cliente, estamos com uma iniciativa forte para convencermos a equipe técnica do mesmo a aceitar a utilização do Enterprise Architect. Este segundo parece muito mais aderente ao cenário do projeto e ao futuro do sistema. Além de ter um custo muito inferior ao custo do primeiro.

Novo blog, apresentações

Com as limitações de meu blog anterior, estou iniciando as atividades no Blogger.

Sou Eduardo Klein, 26 anos. Moro e trabalho em Porto Alegre/RS.

Trabalho com desenvolvimento de sistemas, principalmente sobre a plataforma .NET, na Mobiltec (http://www.mobiltec.com.br). A Mobiltec atua no desenvolvimento de sistemas próprios (produtos) e para terceiros (projetos externos), através de prestação de serviço.

No ciclo de vida dos sistemas desenvolvidos, seja os internos ou os externos, atuo principalmente na parte de Arquitetura destes e nas etapas de desenvolvimento, dentro da Fábrica de Software.

Maiores detalhes ao meu respeito podem ser vistos no meu site pessoal, em http://www.paginas.terra.com.br/informatica/epklein.

Saudações, Eduardo Klein