Примеры разработанных и реализованных программ

Настоящая статья посвящена сравнительному анализу широко распространенных нотаций моделирования производственных процессов и проектирования автоматизированных информационных систем. Рассматриваемыми в рамках данной работы стандартами являются BPMN и UML.

Помимо проведения теоретического анализа, основанного на обобщении сведений о рассматриваемых стандартах, было осуществлено проектирование информационной системы выбранного объекта автоматизации. В качестве объекта моделирования рассматривалась больничная система, а автоматизируемым процессом является документооборот.

В ходе анализа проведен обзор различного программного обеспечения для работы с унифицированным объектно-ориентированным языком и нотацией BPM. Выбор средств разработки в заданной области сделан в пользу систем ArgoUML и Bizagi Studio. При использовании выбранных программных продуктов были спроектированы аналогичные друг другу информационные системы, а также автоматически сгенерированы соответствующие веб-приложения. Указана связь различных диаграмм в данных нотациях. Разработанные прототипы систем и технологии рекомендовано применять в учебных целях, однако после доработки, включающей в себя оптимизацию исходного кода и последующую калибровку и апробацию, они могут быть использованы в реальных условиях.

Крутая Java программа за 10 минут! Изучение JavaFx (Java GUI) на практике

автоматизация
информационная система
визуальное проектирование
1. Ларман К. Применение UML 2.0 и шаблонов проектирования / К. Ларман. – М.: Вильямс, 2002. – 624 с.

2. Объектно-ориентированный анализ и проектирование / Г. Буч, Р.А. Максимчук, М.У. Энгл и др.; пер. с анг. Д. Клюшина. – М.: Вильямс, 2010. – 720 с.

3. ArgoUML // Официальный сайт ПО ArgoUML [Электронный ресурс]. – URL: http://argouml.tigris.org (дата обращения: 02.08.17).

4. Plone // Официальный сайт ПО PLONE [Электронный ресурс]. – URL: https://plone.org (дата обращения: 02.08.17).

5. Object Management Group // Официальный сайт организации Object Management Group [Электронный ресурс]. – URL: http://www.omg.org (дата обращения: 02.08.17).

6. Спиричева Н.Р. Практическое применение методов объектно-ориентированного проектирования при построении информационной системы // СВЧ-техника и телекоммуникационные технологии: Материалы 26-ой Международной Крымской конф. (Севастополь, 4–10 сент. 2016 г.). – Севастополь, 2016 – С. 568–575.

В настоящее время автоматизированные системы различного характера активно используются в различных сферах человеческой деятельности. Уже несколько десятков лет наблюдается тенденция роста спроса на использование информационных систем и различных вспомогательных программно-аппаратных комплексов, представляющих набор инструментов для реализации различных методологий и нотаций проектирования. Как следствие, стремительно возрастает как количество различных программ, на базе которых создаются информационные системы, так и их сложность.

Наибольшее распространение при этом получают готовые решения, предлагаемые компаниями 1С или SAP (Systems, Applications and Products in Data Processing), а также системы моделирования процессов в различных нотациях, на которых базируются программные средства проектирования. Подавляющее большинство современных программ позволяют осуществлять автоматическую генерацию программного кода спроектированной информационной системы, что позволяет получать готовый продукт, реализованный, как правило, в форме веб-приложения. При этом открытым остается вопрос качества генерируемого кода, его понятности и читабельности.

Выполняем тестовое задание на Junior Python разработчика с зарплатой 70000р | PDF в MP3

Наиболее широко распространены следующие нотации: стандарты IDEF (Integration Definition for Function Modeling), в частности IDEF0 и IDEF3, диаграммы потоков данных DFD (Data Flow Diagram), унифицированный язык моделирования UML (Unified Modeling Language) и нотация BPMN (Business Process Modeling Notation), применяемая для моделирования бизнес-процессов.

В настоящее время стандарт IDEF0 считается устаревающим и наиболее часто используется только лишь при описании системы в рамках предпроектного исследования.

Основной целью работы являлось исследование допустимости применения стандартов разного уровня абстракции для решения аналогичных задач.

