CC BY
9
УДК 685.5:67.02
Чаадаев А.А. студент магистратуры факультет «Системы обработки информации и управления»
МГТУ им. Н.Э. Баумана научный руководитель: Мышенков К.С.
профессор Россия, г. Москва
ИСПОЛЬЗОВАНИЕ МЕТОДОЛОГИИ RUP ДЛЯ ПРОЕКТИРОВАНИЯ ПОДСИСТЕМЫ ТЕХНОЛОГИЧЕСКОЙ ПОДГОТОВКИ
ПРОИЗВОДСТВА
Аннотация
В данной работе рассматриваются основные особенности применения методологии RUP при разработке подсистемы технологической подготовки производства. Основными особенностями методологии является то, что RUP управляется прецедентами, ориентирован на архитектуру программы, является итерационно-инкрементным. В ходе разработки подсистемы технологической подготовки производства описана базовая архитектура, затем показаны прецеденты, подразумевающие выполняемые задачи отделами, вовлеченными в технологическую подготовку производства. Также показаны диаграммы, описывающие структуру подсистемы технологической подготовки производства, а именно диаграммы классов. Показаны примеры диаграмм последовательности для реализации основных прецедентов, а также диаграммы компонентов и развертывания с привязкой к выбранным инструментальным средствам.
Ключевые слова: технологический процесс (production process), методология RUP (RUP methodology), подсистема технологической подготовки производства (subsystem of engineering process), язык UML (UML language).
Chaadaev A.A.
Graduate student Faculty of Computer Science and Control Systems Bauman Moscow State Technical University
Moscow, Russia Scientific director: Myshenkov K.S.
professor
Annotation
This paper describes the main principals of RUP software development methodology usage for subsystem of engineering process. During the development of subsystem of engineering process were described the main roles and use cases. All the main UML diagrams were developed to describe the engineering process subsystem, including class and package diagrams. Some of the main use cases
were provided by the sequence diagrams. Deployment and component diagrams were developed and adapted for used instruments, including: C# language, .NET Framework 4.7 and SQL Server 2017 DBMS.
Keywords: RUP methodology, subsystem of engineering process, UML language.
В настоящее время основными технологиями как промышленной, так и индивидуальной разработки программного обеспечения является объектно-ориентированный подход с применением пакетов визуальной разработки в таких средах, как Microsoft Visual Studio, Qt Creator и так далее. Применение таких средств сместили основной акцент при создании ПО на этапы анализа и проектирования. По этой причине главными задачами разработчиков ПО являются формализация исходных требований, последующий их анализ и проектирование, результаты которого транслируются в исходный код. Данный подход включен в унифицированный процесс разработки ПО, RUP (Rational Unified Process). Унифицированный процесс разработки - методология создания программных систем, являющаяся результатом объединения различных подходов к построению ПО. В RUP используется визуальное проектирование с применением графического языка UML (Unified Modeling Language) и автоматическая генерация кода на основе построения моделей.
Унифицированный процесс состоит из четырех этапов разработки: сбора требований, проектирования, построения и внедрения. Каждый этап выполняется как серия итераций, каждая из которых обеспечивает приращение функциональных возможностей системы [1]. Итерация состоит из пяти рабочих процессов: 1) определение требований, 2) анализ, 3) проектирование, 4) реализация, 5) тестирование.
Для RUP характерны следующие особенности:
- управляется прецедентами;
- ориентирован на архитектуру программы;
- является итерационно-инкрементным.
Прецедентом является прикладная задача, которая подлежит автоматизации. В качестве примера на рис. 1 показана диаграмма прецедентов на языке UML для подсистемы технологической подготовки производства. По сути, диаграмма прецедентов показывает взаимодействие между актерами и прецедентами, при этом наборы прецедентов заключены в рамки соответствующей системы. В то же время отношения, которые могут быть изображены на таких диаграммах, представляют собой только фиксированные типы взаимосвязей между актерами и прецедентами, которые в совокупности описывают функциональные требования к моделируемой системе. В качестве основы взяты этапы и работы технологической подготовки производства. Показанные на диаграмме прецеденты выполняются отделами, показанными в виде актёров в нотации UML. При этом актером называется любой объект, субъект или система,
взаимодействующая с моделируемой системой извне. При прохождении каждой итерации унифицированного процесса диаграмма прецедентов уточняется.
Рис. 1. Диаграмма прецедентов подсистемы технологической подготовки производства Еще одной характерной особенностью RUP является то, что методология ориентирована на архитектуру. Это означает, что архитектура будущей системы определяется на начальном этапе, от этого зависит принятие проектных решений на следующих этапах. Архитектура системы -описание основных проектных решений, в том числе компонентов и связей между ними, используемых технологий и аппаратно-программных средств [1]. В качестве средств выбран язык программирования C# с графической системой WPF, для взаимодействия с данными выбрана технология ADO.NET. В качестве СУБД выбран SQL Server 2017. При разработке подсистемы добавления файлов в очередь на печать используется шаблон
проектирования MVC (Моёе1-У1е,^Соп1го11ег), то означает Модель-Представление-Контроллер, показанный в виде диаграммы пакетов в нотации иМЬ на Рис.2. Данный подход обладает важным преимуществом, подразумевающим разделение работы с данными, логики приложения и пользовательского интерфейса. Это позволяет производить модификацию каждого компонента независимо.
Рис. 2. Базовая архитектура подсистемы технологической подготовки
производства
На Рис. 3 показана диаграмма классов подсистемы технологической подготовки производства. Диаграммы классов являются одной из форм статического описания подсистемы технологической подготовки производства с точек зрения ее концепта, спецификации и реализации, показывая структуру разрабатываемого программного продукта. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними. Изображенная на Рис. 3 диаграмма классов показывает точку зрения реализации, так как привязана к программному коду, в данном случае, на языке С#.
Как было описано выше, методология ЯиР ориентирована на архитектуру, следовательно, выбранный подход влияет на дальнейшее приятие решений. Поскольку в качестве основы взят шаблон МУС, то полученная на Рис. 3 диаграмма классов реализует этот подход, что показано на Рис. 4, где указаны вхождения классов в пакеты.
Рис. 3. Диаграмма классов подсистемы технологической подготовки
производства
Рис. 4. Обобщенная диаграмма классов подсистемы технологической
подготовки производства Для описания системы в динамике чаще всего используются диаграммы последовательности, которые предназначены для моделирования отношений между компонентами, ролями или классами системы в рамках одного прецедента.
В общем случае данный вид диаграмм отражает следующие аспекты проектируемой системы:
- обмен сообщениями между объектами (в том числе в рамках обмена сообщениями со сторонними системами);
- ограничения, накладываемые на взаимодействие объектов;
- события, инициирующие взаимодействия объектов.
На рисунках 5 и 6 показаны диаграммы последовательности для прецедентов: «Просмотр данных о доступных наименованиях оснастки», «Просмотр данных о доступных наименованиях оборудования», «Просмотр данных о наличии оснастки» и «Просмотр данных о наличии оборудования».
Рис. 5. Диаграмма последовательности для прецедентов «Просмотр
данных о доступных наименованиях оснастки», «Просмотр данных о доступных наименованиях оборудования» Стоит отметить, что для прецедентов «Просмотр данных о доступных наименованиях оснастки» и «Просмотр данных о доступных наименованиях оборудования» диаграмма последовательности показана общая, так как при реализации данных прецедентов материалы указываются в качестве входных параметров. В зависимости от выбранного материала и выводится список доступных наименований, например оснастки, оборудования, либо деталей или расходных материалов. При данном подходе для прецедентов «Просмотр данных о наличии оснастки» и «Просмотр данных о наличии оборудования» диаграмма последовательности будет одна, так как пользователь из списка нужных материалов выбирает наличие по нужной позиции.
Рис. 6. Диаграмма последовательности для прецедентов «Просмотр данных о наличии оснастки» и «Просмотр данных о наличии оборудования»
Все рассмотренные ранее диаграммы отражали концептуальные и логические аспекты построения модели системы без материального воплощения. Другими словами, различные элементы логического представления, такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически. Они лишь отражают понимание статической структуры той или иной системы или динамические аспекты ее поведения. Полный проект подсистемы технологической подготовки производства представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке ЦЫС для физического представления моделей систем используются диаграммы компонентов и диаграммы развертывания.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
С помощью диаграммы компонентов представляются инкапсулированные классы вместе с их интерфейсными оболочками, портами и внутренними структурами, которые тоже могут состоять из компонентов и коннекторов [2].
На Рис. 7 представлена диаграмма компонентов подсистемы технологической подготовки производства.
Рис. 7. Диаграмма компонентов подсистемы технологической подготовки производства В соответствии с принятым подходом Model-View-Controller, выделены соответствующие компоненты: "Model", "View", 'Control". Данная диаграмма соответствует диаграмме классов на Рис. 4. Однако на Рис. 7 классы показаны в виде соответствующих файлов исходного кода на языке C#.
На Рис. 8 показана диаграмма развертывания подсистемы технологической подготовки производства.
Рис. 8. Диаграмма развертывания подсистемы технологической подготовки производства
В основе подсистемы также задействована простейшая двухуровневая клиент-серверная архитектура, это обеспечивает ряд преимуществ:
- отсутствие дублирования кода программы-сервера программами-клиентами;
- так как все вычисления выполняются на сервере, то требования к компьютерам, на которых установлен клиент, снижаются;
- все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов, что позволяет проще организовать контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа. На рис. 9 показана уточненная диаграмма развертывания с указанием расположения компонентов подсистемы технологической подготовки производства.
Рис. 9. Уточненная диаграмма развертывания подсистемы технологической подготовки производства Таким образом показано применение методологии RUP на примере подсистемы технологической подготовки производства. Приведен набор диаграмм на языке UML для подсистемы технологической подготовки производства с точки зрения реализации с привязкой к используемым инструментам: язык программирования C#, фреймворк Windows Presentation Foundation. Показана реализация прецедентов: «Просмотр данных о доступных наименованиях оснастки», «Просмотр данных о доступных наименованиях оборудования», «Просмотр данных о наличии оснастки», «Просмотр данных о наличии оборудования». Показаны основные особенности RUP и их проявление в ходе разработки подсистемы технологической подготовки производства.
Использованные источники:
1. Виноградова М.В. Унифицированный процесс разработки программного обеспечения: учебное пособие / М.В. Виноградова, В.И. Белоусова. - Москва : Издательство МГТУ им. Н.Э. Баумана, 2015. - 80, [2] с.: ил.
2. Г. Буч, Д. Рамбо, И. Якобсон. Диаграммы UML // Язык UML. Руководство пользователя = The Unified Modeling Language Usere Guide. — 2-е. — М.: ДМК Пресс, 2006. — С. 41. — 496 с. — ISBN 5-94074-334-X.
