Способ автоматизированного проектирования приложений
Изобретение относится к способам автоматизированного проектирования приложений с использованием моделирования бизнес-процессов. Техническим результатом является автоматизация проектирования приложений из компонентов программного обеспечения (ПО) и спецификаций. В способе: выполняют семантический анализ текста спецификации и выделяют термины, определяющие элементарные требования и связи между ними, а также логический порядок между этими связями, который задают как функцию от входных и выходных параметров компонентов ПО, для каждого элементарного требования выделяют пертинентные термины в этом элементарном требовании и формируют семантическое описание на основе выделенных пертинентных терминов, осуществляют доступ к по меньшей мере одному хранилищу компонентов, содержащему сохраненные семантические компоненты ПО, определяют, для каждого выделенного элементарного требования, путем сравнения его семантики и семантических описаний компонентов ПО, один или более программных компонентов, способных выполнить упомянутое выделенное элементарное требование, и объединяют определенные один или более компонентов ПО. После этого выделенные элементы процессов, а также дополнительные функциональные и нефункциональные требования, подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации. 5 з.п. ф-лы.
Изобретение относится к способам автоматизированного проектирования приложений, в частности, с использованием моделирования бизнес-процессов (БП), из имеющихся в наличии компонентов программного обеспечения (ПО) и спецификаций, и целесообразно к применению, в особенности, при разработке государственных услуг (ГУ), оказываемых в электронном виде.
ГУ как БП представляет собой совокупность взаимосвязанных мероприятий или работ (действий), реализующих определенную административную процедуру в соответствии с установленными правилами. В простейшем случае такой БП сводится к подготовке запроса на оказание ГУ, вызову соответствующего сервиса ведомства, предоставляющего ГУ, и направлению ответа заявителю в том или ином виде. На практике же ГУ устроены, как правило, сложнее, и каждое из действий БП представляет собой, в свою очередь, один или несколько бизнес-подпроцессов. Например, подготовка запроса может предусматривать получение документов из различных ведомств, проверку информации заявителя и принятия решения об оказании ГУ или отклонении запроса, а также информирование заявителя.
Для разработки ГУ могут быть использованы различные методологии и нотации моделирования БП, из которых наибольшее распространение получила Business Process Model and Notation (BPMN) [1]. Преимуществом BPMN является выразительная нотация моделирования БП, понятная как техническим специалистам, так и бизнес-пользователям. Большое практическое значение имеет и то, что BPMN, в отличие от других нотаций, позволяет (с учетом известных ограничений) создавать исполняемые модели БП. По этим причинам именно на основе BPMN для регионов России был разработан и успешно апробирован макет Системы подготовки государственных услуг (СПГУ) [2].
Однако, несмотря на положительный опыт использования, BPMN поддерживает не все аспекты моделирования бизнес-деятельности, а только те, которые применимы к простейшим БП. В частности, за ее рамками остаются следующие аспекты, моделирование которых в отдельных случаях может потребоваться в бизнес-целях:
- определение организационных моделей и ресурсов;
- моделирование функционального деления;
- модели данных и информации;
- моделирование стратегии;
- моделирование бизнес-правил.
Неспособность отражения всех аспектов бизнес-деятельности присуща, как известно, не только BPMN, но и другим подобным методологиям моделирования БП [3]. Это привело в последние годы к разработке более совершенных инструментов, в основу которых положен принцип семантического аннотирования, изначально применявшийся для аннотирования текстов, а в дальнейшем и для семантической разметки веб-сервисов [4]. Семантически аннотированные модели БП получили название семантических бизнес-процессов, а управление ими - Semantic Business Process Management (SBPM) [5].
Позволяя одновременно сохранить преимущества BPMN и добиться семантической иноперабельности исполняемой модели БП, за рамками SBPM остается весьма важная проблема полноты и непротиворечивости семантического описания, которое базируется на наборе моделей, описывающих предметную область БП.
Ближайшим к изобретению является способ автоматического построения приложений из спецификаций и из имеющихся в наличии компонентов, выбранных с помощью семантического анализа, который наиболее полно отвечает всему комплексу требований к моделированию относительно сложных БП, каковыми являются, в частности, ГУ [6].
Этот способ позволяет автоматизировать проектирование приложений из компонентов ПО и спецификаций, тексты которых содержат, по меньшей мере, одну из следующих характеристик процессов деятельности: описания, формальные модели или исполняемые модели. Его начинают с выполнения семантического анализа текста спецификации и выделения терминов, определяющих элементарные требования и связи между ними, а также логического порядка между этими связями. Связями и логическим порядком между связями, таким образом, определяют общую структуру спецификации, причем логический порядок между связями задают как функцию от входных и выходных параметров компонентов программного обеспечения, сконфигурированных для выполнения операций для исполнения элементарных требований, определенных выделенными терминами.
Далее для каждого элементарного требования выделяют пертинентные термины в этом элементарном требовании и формируют семантическое описание на основе выделенных пертинентных терминов, причем упомянутое описание представляет семантику упомянутого элементарного требования. Затем осуществляют доступ к, по меньшей мере, одному хранилищу компонентов, содержащему сохраненные семантические компоненты ПО, причем каждый компонент ПО связывают с семантическим описанием, содержащим, по меньшей мере, один пертинентный термин, определяющий каждую публичную операцию, которую упомянутый компонент ПО способен выполнять.
В заключение определяют, для каждого выделенного элементарного требования, путем сравнения его семантики и семантических описаний компонентов ПО, один или более программных компонентов, способных выполнить упомянутое выделенное элементарное требование, и объединяют определенные один или более компонентов ПО, согласно упомянутой общей структуре спецификации, чтобы спроектировать приложение.
Однако этот способ обладает ограниченными возможностями описания проектируемого приложения вследствие того, что в нем реализован исключительно функциональный подход (требования), а значительно расширяющий его возможности процессный подход (описания, формальные и исполняемые модели процессов деятельности) остался неохваченным. Качество проектирования приложений посредством него может оказаться недостаточным из-за того, в частности, что в пертинентных терминах могут содержаться противоречия и неоднозначности, а путей их разрешения с последующей доработкой семантического описания компонент ПО или спецификаций с повторным выполнением семантического анализа не предусмотрено. Кроме того, в спроектированном приложении может быть не обеспечена интероперабельность - способность к его взаимодействию с другими приложениями.
Задачей изобретения является устранение указанных недостатков, а его техническим результатом является получение способа автоматизированного проектирования приложений с расширенными возможностями и повышенным качеством проектирования приложений по отношению к известным способам.
Указанная задача решена тем, что этап семантического анализа текстов спецификаций с описаниями процессов деятельности начинают с анализа описаний, в ходе которого выделяют следующие элементы процессов: состав, порядок и взаимосвязь операций, их исполнители, входные и выходные данные, а также дополнительные функциональные и нефункциональные требования. После этого выделенные элементы процессов, а также дополнительные функциональные и нефункциональные требования, подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации.
На этапе семантического анализа текстов спецификаций с формальными моделями процессов деятельности, после анализа описаний процессов, производят анализ их формальных моделей, в ходе которого выделяют следующие элементы таковых: состав, порядок и взаимосвязь операций, их исполнители, входные и выходные данные, а также дополнительные функциональные и нефункциональные требования, после чего выделенные элементы формальных моделей процесса деятельности, а также дополнительные функциональные и нефункциональные требования подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации.
На этапе семантического анализа текстов спецификаций с исполняемыми моделями процессов деятельности, после анализа описаний и формальных моделей таковых, производят анализ исполняемых моделей, в ходе которого выделяют следующие их элементы: состав, порядок и взаимосвязь операций, их исполнители, входные и выходные данные, а также дополнительные функциональные и нефункциональные требования, после чего выделенные элементы исполняемой модели процесса деятельности, а также дополнительные функциональные и нефункциональные требования подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации.
Тем самым задача изобретения решается, поскольку, наряду с функциональным подходом, оказывается реализован и процессный подход -описания, формальные и исполняемые модели процессов деятельности - вследствие чего возможности способа расширяются.
В ряде случаев целесообразно, после этапа доступа к хранилищу компонентов и перед этапом определения одного или более программных компонентов, выполнять этап определения противоречий и неоднозначности пертинентных терминов, а также их разрешения, причем в ходе выполнения этого этапа целесообразно проводить доработку семантического описания компонентов ПО.
В других случаях целесообразно, после этапа доступа к хранилищу компонентов и перед этапом определения одного или более программных компонентов, выполнять этап определения противоречий и неоднозначности пертинентных терминов, а также их разрешения, причем в ходе выполнения этого этапа целесообразно проводить доработку спецификации с повторным выполнением семантического анализа.
Тем самым качество проектирования приложений, благодаря доработке в необходимых случаях семантического описания компонентов ПО, или доработке спецификации с повторным выполнением семантического анализа, повышается.
На этапе определения противоречий и неоднозначности пертинентных терминов, а также их разрешения, целесообразно проводить синтез обобщенной онтологии, объединяющей пертинентные термины, выделенные на этапе семантического анализа, и связи между ними, после чего синтезированную обобщенную онтологию целесообразно использовать для определения противоречий и неоднозначности пертинентных терминов.
Тем самым точность определения противоречий и неоднозначности пертинентных терминов, благодаря применению синтезированной обобщенной онтологии, повышается.
Кроме того, целесообразно, чтобы способ дополнительно содержал этап, на котором, после объединения одного или более определенных, согласно общей структуре спецификации, компонентов ПО, определяют порядок выполнения операций этих компонентов в соответствии с исполняемой моделью процесса деятельности.
Тем самым, в дополнение к сборке компонентов ПО согласно общей структуре спецификации, появляется новая возможность автоматизировано определить порядок выполнения операций этих компонентов в соответствии с исполняемой моделью процесса деятельности, расширив возможности способа и повысив качество проектирования приложения, благодаря более точному заданию алгоритма его работы.
Кроме того, при синтезе обобщенной онтологии, объединяющей пертинентные термины и связи между ними, целесообразно использовать метамодели контента, определяющие формальную структуру, позволяющую обеспечить согласованность терминов.
Тем самым интероперабельность приложения гарантированно обеспечивается, благодаря согласованности терминов в рамках архитектуры системы, в которую входит проектируемое приложение.
ИСТОЧНИКИ ИНФОРМАЦИИ
1. http://www.omg.org/spec/BPMN/2.0/About-BPMN/
2. Акаткин Ю.М. Предоставление электронных услуг в регионах России и услуги: система подготовки // Информационное общество, 2013, №4, с. 29-40.
3. Федоров И.Г. Преодоление дефицита выразительной способности языков моделирования бизнес-процессов // Бизнес информатика, 2016, №3(37), с. 62-71.
4. http://www.w3.org/TR/sawsd1/
5. http://oro.open.ac.uk/23145/1/sbpm-sws-for-business-process.pdf
6. Патент России на изобретение RU 2495480 С2.
1. Способ автоматизированного проектирования приложений из компонентов программного обеспечения и спецификаций, тексты которых содержат по меньшей мере одну из следующих характеристик процессов деятельности: описания, формальные модели или исполняемые модели, включающий этапы, на которых выполняют семантический анализ текста спецификации и выделяют термины, определяющие элементарные требования, связи между терминами, определяющими элементарные требования, и логический порядок между этими связями, причем связи и логический порядок между связями определяют общую структуру спецификации, при этом логический порядок задают как функцию от входных и выходных параметров компонентов программного обеспечения, сконфигурированных для выполнения операций для исполнения элементарных требований, определенных выделенными терминами; выделяют, для каждого элементарного требования, пертинентные термины в этом элементарном требовании и формируют семантическое описание на основе выделенных пертинентных терминов, причем упомянутое описание представляет семантику упомянутого элементарного требования; осуществляют доступ к по меньшей мере одному хранилищу компонентов, содержащему сохраненные семантические компоненты программного обеспечения, причем каждый компонент программного обеспечения связывают с семантическим описанием, содержащим по меньшей мере один пертинентный термин, который определяет каждую публичную операцию, которую упомянутый компонент программного обеспечения способен выполнять; определяют, для каждого выделенного элементарного требования, путем сравнения семантики этого элементарного требования и семантических описаний компонентов программного обеспечения, один или более программных компонентов, способных выполнить упомянутое выделенное элементарное требование, и объединяют определенные один или более компонентов программного обеспечения, согласно упомянутой общей структуре спецификации, чтобы спроектировать приложение, отличающийся тем, что этап семантического анализа текстов спецификаций с описаниями процессов деятельности начинают с анализа описаний, в ходе которого выделяют следующие элементы процессов: состав, порядок и взаимосвязь операций, их исполнители, входные и выходные данные, а также дополнительные функциональные и нефункциональные требования, после чего выделенные элементы процессов, а также дополнительные функциональные и нефункциональные требования подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации; на этапе семантического анализа текстов спецификаций с формальными моделями процессов деятельности, после анализа описаний процессов, производят анализ их формальных моделей, в ходе которого выделяют следующие элементы таковых: состав, порядок и взаимосвязь операций, их исполнители, входные и выходные данные, а также дополнительные функциональные и нефункциональные требования, после чего выделенные элементы формальных моделей процесса деятельности, а также дополнительные функциональные и нефункциональные требования подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации; на этапе семантического анализа текстов спецификаций с исполняемыми моделями процессов деятельности, после анализа описаний и формальных моделей таковых, производят анализ исполняемых моделей, в ходе которого выделяют следующие их элементы: состав, порядок и взаимосвязь операций, их исполнители, входные и выходные данные, а также дополнительные функциональные и нефункциональные требования, после чего выделенные элементы исполняемой модели процесса деятельности, а также дополнительные функциональные и нефункциональные требования подвергают семантическому анализу совместно с функциональными и нефункциональными требованиями, содержащимися в тексте спецификации.
2. Способ по п. 1, отличающийся тем, что после этапа доступа к хранилищу компонентов и перед этапом определения одного или более программных компонентов выполняют этап определения противоречий и неоднозначности пертинентных терминов, а также их разрешения, причем в ходе выполнения этого этапа проводят доработку семантического описания компонентов программного обеспечения.
3. Способ по п. 1, отличающийся тем, что после этапа доступа к хранилищу компонентов и перед этапом определения одного или более программных компонентов выполняют этап определения противоречий и неоднозначности пертинентных терминов, а также их разрешения, причем в ходе выполнения этого этапа проводят доработку спецификации с повторным выполнением семантического анализа.
4. Способ по пп. 1, 2 или 3, отличающийся тем, что на этапе определения противоречий и неоднозначности пертинентных терминов, а также их разрешения, проводят синтез обобщенной онтологии, объединяющей пертинентные термины, выделенные на этапе семантического анализа, и связи между ними, после чего синтезированную обобщенную онтологию используют для определения противоречий и неоднозначности пертинентных терминов.
5. Способ по пп. 1, 2 или 3, отличающийся тем, что он дополнительно содержит этап, на котором, после объединения одного или более определенных согласно общей структуре спецификации компонентов программного обеспечения, определяют порядок выполнения операций этих компонентов в соответствии с исполняемой моделью процесса деятельности.
6. Способ по пп. 1, 2 или 3, отличающийся тем, что при синтезе обобщенной онтологии, объединяющей пертинентные термины и связи между ними, используют метамодели контента, определяющие формальную структуру, позволяющую обеспечить согласованность терминов.