В рамках проводимого анализа была поставлена задача проектирования АСОИУ (автоматизированной системы обработки информации и управления), основного процесса документооборота для регистратуры больницы, осуществляемого с помощью программных средств моделирования различных нотаций.

Для этого были произведены сопоставление и анализ стандартов UML и BPMN. Помимо теоретического анализа было проведено практическое сравнение нотаций на примере двух систем проектирования для заданного объекта автоматизации. Таким образом, ключевым методом исследования является сравнение различных этапов проектирования информационных систем в разных нотациях на примере двух программ, реализующих работу с этими стандартами.

Выбор данной предметной области обусловлен тем, что она имеет достаточно строгую и упорядоченную структуру, но при этом ее внутренние процессы не являются стандартными. При этом вышеуказанные стандарты для проектирования информационных систем в выбранной сфере, как правило, не используются.

В качестве основных критериев сравнения выбраны параметры, которые наиболее точно определяют качество и адекватность проектируемой модели, а также степень ее соответствия реальной системе, доступности, понятности и практической полезности. К таким критериям относятся, прежде всего, выразительная мощь стандарта визуального проектирования, структурированность, возможность создания готовой информационной системы, ее практического применения, удобство, скорость разработки и внедрения и т.д.

UML – согласно одному из определений – язык графического описания для объектного моделирования процессов, в частности производственных, а также бизнес-процессов, системного проектирования, процессов разработки различных систем, программного обеспечения, а также описания и отображения организационных структур [1].

UML является открытым стандартом, использующим визуальные графические обозначения для проектирования абстрактной модели системы, рассматривая ее с точки зрения конструктивного описания. При этом система рассматривается как набор взаимосвязанных сущностей – объектов [1].

Технология визуального моделирования предоставляет возможность упрощенной и наглядной работы со сложными системами, позволяя более детально рассматривать как систему в целом, так и ее отдельные компоненты.

Основным преимуществом унифицированного языка является то, что он, прежде всего, является объектно-ориентированным, в результате чего методы описания результатов анализа и проектирования системы структурно близки к методам непосредственного программирования на современных объектно-ориентированных языках [2].

Вторым плюсом применения визуальных моделей при проектировании АСОИУ является то, что они позволяют организовать эффективное взаимодействие между участниками процесса анализа и автоматизации системы: заказчиками, аналитиками и разработчиками.

BPMN (Business Process Modeling Notation) – спецификация, содержащая графическую нотацию описания бизнес-процессов на диаграммах, называемых BPD (Business Process Diagram). Данная нотация, подобно прочим, призвана обеспечить взаимопонимание между всеми участниками процесса анализа и автоматизации системы [5].

Нотации UML и BPMN не являются взаимоисключающими. Несмотря на идентичность некоторых функций, схемы процессов в этих нотациях отличаются по визуальному представлению информации.

Основным отличием данных стандартов является то, что UML рассматривает систему в виде взаимосвязанных объектов – классов, образующих ее, и их взаимодействия, в то время как в BPMN система описывается на более высоком абстрактном уровне – уровне бизнес-процессов. Главным в данной нотации являются процессы, а не объекты [5].

Следует отметить, что сравнение данных методологий уже неоднократно производилось. По результатам проведенных исследований отмечалось, что в плане выразительной мощности оба стандарта приблизительно одинаково эффективны. Однако, как уже было упомянуто, BPMN является более высокоуровневой нотацией, рассматривающей систему с точки зрения основного процесса. Это заключает в себе определенный минус, поскольку описание организационной структуры и модели данных затрудняется.

Однако на сегодняшний день существуют BPMS (Business Process Modeling System), позволяющие описывать не только процессы организации, но также структуру и модель данных.

Выбор средств разработки

На сегодняшний день существует большое разнообразие программного обеспечения для работы с рассматриваемыми стандартами.

В ходе работы был проведен сравнительный анализ существующего программного обеспечения. По результату анализа выбор был сделан в пользу open-source системы ArgoUML. Данная система является кроссплатформенной, иными словами может работать практически на всех платформах [3].

Среди BPMS выбор был сделан в пользу системы Bizagi. Данная BPM-система направлена на моделирование, исполнение, автоматизацию и анализ бизнес-процессов.

