• Nenhum resultado encontrado

Relatório de Estágio CdM: Módulo de Refeições

N/A
N/A
Protected

Academic year: 2021

Share "Relatório de Estágio CdM: Módulo de Refeições"

Copied!
91
0
0

Texto

(1)

Relatório de Estágio

CdM: Módulo de Refeições

Relatório de Estágio do Mestrado em Engenharia Informática

Por

Bruno Manuel Rodrigues Lameira

Orientação:

Doutor António Manuel Ribeiro de Sousa

Engenheira Ana Filipa Costa

(2)
(3)

i

Universidade de Trás-os-Montes e Alto Douro

Relatório de Estágio

CdM: Módulo de Refeições

Relatório de Estágio do Mestrado em Engenharia Informática

Por

Bruno Manuel Rodrigues Lameira

Orientação:

Doutor António Manuel Ribeiro de Sousa

Engenheira Ana Filipa Costa

Relatório de Estágio submetido à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Informática, elaborada sob a orientação de António Sousa, Professor Auxiliar do Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro, e da Filipa Costa, Gerente da empresa com enfoque nos Recursos Humanos, Qualidade e atenção ao cliente.

(4)
(5)

iii “More our knowledge increases, more evident is our ignorance”. John F.Kennedy

(6)
(7)

v O Instituto Português de Oncologia de Lisboa (IPOL) é uma instituição altamente especializada no tratamento de doentes oncológicos e que tem vindo a tentar desenvolver as suas infraestruturas e tecnologias para melhor atender os seus doentes. O IPOL entrou em contacto com a empresa ST+I para a criação de um módulo (aplicação) que permitisse realizar a gestão da cozinha ao nível das dietas e suplementos alimentares a confecionar para os doentes e serviços do hospital (funcionários). A empresa já possuía uma aplicação para a cozinha em funcionamento em alguns hospitais em Portugal, mas era considerada lenta, incompleta e difícil de utilizar. Assim, desenvolveu-se uma nova aplicação, tendo em conta os requisitos do cliente.

Para esse efeito, em primeiro lugar escolheram-se as tecnologias que poderiam ser utilizadas. Selecionaram-se as mais indicadas para a realização do projeto, de acordo com as exigências do cliente e as tecnologias em uso na empresa. Considerou-se como tecnologia de base de dados o Oracle e como linguagem de programação foi considerado o C# como a mais indicada para a realização do projeto.

Diferentes funcionalidades foram desenvolvidas de forma a permitir a gestão das refeições a confecionar pela cozinha do hospital, quer para os doentes internados, acompanhantes, doentes não internados e serviços hospitalares. A aplicação permite assegurar uma correta distribuição de refeições pelo hospital, graças às etiquetas que nela são geradas e que acompanham os tabuleiros das refeições para os doentes. Foi também criado um mecanismo de segurança para a faturação das refeições, garantido através da utilização de códigos de barra nas senhas para o refeitório.

Após todo o processo de desenvolvimento da aplicação estar concluído foram realizados testes à aplicação. Os resultados obtidos mostraram que a aplicação necessitava de algumas correções, e que se poderia proceder a algumas melhorias no design e no desempenho. Finalmente, após as alterações à aplicação os testes foram realizados com sucesso e foi alcançado o correto funcionamento da aplicação. Terminada a fase de testes internos, a aplicação foi entregue ao cliente, juntamente com o manual de utilizador, para realizarem os respetivos testes e posterior análise dos resultados. À data do presente relatório, os testes no cliente ainda se encontram em execução, não existindo resultados.

(8)
(9)

vii The Portuguese Institute of Oncology of Lisbon (IPOL) is a highly specialized instituion in the treatment of cancer patients and it has been trying to develop its infrastructures and technologies to better serve its patients. Thus, IPOL contacted the company ST+I to create a module (application) that would allow the management of the kitchen regarding to the diets and food supplements. The company already had an application for the kitchen present in some hospitals in Portugal, but it was considered slow, incomplete and difficult to use. Thus, a new desktop application was developed, taking into account the requirements of the client.

Initially, we considered the technologies that could be used, taking into account the requirements of the client and the technologies used in the company ST+I. It was considered as database technology Oracle and as programming language was considered C# as the most suitable for realization of the project.

Different functionalities were developed to allow the management of meals to be prepared by the hospital kitchen, either for inpatients, caregivers and hospital services. The application ensures correct distribution of meals through the hospital, thanks to the labels generated that accompane the meals for patients. In addition, a security mechanism for meal was created, guaranteed through the use of bar codes for the cafeteria.

After the entire application development process was completed, application tests were performed. The results showed that the application needed some corrections, and that some improvements could be made. Finally, after the changes to the application, the tests were successfully performed and the correct operation of the application was achieved. After the internal testing phase, the application was delivered to the customer, along with the user manual, to carry out the respective tests and subsequent analysis of the results. At the time of this report, the tests on the client are still running, with no results to show.

(10)
(11)

ix Este relatório marca o fim de uma etapa na minha vida. Uma etapa que se mostrou fantástica e trabalhosa. Apesar do percurso ser individual, existiram pessoas que contribuíram para o meu sucesso pessoal e académico, a quem presto o meu mais sentido agradecimento.

Um agradecimento especial aos meus pais e irmão pela coragem, confiança e determinação que depositaram em mim ao longo do meu percurso académico e pela oportunidade que me proporcionaram de crescer.

Ao Professor Doutor António Manuel Ribeiro de Sousa, pela orientação, acompanhamento, sugestões e correções que em muito contribuíram para o trabalho final, mas sobretudo pela sua total disponibilidade demonstrada.

Aos Docentes da Universidade de Trás-os-Montes e Alto Douro, pelo acompanhamento que me deram, o constante apoio e companheirismo que sempre tiveram comigo, e acima de tudo pelos conhecimentos que me transmitiram.

À empresa ST+I, pela oportunidade que me deu e por toda a confiança depositada em mim, em particular à Filipa Costa e ao Carlos Correia.

Aos meus colegas da ST+I, que me ajudaram e acompanharam em todas as fases deste trabalho em especial Carlos Guerra, Vítor Mesquita, Mauro Costa, e Hugo Pinto, sem eles nada disto seria possível.

A todos os meus colegas de Universidade, que me acompanharam durante estes anos, desde a Licenciatura em Tecnologias da Informação e Comunicação até ao Mestrado em Engenharia informática. Aos bons momentos que me proporcionaram, sempre dispostos a ajudar, repletos de simpatia e companheirismo. A todos os meus amigos que acompanharam nos bons e maus momentos académico, e sempre foram cruciais para que este caminho, por vezes difícil, mas, ao mesmo tempo esperançoso e cheio de boas histórias, fosse bem-sucedido.

A todos, o meu sentido e profundo obrigado! UTAD, Vila Real, 10 de junho de 2019

(12)
(13)

xi

Resumo ... v

Abstract ... vii

Agradecimentos ... ix

Índice de Tabelas ... xiii

Índice de Figuras ... xv

Glossário, Acrónimos e Abreviaturas ... xvii

CAPÍTULO 1 | Introdução ... 1 Enquadramento ... 4 Local de Estágio ... 4 Objetivos ... 5 Metodologia ... 6 Organização do Documento ... 8 CAPÍTULO 2 | Especificação ... 9 Requisitos ... 11

Diagramas de Casos de Uso ... 15

Modelo de dados ... 17

CAPÍTULO 3 | Revisão Tecnológica ... 21

Tecnológicas de Base de Dados ... 23

Tecnologia de Desenvolvimento ... 25 Arquiteturas de Software ... 29 CAPÍTULO 4 | Desenvolvimento ... 33 Estrutura Aplicacional ... 36 Ferramentas e Metodologias ... 38 Apache Subversion ... 38

(14)

