Desculpem a demora em atualizar e dar continuidade a esta série de videos-demo do DSL. Estava em férias, e férias quer dizer sem computador :) . Vamos então retomar a nosso exemplo de DSL.
No último "post" terminou-se a construção básica da DSL que representa a máquina de estados, criamos o toolbox. Ou seja, algo muito parecido com a figura apresentada no Laboratório 1 - Parte 3 e nas Figuras 1 e 2 do Laboratório 1 - Parte 2; Entretanto esta DSL na forma em que ela se encontra ainda possue uma série de limitações que requerão um comportamento exemplar de quem quer que venha usá-la. Na prática isto não ocorre, em geral as pessoas tendem a não seguir comportamentos exemplares, existindo sim comportamentos que cobrem os dois extremos. Ou seja pessoas relapsas que construirão diagramas impossíveis e pessoas cuidadosas mas curiosas que por fim conseguiram também gerar diagramas impossíveis. Desta forma temos de complementar a DSL até aqui apresentada para que possamos lidar com estas possibilidades e previnir que os usuários da DSL gerem representações sem sentido. Para tornar mais claro tomemos por exemplo o caso do elemento inicial. No problema proposto desde o início, é de que somente deveria se ter uma única condição inicial, e este não é o caso. Experimente a DSL recem criada, e veremos que é possível de se colocar mais de um estado inicial. E ainda pior, é possível ter condições iniciais que não se conectam a nada.
É neste ponto que vamos apresentar o que Restrições e Validações que irá nos ajudar a evitar erros e limitar a possibilidade de serem criadas construções "impossíveis" com a DSL. De uma forma geral o tema relativos a erros de "linguagem" encerra uma discussão que vai além do escopo destes laboratório. Recomendo aos interessado a recorrem ao capítulo 7 do livro texto Domain-Specific Development with Visual Studio DSL Tools aonde uma discussão mais aprofundada é apresentada.
Esta Laboratório 2 esta relacionado portanto as regras de validação e restrições que vão auxiliar no aprimoramento e "ajuste fino" da linguagem criada. Existem como veremos restrições e validações rígidas (hard) e flexíveis (soft). As rígidas em geral estão associadas a situações que um vez realizadas e imediatemente detectas pela ferramenta de desenho impedirão que o usuário
prossiga. As flexíveis por outro lado permitem que o usuário prossiga com o desenho mas o erro será apenas detectado quando for solicitado para se gerar a linguagem.
No caso do "Issue Tracker" a máquina de estado que o representa possuí um comportamento bastante específico. Que limita, portanto o comportamento da máquina de estado que irá representa-lo. No domínio do nosso problema de rastreamento (Issue Tracker) de "problemas" temos as seguintes condições para a condição inicial (Start Element) e os estados (Issue State) que o representam. Imaginamos inicialmente as seguintes 5 condições, ou restrições:
- Issue State não pode ser repetido, ou seja eu não posso ter estados cujo nome se repete,
- Issue States que estejam soltos ou desconectados (este parece ser uma condição simples mas imagine um desenho complexo que ocupa muito mais que uma tela),
- Apenas um Start Element, ou seja um ponto de entrada, ou condição inicial,
- Issue States não pode estar vazio, ou seja sem um nome,
- E por fim não se pode ter comportamentos ciclomáticos.
As 2 primeiras opções acima são restrições que iremos considerar como flexíveis e as outras 3 últimas são do tipo rígidas.
Vamos começar tratando primeiro caso: Issue State não pode ter nomes repetidos.
O video a seguir mostra como conseguir isto.
Abaixo o código que implementa esta validação.
1: using System;
2: using System.Collections.Generic;
3: using System.Text;
4: using Microsoft.VisualStudio.Modeling.Diagrams;
5: using Microsoft.VisualStudio.Modeling.Validation;
6: using Microsoft.VisualStudio.Modeling;
7: using System.Globalization;
8:
9:
10: // Como requisito da nossa maquina de estado que representa os nossos "Issues"
11: // ela nao pode ter 2 estados com o mesmo nome
12: // Logo o metod abaixo verifica em todo o espaco do dominio da classe (IssueStateModels)
13: // senao existem dois estados com nome iguais.
14: // Caso existam um erro 'e gerado
15: // O erro gerado apenas quando o usu'ario da DSL solicitar uma validacao do modelo
16: // Ou seja um Soft Validation
17:
18: namespace Microsoft.IssueStateModels
19: {
20: [ValidationState(ValidationState.Enabled)]
21: public partial class IssueStateModel
22: {
23: [ValidationMethod(ValidationCategories.Menu)]
24: private void ValidateStateNamesUnique(ValidationContext context)
25: {
26: Dictionary<string, IssueState> stateNames = new Dictionary<string, IssueState>();
27:
28: foreach (StateElement element in this.StateElements)
29: {
30: IssueState state = element as IssueState;
31: if (state != null)
32: {
33: if (stateNames.ContainsKey (state.Name))
34: {
35: string description = String.Format(CultureInfo.CurrentCulture, "State name '{0}' is used more than once.", state.Name);
36: context.LogError(description, "Err 01", state, stateNames[state.Name]);
37: }
38: stateNames[state.Name] = state;
39: }
40: }
41: }
42:
43: }
44: }
Resta agora criarmos o toolbox para que possamos fazer "drag-and-drop" dos elementos que representam nossa DSL. O propósito deste laboratório é mostrar como criar a toolbox e seus elementos.
Nesta parte vamos aprender a criar os tabs e os toolbox. Eles são particularmente úteis pois são os elementos neles representados serão os elementos que o usuário da linguagem (DSL) irá usar. Eles são identicos aos toolbox que temos dentro do VS para o desenvolvimento de aplicações por exemplo para ASP.NET. É portanto muito importante que eles representem visualmente os elementos da nossa linguagem.
Esta é parte final do nosso Laboratório 1, e com isto concluímos a criação da nossa linguagem de uma forma básica, e genérica para resolver o problema proposto. Como veremos a seguir, ela ainda tem uma séria de limitações. Entretanto estas limitaçòes são relativas a restrições e validações que em geral são inerentes as linguagens. Nos laboratório seguinte vamos nos atentar a melhorar a nossa linguagem através da criação destas regras de validação e das restrições.
Feita a limpeza do "Experimental Hive" estamos prontos a dar continuidade a criação da DSL. No Laboratório 1 - Parte 2 criamos a representação ou a descrição da linguagem do domínio agora vamos nos concentrar na criação da representação desta linguagem.
O primeiro passo é escolher as formas geométricas que vão representar os "classes" da nossa linguagem ou seja os elementos representados no nosso domínio criado anteriormente.
A idéia é criar portanto uma representação que possa refletir a simbologia como mostrada na figura abaixo
E em seguida estabelecermos a relação entre estas formas e conectores (elementos de representação gráfica) e "classes" definidas anteriormente.
Os detalhes de como isto é feito estão na demo abaixo
É possível personalizar a aparência, a forma de interação, as propriedades destas representação das mais variadas formas atráves de código. Ou seja assim com no caso das classes que representam o domínio que foi mostrada no Laboratório 1 - Parte, aqui também é possível criar representações bastante elaboradas através de criação de código específco que extenda ou complemente as classes existentes.
Para os que comprarem o livro maiores detalhes podem ser encontrados no capítulo 4.
No Laboratório anterior vimos que ao final um pequeno "problema"ocorreu. Fizemos isto propositalmente para explicarmos um conceito que está dentro do VS quando se trabalha com aplicações que são desenvolvidas para serem parte do VS, que é o caso da nossa DSL. A este conceito é dado o nome de "Experimental Hive", ou seja um espaço reservado para que o VS possa executar as aplicações que a ele mesmo destinadas. Como em geral na montagem de uma demo, como está que estamos aqui colocando no ar, muitas indas e vindas são necessários, e com isto este espaço acaba ficando com dados, classes e estados "persistidos", portanto
é importanto ter certeza que esta área experimental está limpa antes de começar um novo exercício. E é isto exatamente que vamos fazer neste laboratório.
Vimos no Laboratório 1 - Parte 1 que parte do nosso problema é encontrar uma forma de representar situações do tipo
Figura 1
Ou talvez algo mais genérico como
Figura 2
Seguindo o livro estas transições de estado como representadas na figura 1 podem ser de forma equivalente representadas por
Figura 3
E é aqui que as coisas começam a ficar interessantes pois vamos começar a modelar a nossa linguagem específica para resolver este problema em particular.
Poderíamos encarar a Figura 3 como a seguinte representação para uma classe (StateElement) que representa os estados que tentamos representar no nosso problema.
Figura 4
Assim sendo o nosso "domínio" (IssueStateModel) é composto de classes StateElement.
E é a partir deste modelo que vamos criar a "definição" para a DSL que representa o problema acima de transição entre estados que é o que está demonstrado no vídeo abaixo
Como eu havia dito anteriormente os laboratórios que serão apresentados daqui para frente se baseiam no exemplo do livro que eu citei (Domain-Specific Development with Visual Studio DSL Tools ) dado no capítulo 2. O exemplo diz respeito a uam empresa de desenvolvimento de software fictícia, a CJKW, que desenvolveu um software para o rastreamento de problemas de software - Issue Tracker - e um dos seus elementos chaves é o monitor de problemas ou "issues". Este software de rastreamento de problemas (de agora em diante apenas IssueTracker) foi desenvolvido pela CJKW usando o Issue Tracker Model Kit dado no site Microsoft para o ASP.NET.
O monitor de problemas pode ser abaixo visualizado
figura 1
A parte que nos interessa é justamente a parte em evidencia na imagem acima, ou seja o Status que dá uma série de condições ou "estados" do problema.
Cada cliente da CJKW tem requisitos diferentes para as condições ou estados de status, como era de se esperar, bem como as transições entre estas estados também são diferentes de cliente para cliente.
Um exemplo de transição entre diferentes estados de status poderia ser
figura 2
Um exemplo de código que representaria as transições acima poderia ser:
figura 3
Ou seja a cada cliente eles tem de re-escrever este pedaço de código para poder representar as possíveis transições e manter o dro-down box de status com as opções corretas dependendo do estado em que um problema se encontra.
Evidentemente este problema é típico de uma máquina de estado e suas transições e por certo existem métodos mais eficázes de se resolver este problema, mas para o laboratório em questão vamos partir do princípio que queremos automatizar a geração de código para poder dado uma representação como a da figura 2 poder automáticamente gerar o código da figura 3.
Maiores detalhes podem ser encontrados no livro.
Nesta primeiro laboratório vamos nos concentrar em representar a linguagem que representa este problema, ou seja como representar os estados e suas transições. Este Laboratório 1, na qual vamos criar a representação deste problema, será feito passo a passo, ou seja em partes. Na primeira parte tratamos apenas de criarmos um projeto do zero para o que chamaremos de Issue Tracker Model.
O kit SDK do Visual Studio (Visual Studio SDK 2005) é o pacote essencial para que se possa ter o DSL integrado ao Visual Studio, como vimos na parte anterior Produtividade no Desenvolvimento de Software - DSL - Introdução. Ao mesmo tempo ele contem um conjunto de demos (samples) que permitem explorar e conhecer melhor o que é possível se fazer com DSL.
A demo a seguir faz justamente uso de um dos exemplos contidos no SDK (User Interface Process Sample). Este é um exemplo que faz uso do User Interface Application Block (UIPAB). Este Application Block usa o pattern MVC (model-view-controller). Neste exemplo um DSL é desenvolvida para se criar um sistema de reserva de hoteis cuja a interface obedece ao conceito de MVC. A DSL permite se criar a lógica do sistema de reserva de um hotel e partir dela usando o UIPAB toda a interface de interação da aplicação para o sistema de reserva de hotel é gerada automáticamente.
A demo mostra algumas das possibilidades de como "brincar"com este exemplo presente no Visual Studio SDK 2005. Minha sugestão é que os leitores interessados em aprender DSL, baixem e façam outra "bricadeiras"com estes exemplos para conhecer melhor as potencia;idades e limitações do DSL.
A propósito o mesmo exemplo pode ser feito usando o Visual Studio 2008 mas para isto o leitor terá de baixar o Visual Studio SDK da versão 2008
Há aproximadamente uns 2 meses eu, Otavio e Waldemir fizemos um experimento que foi a montagem de um curso (workshop). Otavio dá uma visão geral do workshop no seu blog e neste memo blog ele menciona que eu iria reativar meu blog, que já esta parado há algum tempo em função da minha "preguiça"de escrever já que não sou muito bom em texto, para colocar uns videos mostrando o que foi feito pelo menos na parte de DSL. A ideía deste videos era mostrar como construir uma DSL.
O exemplo básico foi tirado do livro Domain-Specific Development with Visual Studio DSL Tools
A ideia é que este videos ajudem aos interessados a terem uma melhor compreensão do que é DSL e como usa-la.
São uma série de 16 videos que varia de 1 minuto (abertura) a 28 minutos totalizando algo como quase 6 horas de videos de demonstração. Eles seguem uma ordem cuja o objetivo é mostrar desde como ter DSL instalado no ambiente do Visual Studio até um exercício completo de criação de uma DSL para o exemplo do livro (end-to-end)
Espero que vcs aproveitem e dêem feedback pois assim posso altera-las e complementa-las a fim de fazer mais claro o exercício.
Vou posta-las ao longo das proximas semanas sempre acompanhadas de um pequeno texto descritivo explicando a que cada uma das parte se propõe.
A ideia dos videos tem 2 propósitos o primeiro é demonstrar o uso da DSL e o segundo é do mostrar um conceito de S+S. Para tal os videos estão armazanados no Silverlight Streaming e portanto são streaming de videos. Posteriormente eu posso colocar os videos para download.
Para começar vamos por colocar 2 videos.
O primeiro é de abertura
Neste video eu dou um breve introdução sobre o que vamos fazer.
O segundo video explora os requisitos necessários para se ter o DSL no Visual Studio em seguida dar um exemplo ba'sico a fim de familiarizar o usuário com a interface DSL dentro do Visual Studio.
Na semana passada, 8 e 9 de Abril de 2008, nós realizamos o RAF 2008 (Regional Architect Forum) em São Paulo. Algumas mudanças foram feitas com relação aos RAFs anteriores mais o espiríto do evento permaneceu o mesmo.
Foram duas sessões gerais aonde o tema foi S+S (software plus service). Na primeira sessão (O Yin e o Yang do Software - Gianpaolo Carraro) foram abordados elementos mais conceituais do S+S mostrando através de uma analogia como alguns elementos tem de estar presentes para que uma arquitetura que siga o modelo S+S possa ser bem sucedida. Na segunda sessão (Arquiteturas Híbridas - Eugenio Pace) foram abordados elementos de carater prático através de um estudo de caso.
Foram 10 mesas redondas abordando temas como: Green IT, Dynamic System Initiative, Infra-estrutura Web, Business Inteligence, Fábricas de Software, Domain Specific Languages, Enterprise Services Bus / Internet Services Bus, Windows Communication Foundation e Windows Workflow Foundation.
Foram 3 sessoões informativas aonde tivemos 3 visões dstintas do uso da tecnologia da informação. Do ponto de vista de hardware, através da palestra "Data Center Utility" proferida por Bruno Domingues da Intel. Do ponto de vista de software, através da palestra "SOA Roadmap e OSLO" proferida por Lalo Steinmann. E finalmente do ponto de vista de pesquisa científica através da palestra "Arquitetura das proteinas, nano e macro máquinas e do software" proferida pelo Dr. Goran Neshich da EMBRAPA.
Por fim tivemos uma sessão de fechamento feito por Hans Donner com uma apresentação magnifíca aonde ele falou sobre sua carreira como designer e da sua mais nova iniciativa ligada a interpretação e visualização do tempo - Timension.
O material das apresentações será colocado no nosso site do MSDN Brasil em breve. Assim que estiver no ar eu aviso.
Vez por outra recebo perguntas do tipo o que é ser um arquiteto. Existem diversas explicações na net sobre o assunto, mas eu tenha a minha versão. Arquitetos no conceito de construção, e esta pode ser de qualquer tipo, civil, naval, industrial,etc, no primeiro mundo (USA por exemplo) são individuos que tem um papel muito importante. Por exemplo na construção civíl o arquiteto é o sujeito responsável pela obra. É ele que porjeta a cosntrução e suas detalhes, é ele quem supervisiona a execução em geral feitas por engenheiros. Outra medida da importancia do arquiteto é que em geral os cursos universitários são muitos mais extensos e completos para arquitetos do que por exemplo para engenheiros cujo foco é sempre a execução ou prática. Assim desta forma o termo arquiteto dentro do universo de TI tem um carater mais abrangente porém menos especifico que os engenheiros de software e desenvolvedores. Notem que eu não disse mais importante, todos os 3 são muito importantes (arquitetos, engenheiros e desenvolvedores de software). Eu disse mais abrangente ou seja ele deve ser preocupar, como na analogia da construção civíl com o planejamento e arquitetura da solução final.
Entretanto se vocês buscam visão mais pragmática e objetiva com relação ao que é um arquiteto dentro do contexto de TI eu recomendo ler
http://msdn2.microsoft.com/en-us/skyscrapr/bb401007.aspx
Outra pergunta que me fazem vez por outra é se existe um certificação para arquitetos e como obte-las. Sim existe, tanto a Microsoft como algum de seus concorrentes tem certificações para atestar um verdadeio arquiteto. Para saber mais eu recomendo a leitura do seguinte link http://www.microsoft.com/learning/mcp/architect/default.mspx
Nestes instante estamos assistindo um demo do Behrooz Chitsaz a respeito do MSR (Microsoft Research). Ele está nos mostramos coisas incríveis que este laboratório tem feito.
Apenas para ilustrar vou passar dois links para os leitores terem uma idéia:
http://risingfromruin.msnbc.com/tour.html
Neste link vocês poderão ver video em 3 dimensões.
Neste outro aqui http://research.microsoft.com/ivm/HDView.htm vocês podem ver imagens em altíssima resolução.
Mas muitos outros assuntos foram abordados de futuros dispositivos a avanços em gonoma e medicina. Vale a pena gastar algumas horas procurando coisas interessantes que este pessoal anda fazendo.
http://research.microsoft.com/news/featurestories/default.aspx?0hp=n4
ou simplesmente http://research.microsoft.com/
Ok por hora é só. Tenho de correr pois na sequencia tenho de moderadar uma discussão.
Achei bastante interessante este post publicado na
Meio Bit e reproduzido no
Porta 25 pelo Roberto Prado. Vale a pena a leitura.
Na semana passada o René de Paula (http://blogs.msdn.com/renedepaula/) colocou um video super interessante mostrando como Designers e Desenvolvedores podem trabalhar juntos. Embora o video foque bastante no design (Blend) ele serve como inspiração para que desenvolvedores se aventurem por este universo. Vale a pena!!
http://video.msn.com/video.aspx?vid=4ef8e43c-4474-494f-aaa1-5469f62d7bf5
O que nem Rene nem Jonathan Harris contaram aonde se buscar estes softwares para ver como realmente fácil criar uma aplicação como a mostrada neste demo. Para poder baixar e experimentar uma experiencia tanto como designer e desenvolvedors
http://www.microsoft.com/downloads/details.aspx?FamilyID=de665fe2-7cc4-412a-a5de-bfd737f4aeea&DisplayLang=en
Neste link vocês vão encontrar não somente uma versão trial do Blend mas poderão baixar o .Net 3.0 no caso do seu Windows não ser o Vista ou de não ter o .Net 3.0 instalado e o Visual Studio Express.
Depois de baixar e instalar tudo, eu recomendaria um tutorial do Blend que pode ser baixado de http://www.microsoft.com/expression/kc/resources.aspx?product=blend&type=selfstudy
Depois é só se divertir :)
No último mês fiz dois webcast sobre DSL.Webcasts são o tipo de interação que embora permita algum tipo de interação entre o palestrante e a audiência sempre deixa, pelo menos para mim, um sensação de monólogo ( eu gosto de interagir com a audiência presencialmente). Nestes webcasts eu dei uma visão geral sobre a que se destina o DSL e dei alguns exempos do que um DSL pode fazer (p.e. geração de código automática. Os links ainda não estão disponíveis para fazer download dos mesmo. Fica aqui o meu compromisso que assim que eles estejam prontos eu coloco aqui para que áqueles que estejam interessados neste assunto possam baixar e me dar feedback sobre os mesmo.
DSL são muito importantes dentro do conceito MS de Fábricas de Software. Por isto vale a pena conhecer mais sobre este assunto. Para aqueles que tem o Visual Studio 2005 Team System Suite ou Team System Architect já podem dar uma olhada no que um DSL é capaz de fazer.
Tenho visto durante estes 2 últimos meses muitas perguntas relativas a SOA oriundas de diferentees audiências. Noto um grande interesse destas audiências em entrar de cabeça neste assunto. Tenho também percebido que muitos destas perguntas tem um carater introdutório ou de "querer conhecer" mais do asunto por um lado e não incomum, por outro lado, uma mistura ou má interpretação dos preceitos de SOA. Portanto eu gostaria de deixar aqui uma lista de referencias relativas a conceitos básicos de SOA que não devem faltar áqueles que querem mergulhar de cabeça neste assunto.
Vou me concentrar nos artigos já publicados no nosso The Architeture Journal
O primeiro artigo que sugiro a leitura foi publicado em Understanding Service-Oriented Architecture. Neste artigo os conceitos básicos de SOA são abordados e dão uma visão geral do que se precisa para se ter uma arquitetura voltada a serviços. Este artigo em particular é muito interessante para aqueles que tem pouco ou nenhum conhecimento dos conceitos introdutórios de SOA.
Um segundo artigo muito interessante e mais avançado e em particular útil para aqueles que estão querendo mudar a arquitetura de sua aplicação para SOA é o artigo Service-Oriented Architecture: Considerations for Agile Systems publicado no 2 Journal. Esta edição em particular também trás outros artigos interessantes que coloco como referencia mais abaixo. O artigo mencionado é de particular interesse pois dá uma visão sobre as principais considerações a serem tomadas quando se quer migrar uma aplicação para SOA.
Os outros artigos exploram respectivamente, os desafios de se implementar uma solução SOA (Service-Oriented Architecture: Implementation Challenges) e padrões de mensagem SOA (Messaging Patterns in Service-Oriented Architecture, Part 1). Este último esta divido em 2 partes sendo que a segunda parte se encontra no Journal 3 (Messaging Patterns in Service Oriented Architecture, Part 2)
Com a leitura destes artigos (em particular os 3 primeiros na ordem acima) são essenciais para a construção de aplicações SOA.
Pretendo posteriormente explorar em detalhes cada um destes a fim de proporcionar uma interpretação dos conceitos contidos nestes artigos.
Boa leitura :)
