MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

Transcrição

1 MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3 1. Instituto Atlântico, Centro de tecnologia XML (CTXML) 2. Universidade Estadual do Ceará (UECE), Brasil 3. Faculdade Integrada do Ceará (FIC) Resumo - Este artigo apresenta uma idéia de arquitetura para a solução de E-Learning (ensino a distância) utilizando as tecnologias Microsoft: linguagem C# e plataforma ASP.NET. Palavras-chave: Informática Médica, Tecnologia da Informação, Padrões de projeto. Abstract - This paper shows an architecture view to E-Learning solution (education in the distance) using Microsoft technologies: language C# and platform ASP.NET. Key-words: Medical Informatics, Information Technologies, Design Patterns. Introdução A demanda por produtos e serviços na área de educação à distância, em especial, na área da saúde tem crescido de forma considerável nos últimos anos. Isso se deve principalmente a grande necessidade que os profissionais da área da saúde têm de se atualizarem ou se especializarem. Essa dificuldade é ainda maior nas regiões menos desenvolvidas e mais afastadas dos centros de ensino [3]. Atualmente, a melhor forma de oferecer serviços que atendam uma grande gama de clientes (como é o caso dos profissionais de saúde) independentemente de suas localizações é utilização de softwares que possam ser acessados através da Internet (aplicações Web). A tecnologia Microsoft oferece, através da plataforma ASP.NET e do Framework.NET [2], as ferramentas necessárias para o desenvolvimento de aplicações web robustas e de grande escala. Para comprovar a eficiência das tecnologias Microsoft.NET e atender a demanda citada acima (software de ensino a distância para profissionais da saúde) foi desenvolvida a aplicação MedEl (Medical E-Learning). Tal aplicação utiliza fortemente os conceitos de Orientação a Objetos e de Padrões de Projeto [1]. O trabalho está organizado da seguinte forma: primeiro serão abordados os principais conceitos de Orientação a Objetos e Padrões de Projeto. Logo em seguida, serão discutidos os Padrões de Projeto e a Arquitetura utilizados no MedEl. A seguir, serão apresentados alguns resultados e, por fim, algumas conclusões e trabalhos futuros. Metodologia A solução apresentada utiliza conceitos de Orientação a Objetos e de Padrões de Projeto (Design Patterns). Orientação a Objetos Os princípios mais importantes do paradigma da orientação a objetos são: encapsulamento, herança e polimorfismo. Nesse paradigma, tudo está relacionado a objetos. Um objeto pode ser visto como uma entidade do mundo real que tem uma identidade. Objetos podem representar entidades concretas (um arquivo no computador, uma bicicleta) ou entidades conceituais (uma estratégia de um jogo, uma política de gerenciamento de acesso a um programa). Cada objeto ter sua identidade significa dizer que eles são diferentes mesmo que possuam as mesmas características. A estrutura de um objeto é representada por atributos. Os comportamentos de um objeto são representados por um conjunto de operações, tipicamente chamado de métodos, que podem ser executadas sobre o objeto. Objetos com a mesma estrutura e o mesmo comportamento são agrupados em classes. Cada classe descreve um conjunto (possivelmente infinito) de objetos individuais. Cada objeto é, então, uma instância de uma classe. Os objetos não vêem os detalhes de implementação dos métodos, isso é chamado de encapsulamento de código. Polimorfismo significa que a mesma operação pode se comportar de forma diferente em classes diferentes. Isso também implica que

