Библиотека сайта rus-linux.net
OSCAR
Глава 16 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: OSCAR
Автор: Jennifer Ruttan
Перевод: А.Панин
16.7. Выученные уроки
Как вы, возможно, представляете, система OSCAR имеет свой набор недостатков, присущих ее архитектуре. Однако, она предоставляет завершенный набор возможностей, с которым у большинства пользователей не возникает никаких проблем. В этом и заключается главная цель проекта: предоставить качественное решение, функционирующее в большинстве ситуаций.
Я не могу говорить от лица всего сообщества разработчиков системы OSCAR, поэтому в данном разделе будет отражена лишь моя субъективная точка зрения. Мне кажется, что существуют некоторые важные темы, не относящиеся к аспектам архитектуры проекта.
Во-первых, очевидно, что недостаточный контроль над исходным кодом в прошлом привел к тому, что архитектура системы стала достаточно неупорядоченной в некоторых местах, особенно в тех областях, где контроллеры и представления смешивались друг с другом. Путь, по которому проект развивался в прошлом, не позволил предотвратить подобные последствия, но с того времени процесс разработки претерпел значительные изменения и, надеюсь, что проект не столкнется с подобной проблемой снова.
Еще следует упомянуть о том, что из-за достаточного возраста проекта становится сложно обновить (или даже изменить) библиотеки без причинения значительных неудобств остальной кодовой базе. Кстати, это именно ситуация, которая и произошла. Мне обычно сложно выяснить, что важно, а что нет при исследовании директории библиотек. В дополнение к этому следует упомянуть о том, что иногда при значительных обновлениях библиотек они нарушают обратную совместимость (изменение названий пакетов является стандартной причиной). Обычно в комплекте поставки системы OSCAR присутствует несколько библиотек, выполняющих одну и туже задачу - это результат недостаточного контроля над исходным кодом, а также того факта, что не было создано документации со списком библиотек и описанием того, какая библиотека требуется для какого из компонентов.
Дополнительно следует отметить то, что проект OSCAR не достаточно гибок при добавлении новых функций в существующие подсистемы. Например, в том случае, когда вы хотите добавить новое поле в электронную карту пациента, вам придется создать новую JSP-страницу и новый сервлет, модифицировать шаблон электронной карты (в нескольких местах) и модифицировать конфигурационный файл приложения для возможности загрузки вашего сервлета.
Кроме того, ввиду отсутствия документации иногда практически невозможно выяснить то, как работает часть системы - человек, разработавший оригинальный код, может уже не участвовать в проекте и обычно единственным доступным инструментом, позволяющим вам выяснить это, является отладчик. В случае рассмотрения проекта такого возраста ценой этого обстоятельства являются утраченные возможности новых потенциальных участников, которые могли бы начать работу в рамках проекта. Однако, благодаря совместным усилиям участников проекта и схожим факторам, сообщество продолжает работу.
Наконец, система OSCAR является репозиторием медицинской информации и ее безопасность значительно снижается из-за включения в комплект поставки класса DBHandler (описанного в предыдущем разделе). Лично я считаю, что принимающие параметры запросы к базе данных в свободной форме ни в коем случае не должны быть разрешены в системе электронных медицинских записей, так как с помощью них можно достаточно просто производить атаки на основе SQL-инъекций. Хотя запрет на разработку нового, использующего данный класс кода и является правильным решением, приоритетная задача команды разработчиков должна заключаться в удалении всех вариантов использования данного класса.
Все эти слова могут звучать как жесткая критика проекта. В прошлом все описанные проблемы были заметны и, как я говорила, они сдерживали рост сообщества из-за высокого барьера вхождения в проект. Но ситуация меняется, поэтому в будущем эти проблемы не будут настолько большим препятствием на пути развития.
Оглядываясь назад и рассматривая историю развития проекта (особенно в течение выхода нескольких последних версий), мы можем лучшим образом спроектировать приложение. Система все так же должна будет предоставлять базовый набор функций (установленный правительством Онтарио для сертификации приложения как системы электронных медицинских записей), поэтому эти функции должны быть реализованы по умолчанию. Но в том случае, если архитектура системы OSCAR будет изменяться сегодня, она должна стать по-настоящему модульной и позволять рассматривать модули как плагины; если вам не нравился модуль электронной формы, вы получите возможность создать свою собственную реализацию (или даже полностью отличный модуль). У системы должна появится возможность взаимодействия с большим количеством систем (или большее количество систем должно иметь возможность взаимодействия с ней), включая медицинское оборудование, которое все чаще используется в индустрии, такое, как оборудование для проверки остроты зрения. Это утверждение также обозначает, что должна быть предоставлена возможность достаточно простой адаптации системы OSCAR к требованиям, предъявляемым к системам хранения медицинских данных региональными и федеральными правительствами всех стран мира. Так как каждый регион имеет отличный от других набор законов и требований, это архитектурное решение должно быть ключевых для уверенности в том, что система OSCAR разрабатывается для нужд пользователей со всего мира.
Я также верю в то, что вопрос безопасности должен быть наиболее важным из всех. Система электронных медицинских записей безопасна ровно настолько, насколько безопасен ее наименее защищенный компонент, поэтому особое внимание должно быть уделено вопросу абстрагирования приложения от метода доступа к данным настолько, насколько это возможно таким образом, чтобы оно хранило и получало данные, работая в безопасном окружении и используя основной уровень API доступа к данным, который прошел аудит сторонних лиц и считается подходящим для хранения медицинской информации. Другие системы электронных медицинских записей могут скрывать подробности реализации и использовать закрытый пропиетарный код в качестве меры безопасности (которая на самом деле не является таковой), но так как система OSCAR распространяется в форме открытого исходного кода, она должна возглавлять список наиболее тщательно защищающих данные систем.
Я твердо верю в будущее проекта OSCAR. У нас есть сотни пользователей, о которых мы знаем (а также многие сотни пользователей, о которых нам не известно) и мы получаем важные отчеты о работе приложения от медицинских работников, которые взаимодействуют с нашим проектом ежедневно. Через разработку новых процессов и добавление новых возможностей мы надеемся расширить базу установок и начать поддерживать пользователей из всех других регионов. Нашим намерением движет уверенность в том, что мы предоставляем что-либо, улучшающее жизнь использующих систему OSCAR медицинских работников, а также жизни их пациентов, разрабатывая лучшие инструменты для упрощения работы в сфере здравоохранения.
Вернуться к началу статьи.