Основы теории систем и системного анализа

ные методы, атрибуты и методы предка наследуются «автоматически». Таким образом, классы никогда не переписываются, они только расширяются и переопределяются. Это произвело революцию в программировании, так как позволило создавать программу из готовых «кирпичиков» — библиотечных объектов. Для различных языков программирования были созданы библиотеки стандартных классов, содержащие классы стандартных визуальных компонентов — окон, меню, списков выбора, командных кнопок, кнопок выбора и т. д. Библиотечные классы компонентов, построенные на принципах прямого манипулирования, «умеют» в ответ на манипуляции пользователя мышью или ввод с клавиатуры совершать стандартные действия — вызывать соответствующие методы.

Появились средства «визуального» программирования или средства быстрой разработки приложений (RAD — Rapid Application Development), с помощью которых программист создает большую часть программы путем манипулирования мышью (передвигая на экране визуальные компоненты) и ввода свойств компонентов — соответствующий программный код генерируется автоматически. Внимание программистов переключилось с непосредственного написания программного кода на предшествующие этапы — анализ требований к будущей программе, анализ конкретной предметной области, для которой разрабатывается программа, построение концептуальной модели системы.

Эти обстоятельства привели к появлению специальной методологии проектирования информационных систем, получившей название объектно-ориентированного анализа и проектирования (ООАП), основная тенденция развития которой состоит в интеграции различных методов, обусловившей создание унифицированного языка моделирования UML (Unified Modeling Language) [48, 66]. Использование UML наиболее соответствует макетной схеме разработки программы, так как позволяет формировать совокупность связанных моделей (диаграмм), отражающих различные представления о системе, начиная от исходной диаграммы, представляющей собой наиболее общую концептуальную модель системы, заканчивая диаграммой,

199

отражающей представление физических компонентов. Регламентирующая процедура проектирования ИС на основе

UML получила название Rational Unified Process — RUP.

Эволюция инструментальных средств проектирования ИС явилась естественным продолжением эволюции всей отрасли средств разработки программного обеспечения. Современный рынок CASE-средств насчитывает сотни продуктов, обеспечивающих автоматизацию практически всех этапов жизненного цикла от анализа предметной области и определения требований до программирования и сопровождения. Так, средства верхнего уровня (Upper) позволяют формировать функциональную модель предметной области и проектируемой системы. Средние (Middle) CASE поддерживают проектирование спецификаций и структуры информационной системы. Средства нижнего (Lower) уровня поддерживают разработку программного обеспечения, включая автоматическую генерацию программного кода, тестирование, управление конфигурацией и т. д.

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

4.2.2.Технологии реинжиниринга бизнес-процессов

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

200

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

Термин «реинжиниринг бизнес-процессов» (BPR — Business process reengineering) трактуется в настоящее время двояко. Узкое определение ввел М. Хаммер, который определил реинжиниринг как «фундаментальное переосмысление и радикальное перепроектирование деловых процессов для достижения резких, скачкообразных улучшений в решающих современных показателях деятельности компании, таких как стоимость, качество, сервис и темпы» [67]. При более расширенном толковании под реинжинирингом понимается не только радикальное перепроектирование, но и постепенная реорганизация деятельности предприятия. Технология BPR включает четыре основных этапа (рис. 4.3):

1) визуализацию — разработку образа будущей компании, создание спецификации целей реинжиниринга;

2) обратный инжиниринг — создание модели существующего бизнеса, анализ построенной модели;

3) прямой инжиниринг — разработку модели нового бизнеса и систем поддержки (системы управления, информационной системы);

4) внедрение перепроектированных процессов.

Рис. 4.3. Последовательность проведения реинжиниринга

201

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

Восновном регламент проведения реинжиниринга соответствует системной последовательности принятия решений: визуализация соответствует этапу постановки целей; обратный инжиниринг — этапу анализа ситуации; прямой инжиниринг — этапу выработки решений; внедрение — этапу реализации решений системной последовательности.

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