xii Binding ... 39 LINQ ... 39 Partial Classes ... 40 PrEl Cozinha ... 41 CAPÍTULO 5 | Testes ... 51 Testes Internos ... 53 Melhorias à Aplicação ... 60

CAPÍTULO 6 | Conclusões e Trabalho Futuro ... 63

Discussão e Conclusões ... 65

Trabalho Futuro ... 66

Bibliografia ... 67

(15)

xiii

Índice de Tabelas

Tabela 1 –Comparação das principais características entre Oracle DataBase e MS SQL Server. ... 25 Tabela 2 – Esquema representativo de algumas das diferenças entre as linguagens C# e VB.NET pertencentes à .NET Framework ... 28 Tabela 3 - Tarefas (testes) realizadas numa primeira fase de forma a validar a aplicação. ... 54 Tabela 4 - Resultado esperado e resultado obtido para cada tarefa (T) realizada. ... 55 Tabela 5 - Descrição dos riscos e gravidade das falhas encontradas nos testes: S –risco identificado; N – risco não identificado. ... 58 Tabela 6 - Lista de tarefas realizadas numa segunda fase de testes realizados a aplicação. .... 59 Tabela 7. Ações executadas para comparação entre a antiga aplicação da cozinha da empresa e recente aplicação, PrEl Cozinha. ... 61

(16)
(17)

xv

Índice de Figuras

Figura 1 - Mapa dos Clientes, Parcerias e Colaboradores da empresa ST+I ... 5

Figura 2 – Representação do planeamento do trabalho através de stories e as respetivas tarefas assim como os diferentes estados de realização em que se encontram. Retirada do VSTS. ... 7

Figura 3 - Esquema das prescrições e pedidos extra que poderem ser realizados de acordo com o destinatário: a) doentes internados, b) acompanhantes, c) doentes não internados, e d) serviços, e que serão enviados para a aplicação. ... 14

Figura 4 - Diagrama de casos de uso, representativo da área das prescrições. ... 15

Figura 5 - Diagrama de casos de uso, representativo da área dos pedidos. ... 16

Figura 6 - Diagrama de casos de uso, representativo da área do refeitório. ... 17

Figura 7 - Diagrama E-R que representa as entidades pertencentes ao modelo de dados da aplicação. Por razões comerciais alguns campos das tabelas foram ocultados. ... 19

Figura 8 – Esquema demostrativo do funcionamento genérico do CLR ... 26

Figura 9 – Esquema descritivo dos componentes da arquitetura MVC e seu funcionamento. 30 Figura 10 - Esquema descritivo das componentes da arquitetura MVVM e seu funcionamento. ... 30

Figura 11 - Divisão da estrutura da aplicação em camadas: a) Camada de base de dados; b) Camada Lógica; c) GUI e as respetivas linguagens utilizadas para cada uma delas. ... 36

Figura 12 - Esquema descritivo do funcionamento e ligações da aplicação PrEl Cozinha ... 37

Figura 13- Funcionamento genérico do DataBinding, representação da fonte do binding e do alvo de binding e sentido do binding, retirada de (Microsoft, Binding, 2018) ... 39

Figura 14 – Exemplo de uma expressão LINQ utilizada no projeto, a fonte de dados é uma lista de objetos que é ordenada e agrupados os objetos que contenham o mesmo código. ... 40

Figura 15 - Menu principal da aplicação. a) Botão para abrir a janela das prescrições; b) Botão para abrir a janela dos pedidos, c) Botão para abrir a janela do Refeitório; d) Unidades Hospitalares. ... 41

(18)

xvi Figura 17 - Fluxograma que representa o processamento ... 43 Figura 18 – Segmento exemplo do XML utilizado para a criação das etiquetas (à esquerda). Etiqueta teste exemplo (à direita). ... 44 Figura 19- Janela dos pedidos extra da aplicação PrEl Cozinha, com os pedidos já processados. ... 45 Figura 20 - Janela do “Refeitório” da aplicação PrEl Cozinha, com a opção de processamento aberta. ... 46 Figura 21 – À esquerda: imagem com o XML da senha do acompanhante; À direita: imagem exemplo da senha do acompanhante gerada. ... 47 Figura 22 – Exemplo da janela com a composição de uma dieta prescrita. ... 48 Figura 23 - Janela com a composição de uma dieta e das respetivas refeições. ... 49 Figura 24 – Janela dos gráficos relativos aos doentes presentes em internamento hospitalar obtidos através da aplicação. (A) gráfico de barras que apresenta o estado dos doentes em determinado momento; (B) Gráfico circular que apresenta o estado de processamento dos doentes. ... 50 Figura 25 - À esquerda: janela com informações referentes à última alteração da prescrição da dieta do doente. À direita: janela com as informações referentes ao último processamento. .. 50 Figura 26 – Gráfico dos resultados da comparação entre as duas aplicações. Eixo dos xxs: ações executadas (A, B, C, D, E). Eixo dos yys: Tempo de execução (média das 10 repetições, em segundos) ... 62

(19)

xvii

Glossário, Acrónimos e Abreviaturas

Glossário de termos

Back-end – Responsável pela implementação das regras de negócio na aplicação. Parte a que

o utilizador não tem acesso.

Debug – Funcionalidade que permite correr um programa e colocar pontos de pausa de forma

a ser possível inspecionar que tipo de ações o programa está a executar.

Front-end – Parte de uma aplicação que interage diretamente com o utilizador. Interface gráfica

da aplicação.

Web Service – Tecnologia de software utilizada para a integração de sistemas e para a

comunicação entre aplicações diferentes.

Lista de Siglas e de Acrónimos

Sigla/Acrónimo Expansão

APA American Psychological Association CLR Common Language Runtime

COM Component Object Model CSS Cascading Style Sheets DAO Data Access Object

DLL Dynamic Link Library DTD Document Type Definition

FCL Framework Class Library GUI Graphic User Interface HTTP HyperText Markup Language

IDE Integrated Developement Enviroment IPOL Instituto Português de Oncologia de Lisboa

JIT Just-in-time

JVM Java Virtual Machine

MSIL Microsoft Intermediate Language OLAP Online Analytical Processing

PL/SQL Procedural Languages/Structure Query Language

(20)

xviii

Sigla/Acrónimo Expansão

PrEl Prescrição Eletrónica

SGBD Sistemas de Gestão de Base de Dados SQL Structure Query Language

ST+I Serviços Técnicos Informática SVN Sistema de Controlo de Versões

T-SQL Transaction-Structure Query Language UDDI Universal Description, Discovery and

Integration

UML Unified Modeling Language VSTS Visual Studio Team Schedule

URI Uniform Resource Identifier URL Uniform Resource Locator

WPF Windows Presentation Foundation WSDL Web Services Description Language WWW World Wide Web

XML Extensible Markup Language

Abreviaturas

Abreviatura Significado

et. al. e outros (autores) etc. etecetera, outros

(21)

1

CAPÍTULO 1

| Introdução

Neste capítulo é efetuada uma introdução ao projeto proposto, através da definição dos objetivos que se pretendiam alcançar, do enquadramento do tema e da empresa onde o trabalho foi realizado. É também apresentada a estrutura do relatório com uma referência sumária aos temas que são abordados nos diferentes capítulos.

(22)
(23)

3

1.

Introdução

A informática está presente nas mais variadas áreas da sociedade, e em algumas dessas áreas, como a Saúde, desempenha um papel fundamental na organização, tratamento e fluxo de informação. É sobre essa área que a empresa ST+I desenvolve a sua atividade, criando e implementando soluções para ambientes hospitalares que dão resposta aos seus processos e tarefas mais sensíveis. Processos e tarefas essas que envolvem toda a logística hospitalar, de armazém e farmácia, manutenção de equipamentos, imobilizado, concursos, prescrição médica, gestão de internamento, ambulatório, urgência, hospital de dia, circuito do medicamento, nutrição e cozinha.

