An enterprise distributed system

Transcrição

1 An enterprise distributed system 2º Trabalho Prático Tecnologias de Distribuição e Integração 4º Ano do Mestrado Integrado em Engenharia Informática e Computação João Carlos Figueiredo Rodrigues Prudêncio ei07111@fe.up.pt Seraphin Rodrigues Miranda ei06132@fe.up.pt Maio

2 Índice 1.Introdução Descrição Problema Visão Geral Arquitectura Descrição Módulos Web Client Store Client Orders Service Host Wharehouse Web Server Clerk Wharehouse GUI Queued Service Factory Factory GUI Diagramas de Sequência Interface Gráfica Testes Conclusão Referências

3 Índice de Ilustrações Ilustração 1 - Diagrama da arquitectura geral... 6 Ilustração 2 - Diagrama de casos de uso... 7 Ilustração 3 - Diagrama de arquitectura... 8 Ilustração 4 - Binding NetMsmqBinding...12 Ilustração 5 - Diagrama de sequência com stock...14 Ilustração 6 - Diagrama de sequência sem stock...15 Ilustração 7 - GUI do Store Server...16 Ilustração 8 - GUI WEB Client...17 Ilustração 9 - GUI do Store Client...18 Ilustração 10 - GUI do Wharehouse...19 Ilustração 11 - Consola do serviço da Wharehouse...19 Ilustração 12 - GUI da Factory

4 1.Introdução Este projecto foi realizado no âmbito da Unidade Curricular Tecnologias de Distribuição e Integração, pertencente ao 4º ano do Mestrado Integrado de Engenharia Informática e Computação. O principal objectivo deste trabalho é explorar a tecnologia.net Remoting e desenhar aplicações baseadas na arquitectura SOA. Usou-se como ambiente de trabalho o Visual Studio 2010, e como linguagem de programação C# e ASP. Pretende-se implementar um sistema para gerir uma empresa que produz e comercializa artigos, no nosso caso, artigos relacionados com a área da informática. Neste documento irá ser feita uma descrição pormenorizada do problema no capítulo 2. De seguida, será descrita a divisão arquitectural implementada, isso tendo em conta a divisão em diferentes módulos. Posteriormente é feita uma descrição da interface gráfica implementada. Finalmente, apresenta-se a metodologia de testes usada, assim como, as conclusões gerais do trabalho. 4

5 1. Descrição Problema O problema proposto consiste na implementação de um sistema de gestão de vendas, produção e armazenamento de produtos. A aquisição dos produtos por parte dos clientes pode ser realizada de duas maneiras distintas. A primeira alternativa consiste numa encomenda através de uma interface WEB. A segunda alternativa consiste em deslocar-se à loja, onde o empregado preencherá os dados da encomenda no seu computador, através de uma interface dedicada. Caso existir stock disponível para satisfazer o pedido, será imprimido de imediato uma nota de encomenda, de forma a proceder à entrega da mesma. Note-se que esta nota de encomenda será imprimida no armazém, para o empregado responsável proceder à fase de entrega. Em qualquer um dos meios de envio de encomenda se não existir stock suficiente no armazém, será enviado automaticamente um pedido de fabrico à fábrica com dez vezes o número de produtos em falta. A fábrica depois de receber o pedido de fabrico tratará de fabricar os produtos e de os enviar ao armazém, onde por sua vez será enviada a encomenda ao respectivo cliente. Os responsáveis do armazém deverão ter acesso a toda a informação sobre as ordens pendentes, o historial de ordens, assim como o stock disponível. Além disto, é necessário ter em conta que a fábrica tem um horário de funcionamento a tempo parcial, o que tem que ser tomado em conta na arquitectura do sistema. Assim, o servidor da fábrica, deverá ter um mecanismo para armazenar todas as encomendas de fabrico, mesmo que esteja Offline. 5

6 De seguida, ilustra-se um diagrama que representa o sistema geral, separado pelos seus vários módulos constituintes. Ilustração 1 - Diagrama da arquitectura geral Além da arquitectura geral do sistema, é importante definir os actores do sistema, e quais os papéis de cada um. Inicialmente foi descrito o funcionamento geral do sistema, e de seguida ilustra-se um diagrama de casos de uso, que descreve esquematicamente a interacção dos diferentes utilizadores perante o sistema. 6

7 Ilustração 2 - Diagrama de casos de uso 7

