CC BY
37
УДК 622.271.621.879.22
С.Д. Букейханов, С.С. Букейханова, А.А. Канагатова, Е.А. Сапаков
ПРИМЕНЕНИЕ МЕТОДОВ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА ДЛЯ СОЗДАНИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПРОЕКТИРОВАНИЯ КАРЬЕРОВ
Рассмотрены наиболее эффективные способы и методы выявления рациональных решений для создания автоматизированной системы проектирования карьеров с использованием методов объектно-ориентированного анализа, построения и программирования на базе унифицированного языка моделирования UML. Проанализирована методология, позволяющая создавать целостную систему сложной динамической системы в виде комплекса взаимосвязанных моделей и перевод их в реальный программный продукт, и мировой опыт ее применения. Рассмотрены процессы проектирования позволяющие создавать модели и программное обеспечение больших и сложных динамических систем, и технологии позволяющие достичь полного понимания характера зависимостей между артефактами каждой итерации основанных на архитектуре и моделировании и более тщательном подходе к разработке программного обеспечения.
Ключевые слова: геоинформатика, унифицированный язык моделирования, информатика, акторы, система, модель, программирование, итерации, артефакт.
DOI: 10.25018/0236-1493-2018-3-0-208-217
Информационные технологии, совершенствуясь и расширяясь, постепенно завоевывают и охватывают все новые и новые ключевые сферы в деятельности человека. Становление информатики и геоинформатики способствовало появлению и развитию методологий системотехники и интегрированных систем автоматизированного проектирования, управления, геоинформационных графических систем и технологий, баз данных, а также инициировало создание целого ряда интегрированных горно-геологических систем.
Коммерциализация промышленных отраслей требует все более эффективных и качественных программных продуктов, быстрой разработки и распростра-
нения их в различных сферах деятельности человечества. При этом разработчики программного обеспечения не в состоянии полностью удовлетворить растущий спрос. Для быстрой и качественной разработки программного обеспечения еще не созданы, в полной мере, автоматизированные процессы, которые можно реализовывать и повторять, с предсказуемой результативностью и качеством. Вместе с совершенствованием теории вычислительных систем и созданием целого ряда объектно-ориентированных языков программирования, таких как Simula, Smalltalk, Java, Lisp, Visual Basic, C++, Objective-C, COBOL. Eiffel и т.п. в дальнем зарубежье появились фундаментальные теоретические и прик-
ISSN 0236-1493. Горный информационно-аналитический бюллетень. 2018. № 3. С. 208-217. © С.Д. Букейханов, С.С. Букейханова, А.А. Канагатова, Е.А. Сапаков. 2018.
ладные работы, посвященные созданию программно-функциональных комплексов сложных систем [1, 2], таких как Datamine, Lynx, МineScape, Surpac, Vulcan, Gemcom, Geostat, Geovariances, Micro-m^, Minex, Geoblock, Tiger и др., как правило, с неполным набором функций [7, с. 84].
Вместе с тем, следует отметить, что применение методов исследования операций и интегрированных горно-геологических систем, натолкнулось на проблему того, что в этих методах при моделировании и решении задач больших и сложных динамически систем с увеличением числа переменных за определенные пределы происходит стремительный рост сложности самих системы. Это не позволяет посредством этих разработок моделировать, анализировать, проектировать и создавать программное обеспечение целостных полнофункциональных сложных систем таких, как, например, карьер, шахта, рудник и т.п. Поэтому, на практике, такие задачи решаются в следующем порядке: сначала производится декомпозиция системы на отдельные подсистемы, агрегаты и объекты (части системы) в пределах которых выполняются расчеты; далее полученные решения в этих отдельных частях системы без достаточного полного учета всех взаимосвязей и характера взаимовлияния множества параметров и показателей друг на друга, а также взаимовлияния внешних компонентов среды склеиваются в единое целое. Такие технологии решения проблем сложных систем, естественно, не могут привести к удовлетворительным результатам [11, с. 7].
В 1997 г. в США Группа управления объектами OMG (Object Management Group) принимает разработанный Гра-ди Бучем, Джеймсом Рамбо и Айваром Якобсоном объектно-ориентированный язык визуального моделирования UML (Unified Modeling Language) и рациональ-
ный унифицированный процесс создания программного обеспечения RUP (Rational Unified Process) как стандартный язык визуального моделирования, удовлетворяющий промышленным стандартам [12, 3].
Унифицированный язык моделирования UML на наш взгляд объединил лучшие современные технические приемы разработки программных средств больших и сложных динамических систем. Предлагаемая методология, адаптивна для решения сложных взаимосвязанных динамических задач горного производства. И предусматривает установление основных требований к системе на базе основных положений строительных блоков языка UML, правил устанавливающих сочетания строительных блоков и общих для языка механизмов, посредством которых компоненты системы могут сотрудничать друг с другом и осуществлять свое поведение, соответствующее требованиям системы [4]. Для примера приведем несколько отраслей и компаний, разбросанных по всему миру, в которых применяется данная методология:
• телекоммуникация: Ericsson, Alcatel, Verizon Communications Inc;
• транспорт, оборонная промышленность: Lockheed Martin, BAE Systems plc;
• промышленность: Xerox Corporation, Volvo, Intel;
• финансовые и аудиторские компании: Visa, Merrill Lynch, Ernst & Young Deloitte Touche Tohmatsu;
• интеграторы систем: Oracle и др.
Создание программного обеспечения сложной динамической системы формируется путем построения диаграмм структуры (классов, композитной структуры, пакетов, объектов, компонентов и развертывания), диаграмм поведения (вариантов использования, деятельности и конечного автомата) и диаграмм взаимодействия (последовательности, коммуникаций, взаимодействия и вре-
менных диаграмм). Разработка процесса жизненного цикла создания программного обеспечения, которая представляет собой упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках точно определенной хронологической последовательности действий. При этом процесс представляется четырьмя базовыми элементами моделирования: роли (исполнитель) — кто, видов деятельности — как, артефактами — что, технологическими процессами — когда. Они предусматривают: управление вариантами использования и выполнение процессов, сконцентрированных на качестве архитектуры системы, а также использование итеративно-инкрементного пошагового процесса.
Технология разработки программного обеспечения системы на модели жизненного цикла развивается по двум измерениям: по горизонтальной оси времени жизненный цикл создания программного продукта системы делится на четыре фазы, которые описывают динамическую структуру и процессы разделенные контрольными точками, а именно: «Исследование», «Конструирование», «Построение» и «Внедрение», а по нижней шкале планируется и осуществление целенаправленного итеративно-инкре-ментного процесса и его контроль при прохождении собственных вех каждой итерацией [3, 5].
Итеративно-инкрементный подход состоит в том, что проект разбивается на несколько последовательных итерационных мини каскадных частей, каждая из которых представляет собой полный мини каскадный цикл. При этом каждая итерация имеет свою конкретную цель и создает базовую версию системы, подсистемы, агрегата, которая используется для внутреннего (или внешнего) анализа и рассмотрения наборов утвержденных артефактов, сгенерированных в каждой конкретной итерации. Результаты дости-
жения конкретных целей на каждой итерации рассматриваются и оцениваются в межитерационных контрольных точках и в межфазовых вехах.
Процесс разработки программного обеспечения, разбит на серию последовательных шагов или итераций, каждый из которых является по сравнению с предыдущим приближением к желаемому результату. Конечным результатом каждой итерации должна быть работающая система, которую можно запускать, тестировать и отлаживать. Таким образом, итерация представляет собой частично завершенную версию целевой системы и (или) документацию проекта. Каждая базовая версия представляет основу для дальнейшего рассмотрения и разработки и может изменяться только через формальные процедуры управления конфигурацией и изменениями. Процесс продолжается до тех пор, пока не будет создана окончательная и полная версия системы.
Разница между двумя смежными версиями, получаемая в итерационном процессе, называется итеративным инкрементом. Итеративный процесс соотносится (корректируется) со стадиями моделирования и его фазами «исследование», «уточнение плана», «построение» и «развертывание» и включают в себя от одной до нескольких итераций. В каждой итерации в UP (RUP) на жизненном цикле разработки программного обеспечении выполняются шесть рабочих потоков: моделирование производственных и бизнес процессов; сбор, анализ, структурирование и управление требованиями и их реализация в архитектуре системы; анализ и проектирование системы; построения программного обеспечения, их тестирование и реализация, а также распространение разработанной программной продукции с полной документацией.
Существует несколько подходов при описании итеративно-поступательного
процесса, описанных в работе. Это спиральная модель, унифицированный процесс, архитектура управляемая моделями (MDA), ускоренный процесс разработки и аспектно-ориентированная разработка программного обеспечения. Широкое распространение на практике получил итеративно-поступательный (incremental) подход, когда итеративный (iterative) процесс включает управление потоком исполняемых версий системы, а пошаговый процесс — непрерывную интеграцию системной архитектуры в целях выпуска версий. При этом каждая последующая усовершенствована по сравнению с предыдущей. На каждой итерации в проект добавляются новые детали. Процесс, являющейся итеративным и пошаговым и называется процессом с управляемым риском (risk-driven), поскольку при выпуске каждой новой версии (релиза) серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для проекта в целом, и сведение их к минимуму.
Итеративно-пошаговый процесс можно описать посредством разных методов и моделей, к которым можно отнести: спиральные модели, модели унифицированного процесса PUP, архитектуры управляемые моделями, модели ускоренной разработки и аспектно-ориен-тированных разработок. Спиральная модель (spiral model) включает все элементы обычного проекта по разработке проекта большой и сложной динамической системы, которые начинаются с планирования и далее анализа и проектирования, построения, интеграций по моделированию и разработки программного обеспечения и является базовой моделью для всех итеративных процессов создания программных продуктов, их тестирования и подготовки базовой версии. В целом, такой итеративно-ин-крементный процесс приводит к желаемому результату — созданию моделей
и программного обеспечения больших и сложных динамических систем. Этот процесс определяет деятельность направленную на разработку программных продуктов системы, который включает процессы определения функциональных и общесистемных требований (сбор, обработку и формирование), а также уточнение и структурирование требований, и их реализации в процессе разработки программном обеспечении с учетом анализа рисков и их оценки с принятием решений заказчиком и другими заинтересованными субъектами акторами.
Моделирование производства должно дать определение желаемых свойств системы и потребности пользователей акторов и должно выполняться по фазам модели жизненного цикла разработки проекта по всем видам деятельности. Моделирование предметной области предусматривается осуществлять с выделением и идентификацией компонентов предметной области и ее концептуализацией, последние будут выполняться на первоначальных стадиях фазы исследования, а моделирование технологических процессов производства, управления требованиями, анализа и проектирования, реализации и тестирования предусматривается выполнять с учетом трех взаимосвязанных между собой точек зрения на систему.
Модель классов должна описывать структурные аспекты системы, связанные с данными, модель взаимодействия представляет временные, поведенческие и управленческие аспекты системы по упорядочиванию операции во времени, а модели взаимодействия должны представлять кооперацию отдельных объектов, связанных с их взаимодействием. Структурные модели предназначаются для описания статической структуры сущностей и (или) элементов системы, включая классы, интерфейсы, атрибуты и отношения, а модели пове-
дения для описания процесса функционирования элементов модели системы, включая их методы и взаимодействие между ними, а также с учетом в процессе деятельности изменений состояний отдельных элементов и системы в целом.
В процессе разработки потоков жизненного цикла, модели развиваются постепенно от одной итерации к другой и от одной фазы к следующей, проходя свои контрольные точки с достижением при этом определенных целей. Язык UML предусматривает иерархию в процессе моделирования, состоящую их четырех уровней: мета-модели (МЗ); метамодели (М2); модели (М1) и моделей объектов и (или) экземпляров (МО), в структуре модельных представлений. При этом метамодели (МЗ) образуют формально-логическую основу для всех возможных метамодель-ных представлений на самом высоком уровне абстракции и являются наиболее компактным его описанием, необходимым для определения языка спецификаций метамоделей. Метамодель является экземпляром и (или) конкретизацией метамодели на более конструктивном уровне и обладает более развитой семантикой базовых понятий (класс, атрибут, операция, компонент, ассоциация и др.). Модель является экземпляром метамодели. Это уровень для описания информации о конкретной предметной области [8, а 323].
Целью проектирования карьеров является выявление оптимальных взаимосвязанных организационно технических решений по его строительству (реконструкции) и эксплуатации, реализация которых обеспечит максимальный эффект от разработки месторождения. Например, для разработки диаграммы вариантов использования выполняется некоторая последовательность действий:
• определить главных или первичных и второстепенных акторов;
• определить цели главных акторов по отношению к системе;
• сформулировать основные варианты использования, которые специфицируют функциональные требования к системе;
• упорядочить варианты использования по степени убывания риска их реализации;
• рассмотреть все базовые варианты использования в порядке убывания их степени риска;
• выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования;
• написать успешный сценарий реализации выбранного варианта использования;
• определить исключения или неуспех в выполнении сценария варианта использования;
• написать сценарии для всех исключений;
• выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом «include»;
• выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом «extend»;
• проверить диаграмму на отсутствие дублирования вариантов использования и акторов.
Семантика построения диаграммы вариантов использования должна определяться следующими особенностями рассмотренных выше элементов модели. Отдельный экземпляр варианта использования по своему содержанию является выполнением последовательности действий, которая инициализируется посредством экземпляра сообщения от экземпляра актора. В качестве отклика или ответной реакции на сообщение актора выполняется последовательность действий, установленная для данного варианта использования. При этом акторы могут генерировать новые сообщения для инициирования вариантов использования.
Реализация варианта использования зависит от типа элемента модели, в котором он определен. Например, варианты использования моделируемой программной системы могут быть реализованы посредством операций классов модели. Применительно к бизнес-системам варианты использования могут реализоваться сотрудниками этой системы. Во всех случаях элементы системы должны взаимодействовать друг с другом для совместного обеспечения требуемого поведения и выполнения вариантов использования.
Выходная информация результатов проектирования должна содержать проектную документацию, необходимую и достаточную для строительства карьера. В работе [7] авторы обосновывали новый подход при проектировании карьеров, который заключается и выборе рационального решения по разработке месторождения путем моделировании системы и выбора рационального варианта его разработки на основе сочетаний взаимосвязанных показателей, а не наборов последовательного решения задач и оптимизации отдельных параметров разработки.
В общем, модель — это семантическая замкнутая абстракция системы или упрощенное представление действительности, помогающее охватить большую, сложную систему, не поддающуюся пониманию во всей своей полноте [8].
В общем смысле, моделирование — это метод изучения объектов (предметов, систем, процессов и явлений) путем построения и исследования их моделей, что позволяет абстрагироваться от несущественных характеристик объектов, изменять пространственно-временные и другие масштабы протекающих в них процессах, когда не представляется возможным изучать объекты прямым экспериментом, либо такой эксперимент крайне затруднен или вообще не возможен.
Моделирование производства, определение желаемых свойств системы и потребностей пользователей должно выполняться по всем видам деятельности разработки проекта, например:
• разработка математической модели месторождения и карьера должно осуществляться в соответствии с принципами [6, c. 18] или на основе разработок Datamine, Micromine, Gemcom и т.п. руководствуясь при этом материалами протокола ГКЗ об утверждении запасов по данному месторождению;
• горно-геометрический анализ месторождения и карьерного поля; построение множества альтернативных вариантов границ карьера с учетом его производительности на основе данных выполненных на стадиях предпроектных работ (ТЭР, ТЭД, ТЭО) и уточненных в соответствии с регламентом и заданием на проектирование карьера;
• определение граничного коэффициента вскрыши выполняется по данным прогноза и (или) мониторинга технико-экономической ситуации на рынках; расчетов производительности карьера и параметров и показателей технологических процессов производства горных работ;
• выделение и районирование при-бортовых массивов горных пород по фактору их устойчивости с дифференциацией по секторам, этапам, и в целом по карьерному полю; выбор устойчивых конструкций граничных временно нерабочих бортов карьерного поля и углов их наклона;
• выбор технологии и комплексной механизации горных работ.
Определение требований выполняется в фазах «Начало» и «Развитие» и представляются в виде потока событий. Поток событий состоит из последовательности коротких этапов, декларативных, пронумерованных во времени. Каждый этап потока прецедента должен быть вы-
ражен в следующей форме: <номер> <кто-либо> <совершает некоторое действие>. Основной поток регистрирует этапы прецедента, отражающие «идеальную» ситуацию, когда все идет, как ожидается и хочется, то есть не возникает ошибок, отклонений, прерываний или ответвлений.
Существуют два основных типа требований:
• функциональные требования — какое поведение должна предлагать система:
• нефункциональные требования — особое свойство или ограничение, накладываемое на систему.
Модель прецедентов создается в инструменте моделирования UML, таком как Rational Rose. Модель требований может быть создана в текстовом или в специальном инструментальном средстве выработки требований. Для записи требований используется утверждение shall (должен). Функциональное требование — это формулировка того, что должна делать система, это описание назначения системы. Моделирование прецедентов — это форма выработки требований, модельтребований,объединяет функциональные и нефункциональные требования так называемым «традиционным» способом. Моделирование прецедентов — это другой, дополнительный способ выявления и документирования требований.
Моделирование прецедентов обычно происходит следующим образом: устанавливаются границы потенциальной системы; выявляются акторы; выявляются прецеденты: определяется прецедент; устанавливаются основные альтернативные потоки; предыдущие шаги повторяются, пока прецеденты, а акторы и границы системы не стабилизируются.
Обычно начинают с самой общей оценки границ системы, чтобы обозначить область моделирования. Затем все
действия осуществляются итеративно и зачастую параллельно. В этой модели четыре компонента:
• Граница системы — прямоугольник, очерчивающий прецеденты для обозначения края, или границы, моделируемой системы. В UML 2 эту границу называют контекстом системы (subject).
• Акторы — роли, выполняемые людьми или сущностями, использующими систему.
• Прецеденты — то, что акторы могут делать с системой.
• Отношения — значимые отношения между акторами и прецедентами.
Модель прецедентов является основным источником объектов и классов. Это основные исходные данные для моделирования классов.
Моделирование прецедентов включает выявление акторов и прецедентов.
Прецедент — это описание последовательности действий, включая альтернативные и ошибочные последовательности, которые система, подсистема, агрегат или класс могут осуществлять, взаимодействуя с внешними субъектами (акторами). Прецедент описывает поведение, демонстрируемое системой с целью получения значимого результата для одного или более субъектов.
Пиктограмма, напоминающие папки, — это пакеты UML, которые являются механизмом группировки UML и содержат группы элементов модели UML и используются для их организации. Пиктограммы якоря показывают, что сущность, изображенная со стороны кружка, содержит сущность, находящуюся на другом конце линии. Детализация показывает исполнителей и деятельности, вовлеченные в конкретный рабочий поток.
Функциональное требование — это формулировка того, что должна делать система, это описание назначения системы. Пример прецедентов «Буровой-БлокСкважина» приведен в таблице.
Ю: 1Б_
Краткое описание:
Подготовить и обурить в соответствии с типовым паспортом буровзрывных работ каждый взрываемый рабочий буровой блок № Х. , где / = 1, 2, ..., / — номера буровых блоков в карьере для размещения в скважинах зарядов ВВ и их взрыва с целью рыхления скальных и полускальных горных пород и повышения эффективности выемочно-погрузочных и транспортных работ в карьере. Главные акторы:
Маркшейдер взрывного цеха (участка) и комиссия по приему-сдаче обуренных скальных и полускальных блоков карьере. Второстепенные акторы:
Начальник горного или экскаваторного участка. Предусловие:
1. Размеры рабочего бурового блока № Х. расположенного на Ь-ом горизонте между секторами С1 и С2 карьерного поля для размещения в скважинах ВВ и последующего их взрыва являются видимыми и соответствуют типовому паспорту бурения рабочего блока № Х..
2. Рабочий блок должен быть подготовлен для бурения заданным в паспорте бурения рабочего блока № Х. видом и типом бурового оборудования.
3. Ширина рабочего блока предусмотренного для бурения вместе с шириной транспортной полосой и полосой ЛЭП согласно паспорта рабочей площадки не должна быть меньше минимально — допустимой ширины рабочей площадки предусмотренной для данной технологии производства.
4. Расчетная производительность бурового оборудования в рабочем блоке № Х. должна соответствовать принятой в паспорте технологии бурения на данном блоке с учетом категории и класса пород на данном блоке, а также данных практики в соответствии с «Классификацией горных пород по буримости».
Основной поток:
1. Прецедент начинается, когда поверхность блока подготовлена для бурения и имеется возможность подключения буровых станков к электросети; маркшейдер взрывного цеха произвел съемку рабочего блока № Х.; уточнил его границы и определил сеть расположения скважин на данном рабочем блоке с фиксацией точек устья и глубины бурения каждой скважины; составил паспорт бурения сети скважин на блоке и график выполнения буровых работ с определением объема и необходимого времени для обуривания блока.
2. Бригада электриков и бригады буровых станков заслушав оформленный наряд и распоряжение бурового мастера на бурение, подключают буровые станки станков к электросети и приступают к бурению взрывных скважин с соответствии со схемой и графиком последовательности бурения скважин и перемещений станков на блоке.
3. После завершения буровых работ по бурению скважин на блоке № Х. .буровой участок в лице горного мастера по бурению сдает обуренный блок уполномоченной приказом главного инженера карьера комиссии (начальники бурового и взрывного цехов, представителя техотдела, маркшейдера и др.), которая принимает обуренный блок № Х. и подписывает акт приемки-сдачи.
Постусловия:
1. Выполняется маркшейдерская съемка обуренного блок № Х1 с контрольными замерами глубины пробуренных скважин и составляется проект взрыва.
2. С Блока № Х. перемещаются буровые станки (начальники бурового и взрывного цехов, представителя техотдела, маркшейдера и др.) за пределы опасной зоны на следующий подготовленный для бурения Блок № Х2.
3. Из опасной зоны Блока № Х. демонтируется и переносится за его пределы вспомогательное оборудование, ЛЭП, электросиловое и иное оборудование, которое находилось в пределах опасной зоны блока.
Альтернативные потоки:
В качестве выводов по приведенным в статье материалам можно констатировать:
1. Перспективы развития применения методов объектно-ориентированного анализа для создания автоматизированной системы проектирования карьеров с использованием, должны дать оправдание желаемого результата и потребностей пользователей (акторов).
2. В целом, методы, описанные в статье приводят к желаемому результату — созданию моделей и программного обеспечения больших и сложных динамических систем.
3. Уточнение и структурирование требований с учетом анализа рисков и их
СПИСОК ЛИТЕРАТУРЫ
оценки с принятием решений заказчиком и другими заинтересованными субъектами (акторами).
4. Выявление оптимальных взаимосвязанных организационно технических решений по строительству (реконструкции) карьеров и последующей их эксплуатации, реализация которых обеспечит максимальный эффект от разработки месторождения.
В сегодняшней кризисной ситуации коммерческим организациям трудно и невозможно заниматься анализом и теоретическими разработками, и поэтому ученым необходимо помочь управленцам практикам в вопросе использования достижений современного проектирования.
1. Букейханов Д.Г. Принципы моделирования сложных динамических систем недропользования. — Усть-Каменогорск: ВКГТУ, 2012. — С. 25—32.
2. Ларман К. Применение UML и шаблонов проектирования. 2-е изд. — М.: Вильямс, 2002. — С. 624.
3. Буч Г., Рамбо Дж., Якобсон И. Унифицированный язык моделирования. Руководство пользователя. — Бостон: Эддисон-Уэсли, 2007. — С. 496.
4. Крачтен Ф., Кролл П. Унифицированный процесс. Руководство практикующего УП. — Бостон: Эддисон-Уэсли, 2003. — С. 416
5. Фаулер М. UML. Основы. Краткое руководство по унифицированному языку моделирования. 3-е изд. — М.: Лори, 2004. — С. 325.
6. Гома Х. UML. Проектирование систем реального времени, параллельных и распределенных приложений. — Бостон: Эддисон-Уэсли, 2001. — С. 785
7. Жарменов А. А., Турдахунов М. М., Букейханов Д. Г., Бекмурзаев Б.Ж., Съедин В. Ф. Геоинформационные объектно-ориентированные технологии разработки системы автоматизированного проектирования карьеров. — Алматы: АО «НЦ НТИ», 2011. — С. 222.
8. Грэхем И. Объектно-ориентированные методы: принципы и практика. — Нью-Йорк: Эд-дисон-Уэсли, 2001. — С. 832
9. Букейханов Д. Г. Автоматизированное проектирование карьеров // Промышленность Казахстана. — 2012. — № 6. — С. 18—22.
10. Турдахунов М. М., Букейханов Д. Г., Галиев С.Ж. Принципы создания систем автоматизированного проектирования железорудных карьеров с применением объектно-ориентированной методологии // Горный журнал. — 2014. — № 6. — С. 83—89.
11. Хохряков В. С., Корнилков С. В., Лель Ю. И., Стариков А.Д., Терехина Ю. В. Новое в теории оптимизации проектирования открытых горных работ // Горный журнал. — 2005. — № 5. — С. 7—13.
12. АрлоуДж., НейштадтИ. UML 2 и унифицированный процесс. — Бостон: Эддисон-Уэсли, 2008. — С. 621. ЕПЗ
КОРОТКО ОБ АВТОРАХ
Букейханов Санжар Диасович1 — научный сотрудник, Букейханова Софья Санжаровна1 — зав. лабораторией, Канагатова Айтгуль Ахатовна1 — инженер, e-mail: Aitgul.kanagatova@mail.ru, Сапаков Ермек Акбарович — доктор технических наук, Казахстан, 1 Институт горного дела имени Д.А. Кунаева, Казахстан.
ISSN 0236-1493. Gornyy informatsionno-analiticheskiy byulleten'. 2018. No. 3, pp. 208-217.
S.D. Bukeykhanov, S.S. Bukeykhanova, A.A. Kanagatova, E.A. Sapakov
APPLICATION OF THE OBJECT-ORIENTED ANALYSIS METHOD TO CREATING AN AUTOMATED OPEN PIT MINE PLANNING AND DESIGN SYSTEM
Available integrated systems connected with mining and geology are reviewed. The most efficient methods and approaches are identified with a view to making rational decisions on creating an automated system of open pit mine planning and design using the object-oriented analysis and design and programming using unified modeling language UML. The methodology of creating a complex integral dynamic system as a set of interconnected models and their conversion to a real programming product, as well as the international experience of this methodology application are analyzed. The discussed design processes allow modeling and program support of large and complex dynamic systems using technologies which enable thorough understanding of the behavior of correlation between artifacts of each iteration based on the architecture and modeling, and on the more comprehensive approach to software engineering. The article illustrates application of the object-oriented analysis methods to creating an automated open pit mine planning and design system.
Key words: geoinformation science, unified modeling language, information science, actors, system, model, programming, iteration, artifact.
DOI: 10.25018/0236-1493-2018-3-0-208-217
AUTHORS
Bukeykhanov S.D.1, Researcher,
Bukeykhanova S.S.1, Head of Laboratory,
Kanagatova A.A.1, Engineer, e-mail: Aitgul.kanagatova@mail.ru,
Sapakov E.A., Doctor of Technical Sciences, Almaty, Kazakhstan,
1 Mining Institute named after D.A. Kunaev, 050046, Almaty, Kazakhstan.
REFERENCES
1. Bukeykhanov D. G. Printsipy modelirovaniya slozhnykh dinamicheskikh sistem nedropol'zova-niya (Pprinciples of modeling complex dynamic systems of subsoil use), Ust-Kamenogorsk, VKGTU, 2012, pp. 25-32.
2. Larman K. Primenenie UML i shablonov proektirovaniya. 2-e izd. (The use of UML and design patterns, 2nd edition), Moscow, Vil'yams, 2002, pp. 624.
3. Buch G., Rambo Dzh., Yakobson I. Unified modeling language. User manual. Boston, Addison-Wesley, 2007, pp. 496.
4. Krachten F., Kroll P. Unified process. User manual. Boston, Addison-Wesley, 2003, pp. 416.
5. Fauler M. UML. Osnovy. Kratkoe rukovodstvo po unifitsirovannomu yazyku modelirovaniya. 3-e izd. (UML. The basics. User manual, 3rd edition), Moscow, Lori, 2004, pp. 325.
6. Goma H. UML. Designing real-time systems, parallel and distributed applications, Boston, Addi-son-Wesley, 2001, pp. 785
7. Zharmenov A. A., Turdakhunov M. M., Bukeykhanov D. G., Bekmurzaev B. Zh., S"edin V. F. Geoin-formatsionnye ob"ektno-orientirovannye tekhnologii razrabotki sistemy avtomatizirovannogo proektirovaniya kar'erov (Geoinformation object-oriented development technology computer-aided design of quarries), Almaty, AO «NTs NTI», 2011, pp. 222.
8. Graham I. Object-oriented methods: principles and practice, New York, Addison-Wesley, 2001, pp. 832.
9. Bukeykhanov D. G. Promyshlennost' Kazakhstana, 2012, no 6, pp. 18-22.
10. Turdakhunov M. M., Bukeykhanov D. G., Galiev S. Zh. Gornyy zhurnal, 2014, no 6, pp. 83-89.
11. Khokhryakov V. S., Kornilkov S. V., Lel' Yu. I., Starikov A. D., Terekhina Yu. V. Gornyy zhurnal, 2005, no 5, pp. 7-13.
12. Arlow, J., Neyshtadt I. UML 2 and the unified process, Boston, Addison-Wesley, 2008, pp. 621.
TABLE
Well Drilling Block Case.
