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...
quarta-feira, 26 de março de 2008
quinta-feira, 20 de março de 2008
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:
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.
- 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.
terça-feira, 18 de março de 2008
Discontração
Why do computer programmers confuse Halloween with Christmas?
Because Oct 31 = Dec 25.
=)
Because Oct 31 = Dec 25.
=)
segunda-feira, 17 de março de 2008
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 softwarefree 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.
"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
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.
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.
Assinar:
Postagens (Atom)
