Cadastre-se Revistas DevMedia Cursos
 



Últimas 20 atualizações de COLUNA MSP

Artigo - Introdução ao WF

Daniel Franco Abrahão de Oliveira (daniel.oliveira@studentpartners.com) O autor atua como desenvolvedor de software em .NET. É Microsoft Student Partner desde junho de 2007 e é Microsoft Certified Technology Specialist in Web Applications.

Estrutura do artigo:

·         Introdução ao WF

·         Motivações

·         Tipos de Workflow

·         Exemplo de workflow Simples

·         Atividades

·         Serviços

Introdução ao WF

 

         Com o lançamento do .NET Framework 3.0 a Microsoft nos trouxe quatro novas tecnologias: Windows Communication Foundation (WCF), Windows Presentation Foundation (WPF) e Windows Workflow Foundation (WF) e CardSpace.

         É importante deixar bem claro que o Windows Workflow Foundation não é um produto de Workflow e sim uma plataforma para desenvolver aplicações baseadas em workflows. A Microsoft não espera que o Workflow Foundation seja levado ao usuário final. O que o usuário final irá receber são aplicações construídas usando o WF, ficando isso explícito ao usuário ou não.

         Com o WF podemos modelar quaisquer processos usando atividades desenvolvidas pela Microsoft, e que vem com o .NET 3.0, ou atividades customizadas.

 

Motivações

 

         Tanto processos de negócio quanto processos computacionais podem ser modelados usando Workflow Foundation. Neste artigo vamos nos ater aos processos de negócio.

         Quando falamos de um processo de negócio estamos falando de processos que podem durar horas, dias, meses ou anos até que sejam finalizados. Nesses processos, tipicamente, tempos a interação de pessoas, ou seja, determinados momentos do workflow, o que chamaremos de Atividades, podem requerer a interação de uma pessoa para que o fluxo possa continuar.

         Processos de negócio requerem interação de uma grande variedade de partes, dessa forma um requisito de uma plataforma de Workflow é coordenação. Pessoas interagem com instâncias de um processo que está sendo executado. Cada instância pode ter um tempo de vida de horas, dias, semanas e até meses. Dessa forma temos os workflows de longa-duração(long-running).

         Modelando visualmente um processo de negócio em forma de workflow, temos uma vantagem clara que é o entendimento sobre o processo. Uma vez modelado visualmente o processo se torna mais claro e a possibilidade de otimização sobre esse processo aumenta.

Porém, a simples representação visual não é o bastante. Outra vantagem que temos com o WF é que além da representação visual temos a instância do workflow sendo executada. Dessa forma outro benefício trazido é o monitoramento. Uma vez que estamos gravando informações sobre cada instância do processo que está sendo executada, podemos acompanhar a execução, saber em que momento da execução está cada instância, quantas são as instâncias e quaisquer outras informações que possam ser necessárias. Visto que temos a vantagem da representação visual e das informações gravadas sobre a execução de cada instância, podemos trabalhar em cima desses dados para aperfeiçoar os processos de negócio.  

         Uma possibilidade de uso do WF, conforme veremos detalhes mais à frente, é levar ao usuário do sistema o papel de definir a modelagem dos processos de negócio, usando atividades de negócio criadas pelos desenvolvedores do produto. Quem desenvolve software sabe que levar ao usuário final esse tipo de funcionalidade pode ser uma tarefa bem complexa, para gerar uma aplicação com “partes” desconectadas. Isso pode ser traduzido em outro benefício do Workflow Foundation, tornar o software flexível a ponto de o usuário final poder modelar o processo que será seguido.

 

Tipos de Workflow

 

         Temos dois tipos de workflow disponíveis no WF. O primeiro que veremos é o Sequential-Workflow (Workflow Seqüencial), e logo em seguida o State-Machine Workflow (Workflow de Máquina de Estado). Na verdade há um terceiro tipo de workflow, o Data-driven workflow. Sobre este irei fazer alguns comentários posteriormente.

         O estilo de workflow clássico que temos é o workflow seqüencial. Um exemplo de processo que seria indicado ser modelado com o workflow seqüencial: um funcionário solicita uma folga. O gerente desse funcionário recebe o pedido e decide se aprova ou não. Se ele aprovar o funcionário recebe a confirmação da aprovação e então encerra o workflow, senão, se o pedido não for aprovado, o workflow é encerrado.

img01.JPG

Figura 1 - Exemplo de workflow seqüencial

 

