Рекуррентное метамоделирование в системных средах САПР

32

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Специальность: 05.13.12 - Системы автоматизации проектирования

(Информатика)

Автореферат

диссертация на соискание ученой степени доктора технических наук

Рекуррентное метамоделирование в системных средах САПР

Черткова Елена Александровна

Москва - 2008

Работа выполнена в Московском государственном университете инженерной экологии (МГУИЭ)

Научный консультант:доктор технических наук, профессор

Ретинский Валерий Степанович

Официальные оппоненты:доктор технических наук, профессор

Артамонов Евгений Иванович

доктор технических наук, профессор Солодовников Игорь Владимирович

доктор технических наук, профессор Никольский Сергей Николаевич

Ведущая организация -- ФГУП НИИ Автоматической аппаратуры им. В.С. Семенихина.

Защита состоится 26 марта 2009 г. в 14.00 часов в зале ученого совета на заседании диссертационного совета Д 212.133.03 при Московском государственном институте электроники и математики (технический университет) по адресу: 109028, Москва, Б. Трехсвятительский пер., д.3.

С диссертацией можно ознакомиться в библиотеке Московского государственного института электроники математики.

Автореферат разослан « ____ » ______________ 2009 г.

Ученый секретарь диссертационного совета

к.т.н., доцент________________ Ю.Л.Леохин

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Актуальность темы. Значимость процессов автоматизации проектирования и интенсификация работ в сфере внедрения CAD/CAM/CAE в различных отраслях промышленности предопределили появление новых технологий для создания систем автоматизированного проектирования (САПР) и подготовки производства. Важной задачей при внедрении новых технологий САПР является не только ускорение конструкторско-технологической подготовки производства, но и повышение квалификации и переподготовка персонала для эффективной эксплуатации новых технологий.

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

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

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

Эволюция программной инженерии привела к созданию технологий автоматизированного проектирования программного обеспечения - CASE-технологий (Computer Aided Software Engineering) - с соответствующими инструментальными средами разработки - CASE-системами. Инновационные CASE-технологии являются альтернативой традиционным методам разработки программных систем и направлены на снижение трудозатрат при возрастающей сложности программного обеспечения, а также придания системам свойств адаптации и гибкости в условиях платформенных и функциональных изменений. Следует отметить, что в соответствии с современными тенденциями мировой программной индустрии особое значение имеет перенос основного акцента в разработке систем с программирования на объектно-ориентированное проектирование для снижения рисков.

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

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

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

Для достижения поставленной цели в работе решаются следующие задачи:

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

разработать процедуры принятия решения по выбору типа процесса разработки подсистем САПР в условиях доступности экспертной информации;

разработать технологическую модель проектирования подсистем САПР и процедуры реализации подпроцессов;

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

выполнить системный анализ методов идентификации ключевых абстракций и механизмов области приложения и разработать на этой основе принципы концептуализации предметной области для проектных метамоделей;

идентифицировать проектные и навигационные образцы для решения задач повторного использования в метамоделях и разработать технические решения по конвертации образцов в компоненты многократного использования;

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

разработать процедурные и структурные метрики для оценки качества (практичности) визуальных прототипов графического пользовательского интерфейса подсистем, направленные на выявление проблемных элементов модельной конструкции;

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

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

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

На защиту выносятся:

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

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

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

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

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

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

Научная новизна работы:

разработаны методы проектирования обслуживающих подсистем САПР, ориентированные на CASE-технологии и отличающиеся принципами интеграции процессных стратегий, структур и проектных образцов визуальных метамоделей анализа и проектирования;

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

разработана оригинальная процедура многокритериальной оптимизации на основе метода анализа иерархий и полных парных сравнений для принятия решения по выбору процесса разработки подсистем САПР в условиях доступности экспертной информации;

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

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

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

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

Практическая значимость работы

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

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

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

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

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

многофункциональная тестовая оболочка «Модуль-Тест»;