Основной ее особенностью среди многих прочих BPMS является возможность описания модели данных для будущей информационной системы.

При проектировании АСОИУ выбранного к рассмотрению объекта первоначально была разработана действующая модель с помощью UML. По данной модели была осуществлена генерация программного кода и получено работоспособное приложение автоматизации документооборота медицинского учреждения.

Следующим шагом было осуществлено проектирование аналогичной системы средствами BPMN системы Bizagi.

Обе реализованные системы являются работоспособными. Следует отметить, что поскольку моделирование объекта автоматизации производилось упрощенно, разрабатываемые модели не включали в себя отражение специфичных функций, присущих системе. За счет этого можно было явно проследить параллели различных диаграмм нотаций UML и BPMN.

При проектировании информационной системы в среде ArgoUML был создан проект, содержащий две стандартные для UML диаграммы: классов и автоматов (состояний).

Рис. 1. Диаграмма классов

Рис. 2. Диаграмма состояний

Рис. 3. Схема документооборота

Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами, абстрагируясь от предметной области и работая исключительно с сущностями, реализуя принцип объектно-ориентированного программирования. Полученная схема является моделью данных будущего приложения (рис. 1).

Эта диаграмма является основным уровнем описания структуры организации и работы системы [2].

Диаграмма состояний – это один из способов детального описания системы в определенные различные состояния и переходов между ними [2] (рис. 2).

В рассматриваемом примере для реализации системы оборота медицинской карты данных достаточно использования этих двух диаграмм [6, 7].

Субъектами – участниками процесса документооборота являются: регистратор, сестра приемного отделения, врач приемного отделения, диспетчер отделения, лечащий врач, патологоанатом (рис. 3) [6].

По окончанию проектирования двух диаграмм проект был экспортирован в формат XMI (XML Metadata Interchange – стандарт обмена метаданными с помощью языка расширенной разметки XML), и с помощью системы Plone было сгенерировано готовое приложение [4]. Полученное веб-приложение представляет собой интерфейс для взаимодействия с базой данных.

Далее было спроектировано аналогичное приложение средствами Bizagi Studio. Первым шагом была создана диаграмма процесса в нотации BPM (рис. 4).

Для выбранной предметной области можно четко проследить связь этой диаграммы и диаграммы состояний нотации UML. Субъекты, взаимодействующие в данной системе (роли), отражены на «дорожках» процесса.

Описанные функции субъектов в диаграмме состояний UML находят отражение в блоках задач и условных переходах. Процесс можно поделить на несколько крупных блоков: Регистрация, Осмотр, Лечение и Выписка.

Наиболее значимым при проектировании информационной системы, помимо моделирования процесса, является второй шаг разработки в среде Bizagi Studio – создание модели данных будущего приложения (рис. 5).

8. Примеры программ, реализующих рассмотренный алгоритм

Курсовая работа оформляется в виде пояснительной записки объемом 20-25 страниц машинописного текста, включая иллюстрации, рисунки, таблицы и тексты программ.