2 uma operação de uma mesma classe pode ser implementada por mais de um método. O usuário não precisa saber quantas implementações existem para uma operação, ou explicitar qual método deve ser utilizado: a linguagem de programação deve ser capaz de selecionar o método correto a partir do nome da operação, classe do objeto e dos argumentos para a operação. No mundo real, alguns objetos e classes podem ser descritos como casos especiais, ou especializações, de outros objetos e classes. Herança é o mecanismo do paradigma de orientação a objetos que permite compartilhar atributos e operações entre classes baseadas em um relacionamento hierárquico. Uma classe pode ser definida de forma genérica e depois refinada sucessivamente em termos de subclasses ou classes derivadas. Cada subclasse incorpora, ou herda, todas as propriedades de sua superclasse (ou classe base) e adiciona suas propriedades únicas e particulares. As propriedades da classe base não precisam ser repetidas em cada classe derivada. As Linguagens de Programação Orientada a Objetos fornecem todas as ferramentas para o desenvolvimento de software através do paradigma OO. Uma vez implementada, a OO facilita bastante o projeto que pode ser ampliado posteriormente com um considerável ganho de produtividade. A seguir, abordaremos alguns Padrões de Projeto que foram utilizados no desenvolvimento da solução MedEl. Dentre os padrões utilizados estão: MVC, DAO, Factory, Singleton e Abstract Factory. Figura 1 - Modelo do padrão MVC. A camada Model representa os dados e as regras de negócio da aplicação. A camada View é a qual o usuário final vê ou interage. A View mostra parte da Model para o usuário final. A View nunca deve modificar diretamente os dados da camada Model, nem deve interagir com as regras de negócio da Model. A camada Controller é responsável por realizar a ligação entra as camadas Model e View. Ela define o fluxo da aplicação, agindo como interpretador dos eventos de usuário, sendo o mediador entre View e Controller. O padrão Data Access Object (DAO) é responsável por separar o código que acessa o banco de dados (fonte de dados) do código que trabalha com os dados (camada de negócios). Um DAO é responsável por ler dados de uma fonte de dados externa (banco de dados, por exemplo) e prover dados encapsulados em objetos que serão utilizados pelos componentes de negócio. Padrões de Projeto Os padrões de projeto são, basicamente, soluções repetidas para problemas repetidos. Em uma perspectiva de programação, um padrão de projeto fornece um conjunto de interações específicas que podem ser aplicadas para objetos genéricos para resolver problemas conhecidos. Eles são criados à medida que soluções de problemas são descobertas. A seguir iremos apresentar alguns importantes padrões que servem como base para o entendimento da solução MedEl. Uma variação do padrão de projeto MVC, chamada Model 2, que é uma adaptação para o desenvolvimento web, foi utilizado por duas importantes razões: manutenção e facilidade de testes do código. MVC é constituído por três peças básicas: Model, View e Controller. Figura 2 - Diagrama do padrão DAO. No diagrama acima, o objeto DAO Obj. Acesso Dados lê os dados da Fonte Dados e encapsula-os em um objeto chamado ValueObject. O componente de negócio objeto negócio manipula esse objeto e não os dados diretamente. O padrão Factory é responsável por fabricar (criar) um conjunto de objetos que possuem um certo grau de relacionamento. O padrão Singleton é utilizado quando se necessita assegurar que só pode existir uma e somente uma instância de uma classe. Uma maneira de implementar um Singleton é ter uma variável private static dentro da classe com o mesmo tipo da classe, ter seus construtores privados, forçando que uma instância dessa classe não seja criada diretamente, e um método que irá retornar a única instância. Se essa

3 instância não existir, ele será criado a primeira vez e sempre que o método for chamado, ele irá retornar a mesma instância. Abstract factory provê uma interface para criar famílias de objetos relacionados sem especificar suas classes concretas. Algumas vezes queremos construir uma instância de uma classe de um conjunto de classes, decidindo entre as classes em tempo de instanciação. Para evitar duplicar a decisão fazendo em todo lugar que uma instância é criada, precisamos de um mecanismo para criar uma instância das classes relacionadas sem necessariamente saber qual classe concreta será instanciada. Para entender Abstract Factory, examine o diagrama de classes abaixo. Note que existem duas hierarquias separadas. A primeira representa várias abstrações que a classe cliente tem interesse. Para cada abstração, existe uma definição de classe abstrata (Classe abstrata 1, Classe abstrata 2, etc), e as subclasses que fornecem concretas implementações (Classe concreta 1A, Classe concreta 1B, etc). Na segunda hierarquia, uma classe abstrata AbstractFactory é definida para fornecer a interface para cada classe que é responsável por criar os membros de uma particular família. Por exemplo, a classe concreta FactoryB é responsável por criar objetos das classes classe concreta 1B e Classe concreta 2B. Figura 4 Arquitetura geral da solução adotada A seguir, iremos mostrar como cada uma das três camadas trabalha e como elas interagem entre si. Camada de Apresentação MedElUi A camada de apresentação contém os ASP.NET WebForms, possuindo navegabilidade simples e intuitiva. Para a manipulação das Entidades (eg. Cursos, Tutoriais, Arquivos) utilizamos Entities e suas respectivas especializações. Ao receber alguma requisição do usuário, a página monta os Entities necessários a partir dos Forms. Os Forms recebem os dados como strings, fazem a conversão para o tipo correto, e retornam o Entity correspondente. Com o Entity montado, o WebForm poderá chamar os métodos da Camada de Negócio. Figura 3 - Diagrama de um exemplo da aplicabilidade do padrão Abstract Factory. Arquitetura e Padrões de Projeto Utilizados A arquitetura do Sistema é composta de três camadas: MedElUI, camada de apresentação, MedElBusiness, camada de negócios, e MedElDAO, camada de dados. Para uma visão geral do Sistema, veja a Figura 4. Figura 5 Modelagem UML Camada de Negócio Business Layer A camada é a responsável por receber os Entities da Camada de Apresentação e executar