мультимедийный программно-методический комплекс «Автоматизация делопроизводства»;

пакет тестирующих программ по дисциплинам «Делопроизводство» и «Автоматизация делопроизводства»;

мультимедийный программно-методический комплекс «Системы управления химико-технологическими процессами»;

мультимедийный программно-методический комплекс «Интегрированные системы управления делопроизводством»;

программный тренажер «Администрирование операционной системы Windows XP».

Апробация работы. Результаты работы докладывались на 18-ти международных, 10-ти всероссийских, а также межрегиональных, межвузовских, научно-практических конференциях и семинарах, в том числе: VIII, XI-XVIII Международных конференциях «Информационные технологии в образовании» (Москва, 1998, 2001-2008 гг.); II Международной выставке-конференции «Наука и образование» (Москва, 2000); XIII-XV Международных научных конференциях «Математические методы в технике и технологиях» (Казань, 2005; Воронеж, 2006; Ярославль, 2007); XII--XV Всероссийских научно-методических конференциях «Телематика» (Санкт-Петербург, 2005--2008 гг.); VI и VII Всероссийских научно-методических конференциях «Теоретические и прикладные вопросы современных информационных технологий» (Улан-Удэ, 2005, 2006 гг.); XV и XVI Международных конференциях «Применение новых технологий в образовании» (Троицк, 2005, 2006 гг.); IV и V Всероссийских научно-практических конференциях «Технологии Интернет - на службу обществу» (Саратов, 2005, 2006 гг.); VI и VII межвузовских научно-практических конференциях «Информационные технологии XXI века» (Москва, 2004, 2005 гг.); X Международной научно-практической конференции «Наука - сервису» (Москва, 2005 г.); I и II Всероссийских научно-практических конференциях «Информационные технологии в образовании и науке» (Москва, 2006, 2007 гг.).

Публикации. Основные положения диссертации отражены в 74 публикациях, в том числе в 2 монографиях, 16-ти статьях в изданиях, включенных в список ВАК РФ, и 7 свидетельствах на программные продукты отраслевого фонда алгоритмов и программ Государственного координационного центра информационных технологий Федерального агентства по образованию.

Структура и объем диссертации. Диссертационная работа включает: введение, пять глав, заключение, библиографический список из 204 наименований, 4 приложения. Основная часть диссертации изложена на 271 страницах, содержит 94 рисунка и 18 таблиц.

Связь диссертационной работы с научными программами. Диссертация выполнена в рамках Межвузовской комплексной программы «Наукоемкие технологии образования» Министерства образования и науки РФ (2001 - 2005 гг.).

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ

метамоделирование идентификация графический интерфейс

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

Первая глава диссертации посвящена постановке задач исследования и их обоснованию.

В структуре САПР различают два типа подсистем: проектирующие и обслуживающие (рис. 1).

32

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Рис. 1. Структура САПР

Проектирующие подсистемы непосредственно выполняют проектные процедуры. Обслуживающие подсистемы обеспечивают функционирование проектирующих подсистем, а их совокупность называют системной средой (или оболочкой) САПР. Типичными обслуживающими подсистемами являются:

подсистемы управления проектными данными;

инструментальные подсистемы разработки и сопровождения программного обеспечения CASE (Computer Aided Software Engineering);

обучающие подсистемы для освоения пользователями технологий, реализованных в САПР.

На основе анализа общесистемной технологии, а также существующих технологий разработки программных систем, относящихся к классу обслуживающих подсистем САПР, выявлены основные тенденции в развитии этих технологий:

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

- переход к инженерным принципам разработки программного обеспечения, реализующим концепции компонентной разработки (component-based software engineering - CBSE) и готовых коммерчески доступных компонентов (commercial off-the-shelf - COTS);

- применение принципа многомодельности, формирование совокупности связанных визуальных моделей, раскрывающих важнейшие программные решения;

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

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

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