1. Титульный лист;
2. Задание на дипломное проектирование;
3. При необходимости перечисленные разделы могут быть дополнены другими разделами, Содержание. Включает наименование всех разделов, подразделов, пунктов (если они имеют наименование) и заключение с указанием номеров страниц, с которых начинаются эти элементы пояснительной записки. Каждый заголовок записывают с новой строки, причем перед нумеруемыми частями пояснительной записки ставят их номер. Перечень сокращений, условных обозначений, символов, единиц и терминов. Принятые в пояснительной записке малораспространенные сокращения, условные обозначения, символы, единицы и специфические термины должны быть представлены в виде отдельного списка. Если сокращения, условные обозначения, символы, единицы и специфические термины повторяются в пояснительной записке менее трех раз, отдельный список не составляют, а расшифровку дают непосредственно в тексте пояснительной записки при первом упоминании. Перечень должен располагаться столбцом. Слева в порядке использования приводят сокращения, условные обозначения, символы, единицы и термины, справа — их детальную расшифровку. Введение. Во введении нужно кратко охарактеризовать возможные области использования разрабатываемых программ применительно к направлению обучения студента. Перечислить задачи, решаемые в работе. Список использованных источников. Список должен содержать сведения об источниках, использованных при составлении пояснительной записки. В список следует включать все виды использованной литературы: монографии, учебники, справочники, журналы, статьи, диссертации, техническая документация, описания программных продуктов, стандарты, технические условия, авторские свидетельства и патенты, каталоги и т.п. Список следует располагать в порядке появления ссылок на источники в тексте пояснительной записки и нумеровать арабскими цифрами с точкой. Пояснительная записка должна быть написана хорошим языком без грамматических и семантических ошибок; текст не должен допускать различных толкований, не следует употреблять для одного и того же понятия различные термины. Страницы текста пояснительной записки и включенные в записку иллюстрации, таблицы и распечатки с ЭВМ должны соответствовать формату А4. Допускается представлять иллюстрации, таблицы и распечатки с ЭВМ на листах формата А3. Пояснительная записка должна быть выполнена машинописным способом или с применением печатающих и графических устройств вывода ЭВМ на одной стороне листа белой бумаги через полтора интервала (38-40 строк по 60-64 символа в строке). Для пояснительных записок, выполненных на печатающих и графических устройствах вывода ЭВМ, шрифт Times New Roman, кегль 14. Допускается представление пояснительной записки в рукописном виде. В этом случае почерк должен быть разборчивым. Рекомендуется использовать черные чернила или пасту. Текст пояснительной записки представляется, соблюдая следующие размеры полей: левое — не менее 30 мм, правое — не менее 10мм, верхнее — не менее 15 мм, нижнее — не менее 20 мм. Рамки вычерчивать не надо. Вне зависимости от способа выполнения пояснительной записки качество напечатанного текста и оформления иллюстраций, таблиц, распечаток с ЭВМ должно удовлетворять требованию их четкого воспроизведения. Вписывать в отпечатанный текст записки отдельные слова, формулы, знаки допускается только черными чернилами или пастой, при этом плотность вписанного текста должна быть максимально приближена к плотности основного изображения. Наименования структурных элементов «СОДЕРЖАНИЕ», «ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ И ТЕРМИНОВ», «ВВЕДЕНИЕ», «ЗАКЛЮЧЕНИЕ», «СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ» служат заголовками структурных элементов пояснительной записки. Заголовки структурных элементов пояснительной записки и ее разделов следует располагать в середине строки без точки в конце и печатать прописными буквами, не подчеркивая. Заголовки подразделов и пунктов следует начинать с абзацного отступа и печатать с прописной буквы, не подчеркивая, без точки в конце. Если заголовок включает несколько предложений, их разделяют точками. Переносы слов в заголовках не допускаются. Расстояние между заголовками структурных элементов и разделов пояснительной записки и текстом должно быть не менее 3-4 интервалов. Пункты и подпункты разделов общетехнического характера следует начинать печатать с абзацного отступа. Страницы пояснительной записки следует нумеровать арабскими цифрами, соблюдая сквозную нумерацию по всему тексту записки. Номер страницы проставляют в правом верхнем углу без точки в конце. Титульный лист включают в общую нумерацию страниц записки. Номер страницы на титульном листе не проставляют. Иллюстрации и таблицы, расположенные на отдельных листах, и распечатки с ЭВМ включают в общую нумерацию страниц пояснительной записки. Иллюстрации, таблицы и распечатки с ЭВМ на листе формата А3 учитывают как одну страницу. Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами. Разделы пояснительной записки должны иметь порядковую нумерацию и обозначаться арабскими цифрами с точкой, например, 1.1, 1.2, 1.3 и т. д. Пункты должны иметь порядковую нумерацию в пределах раздела или подраздела. Номер пункта включает номер раздела и порядковый номер подраздела или пункта, разделенные точкой, например: 1.1, 1.2, 1.3 или 1.1.1., 1.1.2., 1.1.3. и т.д. Номер подпункта включает номер раздела, подраздела, пункта и порядковый номер подпункта, разделенные точкой, например: 1.1.1.1., 1.1.1.2., 1.1.1.3. и т.д. Если раздел или подраздел имеет только один пункт или пункт имеет один подпункт, то нумеровать пункт (подпункт) не следует. Иллюстрации — это образная информация, которая дополняет вербальную информацию пояснительной записки. Основные требования к иллюстрациям — наглядность, образность, семантическая значимость. Иллюстрации (чертежи, графики, схемы, диаграммы, фотоснимки) следует располагать в пояснительной записке непосредственно после текста, в котором они упоминаются впервые, или на следующей странице. На все иллюстрации должны быть даны ссылки в записке. Чертежи, графики, диаграммы, схемы, помещаемые в записке, должны соответствовать требованиям государственных стандартов ЕСКД. Иллюстрации должны иметь название, которое помещают над иллюстрацией. При необходимости под иллюстрацией помещают поясняющие данные (подрисуночный текст). Иллюстрация обозначается словом «Рис.», которое помещают после поясняющих данных. Иллюстрации следует нумеровать арабскими цифрами порядковой нумерацией в пpеделах всей записки. Если в записке только дна иллюстрация, ее нумеровать наследует и слово «Рис.» под ней не пишут. Иллюстрацию следует выполнять на одной странице. Если иллюстрация не умещается на одной странице, можно переносить ее на другие страницы, при этом название иллюстрации помещают на первой странице, поясняющие данные — к каждой странице и под ними указывают «Рис…, лист». Цифровой материал должен оформляться в виде таблиц. Таблицу следует располагать в пояснительной записке непосредственно после текста, в котором она упоминается впервые, или на следующей странице. На все таблицы должны быть ссылки в записке. Таблицы следует нумеровать арабскими цифрами порядковой нумерацией в пределах всей записки. Номер следует размещать в левом верхнем углу над заголовком таблицы после слова «Таблица». Пояснение значений символов и числовых коэффициентов следует приводить непосредственно под формулой в той же последовательности, в которой они даны в формуле. Значение каждого символа и числового коэффициента следует давать с новой строки. Первую строку пояснения начинают со слова «где» без двоеточия. Уравнения и формулы следует выделять из текста в отдельную строку. Выше и ниже каждой формулы или уравнения должно быть оставлено не менее одной свободной строки. Если уравнение не умещается в одну строку, оно должно быть перенесено после знака равенства (=) или после знаков плюс (+), минус (-), умножения (x), деления (:) или других математических знаков. Формулы в пояснительной записке следует нумеровать порядковой нумерацией в пределах всей записки арабскими цифрами в круглых скобках в крайнем правом положении на строке. Если в пояснительной записке только одна формула или уравнение, их не нумеруют. Ссылки Ссылки на источники следует указывать порядковым номером по списку источников, выделенным двумя косыми чертами. Наряду с общим списком допускается приводить ссылки на источники в подстрочном примечании. Ссылки на разделы, подразделы, пункты, подпункты, иллюстрации, таблицы, формулы, уравнения, перечисления, приложения следует указывать их порядковым номером, например: «. в разд. 4», «. в подпункте 2.3.4.1, перечисление 3», «. по формуле (3)», «. в уравнении (2)», «. на рис. 8», «. в приложении 6». Если в пояснительной записке одна иллюстрация, одна таблица, одна формула, одно уравнение, одно приложение, следует при ссылках писать «на рисунке», «в таблице», «по формуле», «в уравнении», «в приложении». Литература:

