CC BY
69
Пусть динамические параметры, приведенные выше, приняли значения, представленные в таблице 2. Тогда многоугольник динамических параметров будет иметь вид заштрихованной фигуры, вписанной в правильный многоугольник максимальных динамических параметров (рис. 2).
Таблица 2
Сравнив площади идеального и фактического (заштрихованного) многоугольников, на основании коэффициента (0,53) определяем оценку (см. табл. 3).
Таблица 3
Согласно принятым данным итоговая оценка за тренировку - «хорошо».
Однако диаграмма (рис. 2) показывает, что в подготовке расчета есть недостатки (параметры 1 и 6).
Предложенный подход позволит преподавателю объективнее оценивать уровень подготовленности обучающихся и обеспечит контроль со стороны обучающихся за уровнем своей подготовки.
Литература
1. Довженко В., Шустова Н. Автоматизация процесса оценки обучающихся на тренажерах // Морской сборник. 2002. № 7. С. 59-61.
2. Руководство по учебной и методической работе (РУМР-2002). СПб: ВСОК ВМФ, 2002.
3. Положение о проведении текущего контроля и промежуточной аттестации слушателей (курсантов) ВУНЦ ВМФ «ВМА». СПб: ВУНЦ ВМФ «ВМА», 2010.
References
1. Dovzhenko V., Shustova N., Morskoy sbornik [Russian Navy], 2002, no. 7, pp. 59-61.
2. Rukovodstvo po uchebnoy i metodicheskoy rabote (RUMR-2002) [Educational and methodical manual], St. Petersburg, Military and Training Research Center of the Navy, 2002.
3. Polozhenie o provedenii tekushchego kontrolya i prome-zhutochnoy atte.stat.sii slushateley (kursantov) VUNTs VMF «VMA» [Regulation on realization of ongoing monitoring and interim attestation of students (cadets) of The Navy Military Training and Sci. Centre «Navy Academy»]. St. Petersburg, Military and Training Research Center of the Navy, 2010.
Коэффициент Оценка
К>0,7 «Отлично»
0,31<К<0,7 «Хорошо»
0,16<К<0,31 «Удовлетворительно»
К<0,16 «Неудовлетворительно»
Параметр Величина
1 0,3
2 0,7
3 0,8
4 1
5 0,4
6 0
Суммарно-параметрическая оценка «ХОРОШО»
УДК 004.415.2416
АСПЕКТЫ ПРИМЕНЕНИЯ ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО ПОДХОДА К ПРОЕКТИРОВАНИЮ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ
А.В. Карпов, к.т.н., зав. отделом (НИИ «Цектрпрограммсистем», просп. 50лет Октября, 3а, г. Тверь, 170024, Россия, [email protected])
Ключевым аспектом предметно-ориентированного проектирования является разработка архитектуры программных систем на основе модели предметной области. Применение предметно-ориентированного подхода к проектированию классических двухзвенных сложных программных систем зачастую приводит к распределению функционала, связанного с одними и теми же объектами единой модели предметной области, по разным программам.
Адаптация программной системы к изменившимся условиям применения может потребовать реализации централизованного доступа пользователей ко всей информации по объектам модели предметной области, который может быть обеспечен формированием единого информационно-функционального пространства системы.
Такое пространство можно сформировать за счет реализации специального взаимодействия между программными компонентами системы и использовать программой-порталом для предоставления централизованного доступа пользователей к информации по общесистемным объектам и функциям ее обработки. Данное решение позволяет применить ряд основных преимуществ сервис-ориентированной архитектуры в классических двухзвенных сложных программных системах.
Ключевые слова: предметно-ориентированное проектирование, модель предметной области, адаптация, централизованный доступ, сервис-ориентированная архитектура, связность, зацепление.
USING DOMAIN-DRIVEN APPROACH TO ADVANCED SOFTWARE SYSTEMS DESIGN Karpov А. V., Ph.D., head of department (R&D Institute «Centrprogrammsystem», 50 let Oktyabrya Av., 3a, Tver, 170024, Russia, [email protected])
Abstract. Domain-driven design implies that software systems architecture development is based on domain model. When designing classic two-tiered advanced software systems, using domain-driven design often leads to functionality dis-
tribution throughout different programs. This functionality is connected with the same objects of one domain model.
Adaptation of software system to changed conditions can require central user access to all the information about the domain model objects.
This central user access is provided when forming same information functional space of the system. It can be formed using special interaction between program components of the system.
There is a program-portal to use the information functional space for providing central user access to information about the general-system objects and processing functions.
Proposed method allows using main advantages of service-oriented architecture in classic two-tiered advanced software systems.
Keywords: software, domain-driven design, domain model, adaptation, central access, service-oriented architecture, coupling, cohesion.
Предметно-ориентированное проектирование (domain-driven design, DDD) - одна из основных методологий разработки сложных программных систем [1]. Его ключевым аспектом является разработка архитектуры программных объектов на основе модели предметной области, то есть разработка совокупности взаимосвязанных программных объектов, описывающих различные стороны определенной области применения системы (области бизнеса). Объекты домена позволяют реализовать (имитировать) сущности области применения системы и формализовать бизнес-правила, реализуемые ею. Использование модели предметной области является типовым решением, позволяющим упростить реализацию сложной бизнес-логики программной системы, которая характеризуется множеством объектов, правил, условий использования и особенностей поведения [2].
При проектировании ПО сложных АСУ, как правило, используются основные архитектурные шаблоны корпоративных программных приложений [2]. В соответствии с концепцией слоев (layers, [2]) ПО в общем случае разделяется на три слоя: представление, предметная область и источник данных.
Слой представления состоит из компонентов графического интерфейса пользователя, таких как диалоговые окна и различные интерактивные элементы управления. В слой предметной области входят программные классы, представляющие собой реализацию модели предметной области. Слой источника данных реализует задачи, связанные с ведением БД системы. Источник данных зачастую использует в своей работе системы объектно-реляционного преобразования.
Как правило, модель предметной области содержит ряд общесистемных объектов, составляющих ее ядро. Например, в АСУ техническим обеспечением (ТехО) ВМФ в состав общесистемных объектов входят элементы организационно-штатной структуры обеспечиваемых подразделений, типы и экземпляры материально-технических средств, виды технического обеспечения и т.д. Нередко общесистемные объекты составляют основу информационно-лингвистического обеспечения системы, входят в состав рубрикаторов, классификаторов и справочников, используются при разработке протоколов информационного взаимодействия АСУ с другими системами.
В ходе проектирования архитектуры специального ПО (СПО) АСУ по модели предметной области (Model-Driven Design, [1]) определяется набор программ (программных компонентов), каждая из которых реализует часть модели. При этом используются классические паттерны GRASP [3] с целью обеспечения максимального зацепления и минимальной связности между программами. В итоге СПО АСУ состоит из обладающих высоким зацеплением слабосвязанных программ, реализующих части модели предметной области. Компоненты СПО выполняют свои функции, управляя состоянием объектов ядра либо других программных объектов, реализующих отношения с ними. Такими отношениями являются зависимости, обобщения и ассоциации [4]. Реализация компонентами СПО разных частей модели предметной области приводит к тому, что функционал системы выстраивается вокруг общесистемных объектов. Например, разработка разного рода планов выполняется компонентом планирования, формирование выходных отчетов и формализованных документов - программой формирования отчетов, нормативная и справочная информация - программой ведения нормативно-справочной информации и т.д. (рис. 1).
На завершающем этапе разработки АСУ в результате произошедших изменений организационно-штатной структуры автоматизируемых объектов и бизнес-процессов, выполняемых должностными лицами, возникла задача предоставления группе пользователей централизованного доступа ко всей информации по общесистемным объектам. Отсутствие централизованного доступа приводило к тому, что пользователям системы приходилось многократно переключаться между разными программами для сбора всей необходимой информации по одним и тем же общесистемным объектам и для доступа к требуемым функциям (методам) ее обработки. Фактически требовалось обеспечить адаптируемость АСУ к подобным изменениям условий ее применения.
Реализация централизованного доступа к информации об общесистемных объектах должна была исключить необходимость переключения между программами СПО АСУ при сборе определенной информации. Имеющаяся архитектура СПО не позволяла предоставлять централизованный доступ ко всей необходимой информации -
Слой представления
(графический интерфейс)
Программа ведения
нормативно-справочной
информации
Программа планирования
Программа формирования отчетов
Слой домена
(модель предметной области)
Номенклаторы, рубрикаторы, классификаторы и справочники общесистемных объектов
Планы, содержащие общесистемные объекты
Отчеты, содержащие общесистемные объекты
Слой источника данных
(работа с СУБД,
объектно-реляционное
преобразование)
Классы, реализующие работу с СУБД
Классы, реализующие работу с СУБД
Классы, реализующие работу с СУБД
Рис. 1
пользователю приходилось одновременно запускать несколько программ и переключаться между ними.
Типовым решением, позволяющим реализовать требуемый централизованный доступ пользователям к функционалу и информации системы, являются построение системы на основе сервис-ориентированной архитектуры (service-oriented architecture, SOA) и использование специальных приложений-порталов.
SOA определяет модульный подход к разработке ПО, основанный на использовании распределенных, слабосвязанных компонентов, реализующих стандартизированные интерфейсы и протоколы взаимодействия. Сервис-ориентированная архитектура позволяет упростить адаптацию системы к изменившимся условиям функционирования за счет целого ряда стандартизированных решений по обеспечению слабой связности и повторного использования модулей СПО, расширяемости системы. Компоненты СПО в сервис-ориентированной архитектуре обычно реализуются в виде комбинаций слабосвязанных web-сервисов. Применение языка BPEL или спецификаций WS-CDL и WS-Coordination дает возможность так называемой оркестрации сервисов - объединения сервисов для реализации составных приложений, или порталов.
Из-за значительной трудоемкости перевод готовой системы на новую архитектуру, как правило, невозможно выполнить на этапе сопровождения. Поэтому задача разработки специального решения, позволяющего использовать основные преимущества SOA и реализовать приложение-портал, приобретает особую актуальность. При этом важным критерием решения задачи является обеспечение минимального повышения связности и снижения зацепления компонентов СПО.
Предоставление централизованного доступа к информации по общесистемным объектам может осуществляться на основе единого информационно-функционального пространства системы, в котором наряду с информацией об общесистемных объектах содержатся реализации функций (методов) их обработки: S={(e, Me)}, где e - класс общесистемного объекта; Me - множество функций (методов) обработки общесистемных объектов класса е.
Обработка информации по общесистемным объектам требует выполнения бизнес-правил, определенных моделью предметной области. Функции обработки информации реализуют эти бизнес-правила. Например, в соответствии с концепцией непосредственного манипулирования [5] изменение информации должно быть обеспечено непосредственно по месту ее отображения. При этом необходимо удостовериться в наличии у пользователя прав на изменение данной информации, выполнить проверку корректности введенных данных, регистрацию изменения в системном журнале, отправку соответствующих системных сообщений взаимодействующим программным компонентам и т.д. В соответствии с типовыми шаблонами GRASP «информационный эксперт» (Information Expert) и «контроллер» (Controller) [3] задачу изменения информации следует возложить на компонент СПО, который ее предоставил и за нее отвечает.
Сформировать единое информационно-функциональное пространство системы можно посредством опроса компонентов СПО системы и регистрации реализуемых ими методов в привязке к обрабатываемым классам общесистемных объектов. Такой опрос может быть выполнен специальной управляющей программой, при этом ее можно использовать для вызова компонентов СПО, реа-
Программа-портал
Централизованный доступ к функционалу системы
Фасад Ф|
НСИ
E1 E2 Ез
Управляющая программа
Опрос фасадов компонентов и регистрация их функций
Домен программы ведения НСИ Классы общесистемных объектов
Фасад Ф1
Домен программы 1
Классы объектов,
связанных с общесистемными
Kii К12 К13
К14 К15 K1Y
Фасад Фм
Домен программы N
Классы объектов,
связанных с общесистемными
Киэ
KN1 KN4
KN
Рис. 2
Е
E
4
x
лизующих те или иные методы (функции) обработки общесистемных объектов с соблюдением всех необходимых бизнес-правил.
Список функций, выполняемых компонентами СПО, может быть сформирован управляющей программой автоматически путем опроса компонентов в момент начальной инициализации. При его проведении компоненты СПО сообщают управляющей программе перечень выполняемых ими функций применительно к типам (классам) и конкретным экземплярам общесистемных объектов.
Взаимодействие с управляющей программой можно возложить на фасады компонентов СПО. Фасад является типовым решением, позволяющим упростить вызов функций, реализуемых различными компонентами (Facade [6]). Его применение позволяет скрыть сложность компонентов СПО путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам компонента.
В результате опроса фасадов компонентов управляющая программа сформирует реестр функций, выполнение которых обеспечивается компонентами СПО, в привязке к общесистемным объектам. Сформированный реестр функций может использоваться программой-порталом для предоставления пользователям системы централизованного доступа к ее функционалу (рис. 2).
Реестр функций можно представить, например, в виде таблицы, в которой классы общесистемных объектов сопоставлены с функциями, выполняемыми компонентами СПО.
Помимо централизованного доступа к функционалу системы, сформированное информационно-функциональное пространство может быть использовано для контекстной группировки методов (функций) обработки информации. Управляющая программа может предоставлять доступ только к тому функционалу, который напрямую связан с классом обрабатываемого в данный момент обще-
системного объекта. При этом для пользователя системы останется прозрачным состав компонентов СПО, реализующих требуемые функции. Пользователю не придется переключаться между разными программами, реализующими требуемые ему функции. Контекстный объект может быть задан пользователем при помощи средств графического интерфейса программы, например, посредством выделения строки таблицы или вершины дерева, связанной с тем или иным общесистемным объектом. «Выстраивание» функционала системы вокруг общесистемного объекта позволяет собирать всю доступную в системе информацию о нем (информационный срез) без применения поисковых систем.
Реализация взаимодействия с управляющей программой накладывает дополнительные требования на фасады компонентов СПО. При этом становится актуальной задача обеспечения минимального снижения их зацепления и повышения связности.
В соответствии с подходом к оценке зацепления и связности [7] понизить связность можно с помощью разработки дополнительных абстракций в виде абстрактных программных классов-интерфейсов, например «Регистратор» и «Компонент» (рис. 3).
Управляющая программа реализует интерфейс «Регистратор», фасады компонентов СПО - интерфейс «Компонент». Реализация фасадами интерфейсов по взаимодействию с управляющей программой в общем случае позволит минимизировать повышение связности компонентов СПО. Фасады компонентов абстрагированы от технической реализации управляющей программы, с одной стороны, и управляющая программа от реализации фасадов - с другой.
Класс общесистемного объекта Компонент СПО Функция компонента
Класс 1 Компонент 1 Функция 1()
Функция 2()
Компонент 2 Функция 1()
Класс 2 Компонент 1 Функция 3()
Класс X Компонент N Функция Z()
Перечень функций компонента в привязке к общесистемным объектам ^
Рис. 3
Оценка зацепления фасадов компонентов СПО может быть выполнена при помощи метрики LCOM (Lack of Cohesion in Methods, [7]). LCOM -количество пар методов классов, обрабатывающих непересекающиеся множества переменных за вычетом количества пар методов, использующих как минимум одну общую переменную. Например, представим класс С, содержащий методы m1, m2, ..., mn. Пусть {Ij} - набор переменных (атрибутов класса), используемых методом mj. Количество таких наборов для класса C равно n: {Ii}, {I2}, ..., {In}. Вводим две переменные: P - количество пар методов, использующих непересекающиеся наборы переменных; Q - количество пар методов, использующих хотя бы одну общую переменную: p={((4 Ij) |i,w,=0)}, Q={((4 Ij) |i,w^0)}.
В случае, если все наборы {I1}, {I2}, ..., {In} окажутся пустыми, P=0.
Значение LCOM можно рассчитать следующим образом [7]:
LCOM= | P | - | Q |, если | P | > | Q | ;
LCOM=0 в противном случае.
Совокупность классов общесистемных объектов составляет множество E={eb e2, ..., ex}. Все классы общесистемных объектов используются (обрабатываются) методами классов-фасадов компонентов СПО. Следовательно, все классы общесистемных объектов входят в наборы {!,■} переменных, используемых методами фасадов m,-:
V e,eE | 3 mf mj использует eh то есть V e,eE | 3
Методы m реализуются фасадами соответст-
X
вующих компонентов: М= [J.\/(, где М, - множе-
i=i
ство методов /-компонента СПО.
Регистрация методов фасада компонента СПО может быть обеспечена путем реализации дополнительного метода mreg. Задачей этого метода является передача управляющей программе перечня всех классов общесистемных компонентов, используемых методами того или иного фасада с указанием методов их обработки. Соответственно получаем V eeEt | eeIreg, где Ireg - множество классов общесистемных объектов, используемых методом регистрации mreg.
Введение метода mreg регистрации функций компонента в его фасад приводит к тому, что для
каждого класса общесистемного объекта, используемого методами какого-либо фасада, будет существовать пара пересекающихся множеств {/,-, I}: (Уее£,)|з(4 I) | (1^)*0.
При этом количество таких пар будет равно числу методов, реализуемых фасадом: 11 =
= 1м\.
Таким образом, получается, что величина | Qi | уменьшается на значение |Mj|. Следовательно, реализация методов регистрации функционала компонентов в фасадах не приводит к снижению их зацепления.
Управляющая программа может быть включена в состав технологической платформы, используемой при разработке СПО АСУ. Как правило, в состав технологической платформы входит набор компонентов, выполняющих типовые технологические операции, например, ведение журнала событий, выделение и освобождение требуемых ресурсов, формирование сообщений обмена, выходных формализованных документов, различных операций, связанных с предоставлением доступа к БД (слою источника данных), формированием типовых элементов графического интерфейса пользователя и т.д. Представляется целесообразным включение управляющей программы в состав технологической платформы.
Такой подход к реализации централизованного доступа к функционалу системы был применен при разработке АСУ ТехО ВМФ, в состав технологической платформы которой входит управляющая программа «менеджер доменов», выполняющая типовые технологические функции, а также анализирующая конфигурацию установленного СПО.
Менеджер доменов позволяет регистрировать функции, выполняемые программами СПО, и предоставлять оператору (пользователю программы) централизованный доступ к ним. В состав фасадов компонентов СПО АСУ были добавлены специальные методы, реализующие взаимодействие с менеджером доменов и предоставляющие сведения о собственных методах обработки общесистемных объектов. В результате взаимодействия доработанных фасадов компонентов СПО АСУ с менеджером доменов удалось сформировать единое информационно-функциональное пространство, использованное для обеспечения функциони-
рования информационного портала. Таким образом, была реализована адаптируемость АСУ ТехО ВМФ к новым условиям применения без изменения архитектуры СПО.
На основании изложенного можно сделать следующие выводы.
В качестве подхода к обеспечению адаптируемости сложных программных систем к изменению организационно-штатной структуры автоматизируемых объектов и перераспределению обязанностей между должностными лицами на этапе сопровождения могут быть рассмотрены формирование единого информационно-функционального пространства и предоставление пользователям системы централизованного доступа к нему посредством реализации специальной программы-портала. Такое решение характерно для современной сервис-ориентированной архитектуры, одним из основных преимуществ которой является обеспечение адаптируемости ПО.
Единое информационно-функциональное пространство системы может быть сформировано управляющей программой, выполняющей регистрацию методов обработки общесистемных объектов, реализуемых классами-фасадами компонентов СПО. Классы-фасады компонентов СПО реализуют дополнительные задачи по взаимодействию с управляющей программой. Такой подход позволяет адаптировать систему без изменения ее архитектуры на сервис-ориентированную, что значительно сократит трудоемкость ее сопровождения.
Реализация взаимодействия между классами-фасадами и управляющей программой ведет к минимальному повышению связности фасадов про-
граммных компонентов и не снижает степень их зацепления.
Литература
1. Эванс Э. Предметно-ориентированное проектирование. Структуризация сложных программных систем. М.: Виль-ямс, 2011.
2. Фаулер М., Райс Д., Фоммел М., Хайет Э., Ми Р., Стаффорд Р. Архитектура корпоративных программных приложений. М.: Вильямс, 2006.
3. Ларман К. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. М.: Вильямс, 2013.
4. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. М.: ЯМК Пресс; СПб: Питер, 2004.
5. Купер А., Рейман Р., Кронин Д. Об интерфейсе. Основы проектирования взаимодействия. СПб: Символ-Плюс, 2009.
6. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб: Питер, 2007.
7. Hitz M., Montazeri B., Measuring Coupling and Cohesion In Object-Oriented Systems, Proc. Int. Sympos. on Applied Corporate Computing (Oct. 25-27), Monterrey, Mexico, 1995.
References
1. Evans E., Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.
2. Fowler M., Rice D., Foemmel M., Hieatt D., Me R., Stafford R., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.
3. Larman C., Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and Iterative Development, Prentice Hall, 2005.
4. Booch G., Rumbaugh J., Jacobson I., The UnifiedModel-ing Language. User Guide, Addison-Wesley, 2005
5. Cooper A., Reimann R., Cronin D., About Face 3. The Essentials of Interaction Design, Wiley Publ., 2007.
6. Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.
7. Hitz M., Montazeri B., Proc. Int. Symp. on Applied Corporate Computing, Monterrey, Mexico, Okt., 1995.
УДК.004.056.53
СПОСОБЫ РЕШЕНИЯ ПРОБЛЕМ ДОСТУПА К СЛУЖЕБНЫМ ФАЙЛАМ В УСЛОВИЯХ МАНДАТНОГО КОНТРОЛЯ ДОСТУПА
А.Ю. Ефимов, зав. отделом (НИИ «Центрпрограммсистем», просп. 50 лет Октября, 3а, г. Тверь, 1 70024, Россия,
[email protected]. ги)
Статья посвящена проблемам работы со служебными данными в программном обеспечении, функционирующем в защищенной программной среде с действующим мандатным контролем доступа. Описаны основные причины возникновения этих проблем. Рассмотрены типовые сценарии работы приложений со служебными данными в случае хранения этих данных в виде файлов - работа с конфигурационными файлами и запись протоколов. Определены конфликты рассмотренных сценариев с мандатным контролем доступа. Классифицированы и описаны способы доступа к служебным файлам, основанные на дополнении модели Белла-Лападула и на виртуализации контролируемых ресурсов и позволяющие устранить указанные конфликты. Проведен сравнительный анализ этих способов с точки зрения простоты использования и защищенности. Предложены критерии выбора подходящего способа доступа к