Для формализации структур, обеспечивающих функционирование обслуживающих подсистем, на примере обучающей подсистемы для освоения пользователями технологий, реализованных в САПР, рассмотрена структурная схема соответствующего процесса управления электронным обучением. На основе системного анализа выделены основные элементы системы, а также подсистемы, объединяющие (группирующие) некоторые элементы по различным признакам (функциям, смысловому наполнению и т.д.). Полученная высокоуровневая модель определяет границы обслуживающей подсистемы с функциями обучения, обозначая внешние сущности и входные/выходные потоки данных между этими сущностями и системой, и может быть детализирована применительно к различным видам обслуживающих подсистем данного класса (рис. 2).

Рис. 2. Диаграмма потоков данных обучающей подсистемы

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

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

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

Исходя выявленных ключевых факторов качества, а также с учетом тенденций программной индустрии сформулированы требования, предъявляемые к технологии создания обслуживающих подсистем САПР:

- универсальность, высокая степень обобщенности, позволяющая применять ее для разработки приложений, принадлежащих к семейству программных продуктов рассматриваемой предметной области - обслуживающих подсистем САПР;

- базирование на основных принципах программной инженерии, лежащих в основе современных технологий разработки;

- повышение степени формализации спецификаций требований к обслуживающим подсистемам ;

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

Для удовлетворения перечисленных требований предлагаются следующие принципы создания обслуживающих подсистем САПР:

- регламентация процесса моделирования как рекуррентного - многошагового повторяемого процесса с использованием результатов (моделей) на предыдущих шагах;

- использование современных систем автоматизированного проектирования на основе объектно-ориентированных технологий;

- интегрируемость инструментальных и языковых средств, возможность их расширения, возможность распознавания модельной нотации и автоматического перевода в машинный код;

- полномасштабное отражение функциональных требований к системе в проектных моделях при формализации всей совокупности исходной информации;

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

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

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

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

Поток проведения работ по проектированию обслуживающих подсистем САПР представляется как сложная иерархическая структура от общих концепций к описаниям и моделированию метамоделей прототипов до построения приложения. В основу регламентации процесса проектирования положена фундаментальная концепция стандартизованной интегрированной модели зрелости процессов разработки программного обеспечения (Capability Maturity Model Integration -- CMMI), разработанной Институтом программной инженерии при Питтсбургском университете Карнеги-Меллона в США. В эту концепцию входят:

-- требования, определяющие описываемый процесс;

-- архитектурные и проектировочные соображения, влияющие на определение процесса;

-- реализация спроектированного процесса в условиях отдельного проекта или в рамках всей организации;

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

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

Проведен анализ обобщенных моделей технологического процесса создания программного обеспечения, основанных на архитектурном подходе, которые позволяет увидеть структуру процесса создания программного обеспечения, абстрагируясь от частных деталей отдельных его этапов. Рассмотрены классические подходы к построению технологического процесса -- каскадный, итеративный и спиральный, а также усовершенствованные модели этих подходов: RAD (Rapid Application Development), DSDM (Dynamic System Development Method), RUP (Rational Unified Process), MSF (Microsoft Solution Framework) и XP (Extreme Programming). Для сравнения процессов на основе двух характеристик -- формализованности и степени итеративности -- составлена карта процессов, на которой также выделены области стандартизованных моделей зрелости процесса разработки программного обеспеченияCMM (Capability Maturity Model for Software) и CMMI.

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

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

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

Рис. 3. Декомпозиция и иерархическое представление задачи выбора процесса разработки

Для анализа данной многокритериальной задачи принятия решений по выбору типа процесса разработки из множества альтернатив использована математическая модель:

(1)

где - множество вариантов решения, - количество уровней (), - критерии задачи, - множество отношений предпочтения экспертов на каждом уровне, - количество критериев на каждом уровне