O que caracteriza um workflow seqüencial é que quem controla o fluxo é o workflow. De maneira alguma quer dizer que o workflow seqüencial é sempre uma seqüência simples de atividades. Esse estilo de workflow pode ter operadores de repetição, de decisão e mais. Se o conceito, de que quem controla o fluxo é o workflow, ainda não foi bem entendido, será em seguida quando dermos uma olhada no outro estilo de workflow.

         O segundo estilo que temos é o Workflow de máquina de estado.  Vejamos o seguinte exemplo: eu estou testando um software e identifico um bug. Defino uma tarefa para o desenvolvedor responsável para corrigir o bug. Esse desenvolvedor repassa a tarefa para outro desenvolvedor. Esse outro desenvolvedor rejeita o bug alegando que não foi testado corretamente. O testador re-abre passando mais informações para o desenvolvedor entender melhor o bug.

Se esse processo fosse modelado utilizando o workflow seqüencial, teríamos uma quantidade muito grande de laços de repetição e operadores de decisão. Definindo estamos como: aberto, cancelado, corrigido, poderíamos modelar mais facilmente esse fluxo.

                                 img02.JPG

Por fim o outro estilo de workflow que temos é o chamado Data-Driven. Embora em muitos lugares ele seja tratado como

...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
25/09/2007 16:00:00





Artigo - Coluna MSP - Preparando o Dispositivo

Preparando o Dispositivo

por :Murilo Maciel Curti

 

Este artigo tem como objetivo mostrar como dar o primeiro passo no desenvolvimento de Jogos e interfaces gráficas avançadas utilizando a linguagem C++ com a API gráfica DirectX.

Veremos aqui como preparar o nosso "Dispositivo"(Device) para receber a renderização de nossas cenas.

 

Utilizarei aqui o Visual C++ 2005, que atualmente se encontra dem versão Beta e pode sofrer algumas alterações até seu lançamento, mas acredito que nada que possa atrapalhar a utilização deste artigo.

 

Antes de mais nada é necessários prepararmos o nosso projeto Win32 para trabalhar com o DirectX nesta versão, pois esta versão vem com uma parâmetro que pode gerar muita dor de cabeça.
Nas propriedades do projeto faça:

Configuration Properties/General/Character Set -> Not Set

 

Podmos já deixar o projeto preparado para as possíveis dependências, em

Configuration Properties/Linker/Input -> d3dxof.lib dxguid.lib d3dx9d.lib d3d9.lib winmm.lib

 

Iniciamos com a inclusão das bibliotecas necessaries, para trabalharmos simplesmente com o Dispositivo, utilizamos o cabeçalho padrão do Direct 3D.

 

#include

#include

 

Estamos iniciando uma classe que precisa ter uma identificação perante o sistema operacional, podemos definir uma macro que carregue esta identificação para ser utilizada na inicialização e encerramento da janela.

 

#define SHARP_CLASS_NAME "SharpDeviceWindow"

 

A utilização desta macro facilita a leitura e manutenção do código, veremos mais à frente que ela é utilizada em alguns pontos essenciais do programa.

Agora preciamos começar a pensar no nosso Device, e para ele ser utilizado por toda o programa declaramos como globais um objeto do Direct3D que cuidará da renderização das cenas no nosso Device.

 

LPDIRECT3D9 g_pD3D = NULL; // Used to create the D3DDevice

LPDIRECT3DDEVICE9 g_pd3dDevice = NULL; // Our rendering device

 

Objetos prontos e “inicializados” precisamos crier uma função que se responsabilizará pela inicialização do Direct3D. O seu valor de retorno é HRESULT, onde devolveremos S_OK se conseguirmos inicializar o Direct3D com sucesso ou E_FAIL se ocorrer algum erro, assim podemos fazer um tratamento eficaz sobre o estado do nosso dispositivo.
Começamos iniciando o objeto responsável pela criação do nosso dispositivo, é necessário termos uma instância válida para que possamos passer os dados corretos sobre a compatibilidade de hardware para o dispositivo.

 

HRESULT InitD3D( HWND hWnd )