8 3. Visão Geral 3.1 Arquitectura Tendo em conta o problema descrito, é crucial dividir o sistema em várias aplicações distribuídas, sendo que algumas delas serão Web Services. Apresenta-se de seguida um diagrama que ilustra a arquitectura do sistema. Ilustração 3 - Diagrama de arquitectura 8

9 Como se pode verificar, o cliente através da aplicação WEB ou da aplicação Desktop, pode efectuar um pedido. Este pedido é feito a um WEB Service que se encontra localizado na loja. A loja comunica com o armazém através de um outro Web Service, que se encarregará de tratar do pedido. Note-se que optou-se por subdividir a aplicação nestes dois Web Services, para tornar a aplicação mais flexível, de forma a separar a implementação da loja e do armazém, tornando o sistema loosely coupled. O Web Service do armazém através de um sistema de Callbacks, envia a informação para a Interface Gráfica. Esta aplicação fica responsável também por actualizar uma Base de Dados local, desenvolvida em Microsoft SQL Server Compact. Na situação de stock inexistente, irá ser feito um pedido de fabrico a outro Web Service pertencente à fábrica. Neste caso, devido aos requisitos iniciais do problema, usou-se o Binding NetMsmqBinding, de forma a permitir a comunicação através de Filas de espera entre o cliente e o serviço. Este serviço na fábrica irá, de forma análoga ao armazém, actualizar a Interface Gráfica através de Callbacks, e persistir os dados numa Base de Dados local. De seguida, descreve-se cada um dos módulos pormenorizadamente. 3.2 Descrição Módulos Web Client Esta aplicação foi desenvolvida usando a tecnologia ASP, e consiste num pequeno formulário para adicionar uma nova encomenda. Existe uma referência para o serviço OrdersService, para ser possível adicionar essa encomenda Store Client 9

10 Esta aplicação é muito semelhante à anterior, tendo como principal diferença ser uma aplicação Desktop, tendo sido desenvolvido usando a framework WPF Orders Service Host Esta aplicação é uma Windows Form, onde é alojado o serviço OrdersService. Este permite receber pedidos de encomendar e reencaminhar para a fábrica. Note-se que este serviço usa o binding do tipo wshttpbinding, sendo este aplicado em situações onde é necessário segurança e troca de mensagens fiáveis. É o binding por defeito em WCF. Para ser possível efectuar este encaminhamento, este possui uma referência para o serviço WharehouseService Wharehouse Web Server Esta aplicação é crucial para todo o fluxo de informação, uma vez que é responsável pela recepção de novas encomendas, pedidos de produção à fábrica, e impressão de notas de encomenda. Existe um serviço denominado WharehouseService configurado com o binding wsdualhttpbinding para permitir Callbacks. Este serviço disponibiliza opções para adicionar novas encomendas. Quando se recebe um pedido deste tipo, a Base de Dados local DBStocks.sdf, terá que ser actualizada. Esta Base de Dados possui uma tabela para a gestão de encomendas, e outra tabela para a gestão de stocks. Existem Callbacks para actualizar a interface gráfica Clerk Wharehouse GUI. Assim sempre que algo for alterado, esta será actualizada. Este serviço, possui também a referência do serviço QueuedServiceFactory, para ser possível enviar pedidos de produção para a fábrica, em caso de falta de stock. 10

11 Além disso, é importante referir que o serviço WharehouseService está a correr numa aplicação do tipo de linhas de comandos. Esta consola, irá ser usada também para imprimir as notas de encomenda Clerk Wharehouse GUI Esta Interface Gráfica será usada para monitorizar o estado de todas as encomendas. Estão implementados as interfaces dos Callbacks definidos no WharehouseService, permitindo que a informação presente na Interface esteja sempre actualizada. É também possível seleccionar a opção para entregar uma encomenda, na listagem de encomendas pendentes, emitindo automaticamente pedidos ao serviço para actualizar os stocks e o estado da ordem Queued Service Factory Como foi referido anteriormente, usou-se um binding do tipo NetMsmqBinding no Web Service designado por QueuedServiceFactory. Assim, garante-se que as mensagens serão sempre entregues a este serviço, mesmo que este não esteja disponível no momento da comunicação. Este tipo de binding usa um sistema de Queues, criando uma Fila de Espera para armazenar os pedidos, antes de serem processados. 11