Тогда каждый вариант решения из множества вариантов характеризуется значениями , образующего векторную оценку этого варианта . Для сравнения критериев между собой используются предпочтения , данные предпочтения формируют лица, принимающие решение (ЛПР, в нашем случае эксперты). Моделируются данные предпочтения при помощи отношения нестрогого предпочтения на : , что означает, что векторная оценка (значение вектора приоритетов) не менее предпочтительна, чем и т.д.

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

, (2)

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

Согласованность полученных результатов оценки проводится при помощи индекса согласованности (ИС) и отношения согласованности (ОС). Для обратно симметричной матрицей:

, (3)

где - максимальное собственное значение, - размерность матрицы.

Отношение согласованности ОС определялось как ОС=ИС/СИ, где СИ - значение случайного индекса согласованности для матрицы данной размерности. СИ соответствует средним индексам согласованности для сгенерированных случайным образом матриц такой же размерности. Для получения приемлемой согласованности требуется, чтобы и . Для других значений согласованности необходим пересмотр суждения экспертов.

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

, (4)

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

В табл. 1 и 2 представлены результаты расчетов глобального вектора приоритетов каждой модели процесса разработки и итогового вектора приоритетов.

Таблица 1

Значение глобального вектора приоритетов моделей процесса разработки

Каскадная модель	Спиральная модель	RAD	Итеративно-инкрементная модель
0,178	0,309	0,197	0,316
0,179	0,365	0,037	0,419
0,064	0,234	0,169	0,533

Таблица 2

Расчет итоговых векторов приоритетов по типам процессов разработки

Процессы	Глобальные приоритеты по группам критериев качества процесса	Итоговый вектор
	Группа 1	Группа 2	Группа 3
Каскадная модель	0,178	0,179	0,064	0,102
Спиральная модель	0,309	0,365	0,234	0,264
RAD	0,197	0,037	0,169	0,164
Итеративно-инкрементная модель	0,316	0,419	0,533	0,471
Вектор приоритетов групп	0,243	0,088	0,669

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

Сформированы ключевые рекомендации для инкрементно-итеративного процесса проектирования обслуживающих подсистем, направленные на обеспечение согласованного и упорядоченного моделирования проектов:

проектирование и интеграция предшествуют кодированию и тестированию систем для их визуального моделирования с адекватным отражением архитектуры до написания программного кода;

планирование итераций процесса направляется на преодоление основных рисков на ранних стадиях проекта для снижения стоимости проекта за счет устранения дефектов на более ранних стадиях разработки;

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

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

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

На рис. 4 представлена схема в виде диаграммы деятельности предлагаемого макропроцесса проектирования обслуживающих подсистем САПР.

Рис. 4. Макропроцесс проектирования обслуживающих подсистем САПР

Для практических исследований, связанных с моделированием обслуживающих подсистем САПР, выделены четыре технологических дисциплины процесса: исследование концепции и системы, моделирование предметной области, определение требований, анализ и проектирование и разработаны стратегии их реализации (рис. 5).

а)

б) в)

Рис. 5. Стратегии подпроцессов анализа линейки продуктов (а), определения требований к системе (б), анализа и проектирования системы (в)

В работе приводится описание содержания процесса проектирования обслуживающих подсистем САПР: базовых элементов моделирования (исполнители, действия, рабочие продукты) и динамических аспектов процесса (циклы, фазы, вехи процесса).

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

Детальное описание и четкая организация процесса предоставляет возможность его усовершенствования и создания основ для нормирования, расчета и оценки, что, в свою очередь, способствует улучшению качества программного продукта, соблюдению сроков и бюджета разработки.

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

-- сообщать семантику всех стратегических и тактических решений разработки;

-- обеспечивать форму представления, достаточно конкретную для восприятия человеком;

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

Таким образом, язык должен обладать мощной визуальной составляющей для построения моделей обслуживающих подсистем САПР на различных уровнях абстракции и детализации, а также декларативной семантикой для фиксации процедурного значения в форме декларативного предложения. На этом основании, а также фактора применения унифицированного процесса выбран стандартизованный унифицированный язык моделирования (Unified Modeling Language - UML).

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

