Interfaces Ricas

RIA é uma sigla muito discutida recentemente. Vem de Rich Interfaace Applications. Ou Aplicações com Interfaces Ricas. O termo aplica-se, basicamente, a aplicações para Internet, já que (em teoria) aplicações desktop já possuem Interfaces Ricas (ou deveriam possuir).

Recentemente estive em contato com algumas tecnologias que prometem realizar os sonhos de muitos programadores web. Adianto que nenhuma é perfeita. Todas têm pontos positivos e negativos. E cada uma pode ser melhor em determinada situação.

Nos últimos meses pesquisei e testei Ajax, Silverlight e Flex.

Ajax resume-se, basicamente na utilização de XML e javascript trabalhando em conjunto para permitir posts assíncronos. Utilizei duas bibliotecas: AjaxToolkit, da Microsoft, em conjunto com Visual Studio (C#) e ICEFaces, da ICESoft, em conjunto com o Eclipse (Java). A solução da Microsoft exige bastante codificação javascript. A solução Java possui mais componentes e esconde um pouco do javascript neles, mas é de difícil configuração.

Silverlight, da Microsoft, permite a criação de Interfaces bastante ricas. Uma grande vantagem é que o programador .NET não precisa aprender outra linguagem. A página, apesar de não ser em ASP.NET, é em XAML (que é quase um XML). a parte servidora pode ser em qualquer linguagem do Framework .NET (C# ou VB.NET, por exemplo). Mas o SL peca por não possuir muitos componentes disponíveis. Além de não ser multiplataforma. Fanáticos por Microsoft poderiam dizerq ue o Silverlight é multiplaforma: "roda no Vista, no XP, noServer 2008, no Server 2003". Pra mim é pouco. O Silverlight já está lançando a versão 2.0 e ainda não tem plugin para o Firefox rodando no Linux? Pra mim é pouco! Silverlight pode ser ideal para aplicações 100% ambiente Windows. Se precisar de um pouco de portabilidade, melhor procurar outra opção.

Flex, da Adobe, constrói interfaces ricas através de aplicações Flash. O framework já traz muitos componentes e efeitos fáceis de utilizar em uma aplicação web. Apesar do Flex utilizar ActionScript, uma linguagem que eu não conhecia, achei muito fácil trabalhar com ele. Uma grande dificuldade que tive até agora foi encontrar uma forma de gerar, visualizar e imprimir relatórios.

Programando por Interfaces

Já ouvi de várias pessoas diversas vantagens sobre programar através da Interface. O princípio é simples: crie Interfaces para só depois criar as Implementações.

Eu poderia citar e dissertar sobre as diversas vantagens. Que vão desde permitir que o contrato das classes sejam estabelecidos antes de suas implementações, até encapsular as classes concretas, deixando à mostra somente o que interessa: como utilizar a classe. Porém, já existem diversos artigos por aí explicando essas vantagens em detalhes.

O que tenho a dizer é que será muito mais fácil compreender estas vantagens se tivermos um exemplo de como e por quê isso funciona.

Normalmente, temos a noção de quais métodos nossa classe vai precisar possuir. Se você mal escreve a assinatura do primeiro método e já parte para a sua implementação, corre um sério risco de esquecer tudo o que havia planejado no início. Criar a Interface antes também ajuda a não deixar este problema acontecer.

Um pouco de código... Duas Interfaces para nosso projeto de Matriz de Rastreabilidade. Interfaces para Entidades de Negócio.


ITipoDeArtefato.cs

---

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace Dominio.Interfaces

{

public interface ITipoDeArtefato

{

void setCodigo(int codigo);

int getCodigo();

void setDescricao(string descricao);

string getDescricao();

}

}

IArtefato.cs

---

using System;

using System.Collections.Generic;

using System.Text;

namespace Dominio.Interfaces

{

public interface IArtefato

{

void addImpactado(IArtefato artefato);

void removeImpactado(IArtefato artefato);

void addDependencia(IArtefato artefato);

void removeDependencia(IArtefato artefato);

int getCodigo();

string getDescricao();

void setCodigo(int codigo);

void setDescricao(string descricao);

ITipoDeArtefato getTipoDeArtefato();

void setTipoDeArtefato(ITipoDeArtefato tipoDeArtefato);

IDictionary<int, IArtefato> getListaImpactados();

IDictionary<int, IArtefato> getListaDependencias();

void setListaImpactados(IDictionary<int, IArtefato> listaImpactados);

void setListaDependencias(IDictionary<int, IArtefato> listaDependencias);

}

}

Um bom exemplo de .NET Remoting

Tentando conhecer pouco mais sobre .NET Remoting, encontrei um site interessante com um bom exemplo. Nele é mostrado como um cliente pode criar instâncias para um objeto remoto, que está em um serviddor que publica serviços através de .NET Remoting.

Bem simples e prático, ele mostra .NET Remoting funcionando através de TCP. Vale lembrar que ele também permite conexões via HTTP.

Eis o link:
http://www.developer.com/net/cplus/article.php/10919_1479761_1

Vale à pena conferir...

Matriz de Rastreabilidade (Parte 2)

Arquitetura de Software

O domínio é pequeno, e talvez não exigisse uma arquitetura elaborada. Mas para praticar um pouco, quis utilizar um padrão com o qual já tive contato e já vi funcionando tanto em .NET quanto em Java.

Os nomes das camadas podem mudar, mas já vi muita gente utilizando algo semelhante ao que é apresentado no modelo abaixo:

Algumas considerações:
- Cada camada acessa outra através de fábricas.
- Apresentação conhece Interfaces de Façade e Domínio
- Façade conhece Interfaces de DAO e Domínio.
- DAO conhece de Domínio.
- Classes das camadas Façade e DAO são Singleton.
- Controlodor de tela é responsável por controles de tela e entra/saída de dados.
- Façade é responsável por processar informações, manipular objetos e encaminhá-los à DAO.
- Dentro da Façade é que o sistema é distribuído.
- DAO é responsável pelo mapeamento OR.
- É de Domínio que surgem os objetos de negócio.

Discontração

Why do computer programmers confuse Halloween with Christmas?



Because Oct 31 = Dec 25.


=)

Matriz de Rastreabilidade (Parte 1)

Motivação

"A Matriz de Rastreabilidade auxilia bastante na identificação de impactos." Muitos concordam com isso. Entretanto, basta o primeiro aperto durante o ciclo de desenvolvimento e esta frase parece ser esquecida.

Também pudera. Em muitos casos, a Matriz de Rastreabilidade é algo extremamente complicado de ser mantido. Não conheço nenhum software free acessível que mantenha esta matriz. O fato é que existem softwares bastante completos em que a Matriz, ou as associações entre artefatos, é apenas uma parte de todo um conjunto de funcionalidades.

Até para passar o tempo, há algum tempo atrás, comecei a desenvolver uma Matriz de Rastreabilidade em VS.NET 2005. O projeto parou. Quando surgiu a oportunidade em um trabalho de grupo, sugeri para outros três colegas que fizéssemos um software que gerenciasse impactos entre artefatos. A linguagem era Java. A idéia evoluiu e hoje estamos fazendo este trabalho.

Mas agora preciso voltar a estudar .NET. Pensei, então, em recomeçar o projeto para ser minha nova cobaia em C#.

Sem complicações e muita delonga, vamos lá!

Todos sabem o quanto é importante eliciar, encontrar, analisar, documentar e validar requisitos. Estas atividades são muito importantes porque blá blá blá blá blá... Não quero dizer que não seja importante. É sim! E muito. Só não quero fazer isso agora! Afinal, todo mundo sabe como funciona uma matriz de rastreabilidade.

Se temos N artefatos, teremos uma matriz NxN em que cada célula representa a relação entre dois artefatos. A relação pode ser do tipo "depende de", "impacta em", "não está relacionado diretamente". A legenda que cada um utiliza para representar é indiferente neste momento.

Ok, ok! Esta é para os mais conservadores (analistas de requisitos que ficam com medo de perder o emprego quando alguém põe a mão na massa sem falar com ele): suponhamos que eu levantei (já conhecia) e validei (comigo mesmo) os requisitos, e estão todos anotados (na minha cabeça). Tenho um pouco de tempo. Farei uma rápida repassada.

Então, vamos lá!

Um artefato de software possui uma descrição e um identificador numérico único. Um artefato pode ser do tipo "Especificação de Caso de Uso", "CONOPs - Conceitos de Operações", "Classe de Design", entre outros. Seria legal que tipo fosse uma classe. Código e descrição são suficientes?

Maravilha! Agora eu posso cadastrar todos os artefatos de software no meu sistema. Ótimo! Mas e aí? Cadê a tal matriz?

Agora vem, talvez, a parte mais complicada da história. Cada artefato pode impactar em zero ou mais artefatos (0..*). Da mesma forma, um artefato pode depender de zero ou mais artefatos. E agora? Lascou?

Começamos bem! Temos um auto-relacionamento.

Se minhas aulas de UML e Orientação a Objetos valeram de alguma coisa, acho que podemos representar isto de três maneiras.

Assim:
Associações com setas.

Ou talvez assim:
Associações como atributos.

Alguns até representam assim:
Associações como atributos e com setas.

Prefiro não querer acreditar que uma abordagem é certa ou melhor que a outra. Eu, particularmente, não gosto de redundância. Então, não utilizo a terceira (atributos e setas). Gosto mais da segunda (como atributos), pois deixa o modelo mais enxuto. Nada contra quem prefere usar muitas setas, gosto pessoal.

Temos nosso modelo de domínio. O problema parece bem simples e, aparentemente, este modelo permite que tenhamos as informações necessárias para nossa matriz:
- Quais são os artefatos?
- Qual o tipo de cada artefato?
- Quem depende de quem?
- Quem impacta em quem?

A seguir, tentarei esboçar a Arquitetura de Software que pretendo utilizar para resolver nosso problema.

- O quê!? Você vai projetar e documentar uma arquitetura para um sistema que tem apenas duas classes no modelo de domínio?

Sim, eu vou! É uma ótima oportunidade para experimentar e fazer testes. Não quero deixá-la passar.

Um novo começo...

Este não é o primeiro blog que crio. E, provavelmente, não será o último. Também não é o primeiro sobre Desenvolvimento de Software.

A intenção é registrar um pouco da experiência que tive e venho tendo com Engenharia de Software.

Vou criar posts e escrever como se fosse para diversas pessoas, interessadas ou não no assunto, lerem. Vou, inclusive colocar anúncios no blog. Se alguém quiser clicar nestes links e me ajudar a ficar rico, ótimo! :-) Mas se ninguém gostar dos anúncios, ninguém quiser nem ler e muito menos entrar no blog... sem problemas! Vou continuar assim, mesmo.

Claro que escrever para alguém é melhor do que escrever para ninguém. Comentários com sugestões, perguntas, críticas construtivas e idéias serão sempre bem vindos.