CC BY
34
На предприятии проводят обучение персонала, направленное преимущественно на усиление ориен-
тации на потребности предприятия и изменение методов работы с персоналом. Поэтому необходимо также проводить обучение персонала, направленное на повышение эффективности отдельных сотрудников (например, приобретение специальных навыков и освоение управленческих технологий).
Итак, исследование организации профессионального образования кадров предприятия продемонстрировало, что в области обучения и повышения квалификации персонала есть следующие проблемы:
некоторые руководители не придают должного значения обучению и повышению квалификации персонала как одному из факторов инновационного развития предприятия;
есть необходимость разработки тренинга для руководителей, поддерживающего инновационный подход в управлении компанией;
есть необходимость организации дистанционного обучения рабочих предприятия;
есть необходимость использовать технологию обучения, направленную на повышение эффективности отдельных сотрудников, с целью освоения инновационных методов и приемов работы персонала.
ЛИТЕРАТУРА
1. Бакшеев С.Л. и др. Особенности управления персоналом в информационном обществе: учебное пособие / Сургутский государственный университет. Сургут, 2015.
2. Байгулов Р.М., Беляева С.В., Голубева Г.Ф., Домнина С.В., Елисеева Е.В., Ермолаев К.П., Ерохин В.В., Заступов А.В., Захаров В.В., Захарова Н.И., Коробкова Ю.Ю., Королев О.П., Лапочкина С.В., Лизунова Н.М., Лукьянова И.Е., Марущак И.В., Матвеева Л.Г., Мидова Р.М., Милютенко Т.Р., Михайлов О.В. и др.
3. Результаты социально-экономических и междисциплинарных научных исследований XXI века.- Самара, 2016.
4.Майстер В.А., Ширинкина Е.В. Роль интеллектуального капитала в технологическом оснащении производства // Надежность и качество сложных систем. 2016. № 1 (13). С. 107-113.
5. Ширинкина Е.В. Идентификация и оценка факоров среды формирования человеческого капитала // Современная научная мысль. 2016. № 6. С. 144-150.
6. Ширинкина Е.В. Оценка эффективности инвестиций в человеческий капитал // Актуальные проблемы экономики и управления. 2016. № 4 (12). С. 102-104.
7. Ширинкина Е.В., Гантимуров А.В. Совершенствование планирования затрат на предприятиях нефте-гаовой отрасли // Труды международного симпозиума Надежность и качество. 2014. Т. 2. С. 325-330.
8. Ширинкина Е.В., Кауфман Н.Ю. Инновационный подход в организации оплаты труда персонала / сборник материалов международного научно-практического семинара Управление персоналом в программах подготовки менеджеров (двенадцатое ежегодное заседание). 2015. С. 107-110.
УДК 004,413,5
Иванкин И.Г., Надейкина Л,А,
ФГБОУ ВО «Московский государственный технический университет гражданской авиации» (МГТУ ГА) , Москва, Россия
ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИИ АСПЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ПРОГРАММНЫХ СИСТЕМ
Исходный код промышленных программных систем характеризуется чрезвычайной сложностью, излишним дублированием, шаблонными ошибками, неопределенностью, наличием сильной взаимосвязи между модулями и, как следствие, сопровождается неточностями и искажениям, а также низкой отказоустойчивостью. В статье описан современный подход к проектированию, разработке и сопровождению программного обеспечения (ПО) с использованием аспектно-ориентированного программирования(АОП). Методология призвана снизить время, стоимость и сложность разработки ПО. Аспектно-ориентированное программирование предназначено для отделения основной функциональности (бизнес-логики) программных систем от сквозных функциональности общесистемного назначения. Сквозная функциональность пронизывает практически все модули бизнес-логики программной системы, тем самым запутывая основной код. В статье описаны правила и рекомендации аспектной декомпозиции программного кода, а именно абстрагирования бизнес-процессов программы от всех вспомогательных аспектов. Рассмотрена актуальность использования аспектно-ориентированного программирования в крупных программных системах, а также описаны его преимущества и недостатки с точки зрения наибольшей практической ценности. Представлен пример использования аспектно-ориентированного программирования
Ключевые слова:
аспектно - ориентированное программирование, декомпозиция, система, проектирование, эффективность
В настоящее время объектно-ориентированное проектирование и программирование (ООПП) является основной методологий программирования при проектировании и разработке крупных программных систем. Однако такие системы характеризуются чрезвычайно сложным и запутанным кодом, связанностью модулей, дублированием кода и эффективных методов борьбы с этими явлениями в технологии ООПП нет.
В связи с этим особую актуальность приобретает применение инновационных технологий, направленных на решение указанных проблем. Одной из таких технологий является аспектно-ориенти-рованное программирование (АОП).
АОП сейчас является, пожалуй, одной из самых обсуждаемых тем, когда речь заходит о сложности крупных программных системах. Несмотря на то, что сегодня это скорее академические исследования, множество компаний, таких как BEA, IBM, Microsoft а так же open source объединения как JBoss, ObjectWeb, Eclipse уже работают в этом направлении с видимыми результатами. В данной статье показано как можно применять АОП и какие преимущества даёт это применение на примере реализации системы разграничения доступа в WEB-приложениях.
Кратное описание АОП [1].
АОП является естественным расширением ООП, предназначенное для отделения основной функциональности программной системы от сквозной функциональности системного характера (cross-cutting concern), рассеянной по всему коду. Распространение этой сквозной функциональности на несколько компонентов влечет за собой увеличение сложности и запутанности программного кода. Аспектно-ориентированный подход обеспечивает возможность локализации сквозной функциональности в специальных модулях - аспектах. АОП предоставляет возможность вызывать код сквозной функциональности без изменения основного кода программы в определенный момент работы программы [1,2].
Рассмотрим, как решает задачи АОП на примере и синтаксисе самой известной библиотеки среди адептов этой методологии AspectJ, которая является аспектно-ориентированным расширением языка Java, созданная Xerox PARC, и разрабатываемая в Eclipse Foundation.
Основные понятия AspectJ:
1. JoinPoint — строго определенная точка выполнения программы, ассоциированная с контекстом выполнения (вызов метода, доступ к полю класса, обработчик исключения, ...).
2. Pointcut — набор (срез) точек JoinPoint удовлетворяющих заданному условию.
3. Advice — набор инструкций языка Java, выполняемых до, после или вместо каждой из точек выполнения (JoinPoint), входящих в заданный срез (Pointcut).
4. Aspect — основная единица модульности AspectJ. В аспектах задаются срезы точек выполнения (Pointcut) и инструкции, которые выполняются в точках выполнения (Advice).
Pointcut и Advice определяют правила интеграции. Аспект — единица, напоминающая класс в ООП, она соединяет элементы pointcut и элементы advice вместе, и формирует модуль на срезе системы: - перед вызовом метода; - вместо вызова метода; - после вызова метода независимо от результата; - после успешного вызова (выполнение метода завершилось успешно); - после исключения (если вызванный метод возбудил исключение);
Таким образом, АОП позволяет локализовать реализации общесистемных (сквозных, crosscutting) требований, охватывающий практически все модули основной бизнес-логики программной системы в отдельных модулях (аспектах) и тем самым снизить сложность, запутанность программного кода, «очистить» основную функциональность, а следовательно повысить модульность и соответственно качество ПО.
Главная цель АОП состоит в том, чтобы типовой код сквозной функциональности (не связанный с решением прикладных задач предметной области и повторяющийся от компонента к компоненту) не смешивался с прикладной бизнес-логикой.
Типичные классы задач, решение которых требует реализации сквозной функциональности, относятся к надежному и безопасному программированию (trustworthy computing) [1, 2]:
-безопасность (security) — аутентификация пользователей и программ;
-авторизация - проверка полномочий кода или пользователя для выполнения тех или иных действий;
-криптографические операции над данными с целью обеспечения их конфиденциальности;
-надежность (reliability) - проверка выполнения предусловий и постусловий в модулях и инвариантов в классах; обработка ошибок;
- безопасность многопоточного выполнения кода (multi threaded safety) - синхронизация по ресурсам или по событиям, выделение критических участков кода, взаимное исключение доступа к ним и др.;
-протоколирование и профилирование работы программы (logging and profiling) - трассировка начала и окончания выполнения каждой функции (каждого метода), вывод их аргументов и результатов, сбор и вывод статистической информации об исполнении различных фрагментов программы и так далее.
Существует множество способов защиты информационных систем, но все реализации строятся на следующих базисных принципах:
- Идентификация - совместно с системами аутентификации дают ответ на вопрос кто есть пользователь.
- Авторизация - аутентифицированный пользователь может выполнять определённые действия.
-Аудит - система сохраняет отчёт о своей деятельности для дальнейшего анализа.
В данной статье приводится пример простейшего, не защищённого WEB-приложения, реализованного в терминах концепции MVC (Model-View-Controlle) [3,4], и последовательность применения аспектов для реализации защиты данного приложения. АОП дает реальную возможность реализовать систему защиты, удовлетворяющую всем принципам, изложенным выше, но при этом оставить аспекты защиты слабо связанными с основной частью системы. Рассмотрим описание в терминах Модель-Вид-Контроллер:
Модель
- Объект пользователь (либо User либо AnonymousUser) храниться в сессии.
- В сессии сохранён массив объектов Album, доступный для модификации.
В программе определен класс User расширяет (наследует) класс AnonymousUser. Каждый альбом (класс Album) имеет атрибут title и ссылку на владельца альбома - класс User, следовательно первое ограничение - анонимный пользователь не может быть владельцем альбома. Альбомы хранятся в объекте AlbumList реализующим методы добавления, удаления и поиска альбомов.
Вид.
Отображение осуществляется с помощью шаблонов. Данный подход позволяет разделить отображение от остальных частей системы, кроме того, эти шаблоны, достаточно простые для интуитивного понимания. В приложении используется 2 шаблона [5]:
- view.vm - отображает логин текущего пользователя (или Anonymous), ссылки на login/logout, список альбомов, форму для добавления нового альбома.
- login.vm - отображает 2 ссылки для регистрации под разными пользователями.
Контроллер.
В качестве контроллеров выступают 2 сервлета [3]:
- LoginServlet - сервлет осуществляющий логин пользователя.
- ViewServlet - сервлет осуществляет подготовку списка альбомов и обрабатывает добавление/удаление альбома по переданному title.
Кроме того, реализован фильтр
(EntranceFilter) который запускается перед каждым запросом. На данный фильтр возложена обязанность установления пользователя в AnonymousUser если пользователь не найден в сессии, и начальной инициализации массива альбомов.
Рассмотрим терминологию:
- Идентификация - процесс определения «личности» (во внутрисистемном понимании) пользователя. В данном случае пользователь, предоставляющий правильное (существующее) регистрационное имя, идентифицирует себя.
- Аутентификация - процесс подтверждения того, что пользователь является тем, кем, он себя объявляет (с кем он себя идентифицирует). В нашем случае средство аутентификации - уникальный пароль, который известен только конкретному пользователю.
- Авторизация - процесс определения прав пользователя по отношению к объекту внутри системы. В данном случае, очевидно, что даже зарегистрированный пользователь не должен иметь возможность удалить фотографии другого зарегистрированного пользователя.
Для того, что бы явно показать преимущества АОП подхода, для начала бегло рассмотрим реализацию защиты приложения обычными способами.
Идентификация/аутентификация
Обычно WEB-приложение запрашивает регистрационное имя и пароль с помощью формы, данные проверяются (сравниваются с базой данных) и на основании сравнения принимается решение об аутентификации текущего пользователя. Далее в сессию клиента попадает объект, инкапсулирующий пользователя (а в cookie браузера отправляется идентификатор сессии).
Данный способ представляет разработчику приложения полный контроль над процессом аутентификации.
Авторизация
В большинстве случаев применения ООП получаются сложные, сильно связные подсистемы, не позволяющие повторное использование в других проектах. Авторизация - разрешение/запрет действий, выполняемых аутентифицированными пользователями. Вполне логично было бы разместить авторизацию в компоненте «Контроллер», но если, например, несколько контроллеров оперируют с одними и теми же объектами модели, то получается дублирование функций, поэтому логично было бы разместить авторизацию непосредственно в объектах модели. Получаем связь модели и системы авторизации, что недопустимо, так как при смене системы авторизации модель не должна меняться.
Аудит
Реализации аудита могут существенно отличаться, например можно фиксировать каждый вызванный «контроллер» с помощью добавления в каждый метод контроллера вызова метода записи в журнал. Или можно отслеживать посетителей и их путь по сайту с помощью сессии и специального фильтра (такой подход реализован в Open Symphony Click Stream) но возникает проблема установления соответствия между выполнением бизнес-логики и URL на сайте. В любом случае вызовы системы аудита распределяются по всему коду системы, и тем самым существенно затрудняют сопровождение системы и её эволюцию.
Проблемы
В рассмотренной реализации защиты приложения обычными способами явно видны следующие недостатки:
- реализация защиты очень сильно привязана к конкретному приложению;
- так как код проверок внедряется в код системы то никак нельзя надёжно гарантировать, что все места раскрытия секретных данных окружены такими проверками;
- код с внедрёнными вызовами системы авторизации трудно расширять и тестировать.
Очевидно, что все вышеперечисленные проблемы возникают из-за того, что основная функциональность системы переплетается с функциональностью реализующую защиту. Схожие проблемы всегда существуют при создании сложных информационных систем, и происходит это из-за того, что доступные ООП средства не позволяют удобно и просто совмещать пересекающиеся функциональности.
Реализация защиты средствами АОП.
Для анализа рассмотрим те же принципы: идентификацию, авторизацию и аудит.
Аутентификация нужна не для всех областей нашего сайта, следовательно, нам необходимо сделать следующее - перед вызовом контроллеров, для которых аутентификация необходима, мы будем проверять пользователя, и в случае если он не аутен-тифицирован, то перенаправляем запрос на страницу с формой аутентификации. В соответствии с этим был определен аспект с соответствующими Pointcut и Advice.
Данное решение имеет следующие преимущества:
-Используя мощный синтаксис определения pointuct, можно гарантировать, что все контроллеры, которые требуют аутентифицированный доступ, будут доступны только зарегистрированным пользователям. Например, мы можем создать интерфейс AuthnificationNeeded без методов, и определить pointcut, который будет включать в себя все классы, реализующие данный интерфейс. Можно определить pointcut, который будет включать в себя все классы в некотором пакете, или, например, по маске имени класса.
- Действие аспекта будет автоматически распространяться на все новые контроллеры, добавленные в систему в ходе эволюции (при условии, что они будут созданы по определённым в проекте правилам).
- Никаких изменений кода контроллеров не потребовалось, то есть контроллеры совершенно не осведомлены об особенностях аутентификации приложения.
- Вся логика аутентификации, как генерация исключения, и перенаправление запроса, реализована в одном аспекте, а не разбросана по коду системы на разных уровнях.
Попытка анонимного пользователя, добавить альбом -приведёт его на страницу авторизации, так как добавлять альбом могут только авторизованные пользователи.
Авторизация
Наиболее интересная часть решения. Идеальное решение авторизации должно быть слабо связанно со всей системой, и должно реализовывать два различных типа авторизации:
- Пост-проверка - запрет не авторизованных действий. Например, запрет удаления альбома или запрет на чтение поля объекта.
- Пред-проверка - оповещение о том, что конкретное действие не разрешено. Например, слой отображения должен знать отображать ли ссылку «удалить» около альбома, означающую - можно ли удалить данный альбом.
Пост-проверка
Перед каждым методом, считывающим или записывающим данные, нам необходимо проверять пользователя, и в случае если операция не доступна, мы будем показывать пользователю сообщение об ошибке. В нашем примере каждый альбом имеет владельца, следовательно, правило простое - пользователь может удалять только принадлежащие ему альбомы. Определим три различных действия, нуждающиеся в авторизации:
- чтение - вызов любых методов начинающихся с get;
- добавление нового альбома, реализует метод addAlbum класса AlbumList;
- удаление альбома, реализует метод removeAlbum класса AlbumList;
Так как не будет реализована возможность редактирования имени альбома, то методы изменения данных нас не интересуют, хотя в реальных системах этот тип доступа, безусловно, нуждается в авторизации. Перед вызовом методов каждого типа мы будем обращаться к системе авторизации для проверки. Посмотрим более детально на ход работы системы. На первом шаге пользователь запрашивает страницу /view. Запрос с начала поступает на созданный фильтр EntranceFilter, после чего обрабатывается сервлетом. Так как запрос без параметров, то сервлет ничего не делает и направляет запрос на слой отображения view.vm. Скрипт отображения вынимает из сессии список альбомов и выводит их названия.
Здесь видно, что «Before advice» созданный на основе «Read access pointcut» перехватывает операцию getTitle объекта модели и вызывает класс, инкапсулирующий правила авторизации для проверки операции чтения: boolean
isAllowedRead(AnonymousUser, Object). Как видно из сигнатуры метода для проверки нам необходим текущий пользователь. В результате реализации, мы получили pointcut, который даёт нам доступ, как к объекту текущего запроса, так и к объекту над которым производится интересующее нас действие. Обратите внимание, что перехват события будет производиться только в потоке выполнения, включающем в себя фильтр, то есть если запускать unit тесты модели, тестирующие классы напрямую, то никакой проверки происходить не будет, что естественно, так как не откуда будет взять пользователя.
Теперь необходимо обработать исключительные ситуации, то есть когда пользователь не авторизован выполнить действие. В данном случае before advice выбросит unchecked exception
AuthorizationException и тем самым не даст выполниться не разрешённому методу. Для того, что бы отобразить пользователю цивилизованное сообщение об ошибке, или обработать эту ситуацию другим способом, перехватываем исключение, точно так же как и в предыдущем аспекте.
Пред-проверка
Для того, что бы реализовать оповещение слоя отображения о действиях которые разрешено производить с объектом модели, создадим дополнительный интерфейс который будет содержать 3 метода - boolean isReadable(), boolean isDeletable() и boolean isAddable() после чего создадим в классе Album методы реализующие данный интерфейс и возвращающие всегда true. Слой отображения будет отображать ссылку «удалить» только если метод isDeletable() даст добро. А в нашем авторизационном аспекте создадим pointcut перехватывающий соответствующие методы всех классов реализующих данный интерфейс. После чего создадим around advice, который будет возвращать результат вызова системы авторизации. Захват параметров производится точно так же, как это было сделано при пост-проверке.
Достоинства АОП решения:
- Как видно из определения аспектов методы readMethods, addMethods, controlledRead, controlledAdd и controlledDelete не содержат ссылок на определённые классы, следовательно, авторизация будет автоматически распространяться на все новые классы модели помещённые в пакет model и реализующие интерфейс Controllable.
- Выбрасывание исключения и его обработка реализована в пределах одного аспекта, что упрощает дальнейшую эволюцию и сопровождение системы.
- Все вызовы методов классов модели (созданные согласно правилам) будут объектами для применения системы авторизации.
- Слой отображения не зависит от системы авторизации.
- Система полностью работоспособна без применения аспекта авторизации, что говорит об отсутствии связи между системой в целом и аспектом авторизации (в свою очередь аспект авторизации зависит от системы, но эта связь не существенна так как носит декларативный характер и происходит лишь на уровне определения pointcut).
Аудит
Аудит, пожалуй, является самым наглядным примером применения АОП, так как его реализация обычным способом обычно обязывает разработчиков добавлять один и тот же код занесения в журнал во все части системы. Например, для ведения журнала действий каждого пользователя нам необходимо включить в каждый контроллер вызов метода ответственного за занесение данных в журнал событий, опять же гарантии, что такие вызовы включены в каждый контроллер, обеспечить трудно. Гибкость АОП решения состоит в том, что сквозная функциональность аудита изолирована в пределах аспекта. Все изменения в типе и детализации событий могут быть с лёгкостью проведены не затрагивая основную функциональность.
Для примера рассмотрим простейший аспект, который будет перехватывать все вызовы контроллеров, определяя пользователя, и записывать информацию в журнал.
Создадим новый аспект, с pointcut перехватывающий все выполнения контроллеров, и захватывающий объект запроса. На основе созданного
ЛИТЕРАТУРА
1. Programming Community Index - TIOBE Index. URL: http://www.tiobe.com/tiobe index?page=index
2. Laddad R. AspectJ in Action: Enterprise AOP with Spring Applications / Laddad R., Johnson R., Manning Publ., 2009, 568 p
3. Блинов И.Н. Java. Методы программирования /Блинов И.Н., Романчик В.С. Минск: Четыре четверти, 2013, 896 с.
4. Петрянин Д.Л. Архивация как способ защиты информации. / Петрянин Д.Л., Юрков Н.К., Разживина Г.П. / Труды Международного симпозиума Надежность и качество. -2015. - Т .1 - С.251-252.
5. Надейкина Л.А. Использование архитектурных паттернов и функциональной декомпозиции для повышения качества и надежности программного обеспечения/ Надейкина Л.А., Черкасова Н.И./ Труды Международного симпозиума Надежность и качество. -2016. - Т. 1 - С.148-151.
pointcut, напишем before advice выводящий сообщение на System.out.
Приведем код аспекта в связи с его небольшим размером:
package aop.example;
import org.aspectj.lang.*; import ja-vax.servlet.http.*;
public aspect AuditAspect {
public pointcut controllerMethods (HttpS-ervletRequest request):
execution(* javax.servlet.http.HttpS-
ervlet+.*(HttpServletRequest,
HttpServletResponse)) && args(request, HttpServletResponse);
before(HttpServletRequest request): control-lerMethods(request) {
Signature sig = thisJoinPointStat-
icPart.getSignature();
System.out.println("User " + re-
quest.getSession().getAttribute
(EntranceFilter.USER_KEY).toString() + " executing " + sig.getDeclaringType().getName() + "." + sig.getName());}}
В теле advice используется статическая информация о точке вплетения, для того, что бы отобразить имя класса объекта и название метода. Вывод будет отображать строки вида:
User Anonymous ple.LoginServlet.doGet User user1
executing executing
aop.exam-aop.exam-
ple.ViewServlet.doGet
Заключение.
В данной работе показаны достоинства АОП на примере реализации системы защиты WEB-приложе-ния, продемонстрировано как надо внедрять ас-пектный код в целевую программу и как применять AspectJ на практике.
Основные достоинства аспектно-ориентирован-ного подхода - улучшение модульности программной
системы,
"сквозной
упрощение
появление
кода.
снижение ее сложности, отделение функциональности" от основного кода, сопровождения и внесения изменений, возможностей повторного использования
УДК 004.413.5
Бецков1 А.В., Осташкевич2 В.А., Ранюк2 М.А.
1ФГКОУ ВПО «Академия управления МВД России», Москва, Россия
2ФГБУ «НИИ Центр подготовки космонавтов им. Ю.А. Гагарина», Московская область, Звёздный городок, Россия
МЕТОДОЛОГИЧЕСКИЕ ПОДХОДЫ К ВЫЯВЛЕНИЮ УЯЗВИМОСТИ СОЦИАЛЬНО ВАЖНЫХ ОБЪЕКТОВ ТЕРРОРИСТИЧЕСКИМ УГРОЗАМ
В статье рассматриваются некоторые аспекты воздействия и обеспечения безопасности социально важных систем
Ключевые слова:
математическая формализация, уязвимость системы в течение задаваемого периода времени, потенциальные размеры нанесенного ущерба, вероятность
Анализ развития множества свершившихся террористических актов позволяет выявить следующие общие тенденции, осознание которых необходимо для осуществляемой математической формализации: 1) в силу скрытности подготовки акты терроризма зачастую носят для системы внезапный характер и, выражаясь языком теории вероятностей, проявление каких-либо событий террористической деятельности может быть описано в терминах случайных величин и процессов;
2) применяемые способы противодействия, включающие целенаправленный сбор и анализ оперативной информации для выявления подозрительных событий и действий, выработку и реализацию контрмер, направлены на всестороннее и всемерное снижение уровня скрытности подготовки, ухудшение условий деятельности террористов. Как следствие, это может привести к смене объекта террористической атаки, отказу от террористического акта или переносу сроков его осуществления, к непод-