В третьей главе диссертации рассматривается и обосновывается концепция рекуррентного визуального метамоделирования сложных систем - многошагового повторяемого процесса с использованием результатов (моделей) на предыдущих шагах с целью преодоления вариативных и инвариантных по отношению к процессу проблем разработки.

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

выбор моделей во взаимосвязи с подходом к решению проблемы;

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

принцип реалистичности модели для предотвращения существенных потерь при реализации системы;

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

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

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

Метод проектирования рассматривается как последовательный процесс создания объектно-ориентированных моделей, который описывает определенным образом различные стороны разрабатываемой программной системы.

Модель классов представляется кортежем:

, (5)

где каждому классу системы соответствует следующий набор элементов:

-- имя класса;

-- имя класса-предка;

-- множество наследующих классов;

-- множество операций класса, включающее в себя:

-- имя операции;

-- сигнатура операции;

-- множество типов передаваемых атрибутов.

Модель атрибутов представлена кортежем:

,(6)

где каждому атрибуту , принадлежащему классу , соответствуют:

-- имя атрибута;

-- имя класса атрибута;

-- тип атрибута;

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

Модель объектов создается на базе некоторого класса и представляет собой множество мультиобъектов и множество методов для работы с ними. Модель объектов представляет собой кортеж:

, (7)

содержащий:

-- множество имён объектов системы,

-- множество имён классов-родителей соответствующих объектов системы.

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

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

Теоретическую основу анализа составили: классическая категоризация (классификация по свойствам) и концептуальная кластеризация (классификация по понятиям). Итеративный подход к классификации предопределил процедуру конструирования иерархии классов и объектов при разработке обучающих подсистем. При этом взятая за основу определенная структура классов постепенно совершенствуется в процессе проектирования программной системы.

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

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

Метод модельного анализа проектируемых систем дополнен лингвистической составляющей. Использованы два метода лингвистического информационного анализа (ЛИА):

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

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

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

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

Схема взаимосвязи описанных методик поиска и идентификации объектов и классов представлена на рис. 6.

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

Рис. 6. Взаимосвязь методик идентификации объектов и классов

При регламентации процесса проектирования обслуживающих подсистем моделирование предметной области определено как один из начальных этапов, который необходим для выявления, классификации и формализации сведений об аспектах предметной области, определяющих свойства разрабатываемой системы. В модели предметной области должны быть отображены основные (с точки зрения моделирующего) классы понятий (концептуальные классы) предметной области. На языке Unified Modeling Language метамодель предметной области при проектировании обслуживающих подсистем предлагается представлять в виде набора диаграмм классов, на которых не определены операции.

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

На рис. 7 представлен пример метамодели предметной области обучающей подсистемы.

Рис. 7. Объектно-ориентированная метамодель предметной области для интегрированной обучающей подсистемы

(в нотации UML; русифицированная)

32

Размещено на http://www.allbest.ru//

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

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

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

создать более точную спецификацию требований по сравнению с моделью прецедентов;

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

использовать модель анализа в качестве важных исходных данных для формирования системы в ходе проектирования и реализации;

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

Для построения визуальных моделей анализа разработана концепция стереопизации классов анализа и проектирования по выделению граничных классов (Boundary), управляющих классов (контроллеров) (Control) и классов-сущностей (Entity). Эти стереотипы положены в основу типового решения «граница - управление - сущность» для метамоделей анализа и позволяют на этапе анализа разбить систему, отделяя представления от предметной области и управления, необходимого системе. В основную часть стандарта UML эти стереотипы не включены, но шаблон модели анализа в CASE-средстве IBM Rational Rose содержит классы Boundary, Control и Entity в пакете строительных блоков анализа, и его можно использовать для создания граничных классов, управляющих классов и классов-сущностей для метамоделей обслуживающих подсистем.

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

Рис. 8. Визуальная метамодель анализа обучающей подсистемы

(в нотации UML; русифицированная)

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

...