12 Ilustração 4 - Binding NetMsmqBinding Após a recepção do pedido, este é encaminhado para o Web Service da fábrica, designado por FactoryService. Este usa um binding do tipo wsdualhttpbinding, permitindo desta forma o tipo de comunicação Duplex, permitindo que tanto o cliente cmo o serviço enviem mensagens. Note-se que é essencial usar este tipo de binding, para ser possível usar um Callback, que actualizar a Interface Gráfica Factory GUI. O serviço FactoryService, contém uma lista de assinantes, ou seja, de aplicações que pretendem serem notificados com as actualizações. Assim sendo, sempre que o serviço recebe uma nova encomenda, irá invocar o callback de cada um desses assinantes. Apesar de no contexto do problema, apenas foi especificado a existência de uma fábrica, o sistema encontra-se já preparado para extender esses requisitos Factory GUI Esta aplicação foi desenvolvida usando a framework WPF, permitindo desenvolver rapidamente uma Interface Gráfica apelativa. Existe um handler que irá tratar o Callback accionado pelo FactoryService. Esta função irá gravar esta informação na Base de Dados local, e actualizar as listagens na Interface. 12

13 Perante a listagem de pedidos de fabrico, é possível visualizar e a actualizar o estado. Sempre que o estado de uma determinada ordem é alterado, esta informação é enviada para o serviço do armazém WhareHouseService. Existem duas possíveis interacções com cada pedido: 1. Caso o pedido possua o estado waiting manufacturing, é possível alterar esse estado passando para dispatch should occur at (3 days from actual date). Significa que a fábrica iniciou a produção deste artigo, e deve portanto notificar o armazém. 2. Caso o pedido possua o estado dispatch should occur at..., é possível alterar esse estado, notificando o armazém que este artigo já foi produzido e vai ser enviado. 3.3 Diagramas de Sequência Para ilustrar o fluxo de dados entre as várias aplicações e serviços, foram elaborados diagramas de sequência. De seguida ilustra-se um diagrama de sequência, onde se parte do principio que existe stock no armazém para satisfazer o pedido. Apesar de a encomenda neste diagrama ser feita através do Website, o fluxo de dados relativo ao StoreClient seria idêntico. Assume-se que neste caso o stock é actualizado automaticamente, e imprimida a nota de expedição. Assim sendo, o funcionário não terá que tomar qualquer acção perante o sistema. Simplesmente, o funcionário do armazém usará a nota de expedição para entregar o artigo ao cliente. 13

14 Ilustração 5 - Diagrama de sequência com stock Seguidamente, ilustra-se o diagrama respectivo à situação de inexistência de stock para satisfazer o pedido. Neste caso, é necessário efectua um pedido de fabrico à fábrica, e esperar que o artigo esteja pronto. A fábrica vai notificar o armazém da evolução do pedido, e quando este tiver sido produzido, assume-se o pressuposto que o artigo terá algum mecanismo para actualizar o stock automaticamente quando chegar ao armazém. Assim sendo, quando a fabricar notificar que o artigo foi enviado, o armazém actualiza o stock. O funcionário do armazém, terá acesso a uma listagem de pedidos pendentes, e que já podem ser satisfeitos, além da evolução do stock ao longo do tempo. Este funcionário, poderá seleccionar qualquer um destes pedidos e decidir enviar. Esta acção provocará uma actualização do stock, e a impressão da nota de encomenda. 14

15 Ilustração 6 - Diagrama de sequência sem stock 15

16 4. Interface Gráfica Quando a aplicação é iniciada começamos por abrir o Store Server, cuja principal função é aceitar pedidos provenientes do Web Client e da Store Client. Seguese a seguir uma imagem do Store Server. Ilustração 7 - GUI do Store Server Depois de começar a correr o Store Server, já é possível efectuar encomendas através da interface WEB Client e da interface gráfica da Store Client. A seguinte imagem reprensenta a interface gráfica do WEB Client. 16

17 Ilustração 8 - GUI WEB Client Nesta interface WEB Client é preciso carregar no botão Connection para poder começar a enviar pedidos. Deste modo garantimos que os pedidos serão recebidos após o serviço começar a correr. Na próxima imagem é possível visualizar a interface Store Client, onde é possível fazer encomendas tal como a WEB Client. 17

18 Ilustração 9 - GUI do Store Client Da mesma forma do que a interface WEB Client, é possível efectuar uma encomenda no interior da loja. Esta interface é dedicada ao empregado e permite efectuar a mesma tarefa do que a interface WEB Client. Em qualquer um dos casos, poderá preencher as caixas de textos. De seguida deverá clicar no botão Connect para a interface se ligar ao serviço. Se a ligação for bem sucedida então poderá proceder ao envio da encomenda. O pedido de encomenda irá para o serviço que tratará de actualizar a GUI da WhareHouse. Na próxima imagem é possível visualizar a interface da Wharehouse. 18

