Nesta parte vamos ver como fazer para que IssueStates não sejam criados vazios, portanto sem nomes.
Neste caso vamos usar uma restrição rígida, e no exemplo vamos extender uma classe parcial dando um override. Veja isto no código abaixo
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: // Como requisito da nossa maquina de estado que representa os nossos "Issues"
10: // ela nao pode ter estados cuja a propriedade Name e' vazio
11: // O metod abaixo verifica se nao estamos tentando criar uma classe ou estado
12: // cujo nome e' vazio, caso isto occora um erro deve ser gerado imediatamente
13:
14: // Ou seja um hard Validation
15:
16:
17: namespace Microsoft.IssueStateModels
18: {
19:
20: /// <summary>
21: /// Add a hard constraint to StateElement to prevent its "Name" property from being empty.
22: /// </summary>
23: public partial class StateElement
24: {
25: /// <summary>
26: /// Value handler for the NamedElement.Name domain property.
27: /// </summary>
28: internal sealed partial class NamePropertyHandler : DomainPropertyValueHandler<StateElement, global::System.String>
29: {
30: protected override void OnValueChanging(StateElement element, string oldValue, string newValue)
31: {
32: if (!element.Store.InUndoRedoOrRollback)
33: {
34: if (string.IsNullOrEmpty(newValue))
35: {
36: throw new ArgumentOutOfRangeException("Name", "Name cannot be empty or null.");
37: }
38: }
39: base.OnValueChanging(element, oldValue, newValue);
40: }
41: }
42: }
43: }
Nesta demo vamos tratar a restrição relativa a "StartElements" que não podem ter mais do que um é desconectados. Na figura abaixo mostramos exemplos de tal situação;
O vídeo a seguir mostra como fazer 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: // Como requisito da nossa maquina de estado que representa os nossos "Issues"
10: // ela nao pode ter myultiplos pontos de entrada ou seja start elements
11: // assumimos como premissa que apenas um ponto de entrada seria possivel
12: // Logo o metodo abaixo impede que um novo ponto de incio seja introduzido no modelo
13: // Caso haja uma tentativa de inserir um outro ponto de inicion do desenho um erro sea
14: // gerado imediatamente, impedindo que hajam 2 ponto de incio do diagram de estado.
15: // Ou seja um hard constraint
16:
17: namespace Microsoft.IssueStateModels
18: {
19: [RuleOn(typeof(StartElement), FireTime = TimeToFire.TopLevelCommit, InitiallyDisabled = false)]
20: internal sealed class UniqueStartElementAddRule : AddRule
21: {
22: public override void ElementAdded(ElementAddedEventArgs e)
23: {
24: string message = "Impossible to have 2 StartElements state";
25:
26: StartElement g = e.ModelElement as StartElement;
27: string name = g.Name;
28:
29: if (name == "StartElement2")
30: {
31: throw new InvalidOperationException(message);
32: }
33: base.ElementAdded(e);
34: }
35: }
36:
37:
38: /// <summary>
39: /// Domain model class allows extra reflective elements such as rules to be added
40: /// </summary>
41: public partial class IssueStateModelsDomainModel
42: {
43: protected override Type[] GetCustomDomainModelTypes ()
44: {
45: return new System.Type[] { typeof(UniqueStartElementAddRule) };
46: }
47: }
48:
49: }
E o resultado da sua implementação e implantação na nossa DSL
Vamos mudar um pouco de assunto, faz muito tempo que eu só falo de DSL. Vamos falar de HPC e Paralelismo em Aplicações.
Fazem algumas semanas (18 de Junho), nós tivemos um "Encontro de Arquitetos" aonde o Gebara falou sobre Virtualização e eu falei sobre o tema acima (HPC - High Performance Computing). Parte destes slides foram os mesmo usados num webcast que fiz recentemente sobre o mesmo título em 13 de Agosto de 2008.
Na chamada dos trabalhos tinhamos como descrição de cada uma dos temas
14h30 – 16h00: Virtualização
Virtualização é, hoje em dia, um dos temas mais discutidos em tecnologia da informação. Desde a questão de consolidação e otimização de recursos até a nova onda de “Green IT”, o tema virtualização tem se mantido em destaque. Nesta palestra abordaremos as tecnologias de virtualização da plataforma Microsoft (estação, servidores, aplicações e apresentação). Estabelecer as razões para as quais a virtualização é desejada auxiIia no processo de tomada de decisão sobre qual tecnologia pode ou deve ser utilizada.
Palestrante: Fernando Gebara
16h00-16h30: Coffee-break
16h30-18h00: HPC
HPC foi tema de grandes discussões em tecnologia na decado de 80 quando os processadores estavam próximos do seu limite relativo ao processo de fabricação. Na epóca alguns autores e especialistas da área profetizavam que a atual tecnologia não iria durar até o final do século passado ou inicio deste. A evidência de que isto está ocrrendo vem de números da Intel: para um aumento de 20% de clock fornece um aumento de apenas 13% em desempenho mas com um aumento de 73% em consumo de energia. Ao que tudo indica o caminho do multicore é uma realidade, hoje temos processadores com 4 cores e em breve teremos processadores com até 80 processadores numa única pastilha. Nem todos os problemas podem ser resolvidos via virtualização, alguns problemas necessitam fazer uso destes "cores" de forma otimizada ou em paralelo, é aqui que a computação de alto desempenho (HPC) entra. O objetivo desta palestra é resgatar alguns deste princípios e demonstrar o que tem sido feito nos últimos anos para possibilitar o uso desta alta capacidade de processamento para resolver problemas cada vez mais complexos em todos os ramos de atividades e por que o caminho do HPC é inevitável.
Palestrante: Carlos Hulot
Se alguém quiser saber mais sobre o tema de virtualização recomendo visitar o blog do Gebara.
Neste "post"vou comentar e deixar disponível para download os slides e links que utilizei na palestra.
Meu enfoque para a discussão de alto desempenho foi tentar mostrar porque HPC e Parelelismo podem ser uma das próximas ondas de TI para um futuro não muitos distante.
Quem quiser ter acesso aos slides da minha apresentação eles estão disponíveis no SkyDrive no Live em
Eu sintetizo abaixo o que eu abordei e coloco os links para as referencias que fiz durante esta palestra.
Começei perguntando para a audiência (e por incrível que parece tinha mais gente do que eu esperava, sendo este um assunto muito específico e árido) quem acredita que a próxima onde será a de HPC e parelelismo. Muita pouco gente se manifestou de forma a concordar com está minha afirmação-questão, mas era o que eu esperava....
Na sequencia eu fiz uma pequena restrospectiva do que aconteceu no final dos anos 80 início dos 90 quando se imagina que a tecnologia para a fabricação de processadores tinha chegado ou estava próxima de chegar ao seu limite devido as limitações no processo fabril de fotolitografia que é uma das etapas no processo de fabricação dos chips e que sem um melhoria não permitiria criar processadores menores e mais poderosos (mais detalhes sobre o processo de fabricação podem ser visto em Learn how a microprocessor is made e quem quiser saber como é uma fábrica de semicondutores veja em Get interactive inside the chip factory)
Em seguida eu mostrei algumas das evidências econômicas que me leva a crer que desta fez o HPC/Paralelismo estão aqui para ficar.
Achei também importante relembrar alguns conceitos básicos de processamento paralelo e sistemas distribuídos tais como:
- A Lei Amdahl que limita o speed-up, ou seja em outras palavras mesmo colocando mais processadores para cada problema tem uma hora que não resolve mais nada ou seja não há ganho em desempenho (assim sendo o processamento paralelo ou distribuído também tem suas limitações).
- A taxonomia Flynn muito utilizado nos anos 90 para descrever as arquiteturas dos sistemas paralelos/distribuídos.
- Ligado a Lei de Amdahl está o problema da "granularidade" de um problema
- Paralelismo Funcional e de Dados
- Memória Compartilhada e Distribuída
- Técnicas de Modelagem do problema ou decomposição do domínio (do problema) que é muito importante para se encontrar a melhor solução para paralelizar um problema
- A diferença entre Grids e Clusters
Estes temas podem ser fácilmente encontrados na internet buscando pelas palavras chaves dado que são temas acadêmicos de cursos de arquiteturas paralelas e sistemas distribuídos.
Em seguida eu explique por que as empresas de semicondutores entreram nesta de colocar mais de um "core" numa pastilha e cujo o racional estava na chamada, ou seja "um aumento de 20% de clock fornece um aumento de apenas 13% em desempenho mas com um aumento de 73% em consumo de energia" que como podemos ver não é uma relação das mais eficientes, veja também em www.asyncop.com
E para demonstrar que as empresas de semicondutores estão seriamente envolvidas neste conceito de multicore eu mostrei o caso da Intel que já tem um protótipo que coloca 80 cores num único "chip". Os detalhes e o filme podem ser visto em Discover how, Tera-scale computing research vision, e
Mostrado o que o universo do hardware anda preparando tinha que mostrar o que o universo do software anda fazendo. E em se tratando de MS o objetio era mostar o que estamos fazendo para lidar com este no cenário de hardware.
Cenário Scale-Up (Multi-Core)
O primeiro passo é fazer uma distinção entre plataformas distribuídas e platformas multicore, ou seja scale-down e scale-up respecitvamente. E que no caso da Microsoft se resumem Windows HPC e extensões parelelas para o .Net Framework que virão inclusas na versão 4.0 do .Net.
Começei pelos cenários de scale-up (multicore) por acreditar serem de mais fácil "digestão". Aqui eu recomendo baixar o CTP do novo Microsoft Parallel Extensions to .NET Framework 3.5, June 2008 Community Technology Preview
E "brincar"um pouco com as novas "extensões paralelas do .NET" que virão na versão 4.0. Elas estão refletidas em 3 grandes grupos, a saber, PLINQ (Parallel Linq), CDS (Concurrent Data Structures) e TPL (Task Parallel Library). Para quem quiser conhecer mais recomendo visitar links como:
Parallel LINQ
Parallel Extensions Samples Tour
Understanding the Parallel Class
Ou visitar a página da MS sobre o tema de Processamanto Parelelo
O objetivo das "extensões paralelas do .Net" é facilitar a vida do desenvolvedor. uma vez que hoje existem outras técnicas mais complexas que são hoje usadas para o desenvolvimento de aplicações concorrentes.Entre estas temos
- CCR - Concurrency and Coordination Runtime parte do Microsoft Robotics Studio
- Trata de programação assincrona visto que robos são um conjunto de eventos assincronos. Ele lida com os 3 principais problemas em robótica:
- 1. Assincronicidade
- 2. Concorrencia
- 3. Coordenação e Suporte/Tolerância a falhas
Mais detalhes em podem ser encontrados em CCR User Guide e em CCR Programming - Jeffrey Richter and George Chrysanthakopoulos e Concurrency and Coordination Runtime
- Threadpools - Recurso que permite um programa C# realizar processamento concorrente.
Multithreading pode resolver o problema de multi-tarefas e resposta de um sistema, ao permitir separar “processos” ou “tarefas” para trabalharem de forma independente e assincrona, mas ao mesmo tempo introduz outras complexidades tais como o compartilhamento de recursos (exemplo dos filosofos)
Mais detalhes em Threading (C# Programming Guide) e How to- Use a Thread Pool
Parallel LINQ (PLINQ)
A primeira extensão paralela do .NET é o Parallel LINQ ou PLINQ que é uma implementação paralela do LINQ-to-objects que usa paralelismo de dados. POr exemplo tomemos a seguinte exemplo que está contido no CTP (LINQRayTracer)
Evidentemente não é minha intenção explicar o algoritmo de "ray-tracing" - a não ser que alguém me peça :) - mas é algo como uma forma simples de simular os raios de luz que emanam de uma fonte luminosa. A idéia é simular o comportamento de cada raio ou feixe de luz e sua intereção com os objetos a sua volta. Portanto envolve Física (teoria da luz) e logo um conjunto de equações que demandam muitos calculos. Para visualizar o que estamos falando, recomendo olhar no arquivo LINQRayTracer.cs aonde temos
1: internal void RenderParallel(Scene scene)
2: { 3: int[] rgb = new int[screenWidth * screenHeight];
4:
5: var pixelsQuery =
6: from y in Enumerable.Range(0, screenHeight).AsParallel()
7: let recenterY = -(y - (screenHeight / 2.0)) / (2.0 * screenHeight)
8: select from x in Enumerable.Range(0, screenWidth)
9: let recenterX = (x - (screenWidth / 2.0)) / (2.0 * screenWidth)
10: let point =
11: Vector.Norm(Vector.Plus(scene.Camera.Forward,
12: Vector.Plus(Vector.Times(recenterX, scene.Camera.Right),
13: Vector.Times(recenterY, scene.Camera.Up))))
14: let ray = new Ray() { Start = scene.Camera.Pos, Dir = point } 15: let computeTraceRay = (Func<Func<TraceRayArgs, Color>, Func<TraceRayArgs, Color>>)
16: (f => traceRayArgs =>
17: (from isect in
18: from thing in traceRayArgs.Scene.Things
19: select thing.Intersect(traceRayArgs.Ray)
20: where isect != null
21: orderby isect.Dist
22: let d = isect.Ray.Dir
23: let pos = Vector.Plus(Vector.Times(isect.Dist, isect.Ray.Dir), isect.Ray.Start)
24: let normal = isect.Thing.Normal(pos)
25: let reflectDir = Vector.Minus(d, Vector.Times(2 * Vector.Dot(normal, d), normal))
26: let naturalColors =
27: from light in traceRayArgs.Scene.Lights
28: let ldis = Vector.Minus(light.Pos, pos)
29: let livec = Vector.Norm(ldis)
30: let testRay = new Ray() { Start = pos, Dir = livec } 31: let testIsects = from inter in
32: from thing in traceRayArgs.Scene.Things
33: select thing.Intersect(testRay)
34: where inter != null
35: orderby inter.Dist
36: select inter
37: let testIsect = testIsects.FirstOrDefault()
38: let neatIsect = testIsect == null ? 0 : testIsect.Dist
39: let isInShadow = !((neatIsect > Vector.Mag(ldis)) || (neatIsect == 0))
40: where !isInShadow
41: let illum = Vector.Dot(livec, normal)
42: let lcolor = illum > 0 ? Color.Times(illum, light.Color) : Color.Make(0, 0, 0)
43: let specular = Vector.Dot(livec, Vector.Norm(reflectDir))
44: let scolor = specular > 0
45: ? Color.Times(Math.Pow(specular, isect.Thing.Surface.Roughness),
46: light.Color)
47: : Color.Make(0, 0, 0)
48: select Color.Plus(Color.Times(isect.Thing.Surface.Diffuse(pos), lcolor),
49: Color.Times(isect.Thing.Surface.Specular(pos), scolor))
50: let reflectPos = Vector.Plus(pos, Vector.Times(.001, reflectDir))
51: let reflectColor = traceRayArgs.Depth >= MaxDepth
52: ? Color.Make(.5, .5, .5)
53: : Color.Times(isect.Thing.Surface.Reflect(reflectPos),
54: f(new TraceRayArgs(new Ray()
55: { 56: Start = reflectPos,
57: Dir = reflectDir
58: },
59: traceRayArgs.Scene,
60: traceRayArgs.Depth + 1)))
61: select naturalColors.Aggregate(reflectColor,
62: (color, natColor) => Color.Plus(color, natColor))
63: ).DefaultIfEmpty(Color.Background).First())
64: let traceRay = Y(computeTraceRay)
65: select new { X = x, Y = y, Color = traceRay(new TraceRayArgs(ray, scene, 0)) }; 66:
67: int rowsProcessed = 0;
68: pixelsQuery.ForAll(row =>
69: { 70: foreach (var pixel in row)
71: { 72: rgb[pixel.X + (pixel.Y * screenWidth)] = pixel.Color.ToInt32();
73: }
74: int processed = Interlocked.Increment(ref rowsProcessed);
75: if (processed % rowsPerUpdate == 0 ||
76: processed >= screenHeight) updateImageHandler(rgb);
77: });
78: }
Esta demo possivilmente só vai mostrar resultado positivos se o seu computador tiver mais de 1 "core". No caso do meu notebook ele possuí dois cores.
Execute primeiro sequencialmente e depois em paralelo e veja como os cores são utilizados em ambos os casos. Para isto use Windows Task Manager (ctrl-alt-del) e selecione a aba Performance e dê um duplo click em CPU Usage.
No meu notebook os resultado foram algo como uma melhora de aproximadamente 10 a 30%. Existe grande variação pois tive de usar um software de gravação que intervere com o resultado final.
Task Parallel Library
O segundo exemplo é o mesmo problema de ray-tracing só que agora usando o segundo recurso da extensão paralela do .NET que é o TPL (Task Parallel Library). TPL é implementado em um bilbioteca e não depende da extensão da linguagem.
1: internal void RenderParallel(Scene scene, Int32[] rgb)
2: { 3: Parallel.For(0, screenHeight, y =>
4: { 5: int stride = y * screenWidth;
6: Camera camera = scene.Camera;
7: for (int x = 0; x < screenWidth; x++)
8: { 9: Color color = TraceRay(new Ray(camera.Pos, GetPoint(x, y, camera)), scene, 0);
10: rgb[x + stride] = color.ToInt32();
11: }
12: });
13: }
Como no caso anterior esta demo só tirará vantagem se o seu computador possuir uma CPU com mais de um core. Se observarem, no caso do processamento sequencial os cores da CPU nunca (ou quase nunca) chegam a 100%. Entetanto quando selecionamos o processamento paralelo (via TPL) os cores são usados a 100%. Acima quando eu mencionei "ou quase nunca" é por que, como no caso anterior, o software usado para gravar interfere com o resultado uma vez que ele consome bastante CPU.
Concurrent Data Structures
Neste CTP ainda não temos nenhum material ou bits sobre o CDS. Assim que ele seja incluido eu volto a blogar sobre que estas estruturas de dados paralelos tais como:
Coleções thread-safe (p.e. ConcurrentDictionary<K,V>, ConcurrentQueue<T>, ConcurrentStack<T>,etc. )
Troca (p.e. BlockingCollection<T>, SynchronousQueue<T>, etc.)
e outros, podem fazer.
Velocity
Como existe uma outra iniciativa para trazer desempenho para aplicações achei importante durante o Encontro de Arquitetos falar sobre o Microsoft Project Code Named “Velocity” Community Technology Preview 1 (CTP1). Esta é um tecnologia que permite "fundir" caches de várias aplicações em um cache único, é como um cache compartilhado. Ou seja você pode agora criar um cache virtual "gigante" que atende a várias aplicações. Como os caches são estruturas intermediárias para armazenagem de dados que devem estar muito próximos da aplicação por questões de desempenho, esta iniciativa permite trazer melhorias a aplicações que precisam de muitos dados e não querem fazer acesso a memória ou discos em outro lugar, logo as informações podem ser mantidas no cache. Embora esta seja uma forma de trazer desempenho a estas aplicações e o cache tenha a "cara" de uma grande memória compartilhada, este não é um problema ou solução de computação de alto desempenho (HPC) ou paralela. De qualquer forma achei importante mencionar e mais detalhes podem ser vistos no link acima.
Cenários Scale-Out (HPC)
Por fim acabei mostrando os cenários de scale-out que significam problemas que requerem soluções em plataformas do tipo cluster ou grids. Para isto eu falei da solucão Windows High Performance Computer Server (WHPCS) que nada mais é do que uma evolução do Windows Computer Cluster Server (WCCS).
Neste caso importante modificações foram introduzidas e melhoradas no Job Scheduler do WHPCS. Novas ferramentas internas e de terceiros foram incorporadas ou agregadas a solução. Além disto o WCF (Windows Communication Foundation) foi utilizado para permitir a criação de "brokers" (mediadores/negociadores). Com estes brokers é possível uma aplicação paralela negociar com o broker um aumento da quantidade de nós de processamento necessários.
Uma descrição para completa pode ser encontrada em Windows HPC
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.