Geralmente os motivos que levam as pessoas ao hospital não são os melhores, e o internamento estende-se, por vezes, por muito tempo, o que se torna numa experiência penosa. Se há alguma coisa que a possa tornar menos dolorosa, será a alimentação. A alimentação desempenha um papel essencial no dia-a-dia dos hospitais, principalmente nos casos dos internamentos, afetando a saúde física do doente e até o seu bem-estar psicológico. Por isso podemos considerar a alimentação hospitalar um elemento fundamental para melhorar a saúde do paciente hospitalizado, podendo assumir uma importância relevante a par do tratamento médico e farmacêutico.

“A atenção médica pode ser a melhor, o serviço de enfermaria insuperável e o equipamento o mais moderno, contudo o que a maioria dos pacientes

irão recordar do hospital é …. A COMIDA”

Luis García Santacana, Product Manager Dominion

Estes fatores levaram a que, em conjunto com a empresa ST+I fosse proposto o desenvolvimento de uma aplicação, que permitisse fazer toda a gestão da cozinha de um hospital dando resposta às necessidades apresentadas pelo Instituto Português de Oncologia de Lisboa (IPOL) que irá ser denominada de agora em diante PrEl Cozinha.

Tendo em consideração que este trabalho decorreu no contexto de um estágio em ambiente empresarial, inicialmente realizaram-se formações de forma a facilitar a integração na empresa e visitas hospitalares no sentido de melhor compreender o negócio e atividade que esta desenvolve.

(24)

Introdução

4

Enquadramento

Este trabalho realizou-se no âmbito do trabalho final do Mestrado em Engenharia Informática (MEI). A Universidade de Trás-os-Montes e Alto Douro (UTAD) disponibilizou um leque de alternativas quanto ao trabalho a realizar, assim como quanto à estrutura, redação e tipo do documento. Optou-se pela realização de um projeto que resultou neste documento de estágio, em colaboração com a empresa ST+I.

Como referido no ponto anterior, a empresa ST+I desenvolve software para gestão, facilitação e otimização de todo o processo hospitalar, possuindo vários módulos (aplicações), com funcionalidades diferente, que cobrem toda essa área e que se encaixam numa única aplicação que é o GHAF. O GHAF está dividido em duas grandes componentes: a Logística Hospitalar, que disponibiliza ferramentas, software, e permite fazer toda a logística e gestão de stocks de um hospital, gestão do imobilizado hospitalar e informatização de todo o processo envolvente na manutenção preventiva, corretiva, assistência e gestão de concursos dentro de uma Instituição Hospitalar.

A segunda grande componente da aplicação GHAF é o circuito do medicamento, que trata da monitorização do medicamento desde o momento em que é prescrito ao doente (por parte do médico), preparado (em casos de necessidade por parte dos técnicos de farmácia, por exemplo, medicamentos para o tratamento do cancro) e, por fim, administrado ao doente pelo enfermeiro. É na componente do circuito do medicamento, mais concretamente na parte da gestão de nutrição hospitalar, que se encaixou este projeto, pretendendo ser uma ferramenta para a gestão individualizada de cozinha hospitalar.

Local de Estágio

A empresa ST+I tornou-se uma entidade legal em 1989 com a comercialização de hardware para hospitais. Atualmente é uma Software-House que desenvolve a sua atividade na área das Tecnologias de Informação para a Saúde. Nos últimos anos tem tido um crescimento sustentado, essencialmente no setor público da saúde em Portugal (ST+I, 2019).

A empresa detém das soluções mais evoluídas do mercado nacional capazes de responder a todas as necessidades da gestão hospitalar. As soluções integradas de Gestão de Logística e

(25)

5 Circuito do Medicamento (GHAF – Gestão hospitalar, armazém e farmácia) englobam em si tecnologias e processos de trabalho recentes, o que possibilita uma melhor gestão, organização e consistência de toda a informação. Sendo o processo de desenvolvimento devidamente certificado, as soluções que produz contribuem de forma decisiva para a otimização dos processos hospitalares, traduzindo-se numa melhoria dos processos operacionais para os clientes e no serviço que os mesmos prestam aos seus doentes.

A empresa encontra-se agora numa fase de expansão, com uma aposta evidente na internacionalização, e com entrada em novos mercados com o sistema QuimioProcess. Este processo é uma solução integrada para Oncologia, que permite fazer toda a gestão do tratamento do doente oncológico numa única plataforma.

A principal missão da ST + I é ser uma referência internacional de elevado valor no sector da Saúde, de forma a garantir a sustentabilidade da empresa, valorizar as parcerias com os fornecedores e apostar na constante formação e evolução da sua equipa, melhorando cada vez mais os serviços prestados aos clientes (ST+I, 2019). As suas soluções tentam servir os princípios mais nobres das Instituições Hospitalares, e pretendem prestar um serviço de qualidade aos utentes das Instituições utilizadoras.

Objetivos

Pretendeu-se com este trabalho desenvolver uma aplicação (Desktop) para a gestão de uma cozinha hospitalar. A aplicação, de nome PrEl Cozinha, teve como referência inicial a antiga aplicação que a empresa já possuía. Reestruturou-se por completo o seu design, e foram criadas as funcionalidades pedidas pelo cliente, permitindo à instituição hospitalar realizar a gestão, de forma individualizada e/ou por especialidade, das dietas dos doentes, dos pedidos

(26)

Introdução

6 extra (refeições pedidas fora de hora, ou para acompanhantes do doente) e dos pedidos para o refeitório hospitalar (pedidos de refeições a realizar no refeitório do hospital). Para alcançar o objetivo principal foi necessário realizar uma lista de tarefas específicas:

 Especificar a solução a desenvolver, tendo em conta os requisitos para a sua realização.

Realizar um levantamento das tecnologias existentes para bases de dados, Front-end e Back-Front-end, e analisar a melhor opção para o desenvolvimento.

 Elaborar um manual de utilizador da aplicação para o cliente.

 Elaborar um manual técnico da aplicação.

 Realizar uma avaliação do desempenho (rapidez no carregamento dos dados) da aplicação proposta na execução das ações, e comparar com a antiga aplicação da cozinha.

 Realizar testes internos de forma a avaliar o funcionamento da aplicação proposta.

 Realizar testes no cliente ao funcionamento da aplicação proposto e validá-lo.

 Realizar ações de formação com o cliente.

 Analisar os resultados obtidos com os testes e definir alterações tendo em vista a melhoria.

Importa destacar que os objetivos não estão apresentados por qualquer ordem específica de importância.

Metodologia

No processo de desenvolvimento de software, a planificação, o agendamento, a previsão e antecipação de problemas são fundamentais para se conseguir cumprir prazos, orçamentos, e os requisitos do cliente. Para uma melhor definição das tarefas e organização do trabalho utilizou-se uma ferramenta do software Microsoft Visual Studio, para gerir e planear as etapas da realização do projeto, Visual Studio Team System (VSTS) como ilustrado na Figura 2 (Newkirk & Slott, 2007). O VSTS permite criar stories (atividades a realizar), de forma a organizar e descriminar as partes constituintes do projeto, é ainda possível atibuir a cada elemento da equipa um story. Dentro de cada story podem ser criadas tarefas e testes.

(27)

7 Os stories têm ainda um estado associado que indica a fase de realização em que se encontram (new, active, resolved closed) (Perez & Guckenheimer, 2006).

Figura 2 – Representação do planeamento do trabalho através de stories e as respetivas tarefas assim como os diferentes estados de realização em que se encontram. Retirada do VSTS.

Inicialmente procedeu-se ao levantamento dos requisitos/funcionalidades e detalhes pretendidos para a aplicação. Posteriormente, fez-se um levantamento bibliográfico das tecnologias que podiam ser uma opção viável para o desenvolvimento (tendo sempre em consideração as utilizadas na empresa).