1. Иванова Г.С. Основы программирования: Учебник для вузов.-М.: Изд-во МГТУ им. Н.Э.Баумана, 2001;
2. Бураков М.В. Основы работы в MATLAB: учебное пособие/ М.В. Бураков .- ГУАП.СПб., 2006;
3. Васильев Ф.П. Численные методы решения экстремальных задач. Учебное пособие для студ. ВУЗов — М.,НАУКА 1982, 552 с., [Шифр 519.6/8,В-19]
4. Волков Е.А. Численные методы: учебное пособие — М., Наука, 1982,254 с.;
5. Самарский А.А. Введение в численные методы. Учебное пособие для Вузов, — М., Наука,1987,288 с.,;
6. Мудров А.Е. Численные методы для ПЭВМ на языках Бейсик, Фортран, Паскаль. — Томск, МП «Раско»,1992,406 с.;
7. Дудник В.М., Карпова Т.С., Плющева Л.В. Документирование программного обеспечения. Методические указания для курсового проектирования. -Л., ЛИАП,1986.

Источник: studfile.net

Пример разработки программы, реализующей расчетную методику

Пример разработки программы, реализующей расчетную методику

1 Постановка задачи

1.1 Описание задачи

Разработать программу для расчета массы тела.

Исходные данные для расчета:

