Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
Продолжение. Начало ≈ в ╚КИ╩ ╧ 16/2001
Игорь Полубелов,
Oдной из главных составляющих успешного создания и внедрения информационной системы (ИС) является правильно выбранная программная архитектура. От этого выбора зависит успех разработки в целом, эффективность функционирования ИС, возможность ее масштабирования в будущем и, как следствие оправданность инвестиций. Создание новой ИС ≈ это всегда риск, подтверждение тому ≈ масса упоминаний в компьютерной печати подобных следующему: ╚по оценкам The Wall Street Journal, более 50% от общего числа корпоративных программных проектов не оправдывают возложенных надежд, причем работы над 42% прекращаются задолго до их логического завершения╩ (Брюс Эбботт ╚От программной ошибки к финансовой катастрофе╩, Computerworld, #44/2000. Этот риск важно минимизировать, поэтому специалисты компании Эврика уделяют особое внимание выбору программной архитектуры системы, которая должна быть максимально адекватной поставленной задаче.
При выборе программной архитектуры системы необходимо учитывать множество факторов, таких как назначение системы, требуемая производительность, условия эксплуатации системы, требования надежности, масштабируемости и безопасности, особенности объекта автоматизации. Другим, не менее важным моментом, является ╚способность╩ архитектуры и выбранных программных средств обеспечить коллективную разработку, повторное использование кода, созданного, в том числе, и другими разработчиками, единую среду хранения проектов и кода.
Для автоматизации военных медицинских учреждений (╚КИ╩═╧ 16/2001, стр. 4) было решено разрабатывать систему с использованием технологии ╚Интранет╩ и трехзвенной клиент-серверной архитектуры. Такой выбор объясняется сложностью разрабатываемой системы как в качественном, так и в количественном отношении, необходимостью масштабирования и соединения в единую систему всех объектов.
Выбор интранет объясняется несколькими причинами. Во-первых, в этом случае требования, предъявляемые к аппаратному обеспечению рабочих станций пользователей, становятся минимальны. Основное требование ≈ нормальная работа Web-браузера. Во-вторых, в этом случае существенно упрощается администрирование рабочих мест, т.═к. практически вся функциональность системы находится на серверах, и настройка конкретного рабочего места может осуществляться средствами удаленного администрирования с любого компьютера, входящего в ЛВС организации. В-третьих это позволяет создать единую среду для корпоративной системы.
При выборе архитектуры также учитывалась тенденция развития математического обеспечения, и производился сравнительный анализ существующих программных продуктов, предлагаемых на рынке.
Для реализации системы была выбрана линейка продуктов фирмы Sybase, включающая все необходимое математическое обеспечения (сервер БД, сервера приложений, сервер репликации) √ Adaptive Server Enterprise, Enterprise Application Studio и Replication Server.
Получение высоких результатов работы информационной системы зависит от правильного и оптимального распределения функциональности между всеми звеньями выбранной архитектуры и программными компонентами, ее реализующими, т.═е. высококачественного проектирования системы.
Для этой цели системными аналитиками компании Эврика был разработан процесс проектирования ПО, включающий ряд методик (методика проектирования, методика использования информации эскизного проекта), которые применялись при разработке систем автоматизации военных лечебных и медицинских учреждений и могут быть с успехом применены при разработке системы из любой другой предметной области.
Используемые CASE-средства на всех этапах проектирования осуществляют контроль корректности создаваемых моделей, а система контроля версий обеспечивает поддержку ведения групповой работы над проектом, что в конечном итоге позволяет добиться оптимального соотношения скорости разработки и качества проекта.
Процесс проектирования системы автоматизации состоит из двух частей: создания модели данных, адекватной рассматриваемой предметной области, и создания проекта программных компонентов, реализующих заданную функциональность.
Для хранения информации в системе автоматизации деятельности ВЛУ и ВМУ было решено использовать реляционную модель представления данных как наиболее опробованную и распространенную. На наш взгляд (это частное мнение), существующие объектные СУБД пока еще не готовы к промышленной эксплуатации, тем более что при их выборе возникает много других вопросов: доступность на рынке, техническая поддержка, опыт применения и пр. Проект БД был выполнен на основе традиционной технологии (модель ╚сущность-связь╩, CASE Power Designer). Исходной информацией для него послужили материалы обследования (см.═предыдущую статью цикла), такие как постановки задач, медицинские и корпоративные справочники, классификаторы, формы документов.
Учитывая объем представляемой информации, модель данных была разбита на подмодели, представляющие отдельные части предметной области. В качестве примеров подмоделей можно привести подмодели персональной информации о пациенте, медицинской информации, адресной информации, информации о движении пациентов, диагностические исследования операции и процедуры, индивидуальный носитель информации, нормативно справочная информация, снабжение медикаментами и медицинским имуществом, организационная структура учреждения. Такое структурирование уже на уровне предметной области отразилось на дальнейшей структуре программного обеспечения ≈ формировании набора слабо связанных прикладных сервисов (об этом ниже). Как следствие, любой из них, при необходимости, может быть применен при создании ИС других организаций.
Методика проектирования, применяемая системными аналитиками компании Эврика, основана на принципах, заложенных в Rational Unified Process. Эти принципы были адаптированы с учетом особенностей успешно зарекомендовавших себя методик обследования объектов автоматизации и обработки его результатов.
Процесс создания проекта ПО согласно применяемой методике проиллюстрирован на рис.2. Он состоит из последовательной разработки модели use-case, аналитической модели, проектной модели и компонентной модели. При разработке каждой последующей модели происходит детализация предыдущей, внесение новых деталей, необходимых для реализации системы. Таким образом, на любом этапе проектирования проверяется целостность всей модели. Основным источником информации при проектировании ПО являются постановки задач.
Процесс создания проекта ПО начинается с разработки use-case модели. В ней фиксируется множество задач, перечень должностных лиц и отношения должностных лиц к задачам. Эта модель достаточно простая, но выполняет важную роль: определяет набор задач, подлежащих реализации. В дальнейшем проектируются именно те задачи, которые представлены в этой модели.
Аналитическая модель отражает логическую структуру системы. В ней нет подробностей, связанных с техническими сторонами и языком реализации.
При разработке аналитической модели используется принцип разделения задачи на три составляющие: компоненты доступа к данным (сущности), компоненты обработчики информации (контроллеры) и интерфейсные компоненты (представления). Такое разделение увеличивает возможности по повторному использованию компонентов, упрощает дальнейшую поддержку и, при необходимости, последующую модификацию системы. Например, изолирование компонентов доступа к данным от компонентов обработчиков информации позволяет достаточно легко перейти к другим средствам хранения данных, а изолирование интерфейсных компонентов
от компонентов обработчиков информации ≈ изменять идеологию и структуру интерфейса системы, не затрагивая другие ее части.
Для компонентов из перечисленных выше групп производится уточнение свойств и методов работы с данными согласно методике использования информации эскизного проекта. Входные, выходные и справочные данные, описанные в постановках задач, определяют перечень и формат информации для компонентов, а алгоритмы выполнения задач определяют необходимый набор методов. Для каждой задачи создаются диаграммы сотрудничества (collaboration diagram),
в которых отражаются способы взаимодействия компонентов при их выполнении.
В результате разработки аналитической модели формируется множество компонентов и формальное описание их взаимодействия для решения конкретных задач системы.
Проектная модель является продолжением детализации аналитической модели. Она разрабатывается как точное описание компонентов системы, подлежащих реализации. В нее добавляются особенности, связанные с выбранной архитектурой системы, языком (или языками) программирования, перечнем используемых библиотек, стандартом реализации компонентов и т.═п., формируются уровни программного обеспечения.
При разработке программных компонентов системы автоматизации ВЛУ и ВМУ использовался стандарт CORBA. Этот стандарт регламентирует правила описания интерфейсов компонентов и способы вызова их методов работы с данными, что обеспечивает платформенную независимость и мобильность компонентов. Эти преимущества становятся более выражены при выборе
в качестве языка реализации системы язык программирования Java (Sun Microsystems).
Учитывая, что выбранной архитектурой являлась трехзвенная архитектура клиент-сервер
с тонким клиентом, были сформированы четыре уровня ПО: уровень системных библиотек, уровень сервисов, уровень бизнес-логики, уровень приложения. Программные компоненты более высоких уровней используют наиболее общие функции, предоставляемые компонентами низкого уровня. Например, на уровне системных библиотек находятся библиотеки доступа к БД, библиотеки ведения журналов, библиотеки управления сервером приложения. На уровне сервисов находятся компоненты, обеспечивающие выполнение базовых операций над информацией из базы данных (выбор, запись, поиск), описывающей объекты предметной области (аналог сущностей аналитической модели). К таким сервисам относятся сервис персональной информации, обеспечивающий запись и выбор немедицинской информации обо всех персонах, зарегистрированных в системе, или сервис медицинской информации, обеспечивающий работу с медицинскими данными для тех персон, которые являются пациентами. Уровень бизнес-логики объединяет компоненты, осуществляющие обработку информации согласно заданным в постановках задач алгоритмам (аналог контроллеров аналитической модели). Уровень приложения содержит подробную спецификацию пользовательского интерфейса (аналог представлений аналитической модели).
В результате таких решений разработка задачи сводится к формированию стека компонентов, находящихся на различных уровнях, и осуществляющих трансляцию вызовов сервисов верхнего уровня на соответствующие выполняемой задаче сервисы нижнего уровня.
Выбор стандарта CORBA потребовал отдельного проектирования интерфейсов компонентов в стиле CORBA и дальнейшую реализацию этих компонентов на базе Java. Так как Java и CORBA прекрасно дополняют друг друга, такое разделение проектной модели на две составляющие не вызвало никаких трудностей. Результатом создания проектной модели является множество компонентов, точно соответствующих реализуемым функциям. Декларация этих компонентов используется в процессе кодирования.
Компонентная модель служит для определения перечня программных модулей и разработки их состава. Каждый разрабатываемый объект из проектной модели в результате реализации попадает в один из модулей компонентной модели.
При реализации проекта ПО от use-case модели до компонентной модели используется case-средство Rational Rose. По данным проектной и компонентной модели, оно осуществляет автоматическую генерацию описаний интерфейсов на языке CORBA IDL и заготовки для кодирования классов на языке Java.
В результате выполнения описанных выше этапов формируются компоненты, реализующие при их совместной работе задачи, зафиксированные в модели use-case.
Одной из особенностей разрабатываемой системы является то, что рабочие места конкретных пользователей формируются на сервере приложений из набора задач.
Администратор системы определяет права доступа к задачам и профили пользователей. Согласно заданному профилю, определяется множество задач доступных конкретному пользователю. После его идентификации и входа в систему, список доступных задач запрашивается у подсистемы безопасности. Далее компонентами сервера строится главная форма рабочего места с элементами меню вызова задач данного пользователя.
Таким образом, предполагается возможность более тонкой настройки на конкретное учреждение и уменьшение количества возможных трудностей при тиражировании системы.
Разработка программного обеспечения является не последним этапом в создании системы автоматизации. До ввода в эксплуатацию систему необходимо настроить на автоматизируемое учреждение: сформировать рабочие места, определить права доступа, заполнить базу данных в части нормативно-справочной информации и специфических данных учреждения (например, оргштатной структуры), произвести комплексную отладку системы и, что немаловажно, провести необходимые для внедрения КИС организационные мероприятия. Эти работы фирма Эврика будет проводить на следующих этапах создания систем автоматизации ВЛУ и ВМУ МО РФ.
Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
e-mail:
Для пресс-релизов и новостей