Ao longo do desenvolvimento utilizou-se, para a gestão de versões da aplicação, a ferramenta Apache Subversion (SVN). Esta ferramenta permite manter o projeto num repositório e fazer o controlo das várias versões e alterações feitas ao longo do tempo, assim como a documentação dessas mesmas alterações (Pilato & Fitzpatrick, 2008). Mais adiante neste relatório são apresentados mais detalhes das funcionalidades que o SVN permite.

(28)

Introdução

8

Organização do Documento

Este documento está dividido em 6 capítulos, que abordam os tópicos identificados nos objetivos apresentados anteriormente (Consultar 0). Neste capítulo é efetuada uma introdução ao tema e à instituição, contextualizando o trabalho a desenvolver, qual o seu contributo e quais os objetivos que se pretendiam atingir.

No Capítulo 2 apresenta-se uma descrição detalhada dos requisitos funcionais e não funcionais recolhidos no cliente, que a aplicação teve de cumprir, o desenho e especificação das aplicações.

No Capítulo 3 abordam-se as tecnologias que foram ponderadas para o desenvolvimento do projeto.

No Capítulo 4 descreve-se o desenvolvimento do projeto, onde se podem encontrar imagens da aplicação e das suas funcionalidades, também neste capitulo temos a estrutura da aplicação e a arquitetura física.

No Capítulo 5 apresentam-se os testes e as validações que foram efetuadas à aplicação, assim como, as alterações e melhorias nela realizadas.

Por fim, no Capítulo 6 são apresentadas as conclusões, juntamente com uma reflexão sobre o trabalho que se desenvolveu e qual a sua real contribuição. Adicionalmente, são apresentadas perspetivas futuras de desenvolvimento e de manutenção da aplicação.

Nota Prévia: Este documento segue as normas de apresentação e escrita dos Relatórios

de estágio e Dissertações de Mestrado da Universidade de Trás dos Montes e Alto Douro, e as referências seguem a norma Bibliográfica da American Psychological Association (APA).

(29)

9

CAPÍTULO 2

| Especificação

Neste capítulo são descritos os requisitos que a aplicação deve cumprir de acordo com as necessidades do cliente, e os diagramas representativos das ações que o utilizador pode executar sobre a aplicação.

(30)
(31)

11

2

Especificação – PrEl Cozinha

A especificação do software é crucial em todos os projetos de desenvolvimento de aplicações, e segundo (Dick, 2017), a especificação incorreta ou incompleta é a causa mais comum para o fracasso do desenvolvimento.

A especificação da aplicação efetuou-se através dos requisitos funcionais e não funcionais. Os requisitos funcionais indicam quais as funcionalidades que a aplicação deve cumprir, os requisitos não-funcionais indicam as restrições que se colocam à aplicação, definindo-a. De forma a conseguir uma especificação consistente recorreu-se às ferramentas de Unified Modeling Language (UML), mais propriamente aos diagramas UML (Eriksson, 2000).

Requisitos

Identificaram-se um conjunto de requisitos funcionais, que traduzem aquilo que aplicação deverá permitir ao utilizador, ou seja, características e funcionalidades que a aplicação deverá possuir:

 A aplicação deverá permitir fazer a previsão das refeições a confecionar para um determinado dia/refeição/especialidade.

 A aplicação deverá permitir fazer a listagem por refeição com todas as dietas a enviar para as especialidades.

 A aplicação deverá permitir visualizar a informação de cada doente e da especialidade em que se encontra.

 A aplicação deverá permitir confirmar envio de refeições para as várias especialidades do hospital.

 A aplicação deverá permitir o envio de refeições para o(s) serviço(s).

 A aplicação deverá permitir a confirmar a emissão de senhas para os acompanhantes, doentes não internados e internados utilizarem o refeitório.

 A aplicação deverá ter um mecanismo de validação de senhas para o refeitório.

 A aplicação deverá permitir fazer a verificação e atualização dos preços das refeições.

(32)

Especificação

12

 A aplicação deverá permitir visualizar qual utilizador fez o processamento e em que data.

 A aplicação deverá permitir eliminar o processamento de dietas e suplementos/substituições para utilizadores que tenham permissão para tal.

 A aplicação deverá permitir fazer a impressão de etiquetas que acompanham os tabuleiros, apenas depois de processadas, aumentando a fiabilidade da refeição preparada na cozinha ser a mesma que é entregue ao doente.

 A aplicação deverá permitir a contagem automática de todos os tipos de dieta a confecionar e suplementos a enviar.

 A aplicação deverá permitir consultar as informações da última prescrição do doente.

 A aplicação deverá permitir consultar um histórico de todas as dietas de cada doente durante o seu internamento.

 A aplicação deverá permitir gerar notificações em caso de mudança de cama e de especialidades.

 A aplicação deverá permitir consultar as refeições e suplementos que são necessários confecionar por dia, refeição ou especialidade.

 A aplicação deverá permitir consultar listagens de doentes com dietas prescritas, listagens de doentes sem dietas, listagens de doentes sem composição (com dieta zero), listagens de doentes sem refeição e listagens de especialidades com dietas ativas.

 A aplicação deverá permitir visualizar se o doente se encontra em saída temporária.

 A aplicação deverá permitir visualizar a dieta prescrita a cada doente.

 A aplicação deverá permitir consultar a composição da dieta descrita por refeição.

 A aplicação deverá permitir consultar as alterações que foram efetuadas às prescrições das dietas dos doentes mediante o intervalo temporal pretendido.

 A aplicação deverá indicar as alergias alimentares que estão associadas aos doentes em caso de existirem.

 A aplicação deverá permitir a escolha da língua ao utilizador (Inglês, Espanhol e Português)

(33)

13 Foram também identificados os requisitos não funcionais que indicam o modo como o sistema deverá ser implementado e as suas restrições:

 A Base de dados deverá ser protegida para dar acesso somente a utilizadores autorizados.

A aplicação deverá incluir um sistema de username e password, de forma a que apenas utilizadores autorizados possam aceder à aplicação.

A aplicação deverá operar no sistema operativo Windows.

 A aplicação deverá ser ajustável a várias resoluções de diferentes monitores que o hospital possua.

 Todas as ações que têm implicações críticas (por exemplo: processamento de refeições, atualizações de preços, eliminar processamentos de refeições) só deverão ser executadas por utilizadores autorizados.

Após definidos os requisitos que moldam o sistema, foi realizada a especificação (desenho) da aplicação, recorrendo-se aos diagramas de casos de uso e diagramas entidade-relacionamento (Diagrama E-R).

Os médicos, enfermeiros e nutricionistas podem, utilizando os seus respetivos módulos no GHAF (PrEl Médico, PrEl Enfermeiro e PrEl Nutricionista respetivamente), efetuar prescrições de dietas e pedidos extra que são enviados para a aplicação, PrEl Cozinha. As prescrições são dietas passadas ao doente, nas quais são indicadas as refeições a realizar, os suplementos (acrescentos à refeição, caso os haja), as restrições, a data de início e de fim da dieta, e mais informações que sejam relevantes (necessidade de ajuda para comer por parte do doente, saídas temporárias, observações, etc). Os pedidos extra são refeições pedidas para um doente, acompanhante ou serviço que com exceção deste último, podem ser associados a uma dieta especifica (dieta geral, dieta vegetariana, dieta líquida, etc).

Na Figura 3 é possível observar as ações, prescrições e pedidos extra de dietas para doentes, que podem ser realizadas nos módulos médico, enfermeiro e nutricionista: para os doentes internados a) podem ser prescritas dietas, suplementos e substituições, admitindo também ser feitos pedidos de refeições associadas a dietas ou suplementos em casos excecionais para o doente (como por exemplo, se a hora de admissão do doente no hospital ultrapassa a hora limite da refeição pode ser criado um pedido extra para o doente); para os acompanhantes b), permite serem pedidas dietas e suplementos ou senhas de refeição para o refeitório; para doentes