1. плотность материала (сталь, стекло, дерево);

2. вид тела (шар, куб, конус);

3. геометрические параметры тела (диаметр, ребро, высота, диаметр основания).

Исходные данные вводятся пользователем в интерактивном режиме, при расчете выводятся промежуточные результаты, окончательные результаты расчета должны сохраняться в текстовом файле.

1.2 Расчетная методика

Расчет выполняется в два этапа:

1) расчет объема тела в зависимости от вида тела а) шар

2) расчет массы тела через объем и плотность

2 Разработка программы

2.1 Создание проекта

1) создайте новый проект;

(центр рабочего стола)

4) сохраните весь проект File > Save All. В диалоговом окне на сохранение модуля формы Save Unit1 As укажите имя файла модуля ufrmMain.

5) в диалоговом окне на сохранение проекта Save Project1 As укажите имя файла проекта RaschetMas.

6) Таким образом, мы сохранили весь проект. На данном этапе он состоит из одной формы (форма и ее модуль) и файла проекта.

7) запустите проект на выполнение

2.2 Реализация расчетной методики

Расчетную методику оформим в виде модуля. Это позволит отделить логику расчета от интерфейсной части программы.

1. создайте модуль

2. сохраните модуль File > Save под именем uMetodika

Для хранения данных необходимо создать соответствующие переменные и пользовательские типы.

Создание типов и переменных:

1. создайте в интерфейсной части модуля блок описания типов type и поместите в него перечислимые типы материала тела TMaterial и вида тела TTelo

2. создайте в интерфейсной части модуля (interface) после блока описания типов блок описания переменных var и поместите в него переменные:

1) массив (array) названий материалов NazvMaterial

2) массив (array) названий тел NazvTelo

3) переменную Material типа TMaterial

4) переменную Telo типа TTelo

5) переменные Razmer1 и Razmer2 типа Real (вещественное число), которые для разных тел будут интерпретироваться как геометрические параметры тел

6) переменные Obiem и Massa типа Real (вещественное число)

7) массив Plotnost

Расчетные формулы реализуем в виде подпрограмм. Т.к. результатами формул являются скалярные величины, то удобно использовать для этих целей подпрограммы-функции.

1. создайте в интерфейсной части модуля (interface) после блока описания переменных заголовки функций:

1) функция расчета объема тела fObiem (параметрами являются вид тела и геометрические параметры)

2) функция расчета массы тела fMassa (параметрами являются материал и объем тела)

2. создайте в части реализации модуля (implementation) после блока описания переменных следующие функции:

1) функцию расчета объема шара fObiemShar

2) функцию расчета объема куба fObiemKub

3) функцию расчета объема конуса fObiemKonus

4) функцию расчета объема тела fObiem, которая в зависимости от вида тела, вызывает соответствующие функции расчета объема шара, куба и конуса

5) функцию расчета массы тела fMassa

2.3 Разработка интерфейса программы

Расчет в соответствии с заданием будет проводиться по этапам. Кроме двух расчетных этапов (расчет объема и расчет массы) необходимо реализовать этапы ввода исходных данных и вывод результатов расчета (протокола расчета).

Для отображения этапов хорошо подходит компонент постраничного отображения PageControl, каждая страница которого будет содержать отдельный этап расчета.

Кроме этого программа должна содержать меню, панель инструментов, строку подсказки (статусную строку) и справку.

1. поместите на форму компоненты

1) главное меню MainMenu (Standard)

2) панель инструментов ToolBar (Win32)

3) список иконок ImageList (Win32)

4) статусную строку StatusBar (Win32)

Источник: vunivere.ru