Основным средством реинжиниринга является моделирование бизнес-процессов. На этапе обратного инжиниринга строится модель существующего бизнеса — модель «как есть» («As is»), отражающая текущее состояние системы. На этапе прямого инжиниринга строится модель нового бизнеса — модель «как должно быть» («To be»), отражающая проектируемое состояние.

Впроцессе создания модели существующего или нового бизнеса, как правило, формируется не одна, а целая серия взаимосвязанных моделей. Сначала строится так называемая внешняя (прецедентная) модель, описывающая основные бизнеспроцессы, функции (шаги процессов), окружающую среду и взаимодействие процессов с этой средой. На основе внешней модели строится внутренняя (объектная) модель, описывающая структурные элементы, участвующие в реализации биз- нес-процессов (ресурсы, средства деятельности, продукцию, исполнителей), а также их взаимодействие [68, 69].

Спектр методов моделирования довольно широк. Выделяют классы методов функционального, функционально-стои- мостного, информационного и динамического (имитационного)

202

моделирования [68, 69]. Наиболее распространенными методами формирования функциональных моделей являются IDEF0, DFD. К методам функционально-стоимостного анализа, прежде всего, относятся ABC, ABB, ABM, ARP. Из средств информационного моделирования выделяются IDEF1X, ERD. Среди методов динамического моделирования можно выделить CPN (раскрашенные сети Петри), STD (диаграммы переходов состояний). Все большую популярность приобретают объектно-ориентированные методы моделирования благодаря предоставляемым ими возможностям повторного использования типовых элементов, объединения в одном описании статических и поведенческих свойств, простоте внесения изменений. Среди объектно-ориентированных методов имеются методики и функционального, и информационного, и динамического моделирования.

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

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

темы ARIS (IDS Scheer), SPARKS (Coopers & Lybrand), G2 (Gensym) [68]. Как правило, они построены по «каркасной»

203

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

4.2.3.Технологии проектирования технических систем

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

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

204

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

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

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

205

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

Архитектура систем нового поколения должна быть открытой с тем, чтобы пользователь мог самостоятельно адаптировать САПИР под свои цели. Эта адаптация может подразумевать различные корректировки в системе — пополнение базы данных новой нормативно-справочной информацией, расширение функциональных возможностей, пополнение понятийной модели. Именно пользователь отбирает типовые решения, формирует словари понятий, специфицирует действия в типовых ситуациях, реализует графические прототипы чертежей к ним для многократного использования. «Каркас» системы в виде некоторой инвариантной программной оболочки предоставляет базовые средства для разработки и развития приложений, ориентированных на проектирование конкретных технических объектов. Наличие такой повторно используемой оболочки позволяет резко снизить себестоимость создания прикладной системы [71, 72].

4.3.Объектно-ориентированная технология системного анализа

4.3.1. Принципы разработки технологии

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

Требования к регламенту:

гибкость, простота адаптации, настройки на конкретную предметную область;

206

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

Требования к методологии моделирования:

наглядность и обозримость формируемой модели проблемосодержащей (проблеморазрешающей) системы;

использование при построении моделей опыта экспертов.

Требования к инструментальным средствам:

открытость и интегрируемость;

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

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

1. Принцип декларативности: регламент должен пред-

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

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

207

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

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

На рис. 4.4 приведены три схемы автоматизированной разработки проблеморазрешающей системы. Алгоритмическая схема (рис. 4.4, а) предполагает, что последовательность преобразований исходной информации I в конечное описание R воплощена в некоторый единый универсальный алгоритм F, выполняемый ИС. Разработчику необходимо реализовать лишь процедуру сбора информации D и реализации готового проекта W. Схема идеальна с точки зрения снижения трудоемкости процесса разработки, однако при сложных многофакторных проблемных ситуациях практически нереализуема.

Модельная схема (рис. 4.4, б) предполагает формирование декларативной модели M проектируемой системы с помощью инструментального средства. Инструментарий содержит процедуры построения модели FM, используемые разработчиком в интерактивном режиме для формирования модели системы «как есть» (As is) или «как должно быть» (To be). Непосредственно же принятие решений (с помощью соответствующих процедур FP) осуществляется самим разработчиком.

208