(34)

Especificação

14 não internados c) também pode ser feito o pedido de dietas e suplementos ou senhas de refeição para o refeitório. Adicionalmente, também é possível fazer pedidos de refeições para os serviços do hospital d).

Figura 3 - Esquema das prescrições e pedidos extra que poderem ser realizados de acordo com o destinatário: a) doentes internados, b) acompanhantes, c) doentes não internados, e d) serviços, e que serão enviados para a aplicação.

Como referido no parágrafo anterior existe a possibilidade de serem efetuados vários tipos de prescrições e pedidos extra com diferentes destinatários, com base nisto e para uma melhor especificação e organização da aplicação, foi realizada uma divisão do sistema em termos de logística e de informação a ser apresentada. A divisão resultou em três áreas principais: área das prescrições onde são apresentados os doentes que se encontram em internamento no hospital, com dietas e suplementos prescritos pelos médicos, enfermeiros ou nutricionistas e também os doentes de especialidades que não tenham dietas; a área dos pedidos onde surgem os pedidos extra feitos pelos médicos, enfermeiros ou nutricionistas para acompanhantes, doentes não internados, internados e funcionários dos serviços hospitalares de

(35)

15 cada especialidade; a área do refeitório que representa os pedidos extra de senhas para acompanhantes e doentes, mas que são emitidos para o refeitório do Hospital.

Diagramas de Casos de Uso

Os diagramas de casos de uso, permitem documentar as funcionalidades necessárias no sistema e a interação entre as funcionalidades e o utilizador. Os casos de uso apresentados têm como base os requisitos funcionais apresentados no ponto anterior (2.1). Cada área descrita anteriormente é representada por um diagrama de casos de uso de forma a tornar mais percetível as interações possíveis do utilizador com o sistema.

Os diagramas que se seguem na Figura 4, Figura 5 e Figura 6 documentam o funcionamento da aplicação do ponto de vista do utilizador:

Área das Prescrições

(36)

Especificação

16

Área dos Pedidos Extra

(37)

17

Área do Refeitório

Figura 6 - Diagrama de casos de uso, representativo da área do refeitório.

Modelo de dados

Após definidos os casos de uso, desenvolveu-se um Diagrama E-R como ilustrado na Figura 7, que representa a estrutura da base de dados da aplicação. As relações entre si são descritas de seguida:

Cada doente pode ter várias admissões hospitalares (vários casos que compõem o histórico de casos) que por sua vez estão associadas a apenas um doente.

Cada um dos históricos de casos tem uma especialidade física (específica) que por sua vez está associada a uma especialidade médica (geral).

Cada doente pode ter associado uma linha (um registo na base de dados) com

(38)

Especificação

18

Para cada admissão (histórico de casos) existem várias linhas de cabeçalho descrevendo as prescrições, situações e parâmetros associados.

Para cada histórico de casos podem existir várias mudanças (as mudanças podem ser de cama, sala e especialidade).

Cada cabeçalho admite a associação a várias prescrições de dietas (linhas

dietas) que por sua vez estão associadas a uma dieta.

Cada suplemento pode ser prescrito várias vezes (linhas suplementos), e cada uma pode estar associada a várias prescrições de dietas (linhas dietas).

Cada dieta ao ser processada fica associada a um processamento_dietas.

 Cada suplemento ao ser processado fica associado a um

processamento_suplementos.

Cada pedido permite ter associada uma dieta e cada dieta pode estar associada a vários pedidos.

Cada pedido ao ser processado fica associado a um processamento_pedidos.

Como muitas dietas podem ser associadas a muitas refeições, tipos e variantes, foram criadas as tabelas associativas refeições_dietas, tipos-dietas,

variantes-dietas com o objetivo de se eliminar as ligações n para n (relação

(39)

19 Figura 7 - Diagrama E-R que representa as entidades pertencentes ao modelo de dados da aplicação. Por razões

(40)
(41)

21

CAPÍTULO 3

| Revisão Tecnológica

Este capítulo descreve as tecnologias e arquiteturas que foram estudadas e ponderadas para o desenvolvimento, assim como as escolhas feitas para cada componente da aplicação com base nesse estudo.

(42)
(43)

23

3

Revisão Tecnológica

Como se trata de um relatório de estágio, ou seja, um documento mais técnico que o documento de dissertação tradicional, a componente de estado da arte foi substituída por uma revisão tecnológica.

Antes de se iniciar o desenvolvimento da aplicação, efetuou-se uma revisão das tecnologias que podiam ser úteis para o seu desenvolvimento. Após essa fase escolheu-se as tecnologias que melhor se enquadravam, tendo em conta as ferramentas já em utilização pela empresa (compatibilidade) e os requisitos pretendidos pelo cliente. Para melhor se compreender as opções de desenvolvimento deste projeto são debatidas ao longo deste capítulo as tecnologias utilizadas, assim como alternativas também ponderadas na fase da sua seleção.

Tecnológicas de Base de Dados

A utilização de um Sistemas de Gestão de Base de Dados (SGBD) para aplicações focadas na apresentação de informação ao utilizador é essencial. Existem vários tipos de SGBD, sendo os mais utilizados, segundo o ranking DB-Engines Ranking (2018), o Oracle e o Microsoft SQL Server. O Microsoft SQL Server tem uma versão gratuita, denominada “Express Edition” assim como o Oracle Developer.

De acordo com (Greenwald, 2013), para a consulta de dados a linguagem mais utilizada é o Structured Query Language (SQL), que também permite a definição e manipulação de dados, o controlo de transações e o controlo de acesso à base de dados.

Oracle

Sendo um SGBD, o Oracle permite que os dados possam ser organizados em tabelas, que por sua vez se associem entre si por intermédio de chaves. A relação entre as tabelas é feita através de foreign key, e todas as tabelas possuem uma primary key, identificador único, não repetível e não nulo (Sumathi, 2007).

A arquitetura do Oracle encontra-se dividida entre a lógica de armazenamento e a estrutura física (como acontece nos SGBD). Esta característica permite adicionar ou alterar a

(44)

Revisão Tecnológica

24 lógica sem afetar a estrutura física da base de dados, os dados ou os utilizadores, desta forma a capacidade da base de dados é ajustada tendo em conta a necessidade dos utilizadores.

O Oracle utiliza a linguagem SQL como linguagem de consulta/manipulação dos dados, contudo o SQL tem algumas limitações por ser uma linguagem declarativa como é referido em (Feuerstein & Pribyl, 2005), não permitindo fazer por exemplo: if, while, for, foreach, etc. Para esse tipo de comandos o Oracle tem o Procedural Language/Structured Query Language (PL/SQL), que permite acesso a funcionalidades de uma linguagem de programação completa (Dorsey & Rosenblum, 2006). O PL/SQL é uma extensão da linguagem padrão SQL para o SGBD da Oracle, e é utilizada no processamento de transações, (Greenwald, 2013). Esta linguagem utiliza técnicas de programação orientada a objetos, e possibilita a utilização de stored and procedures, permite ainda o encapsulamento, sobrecarga de funções.

MS SQL SERVER

O Microsoft SQL Server (MS SQL Server), assim como o Oracle, é um SGBD relacional desenvolvido pela Microsoft, que possui várias versões destinadas a diferentes públicos e necessidades. O MS SQL Server tem a sua própria linguagem estendida do SQL que é o Transact-SQL (T-SQL) (Nielsen & Parui, 2011). O T-SQL é uma adição de características a linguagem SQL, como incluir controlo de transações, tratamento de exceções e de erros e declaração de variáveis.

Os dois têm estruturas similares, e as suas linguagens de processamento e transações derivam do SQL.

Oracle vs MS SQL SERVER

Na Tabela 1, estão ilustradas as principais diferenças entre estas duas tecnologias, tratando-se das mais utilizadas no mercado de base de dados.

(45)

25 Tabela 1 –Comparação das principais características entre Oracle DataBase e MS SQL Server.

Depois de ponderadas as duas soluções foi escolhido como tecnologia de base de dados o Oracle. As razões que levaram à escolha do Oracle foram: i) a empresa utiliza este sistema, tendo todas as estruturas de base de dados em Oracle, incluindo algumas das tabelas usadas no projeto, permitindo a sua reutilização; ii) ser útil em aplicações que requerem um alto desempenho na execução de tarefas (Feuerstein & Pribyl, 2005), que é o caso da aplicação PrEl Cozinha.

