Анализ практики проектирования программного обеспечения АСУП. Часть 2

автор публикации: Мадорская Ю.М.,
к.т.н., доцент СПбГПУ,

Основные регламенты проектирования ПО АСУП и область их применения

Наиболее известные регламенты, используемые при проектировании ПО АСУП, включающие требования к структуре и содержанию проектных данных, можно условно разделить на следующие категории:

  • каркасные модели архитектуры;
  • методологии разработки;
  • методы анализа и проектирования.

Данное разделение условно, так как наиболее известные представители этих методов нельзя однозначно соотнести с той или иной категорией. Разработчики практически любого метода проектирования АСУП стремятся в дальнейшем довести его до уровня методологии, согласованно определяющей все процессы разработки системы. Они дополняют данный метод процессами или интегрируют в какую-либо существующую методологию. То, с какой из приведенных категорий разработчики соотносят свой метод, зачастую отражает лишь популярность той или иной аббревиатуры во времена разработки метода.

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

При разработке автоматизированных систем в РФ часто используется комплекс стандартов ГОСТ серии 34, содержащий наиболее полный состав требований, на основании которых может быть выполнена разработка ИО и ПО автоматизированной системы любого класса. Данный регламент можно отнести к методологиям разработки, так как он содержит не только структуру требований к системе, но и описывает процессы, связанные с созданием и сопровождением АС.

Основной документ, описывающий структуру и содержание требований к АС — ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Центральным разделом данного документа является раздел «Требования к системе», он включает  требования к системе в целом, требования к функциям (задачам), выполняемым системой.

Среди методологий разработки программного обеспечения можно отметить широко известный, однако трудно применимый на практике RUP (Rational Unified Process) – унифицированный процесс разработки программного обеспечения любого класса и методологию MSF (Microsoft Solution Framework), продвигаемую таким крупным разработчиком ПО как Microsoft. Обе методологии содержат требования к структуре проектных данных.

При разработке более узкого класса автоматизированных систем —  а именно АСУП, для структурирования проектных данных также находят применение различные архитектурные каркасы (architecture framework или enterprise architecture framework).

Перевод понятия architecture framework наиболее корректно раскрывает Соснин П.И. в своей книге, посвященной архитектуре автоматизированных систем [37]: «в искусственном интеллекте с типовыми темами связывают понятие фрейма (frame). Если типовая тема сопровождает определённую работу (work), то её логично называть «framework». Фреймы класса, а значит и frameworks, принято представлять семантическими структурами, состоящими из узлов и связей между ними. Узлы фрейма соответствуют определённым «понятиям», а связи – отношениям между «понятиями». Концептуальные образования типа «framework» являются типовым нормативным средством (нормативными концептуальными схемами) для представления архитектур АС».

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

Стандарт IEEE 1471 Recommended Practice for Architecture Description of Software-Intensive Systems [66], посвященный практике описания архитектуры АС, рекомендует объединять такие схемы в представления, соответствующие точкам зрения заинтересованных в разработке АС лиц. Стандарт не определяет сами представления и схемы.

В данном стандарте отмечается необходимость использования архитектуры системы, в том числе для таких задач как: 

  • анализ альтернативных проектов системы;
  • планирование перепроектирования системы, внесения изменений в ее организацию;
  • сопровождение, эксплуатация, управление конфигурациями и внесение изменений в систему [37].

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

Наиболее известными разработками, на которые ссылаются как на архитектурные каркасы, являются: 4+1 View, The Open Group Architecture Framework, (TOGAF) Federal Enterprise Architecture Framework (FEAF), Open Distributed Processing — Reference Model (RM-ODP), Department of Defence Architecture Framework (DoDAF) и Zachman Architecture Framework  [97].

Важно отметить, что на практике понятие архитектурного каркаса в области разработки АСУП объединило системы описаний различных классов, касающихся архитектуры АСУП. Так, например, модель Захмана более точно может быть определена как таксономия, архитектурный каркас TOGAF — как процесс, а FEA – как методология создания архитектуры предприятия [95].

Детальное описание ИО и ПО АСУП основывается на двух известных парадигмах проектирования – структурной и объектной. Методы проектирования, такие как SADT, DFD, ERD, STD, UML,  могут использоваться  как для логического проектирования, так и для описания требований на верхнем уровне – уровне бизнес-процессов. Однако практика и семинары разработчиков от различных предприятий показывают, что известные методы структурного и объектного анализа  с трудом применимы для детального анализа и описания бизнес-процессов, так эта задача  требует  расширенного набора категорий.

Поэтому отдельную нишу занимают развивающиеся специализированные методы моделирования бизнес-процессов, имеющие в основе структурный подход, но ориентированные на описание бизнес-процессов предприятия и потому выделяющие такие категории, как ресурсы или участники процесса, а также позволяющие описывать нелинейный алгоритм выполнения бизнес-процесса. Актуальными примерами таких методов являются EPC и BMPN.

Также при проектировании АСУП применяются комплексные методы анализа и проектирования, включающие разнообразные средства моделирования системы. Наиболее известными комплексами являются IDEF и ARIS. IDEF содержит порядка десяти стандартов, из которых лишь часть проработана и еще меньшая часть интенсивно используется на практике. ARIS же является методологией и инструментальной средой, содержащей нотации моделирования на все случаи жизни, из которых лишь небольшой процент используется практиками.

Редко применяются при разработке АСУП, но являются значимыми с точки зрения перспективы развития методов проектирования, в том числе для АСУП, методы формальной спецификации требований. Одним из обязательных условий широкого распространения метода проектирования среди реальных проектировщиков, работающих на производстве, на мой взгляд, является наличие удобной графической нотации. Среди таких методов можно  отметить SDL и LePUS3. Первый получил достаточно широкое распространение при проектировании телекоммуникационных систем, но как средство описания алгоритмов выполнения функций системы применим и для проектирования АСУП, в то время как последний интересен  с точки зрения выбранного минимального набора категорий и построенных на них правил семантического контроля ошибок.

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

Профессиональная система для проектирования программного обеспечения, моделирования и генерации ТЗ

;-)Любое копирование и публикация материала допускается только с письменного разрешения автора.
Для ссылки правильно использовать:
Мадорская Ю. М., Метод оценки сложности модификации программного обеспечения АСУП: дис. … канд. техн. наук: 05.13.06/ Мадорская Юлия Михайловна; Санкт-Петербургский государственный политехнический университет; науч. рук. Курочкин М. А. — СПб., 2011. — 205 с. : ил.- Библиогр.: с. 138-148.

Аббревиатуры

  • АСУП — Автоматизированная Система Управления Предприятием
  • ИО — информационное обеспечение
  • ПО — программное обеспечение 

Литература

[37] Соснин П.И. Архитектурное моделирование автоматизированных систем: учебное пособие / П. И. Соснин. – Ульяновск: УлГТУ, 2008. – 147 с. 

[97] Tang A., Jin Y., Han J., Nicholson A. Predicting Change Impact in Architecture Design with Bayesian Belief Networks // Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, 2005.  – P.  67-76. 

[95]  Sessions R.   A Comparison of the Top Four Enterprise-Architecture Methodologies  // MSDN 2007 URL: http://msdn.microsoft.com/en-us/library/bb466232.aspx#eacompar_topic9.

Читать предыдущую часть:  Анализ практики проектирования программного обеспечения АСУП. Часть 1

 

Присоединиться в facebook или linkedin

Комментарии

комментарии

Комментарии закрыты.