19 Ilustração 10 - GUI do Wharehouse Primeiramente é verificado se existe stock, se este for suficiente para satisfazer o pedido então é enviado uma mensagem para a linha de comandos do serviço da Wharehouse que irá ser utilizada para simular a impressora. A impressora poderá ser visualizada na próxima imagem. Ilustração 11 - Consola do serviço da Wharehouse 19

20 Ainda na Wharehouse é possível consultar três tabs. Na primeira tab é possível consultar o histórico de todos os pedidos que foram realizados até à data. Na segunda tab é possível visualizar todos os pedidos que podem ser entregues ao cliente. Estes pedidos são resultados de pedidos de encomenda que não tinham stock e que posteriormente, após o envio do pedido de produção, foram entregues à WhareHouse por parte da fábrica. Ainda nessa tab existem um botão Dispatch que permite enviar ao cliente o que ele encomendou. Além de ser actualizado a informação na primeira tab relativa a todas as ordens, é também imprimido a ordem de encomenda na impressora (linha de comandos). Na útlima tab, é possível visualizar a quantidade de stock existente de cada produto. No caso de ser efectuado um pedido para o qual não existia stock suficiente, é lançado um pedido de fabrico da quantidade desse produto vezes dez. Esse pedido é enviado para a Factory através de um serviço de message queueing. Na seguinte imagem é possível visualizar a interface da Factory. Ilustração 12 - GUI da Factory 20

21 Inicialmente para subscrever ao serviço é necessário clicar no botão Connect, a partir desse momento já é possível visualizar todos os pedidos de fabrico. Para cada pedido deverá carregar inicialmente no botão Manufacter para começar a produzir o produto do pedido de fabrico em questão. O estado do pedido será alterado para mostar que o produto está em fabricação. Quando acabar a fabrico do produto, o utilizador deverá carregar no botão Completed para mudar o estado do pedido para waiting expedition e então o o resultado do pedido ser encaminhado para a Wharehouse, onde por sua vez será encaminhado para o cliente final. O sistema tratará de garantir que não poderá terminar um pedido de fabrico sem que este tenha sido posto em produção. 21

22 5. Testes Para determinar o correcto funcionamento da aplicação foram realizados alguns testes que comprovam o correcto funcionamento da aplicação. Estes testes têm o intuito de validar as funcionalidades desenvolvidas, relativamente aos requisitos determinados na análise dos requisitos da aplicação. Para garantir a persistência dos dados, foram feitos vários testes para confirmar o bom funcionamento das bases de dados locais implementadas. Durante a fase de testes, foi testada a aplicação em rede a qual funcionou correctamente. A abordagem utilizada no desenvolvimento do sistema foi a abordagem incremental. No fim de implementar e integrar cada funcionalidade, tivemos o cuidado de testar exaustivamente essas funcionalidades. Nesta mesma abordagem, inicialmente tínhamos a aplicação a funcionar em modo consola. Quase no final da implementação, convertemos as nossas aplicações em modo consola em interfaces gráficas. Para testar o serviço de message queueing desligamos a FactoryGUI e o serviço QueuedServiceFactory. De seguida efectuamos um pedido normalmente e esse deverá ficar guardado na mesma numa queue. Quando o funcionário da fábrica iniciar a aplicação ele deverá receber, na mesma, esse pedido. 22

23 6. Conclusão Foram atingidos todos os objectivos inicialmente definidos para a elaboração do projecto. As funcionalidades definidas inicialmente também foram concretizadas com sucesso. Durante o desenvolvimento foram discutidas várias arquitecturas para a aplicação. Acreditamos que a nossa arquitectura, discutida anteriormente, seja adequada ao ambiente na qual se insere. Este projecto foi essencial para a aplicar os conhecimentos adquiridos sobre C#,.NET Remoting e SOA. 23

24 7. Referências Ingo Rammer, M. S. (2005). Advanced.NET Remoting. Apress. Microsoft. (s.d.). Microsoft msdn library. Obtido de Monteiro, M. P. (s.d.). TDIN. Obtido de Myers, B. (2007). Foundation of WPF - An Introduction to Windows Worklfow Foundation. Apress. 24