A versão do Oracle utilizada foi a 11g, introduzida no mercado no ano de 2007 e que é a utilizada na empresa. Esta versão oferece um aumento do desempenho dos sistemas, redução da redundância na base de dados e redução dos custos no armazenamento (Belknap, 2009).

Tecnologia de Desenvolvimento

Relativamente à framework de desenvolvimento utilizou-se a .NET Framework, não tendo sido ponderada para o desenvolvimento mais nenhuma framework, uma vez que a empresa utiliza apenas a .NET Framework. Para além disso existe uma maior experiência obtida na utilização desta tecnologia.

Diferenças Oracle DataBase MS SQL Server

Sistemas Operativos Windows, Linux, Unix e Mac OS…

Windows e Linux (Sql Server 2016)

Linguagens

Server-Side scripts

(Stored&Procedure)

PL/SQL T-SQL

Transaction Control Ativo por defeito.

(Stansfield, 2019).

Necessária ativação do mecanismo via Begin Transaction (Stansfield, 2019).

Disponibilidade Versão free – Express Edition Versão free – Express Edition

Triggers Usa After e Before triggers Usa geralmente After triggers

(46)

Revisão Tecnológica

26

.NET Framework – É uma framework da Microsoft que foi criada com o objetivo de

proporcionar uma plataforma única de desenvolvimento e execução de aplicações, permitindo que todo o código gerado possa ser executado em qualquer dispositivo que possua a Framework. Ou seja, dá a possibilidade de interoperabilidade entre as linguagens e qualquer aplicação que tenha sido desenvolvida, por exemplo, na linguagem C# pode ser facilmente transportada para a linguagem VisualBasic.NET (VB.NET) (Thai, 2003). Outra das características da Framework é permitir construir aplicações cliente/servidor em multicamadas, fornecendo um ambiente (arquiteturas remotas e Web Services) com capacidade para explorar os Standards da Internet como Hyper Text Transfer Protocol (HTTP), eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP) e Web Services Description Language (WSDL) (Thai, 2003). Esta Framework permite ainda a utilização de Language Integrated Query (LINQ).

A .Net Framework tem duas componentes principais:

1) Common Language Runtime (CLR) - representa o coração da .NET Framework (Microsoft CLR, 2019), sendo responsável pelos serviços de runtime tal como a gestão de segurança, memória, processos, threads e tratamento de exceções (Fruja, 2007). Todos os programas desenvolvidos na .NET Framework, independentemente da linguagem de programação, são executados pelo CLR. O CLR também permite que os programadores continuem a usar tecnologia de Dynamic Link Librarys (DLLs), muito utilizada na ST+I no desenvolvimento de aplicações.

O CLR (Figura 8) começa por compilar o código fonte para uma linguagem intermédia Microsoft Intermediate Language (MSIL) sempre que se executa a aplicação pela primeira vez, nas vezes seguintes acede à MSIL diretamente. De seguida o código é convertido para código nativo através do Just-In-Time (JIT). A utilização do JIT permite que o código seja executado na linguagem máquina nativa onde se encontra a correr.

(47)

27 2) Framework Class Library (FCL) - conjunto de bibliotecas que permitem conectar com a base de dados, aceder aos serviços do sistema operativo, estruturas de dados e algoritmos. Os recursos existentes nesta biblioteca são orientados a objetos, pelo que é possível derivar novas funcionalidades a partir das já existentes, reutilizando o código e reduzindo o tempo de desenvolvimento das aplicações.

Visual Studio .NET – É um ambiente de desenvolvimento integrado (IDE) pertencente à

.NET Framework, que permite o desenvolvimento de aplicações e de Web Services, e tem suporte para linguagens de programação como VB.NET, C#, F#, e ASP.NET. Foi o IDE que utilizado para o desenvolvimento da aplicação. Dentro das linguagens referidas foram ponderadas para o desenvolvimento o C# e o VB.NET, pois são as linguagens utilizadas na empresa para o desenvolvimento de software.

Linguagem de Programação C#

O C# é uma linguagem de programação desenvolvida pela Microsoft que faz parte de um conjunto de ferramentas oferecidas pela .Net Framework. É uma linguagem que possui uma sintaxe simples, robusta, moderna e totalmente orientada a objetos (Liberty, 2005). É baseada em C++ com algumas influências de Java e Object Pascal. Apesar de se basear em C++, fornece um conjunto de recursos adicionais que são essenciais ao programador, como tipos de valor nulo, enumerações, Delegates, e acesso direto à memória. O C# permite criar aplicações para o sistema operativo Windows, Web Services baseados em XML, aplicações cliente-servidor, aplicações que acedam a bases de dados, entre outras.

Tem caraterísticas fundamentais presentes em qualquer linguagem de topo como:

Garbage Collection: permite automatizar a gestão de memória (alocação/libertação) (Pizlo, 2007). Sempre que é criado um objeto, o CLR efetua a alocação de memória para esse objeto, desde que haja espaço para isso. Quando não existe espaço o garbage collection, verifica se existem objetos em memória que não estejam a ser usados e tenta recuperar a sua memória.

Tratamento de exceções: permite a deteção e recuperação de erros através de comandos Try, Catch e Finally.

Type-safe design: utilizado para prevenir erros relacionados com os tipos de dados. Não permite que se utilizem variáveis não inicializadas ou a indexação de arrays para além

(48)

Revisão Tecnológica

28 dos seus limites. Desempenha um papel fundamental no reforço da segurança da linguagem (Fruja, 2007).

Como geralmente acontece nas linguagens orientadas a objetos, esta linguagem suporta também os conceitos de encapsulamento, herança e polimorfismo. A linguagem C# é fortemente tipificada (variáveis têm que ter todas um tipo associado), é case-sensitive e possui suporte a DLL’s. Como as aplicações e as bibliotecas tendem a sofrer alterações frequentes ao longo da fase de desenvolvimento é necessário que, apesar das mudanças, seja mantido o bom funcionamento. Esse aspeto é possível através do controlo de versões permitido pela linguagem de programação.

Linguagem de Programação VisualBasic.NET

Assim como o C#, o VisualBasic.Net (VB.Net) também pertence à .NET Framework. É uma linguagem de programação criada pela Microsoft e orientada a objetos, com origem no Visual Basic 6.0 que foi descontinuado e a sua reformulação originou o VB.NET. Esta linguagem permite a criação de aplicações para a Web, mobile e Desktop, e tem suporte, tal como o C#, para classes abstratas, herança e polimorfismo. O VB.Net apresenta várias diferenças em comparação com o C#, algumas dessas diferenças encontram-se ilustradas na Tabela 2.

Tabela 2 – Esquema representativo de algumas das diferenças entre as linguagens C# e VB.NET pertencentes à .NET Framework

Diferenças C# VB.NET

Case Sensitive Sim Não

Keyword differences

Base, this, New MyBase, Me, New,CreateObject()

Syntax examples &; ||; null AND, OrElse,

Nothing

Data Types Int, float, bool Integer, Double,

(49)

29 Apesar de diferentes, estas duas linguagens também apresentam semelhanças: ambas foram desenvolvidas pela Microsoft, e fazem parte da .NET Framework, o que permite que qualquer programa escrito numa destas linguagens possa facilmente ser convertido para a outra.