4 as ações requisitadas, gerando algum tipo de retorno se necessário. Quando a Camada de Apresentação deseja fazer alguma chamada para a Camada de Negócio, esta deve fazê-la através do Business da entidade a ser tratada (CourseBusiness, UserBusiness, etc). O Business é um Singleton [1] e é obtido através do BusinessFactory, que implementa o padrão de projeto AbstractFactory [1] Para ações que requerem um número significativo de interações, um Facade [1] é utilizado para interceptar as chamadas e enviá-las para o(s) Business correspondentes. Para ações que requerem acesso a dados, uma especialização da Interface DAO, que implementa o padrão de projeto Data Acess Object [2], é utilizada através da Camada de Dados. Figura 6 Diagrama de classes Camada de Dados Data Base Layer Nessa camada estão presentes as implementações dos Data Acess Objects (DAO s). Cada DAO é chamado através de sua Interface (ICourseDAO, IFileDAO, etc), deixando a camada flexível para diversas formas de acesso a dados, bastando para isso implementar a Interface de acordo com a forma de acesso desejada. Na solução apresentada, foram implementados DAO s para acesso a Banco de Dados SQL Server Antes de executar alguma operação no Banco, o DAO utiliza a classe QueryReader, passando a string correspondente à sua instância e o nome da operação a ser realizada, para obter a query SQL correspondente. As operações no banco são executadas através da classe SqlCommand. Para operações de insert e update o DAO recebe da camada de negócios o Entity a ser incluído ou atualizado e modifica o banco. Para operações de consulta o DAO recebe Entities como parâmetros e devolve o resultado em uma IList. Por exemplo, para recuperar todos os alunos de um curso o DAO deve receber um ICourseEntity e devolver uma IList contendo os Users cadastrados no curso. Resultados Figura 7 Modelagem UML O desenvolvimento da aplicação MedEl em apenas um mês serve para demonstrar a produtividade da arquitetura detalhada anteriormente e do ambiente RAD (Visual Studio.NET) da Microsoft. Além disso, o MedEl poderá ser um passo importante no processo de atualização e especialização dos profissionais de saúde. Segue abaixo, uma amostra da Interface Homem-Computador do MedEl. O usuário autentica-se (figura 8) no sistema e a partir deste ponto, ele começa a ser limitado pela configuração do seu perfil. Administradores, professores e alunos têm acesso a certos recursos como, provas, edição de perfis, confecção de cursos (figura 9), visualização do mesmo (figura 10). Figura 8 Tela de Login

5 Referências [1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns Elements of Reusable Object Oriented Software. Addison Wesley, [2] David S. Platt. Introducing Microsoft.NET. Microsoft Press, Figura 9 Tela de cadastro de cursos [3] Christante, L., Ramos, M. P., Bessa, R., Sigulem, D., (2002), O Papel do Ensino a Distância na Educação Médica Continuada: uma Análise Crítica. Anais do VII Congresso Brasileiro de Informática em Saúde. Contatos Átila Correia {atila@atlantico.com.br} Glaucon Henrique {glaucon@atlantico.com.br} Jorge Bérgson {jorge@atlantico.com.br} Rui Gomes Patrício {rui_design@hotmail.com} Waner Tavares {wanft@atlantico.com.br} Instituto Atlântico Rua Chico Lemos, 946 Fortaleza CE (85) Figura 10 Visualização do curso Discussão e Conclusões A utilização de arquitetura em três camadas, com a conseqüente definição dos serviços entre elas, foi de fundamental importância na conclusão do projeto. A facilidade de manutenção, gerenciamento de códigos e recursos foi ideal para a conclusão em tempo hábil. A arquitetura tem grande poder de reutilização, pode ser utilizada em sistemas similares ou mesmo na ampliação de outros que foram idealizados nesta arquitetura. O ambiente RAD do Visual Studio.NET é de alta produtividade, tanto na parte de geração de código, como na parte da confecção da GUI (que realmente representa uma verdadeira ferramenta RAD) e até a geração do instalador da aplicação. Além das facilidades que a IDE fornece, o Framework.NET possui uma extensa biblioteca de classes bem documentada (o que facilita o seu aprendizado). Devido ao grau de desacoplamento dos componentes, como pode ser visto no detalhamento da arquitetura do projeto, a inclusão de novos componentes, tais como Chat, Vídeos, base de conhecimento inteligente, etc, torna-se menos complexo e mais gerenciável. A inclusão desses módulos bem como o melhoramento dos outros (após feedback dos usuários finais) serão objetos de trabalhos futuros.