CC BY
78
«рабочий стол», на котором он видит документы, которые он должен обработать, просроченные документы и общий список документов.
Внедрение информационной системы электронного документооборота значительно повысит эффективность работы транспортно-экспедиторской компании ООО «Деловые Линии», поскольку разрабатываемая база данных позволит оперативно отражать информацию и упростить процесс изменения и ведения бумажной документации, при этом основные элементы операций автоматизированы и выполняются по достаточно несложному алгоритму, в результате чего экономится время, финансовые затраты, человеческие ресурсы, оперативно поступает информация и повышается качество работы в целом. Функциональность разрабатываемой информационной системы возможно расширить при дальнейшем процессе роста компании и появлении новых задач.
Литература
1. Гущин, А.Н. Базы данных: учебно-методическое пособие / А.Н. Гущин. - 2-е изд., испр. и доп. - М.; Берлин : Директ-Медиа, 2015. - 311 с.
2. Мухин, Н.П. Компьютерные системы управления документооборотом / Н.П. Мухин. - М. : Лаборатория книги, 2010. - 58 с.
3. Шафоростова Е.Н., Квашина С.В. «Автоматизация учета товаров на АГЗС «Северного объединения по эксплуатации газового хозяйства», СТИ НИТУ «МИСиС», 2009.
УДК 004.9
МЕТОД ОНТОЛОГИЧЕСКОГО ИНЖИНИРИНГА В ГИБКОМ ПРОЦЕССЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ7
Кошкидько Алексей Владимирович, аспирант кафедры Математического обеспечения и применения ЭВМ, Инженерно-технологическая академия Южного федерального университета,
Россия, г. Таганрог, a.koshkidko@gmail.com
Онтология (в информатике) — это попытка всеобъемлющей и детальной формализации некоторой области знаний. Это структурная спецификация некоторой предметной области, ее формализованное представление, которое включает словарь (или имена) указателей на термины предметной области и логические выражения, которые описывают, как они соотносятся друг с другом. Онтологии обеспечивают словарь для представления и обмена знаниями о некоторой предметной области и множество связей, установленных между терминами в этом словаре. Онтологии используются для построения концептуальных моделей. Концептуальная модель — модель предметной области, состоящей из перечня взаимосвязанных понятий, используемых для описания этой области, вместе со свойствами и характеристиками, классификацией этих понятий, по типам, ситуациям, признакам в данной области и законов протекания процессов в ней.
Онтологический инжиниринг — ядро концепции «управления знаниями» (Knowledge Management), которое появилось в середине 90-ых годов в крупных корпорациях, где проблемы обработки информация приобрели особую остроту и стали критическими [2]. При этом стало очевидным, что основным узким местом является обработка знаний, накопленных специалистами компании, так как именно знания обеспечивают преимущество перед конкурентами.
Существуют различные подходы, модели и языки описания данных и знаний. Однако все большую популярность последнее время приобретают онтологии. Онтология - по
7 Статья рекомендована к опубликованию в журнале "Прикладная информатика"
14
определению Грубера [1], есть спецификация концептуализации, формализованное представление основных понятий и связей между ними. Ранее этот философский термин означал учение о бытии, затем он переместился в область точных наук, где полуформализованные концептуальные модели всегда сопутствовали математически строгим определениям. Под определение онтологии подпадают многие понятийные структуры: иерархия классов в объектно-ориентированном программировании, концептуальные карты, семантические сети, и т. п. Можно еще шире трактовать онтологию -например, как сценарий или процесс, как нечто структурирующее хаос.
Томас Грубер рассматривал вопросы взаимодействия интеллектуальных систем между собой, а также с человеком. Идея Грубера состояла в том, чтобы позволить интеллектуальным системам обмениваться между собой заложенными в них знаниями о мирах задач. Если внутри интеллектуальной системы знания о мире могут быть закодированы как угодно, то для обмена этими знаниями с другой интеллектуальной системой необходимо предоставить описание этих знаний. Это описание должно быть в достаточной степени формальным, чтобы быть понятным другой системе, а также должен быть известен язык этого описания. Кроме того, описание должно быть понятно и человеку. Для этого Грубер предложил описывать знания двумя способами:
1. В канонической форме, которая представляет собой описание знаний на языке логики предикатов (например, в виде фактов языка Prolog).
2. В форме онтологии, которая представляет собой множество классов, связанных между собой отношением обобщения (это обратное отношение для отношения наследования).
Таким образом, онтология по Груберу представляет собой описание декларативных знаний, сделанное в виде классов с отношением иерархии между ними. К этому описанию, предназначенному для чтения человеком, присоединено описание в канонической форме, которое предназначено для чтения машинами. Каждая интеллектуальная система может предоставлять несколько таких описаний, соответствующих различным областям хранящихся в ней декларативных знаний и, таким образом, выступает как хранилище библиотеки онтологий. Грубер представлял, что интеллектуальные системы будут выступать как библиотеки онтологий и свободно обмениваться онтологиями между собой. При этом библиотеке онтологий уже не обязательно быть интеллектуальной системой, достаточно просто предоставлять сервис по передаче онтологий по требованию.
Онтологический инжиниринг должен и может стать «путеводной нитью» для всего процесса структурирования комплексных программных продуктов, так как он объединяет две основные технологии проектирования больших систем - объектно-ориентированный и структурный анализ.
Для описания онтологий существуют различные языки и системы. Наиболее перспективным представляется визуальный подход, позволяющий специалистам непосредственно «рисовать» онтологии, что помогает наглядно сформулировать и объяснить природу и структуру явлений. Визуальные модели, - например, графы, - обладают особенной когнитивной (т.е. познавательной) силой. Любой программный графический пакет можно использовать как первичный инструмент описания онтологий.
Однако, проектирование и разработка онтологий, т.е. онтологический инжиниринг, не является тривиальной задачей. Он требует от разработчиков профессионального владения технологиями инженерии знаний - от методов извлечения знаний до структурирования и формализации [3].
В связи с этим задачу онтологического инжиниринга программного продукта следует декомпозировать на несколько подзадач:
1. Выделение концептов — базовых понятий данной предметной области.
2. Определение «высоты дерева онтологий» - числа уровней абстракции.
3. Распределение концептов по уровням.
4. Построение связей между концептами — определение отношений и взаимодействий базовых понятий;
5. Исключения противоречий и неточностей.
С помощью декомпозиции мы получаем план решения задачи, в котором подзадачи могут быть решены последовательно. Тем не менее, для программных проектов с высокой степенью неопределенности специфичны следующие проблемы:
1. Отсутствие полного представления о требованиях к продукту, обусловленное динамически изменяющейся предметной областью, для которой создается программный продукт.
2. Слабая структурированность теоретических и фактических знаний о программных проектах, а также организационные сложности на стороне заказчика.
3. Неполнота информации, обусловленная игнорированием имеющегося большого опыта проектных организаций: реальные технико-экономические показатели удачно выполненных программных проектов не обобщаются и не используются в качестве исходной базы для управления новыми программными проектами [4].
В связи с этим, однократное решение всех подзадач с имеющимися входными данными, известными о продукте на стадии инициации проекта, позволяет получить только грубые результаты в виде онтологии с большим количеством неточностей.
Более того, для проектов, которые включают в себя значительный программный компонент, традиционный метод управления проектом, который подразумевает однократный проход всех этапов проекта, может быть неэффективным, поскольку требования могут оказаться смутными, изменчивыми.
В настоящее время в сфере разработки программного обеспечения очень популярно понятие гибкой методологии разработки (англ. Agile software development). Гибкая методология представляет собой серию подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований [5] и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
Гибкие методы используются тогда, когда присутствуют следующие условия:
1. значение проекта четко обозначено;
2. клиент активно участвует на протяжении всего проекта;
3. возможна пошаговая разработка, основанная на функциях;
4. допустима визуальная документация (карточки на стене в противоположность формальной документации).
Гибкий метод разработки состоит из множества скорых итеративных циклов планирования и разработки, позволяя команде разработчиков постоянно оценивать развивающийся продукт и получать мгновенные отзывы от пользователей и участников проекта. Команда изучает и улучшает продукт, а также метод работы в каждом успешном цикле. После хорошо налаженного планирования, определения нужд и наброска решения этап завершается, при этом проект проходит через итерации с уже более детальными процессами планирования, анализа нужд и реализации, принимая форму волн. Такой подход позволяет совершать мгновенные изменения как онтологии программного продукта, так и непосредственно продукта при поступлении новых требований.
Основная команда обычно состоит из разработчиков, которые занимаются написанием кода попарно (полноценное управление качеством), клиента/пользователя, архитектора (-ов) в области ИТ, бизнес-аналитика и руководителя проекта. Работы выполняются на протяжении серии сессий, где команда пишет код, затем тестирует рабочие модули системы, и затем процесс повторяется. Гибкая методология разработки основана на сотрудничестве
среди всех участников команды для получения хороших результатов, объективных мнений и реализации всех полученных знаний на следующем этапе разработки. Это одно из преимуществ данного метода - постоянные объективные мнения и улучшения. Руководитель проекта завершает начальное планирование, а бизнес-аналитик определяет и дает приоритеты элементам разрабатываемого продукта вместе с клиентом и специалистами.
Это отличается от традиционного подхода, где значительное количество времени уделяется планированию и ведется обширная документация нужд и требований. Команда, применяющая гибкий метод, определяет и дает приоритеты разрабатываемым функциям на основе их ценности в бизнесе, а после того, как будут созданы критические компоненты системы, работа ведется над теми, которые имеют высший приоритет. Такой подход пригоден в случае, если предлагаемый продукт может быть доставлен клиенту пошагово. В случае, если это невозможно, функции и свойства все же могут быть разработаны и затем интегрированы в первоначальную версию системы.
Внедрение метода онтологического инжиниринга в итеративный процесс разработки программного обеспечения позволит последовательно решать обозначенные подзадачи общей задачи онтологического инжиниринга с использованием обновленных входных данных, появившихся в рамках очередной итерации. Таким образом, на выходе из каждой итерации разработки программного обеспечения мы получаем все более полную и точную онтологию программного продукта. Это, в свою очередь, позволяет разрешить вышеописанные проблемы и достичь поставленной цели в составлении онтологии комплексного программного продукта в проектах с высокой степенью неопределенности.
Литература
1. Gruber T.R. A translation approach to portable ontologies / Knowledge Acquisition, 5(2):199-220,1993.
2. Wiig К. Knowledge management is no illusion! / Proc. of the First International Conference on Practical Aspects of Knowledge Management. - Zurich, Switzerland: Swiss Information Society, 1996.
3. Гаврилова ТА., Хорошевский В.Ф., 2000. Базы знаний интеллектуальных систем / Учебник для вузов. - СПб, Изд-во «Питер», 2000.
4. Колоденкова А.Е. Задачи программного инжиниринга сложных систем на основе критерия жизнеспособности проекта / Журнал Вестник Уфимского государственного авиационного технического университета. - г. Уфа, 2011
5. Кошкидько А.В. «Метод контрольных точек в гибких методологиях разработки программного обеспечения» / Материалы десятой юбилейной ежегодной научной конференции студентов и аспирантов базовых кафедр Южного научного центра РАН. - г. Таганрог, 2014 г.
УДК 004.94
ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ РЕАЛИЗАЦИЯ СВЯЗНОЙ СТРУКТУРЫ ДАННЫХ ДЛЯ ОПТИМИЗАЦИОННЫХ ЗАДАЧ УПАКОВКИ
Чеканин Владислав Александрович, к.т.н., доцент, ФГБОУ ВО «МГТУ «СТАНКИН», Москва,
Россия, vladchekanin@rambler.ru Чеканин Александр Васильевич, д.т.н., профессор, ФГБОУ ВО «МГТУ «СТАНКИН», Москва,
Россия, avchekanin@rambler.ru
Введение
Задачи упаковки объединяют широкий набор оптимизационных задач, заключающихся в поиске наиболее плотного размещения объектов в контейнерах. К решению задач упаковки сводится решение большого числа практических задач