Das linguagens ponderadas para o desenvolvimento da aplicação optou-se pelo C#, pois é uma das mais utilizada (Cass, 2014), existe uma maior experiência adquirida sobre a mesma e tem suporte ao desenvolvimento em sites/fóruns como o Stack-OverFlow e CodeProject. Contudo, apesar do C# ter sido a linguagem principal para o desenvolvimento da aplicação, foi necessário o desenvolvimento de algumas funcionalidades em VB.NET em módulos já existentes na empresa (desenvolvidos em VB.NET), para posterior integração com a aplicação.

Definida a linguagem a usar no desenvolvimento, foi então necessário avaliar a melhor solução no que diz respeito à arquitetura de software da aplicação.

Arquiteturas de Software

Todos as aplicações, com as quais os utilizadores tenham contacto direto, necessitam de uma interface gráfica, fazendo com que a integração da aplicação com a interface seja, atualmente, um dos grandes desafios da programação.

Para alcançar esta integração, vários padrões podem ser utilizados, sendo dos mais conhecidos o Model-View-Controller (MVC) e o Model-View-ViewModel (MVVM). Estes dois padrões são muito idênticos entre si e têm como ideia base a separação aplicacional de forma a diminuir a dependência entre as partes integrantes, conceito conhecido como Separated Presentation (Li, et al., 2015).

MVC

Atualmente, o padrão MVC é usado maioritariamente na criação de aplicações, e sistemas móveis. Com o MVC, a separação lógica da aplicação e a interface faz-se separando a aplicação em três componentes, em que cada uma delas lida com partes diferentes da aplicação (Diana M, 2006) (Figura 9):

(50)

Revisão Tecnológica

30

O model é responsável pela gestão dos dados e lógica da aplicação.

A view é responsável por mostrar o estado da aplicação (dados do model).

O controller é responsável por receber os inputs do utilizador, notificar/alterar o model e fazer as alterações na view.

A principal vantagem do padrão MVC é a independência que fornece à aplicação, permitindo alterações em cada componente sem ser necessário alterar as restantes, o que facilita a manutenção da aplicação e o reaproveitamento de código. Este padrão é muito útil em aplicações web, mas menos utilizado em aplicações de desktop (Leff & Rayfield, 2001).

MVVM

O padrão MVVM, é uma derivação do padrão MVC e por isso semelhante, separa a lógica do negócio da lógica da apresentação (Figura 10).

Figura 10 - Esquema descritivo das componentes da arquitetura MVVM e seu funcionamento. Figura 9 – Esquema descritivo dos componentes da arquitetura MVC e seu funcionamento.

(51)

31

O model lida com a lógica dos dados e as classes que a representam. No caso deste projeto, as classes e os respetivos atributos são gerados de forma automática a partir de queries à base de dados. O model contém os dados que serão consumidos pela aplicação e serve como uma ponte entre a base de dados e o viewmodel (Li, et al., 2015).

A view lida com a interface do utilizador, mostra as informações ao cliente e faz binding (tema que será aprofundado mais adiante) com as propriedades do viewmodel. Na view podem ser definidas as grelhas, botões, caixas de texto, painéis e outros controladores que são necessários à aplicação (Gao, Zhang, & YAO, 2012).

O viewmodel é responsável pelo estado e lógica da view, sendo a sua principal função de coordenar os controlos da view com os objetos presentes no model, funcionando assim como um mediador, fazendo queries, conversões e validação dos dados, de acordo com as necessidades da view (Li, et al., 2015). O viewmodel, através da invocação de métodos, expõe o model, através de um conjunto de propriedades que posteriormente são utilizadas na view. Para além de expor o model, o viewmodel manipula os seus dados de forma a facilitar o consumo pela view. O viewmodel liga-se à view através do binding. O binding permite vincular as propriedades do viewmodel aos controlos da view, mantendo-os sempre sincronizados (caixas de textos, labels, grelhas). Sempre que existe uma ação do utilizador num controlo da view alvo de binding, o viewmodel é notificado e vice-versa.

Em suma, o model e a view desempenham papéis semelhantes em ambas as arquiteturas. A principal diferença entre o MVVM e MVC encontra-se na função desempenhada pelo controller/viewmodel: no MVC o controller “controla” os eventos da aplicação, a view e o model; no caso do MVVM, o viewmodel é um mediador entre a view e o model. Entre as arquiteturas mencionadas optou-se pelo MVVM porque: i) permite usar na aplicação os mesmos dados para diferentes views, alterando apenas a forma como esses dados são apresentados; ii) permite que diferentes views utilizem o mesmo viewmodel reaproveitando código e ao mesmo tempo tornando o programa mais fácil de desenvolver, de testar e de manter (Li, et al., 2015); iii) permite o desenvolvimento em paralelo, e ainda iv) permite que os viewmodels possam ser reutilizados para o desenvolvimento web (que será um próximo passo deste projeto).

(52)

Revisão Tecnológica

32 Em comparação, o MVVM permite uma separação mais clara entre a view e a lógica do negócio. A abstração da view faz com que haja menos lógica necessária logo menos código. Contudo, esta arquitetura revela o problema de o viewmodel ficar com a maior parte das responsabilidades, ficando sobrecarregado de funções e complexo, tornando o debug difícil (Li, et al., 2015). Este facto gerou dificuldades no desenvolvimento da aplicação PrEl Cozinha, pois a análise do código em debug era complicada, com interações confusas principalmente com a utilização do mecanismo de binding.

(53)

33

CAPÍTULO 4 |

Desenvolvimento

Neste capítulo é descrita a fase de desenvolvimento da aplicação, identificada a estrutura que a constitui, as ferramentas e metodologias que permitiram o seu desenvolvimento, e a descrição da aplicação

(54)

34 .

(55)

35

4

Desenvolvimento

Escolhidas as tecnologias a utilizar na criação da aplicação partiu-se para o desenvolvimento. Todas as etapas do desenvolvimento foram documentadas de acordo com as regras de documentação de projetos da empresa, nomeadamente: todas as classes tiveram, no seu início, um comentário com as informações sumárias sobre os seus campos e uma descrição dos métodos que contêm; os métodos criados e as propriedades apresentam-se num breve texto com uma descrição do que fazem e os seus parâmetros. Para manter uma organização clara do código todos os documentos do código foram divididos em regions de acordo com o papel que cada componente desempenha (construtor, variáveis, métodos, notificações, eventos, propriedades, etc).

O desenvolvimento do software baseou-se nas normas de criação de software da empresa:

O software deve proporcionar ao utilizador um elevado grau de segurança.

 O utilizador tem sempre a palavra final no desenvolvimento do software.

O software deve permitir ao utilizador uma rápida aprendizagem.

O software deve ser fácil de utilizar e intuitivo.

O software deve ter em conta os recursos que o utilizador possui.

O software deve ser esteticamente atrativo, mas ao mesmo tempo funcional.

O software deve apresentar ao utilizador a possibilidade de visualizar o histórico de todos os registos que são realizados.

O software deve apresentar uma performance consistente.

O software deve estar preparado para se adaptar a alterações que sejam necessárias (atualizações).

O software deve evitar o engano por parte do utilizador, e em caso de engano deve conseguir reverter a ação.

(56)

Desenvolvimento

36

Estrutura Aplicacional

A aplicação caracterizou-se por uma divisão em 3 camadas lógicas (Figura 11) e que podiam ou não estar em execução no mesmo servidor físico. O principal objetivo da utilização deste modelo foi retirar a lógica da aplicação da parte do cliente, e assim obter uma maior separação aplicacional e um acoplamento fraco entre as componentes da aplicação. Isto refletiu-se numa vantagem pois, nos casos de erros e necessidades de atualizações de algum das componentes as restantes não foram afetadas/alteradas.

 A primeira camada (Figura 11a) caracterizou-se pela camada dos dados, servindo como repositório de informação.

 A segunda camada (Figura 11b) caracterizou-se pela camada lógica/negócio onde foram criadas as regras e métodos de negócio.

 A terceira camada (Figura 11c) caracterizou-se pela camada de apresentação/interface (GUI), é através dela que o utilizador pode interagir com a aplicação, fazendo requisições de informações, alterações ou pesquisas.