{

    // Cria o objeto do Direct3D

    if((g_pD3D = Direct3DCreate9(D3D_SDK_VERSION)) == NULL)

        return E_FAIL;

 

Obtendo êxito na criação do objeto, podemos declarar a estrutura D3DPRESENT_PARAMETERS, que é responsável pelas propriedades da tela. Com ela podemos definer a quantidade de cores, as configurações dos Buffers, formato de apresentação entre outros.

D3DPRESENT_PARAMETERS d3dpp;

 

Como alguns parâmetros não serão definidos, existe a necessidade de “zerá-los” para que não passem dados inválidos para o nosso dispositivo, a função ZeroMemory cuida disto, ela faz com que todos os bytes encontrados na região reservada para a estrutura sejam setados para 0, assim podemos trabalhar tranquilamente sem a preocupação com alguma anomalia inesperada.

 

ZeroMemory(&d3dpp, sizeof(d3dpp));

 

Passamos um ponteiro que aponta para a região da memória onde é iniciado o espaço de nossa estrutura e utilizamos a função sizeof para informar a quantidade de bytes que correspondem à declaração de nossta estrutura. Atentem para estas funções, elas serão amplamente utilizadas no desenvolvimento de jogos.

 

O primeiro parâmetro que nos interessa é o responsável pelo modo de apresentação da janela, neste exemplo queremos que ela seja apresentada da forma convencional, uma janela, com os botões padrões.

 

d3dpp.Windowed = TRUE;

 

Para este tipo de exibição devemos usar o SwapEffect em sua forma padrão, onde ele informa ao Direct3D que ele deve escolher o melhor metodo para fazer a troca entre back e front buffer. Caso queiramos uma janela em modo FullScreen, devemos tomar alguns cuidados, que serão abordados no próximo artigo.

 

d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;

 

Também Podemos, e devemos definir qual é o formato de cores do nosso Back Buffer. Assim podemos definer se serão utilizadas 16 ou 32 bits de cores. É preciso tomar cuidado com este parâmetro pois nem todos os formatos são compatíveis com as placas de videos, então deixar o Direct3D fazer este trabalho por nós é interessante, pelo menos para este exemplo.

 

 

D3dpp.BackBufferFormat = D3DFMT_UNKNOWN;

 

Assim o Direct3D utilize o formato exibido na tela atualmente, porém este método só é válido para a janela vista como Windowed.
Para outras opções de cores utilize D3DFMT_R5G6B5 para 16 bits e D3DFMT_X8R8G8 para 32 bits.

 

Para finalizar a função agora vamos crier o nosso dispositivo, que vai ser criado baseando se nos dados da placa padrão D3DADAPTER_DEFAULT, geralmente encontramos apenas uma placa em cada máquina, mas se houver mais de uma não haverá problema algum.

Também instruimos o Direct3D a usar o máximo de processamento de Hardware possível, baseando se nas capacidades do sistema em qual está atuando, tendo assim processamento de software onde houver incompatibilidade e utilizar o máximo de hardware possível, fazendo a mixagem necessária para a rasterização, D3DDEVTYPE_HAL.

Também utilizamos aqui o processamento de vertices via Software, D3DCREATE_SOFTWARE_VERTEXPROCESSING, isto também para efeito de compatibilidade, porém o processamento de vertices via hardware, D3DCREATE_HARDWARE_VERTEXPROCESSING, consegue uma melhor performance, o que hoje em dia está se tornando muito comum devido às placas robustas que estão no Mercado.
Terminamos passando os ponteiros que apontam para nossos parâmetros de apresentação e para o dispositivo que está sendo criado, caso tudo corra bem nosso dispositivo estará criado e pronto para ser utilizado.

 

  

   if(FAILED(g_pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL,                   hWnd,D3DCREATE_SOFTWARE_VERTEXPROCESSING,&d3dpp,&g_pd3dDevice)))

   {

       return E_FAIL;

   }

 

   return S_OK;

}

 

Antes de continuar a implementação, vamos preparar nossa classe para que ela possa ser totalmente limpa da memória em seu encerramento, no nosso caso, ao final do jogo.

Com a função Cleanup() liberamos os recursos dos nosso dispositivo e do Direct3D que foram utilizados para nossa aplicação, mas aqui podemos centralizer outros recursos a serem “disposados”, é questão de evoluir o projeto.

 

VOID Cleanup()

{

    if(g_pd3dDevice != NULL)

        g_pd3dDevice->Release();

 

    if(g_pD3D != NULL)

        g_pD3D->Release();

}

 

 

...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
12/07/2007 17:46:00





 

Noticias/Dicas/Artigos pulicados.
Arquivo de atualizações
 2007

Estatísticas do Autor:
Número de posts: 2
Características dos posts deste autor:
Conteúdo:
Utilidade:
4 0
 
DevMedia Group - Tel: (21) 3382-5038 - www.devmedia.com.br
Todos os Direitos Reservados a DevMedia Group