A aplicação comunica com a base de dados através do DAO. O DAO não é mais do que um cliente de web services (Figura 12) que permite executar queries. Os dados obtidos do DAO são enviados para o BUS, validados e transformados em DataObjects conforme as regras de negócio e são enviados para o GUI, onde serão usados como Model da arquitetura MVVM. A gestão do contexto de negócio é feita pelo AppBusiness, que é responsável pela manutenção do contexto, variáveis globais e orquestração das ações básicas da aplicação.

a

b

c

Figura 11 - Divisão da estrutura da aplicação em camadas: a) Camada de base de dados; b) Camada Lógica; c) GUI e as respetivas linguagens utilizadas para cada uma delas.

(57)

37 Cada uma destas componentes (Figura 12) desempenha uma função essencial para o funcionamento correto da aplicação:

Base de dados constituída por tabelas, triggers, packages, contêm a estrutura dos dados.

Midleware comunica com a camada de base de dados e com o GUI:

o DAO faz operações sobre a base de dados. A utilização do DAO permite mudar a fonte dos dados sem ter que se fazer alterações na aplicação. Tornando a aplicação flexível quanto à proveniência dos dados.

o BUS (Business) carrega, guarda, preenche objetos e estruturas conforme regras de negócio.

o DataObjects armazenamento de dados em objetos POCO de modo a ser fácil o transporte de informação.

o DataContext: define os parâmetros de ligação a uma base de dados, podendo ser de acesso direto, via cliente Oracle ou via Web Service.

o AppBusiness: Contexto do Negócio. É responsável por inicializar e manter o DataContext assim como todas as variáveis globais e orquestração das ações básicas da aplicação.

Gui é a interface do utilizador (UserControls, Eventos, Bindings, etc..):

o ViewModel carrega os dados a partir do Model e vincula-os aos eventos da View, cada ViewModel pode ter várias Views associadas, mas cada View só pode ter um ViewModel associado.

o View constituída por janelas, botões, eventos e interface gráfica.

o Model é uma representação dos DataObjects, mas manipulados, para que, melhor se encaixem nas necessidades das views.

(58)

Desenvolvimento

38

Ferramentas e Metodologias

Ao longo do desenvolvimento surgiu a necessidade de utilização de algumas ferramentas e mecanismos de programação que foram essenciais para atingir os objetivos propostos e para o correto funcionamento da aplicação, sendo destacados em seguida.

Apache Subversion

Para o controlo das versões no desenvolvimento foi utilizado o Apache Subversion (SVN). O seu funcionamento é semelhante a uma arquitetura de cliente-servidor: um servidor (repositório) armazena a versão mais atual do projeto e o seu histórico, e os clientes conectam-se ao conectam-servidor para fazer check-out da cópia completa do projeto. Os clientes trabalham então na sua cópia local e mais tarde fazem check-in das alterações realizadas para o servidor (Rooney & Berlin, 2007). O SVN é constituído pelo trunk que armazena a versão funcional mais recente, pelos branches que são versões para o desenvolvimento paralelo geradas a partir do trunk, e pelas tags que são os backups das versões (Pilato & Fitzpatrick, 2008).

As principais características deste mecanismo são:

 Controlar versões de ficheiros e diretorias.

 Permitir que vários programadores trabalhem no mesmo projeto ao mesmo tempo.

 A fusão das alterações é feita automaticamente caso não exista conflitos nas alterações realizadas.

Criar um branch para o debug enquanto mantém o branch principal para o desenvolvimento de novas funcionalidades, branching.

 Quando um ficheiro é submetido para o servidor, apenas as linhas que tiveram alterações em relação à versão anterior são enviadas e armazenadas.

Permite fazer commit das alterações realizadas localmente para o repositório.

 Permite recuperar versões anteriores e visualizar um histórico com as alterações. Todo o projeto foi mantido num repositório único e as várias versões geridas através do SVN. No final de cada dia todas os desenvolvimentos e alterações realizadas foram submetidas (commit) para esse mesmo repositório com uma descrição das alterações.

(59)

39

Binding

O binding ou databinding é o processo através do qual se estabelece uma ligação/conexão entre elementos da interface gráfica (por exemplo: caixas de textos, labels, grelhas, etc) com os dados. Sempre que existe uma alteração na propriedade fonte de binding, essas alterações são refletidas no elemento que está a ser alvo do binding, com recurso a notificações (Microsoft, Binding, 2018). Note-se o seguinte exemplo do funcionamento do binding: um objeto aluno, com um atributo idade que esteja a ser alvo de binding por parte de uma textbox (fonte do binding), sempre que for inserido um valor para a idade na textbox, será desencadeada uma notificação e o atributo da idade irá refletir o valor da textbox. O binding pode ser feito num sentido ou nos dois sentidos como ilustrado na Figura 13, sendo o sentido do binding definido pelo programador. Os dados são atualizados através da interface Notify-Property-Changed.

LINQ

O LINQ é uma componente exclusiva da .NET Framework que possui funcionalidades que permitem realizar consultas. A sua sintaxe é semelhante ao SQL, e assim como ele, as suas expressões de consulta permitem a construção de instruções para extrair informações de fontes de dados (Rattz, 2008). Essas fontes de dados podem ser vetores, coleções de objetos (Figura 14), ficheiros XML, entre outros.

Figura 13- Funcionamento genérico do DataBinding, representação da fonte do binding e do alvo de binding e sentido do binding, retirada de (Microsoft, Binding, 2018)

Imagem

Figura 1 - Mapa dos Clientes, Parcerias e Colaboradores da empresa ST+I
Figura  2 – Representação do planeamento do trabalho através de  stories e as respetivas  tarefas assim como os  diferentes estados de realização em que se encontram
Figura 3 - Esquema das prescrições e pedidos extra que poderem ser realizados de acordo com o destinatário: a)  doentes  internados,  b)  acompanhantes,  c)  doentes  não  internados,  e  d)  serviços,    e  que  serão  enviados  para  a  aplicação
Figura 4 - Diagrama de casos de uso, representativo da área das prescrições.
+7

Referências

Documentos relacionados

É discutido desde uma revisão histórica da maneira como os animais não-humanos são representados no contexto de modernização de uma urbe; passando por revisões

Todas as segundas-feiras na parte de manhã, na sala de professores da Escola Secundária José Augusto Pinto, se reuniam a professora estagiária Manísia Ferreira e a

Estudar) a) importância) da) marca) em) negócios) start`up,) desde) a) sua) criação,) passando) pelo)desenvolvimento)até)aos)objetivos)que)se)pretendem)alcançar,)permite)fazer)com)

8) O circuito do exercício anterior mostra claramente que o AO será destruído, caso seja drenada uma corrente superior ao que é especificada pelo fabricante. Uma das maneiras

Passo 1- Introduzir o conceito alvo a ser aprendido. Fazer uma breve ou completa explicação dependendo de como a analogia será empregada. Passo 2- Sugerir aos estudantes a

Após as medições de fosforescência, as médias dos resultados das triplicatas foram calculadas e se encontram na Tabela 1, onde pode ser visto que o harmine é mais sensível à

a) Caberá a interposição de recurso da Prova Escrita, por escrito e devidamente fundamentado, dirigido ao Conselho Administrativo do Centro, no prazo de 02(dois)

 A Copacol, cooperativa da agroindústria, irá investir R$ 390 milhões em projetos voltados à ampliação de três fábricas, em Cafelândia e Nova Aurora, e um