CC BY
46
Смирнов Е.В. ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ ПРОЕКТИРОВАНИЯ АИС С ПРИМЕНЕНИЕМ ИНТЕГРИРОВАННОГО ПРОГРАММНОГО КОМПЛЕКСА
Не будет преувеличением утверждать, что наиболее сложной проблемой проектирования является процесс формализации предметной области. Сложные системы, по возможности, нужно анализировать «изнутри». Хорошим примером здесь может послужить процесс проектирования АИС (автоматизированной информационной системы) для ВУЗа. Поскольку аналитик легко может поставить себя на место любого участника системы, он получает огромное преимущество при построении модели системы. Другим примером послужит процесс проектирования модели взаимодействия частиц в ядерной физике, который осложнен недостатком информации об изучаемом явлении (проблемы измерения, эксперимента и многие другие).
Но даже в случае полной информации о предметной области проблема формализации имеет место, так как существует в определенном смысле барьер (в лучшем случае граница) между ученым (предметником) и инженером (тем, кто разрабатывает АИС). В [1] подчеркивается, что «возможность отчуждения профессиональных знаний от их носителей определяется возможностью формализации этих знаний».
Общая схема процесса моделирования может быть представлена как на рисунке 1, где показано направление формализации объекта моделирования. Знания и опыт предметной области должны быть переданы от «носителя» к инженеру, непосредственно создающему АИС. Для осуществления этой передачи необходима определенная помощь, нужно промежуточное звено, связывающее два противоположных начала. Противоположность заключается в различном подходе к моделированию: для ученого модель подгоняется под действительность, а для инженера действительность подгоняется под модель [3].
£ предметник
аналитик
предметная
область
АИС
Рис.1. Процесс моделирования АИС
Промежуточным звеном в проектировании становится аналитик. Он совместно с предметником вырабатывает (описывает существующую) структуру системы в виде взаимосвязанных логических единиц. Распространенной практикой, получившей огромную популярность, стало моделирование IDEF0 - IDEF3 -DFD. На основе разработанной модели инженер вместе с аналитиком вырабатывают объектную модель, подходящую для стадии разработки. Таким образом, аналитик должен разбираться как в предметной области так и в вопросах реализации (например, в принципах объектно-ориентированного программирования).
Аналитики для построения функциональной модели чаще всего используют CASE средства, реализующее функциональное моделирование IDEF - BPWin и ERWin [3]. Основные преимущества - наглядность представления, возможность многократной декомпозиции, открытость технологии. Кроме того указанные средства автоматизации открывают новые возможности для обработки данных модели.
В роли инженера чаще выступает архитектор или менеджер ИТ-отдела. Его задачей является выявление из функциональной модели объектов информационного обмена, информационных каналов и данных, циркулирующих в системе, а также систематизация и классификация объектов информационной системы. Инженерам понятнее и ближе объектно-ориентированное моделирование на UML. Приложений, реализующих моделирование UML достаточно много, но наибольшее распространение получили Rational Rose и Visio.
Люди, непосредственно осуществляющие разработку, - программисты - склонны не использовать никаких CASE средств и платформ, кроме среды разработки (например, Visual Studio). Следовательно, в задачи архитектора (менеджера) входит разделение всего реализуемого функционала на малые части и распределение их между участниками проекта.
Известно, что чем больше трансформаций претерпевает информация, тем с большей вероятностью она изменится. Другими словами: чем больше этапов формализации, тем менее адекватная модель получается. На рисунке 1 показан необходимый минимум участников процесса формализации. Но стоит обратить внимание на количество переходов на пути формализации: (предметная область) - (предметник) -
(аналитик) - (функциональная модель) - (аналитик) - (архитектор) - (объектная модель) - (программист) - (частное представление).
С целью сокращения числа трансформаций информации и повышения эффективности процесса проектирования предлагается следующая методика проектирования, ориентированная на сопряжение с этапом разработки.
Аналитик совместно с предметником строят функиональную структуру системы в нотации IDEF0. IDEF позволяет декомпозировать функции с необходимой степенью детализации, но, в то же время, не регламентирует, когда следует остановиться. Предлагается декомпозировать функции, пока не удастся добиться модели, в которой каждая функция имеет ровно один механизм. Это всегда выполнимо: всегда можно указать кто (исполнитель) или что (устройство) выполняет данную функцию; если механизмов для некоторой функции более одного, то эту функцию можно декомпозировать методом отделения одного из механизмов от остальных. В случае трудностей отделения можно воспользоваться альтернативной декомпозицией надфункции.
Целью данного подхода является возможность сопоставления бизнес-процессов функциям разрабатываемой АИС на некотором языке программирования. Смысл сопоставления заключается в следующем. Будем рассматривать функцию языка программирования (процедуру) как образ бизнес-функции, декомпозированной по описанному принципу.
На рисунке 2 показано типичное соответствие. Сама функция соответствует бизнес процессу, входные дуги (или ресурсы) - входным аргументам функции, выходные дуги функционального блока - выходным значениям (во многих языках программирования, например в C#, синтаксисом разрешено более одного выходного параметра). Управление в нотации IDEF будет соответствовать различного рода ограничениям, накладываемым на процесс вычисления. Примером ограничений являются ОДЗ (область допустимых значений аргументов), ОЗФ (область допустимых значений функции), параметры условных переходов и циклов.
а} ат условия, параметры циклов, ОДЗ, ОЗФ (управление)
аргументы (ресурсы) х, , F(x,,... xj функция (бизнес-процесс) выходные значения (продукт) f
хп ,
J С > исполнитель, класс (механизм)
Рис.2. Соответствие бизнес-процесса программной функции
Отдельного внимания заслуживает соответствие дуги механизма. Будем сопоставлять ее с объектом (классом языка программирования), к которому следует отнести данную функцию. Поскольку функция может принадлежать только одному классу, то и механизм у каждого декомпозированного бизнес-процесса должен остаться строго один.
Полученная декомпозиция может получиться достаточно разветвленной и сложной для восприятия. Для учета и обработки данных модели следует пользоваться CASE средством с развитым API (Application Programming Interface) - для возможности создания пользовательских надстроек. Под пользовательскими надстройками понимается дополнительный функционал, подключаемый в виде плагина или библиотеки расширения.
Дополнительный функционал (в условиях отсутствия стандартной возможности) требуется для выделения (и пометки) из всего множества потоков - потоков информации, а также присвоения каждому механизму - имени реализующего класса. На рисунке 3 показан фрагмент диаграммы в нотации IDEF0, на котором звездочками (*) отмечены информационные потоки, а курсивом подписаны имена реализующих классов, к которым отнесены соответствующие функции. Подобные дополнения разрешены благодаря тому, что IDEF является открытым стандартом.
Рис.3. Диаграмма в расширенной нотации IDEF0
На рисунке 3 блок «деятельность производственной службы» имеет два механизма. С целью присоединения функции к определенному классу необходимо декомпозировать данный блок. При дальнейшей декомпозиции может оказаться, что определенный блок чрезмерно детализирован, и тогда понадобится объединить существующие блоки воедино. Многократные преобразования структуры проектируемой системы немыслимы без применения инструментального средства.
Современная АИС постоянно находится в движении, т.е. подвержена структурным и функциональным изменениям. Это явление связано со следующими фактами. Во-первых, не стоит на месте научнотехнический прогресс, и рождаются новые информационные технологии, появляющиеся на смену старых, обладающие лучшими качествами, лишенные недостатков старых. Естественно, что желательно, а в отдельных случаях необходимо, внедрять новые технологии в существующие системы. Во-вторых, в ходе испытаний пилотных или функционирования реализованных проектов зачастую появляется необходимость в новых функциях АИС. Кроме того, отдельные функции могут оказаться невостребованными. В последнем случае может оказаться, что необходимо проводить реинжиниринг системы (перестроение с изменением концепции) [4].
Любое изменение в концепции или модели проектируемой системы неизбежно влечет ряд изменений в программных компонентах АИС. На практике это чаще всего означает доработку существующего или разработку нового программного комплекса АИС.
Хорошей практикой в тоже время является поддержание разработчиками программного кода в соответствии с принципами рефакторинга [2]. Рефакторинг призван прояснить структуру программного кода, сделать код более ясным для понимания и, следовательно, для поддержания. Согласно принципам рефакторинга программные процедуры не должны быть слишком длинными (включать слишком много операций) - такие процедуры должны быть разбиты на множество малых (по аналогии с бизнес-процессами -декомпозированы). Другим правилом рефакторинга является избегание слишком сложного взаимодействия между классами: если определенная процедура обращается к полям другого класса чаще, чем к своим
(«завистливая функция»), то последнюю следует переместить в другой класс.
Постепенное повышение адекватности разрабатываемой модели (за счет возможности многократной декомпозиции одного бизнес-процесса) соответствует процессу «чистки» программного кода. По сути, графическая модель в нотации IDEF0 соответствует программной модели (коду) АИС, а движение в структуре отражается на обеих моделях.
Следовательно, для повышения эффективности разработки АИС в условиях существования модели IDEF0 целесообразно автоматически генерировать программный код, моделирующий общую структуру системы (на основе принадлежности функций определенным классам).
Таким образом, с целью более эффективного проектирования АИС необходимо создать автоматизированное инструментальное программное средство, выполняющее следующие функции:
Построение (экспорт и импорт в BPWin) диаграмм в нотации IDEF0. Простое переключение между контекстными диаграммами.
Осуществление декомпозиции листового блока. Осуществление объединения нескольких блоков.
Возможность пометки информационных потоков. Возможность применения фильтров для частичного представления.
Кластеризация функций - по классам и компонентам.
Генерация программного кода структуры АИС.
Современный уровень развития информационных технологий и технологий проектирования позволяет разработать подобный инструмент. Весь перечисленный функционал, например, можно реализовать в виде плагина для среды разработки Visual Studio. Учитывая вечную актуальность эффективного проектирования, разработчики платформенных решений, реализовав подобный продукт, нашли бы большой спрос на него среди аналитиков и менеджеров, занимающихся вопросами проектирования.
ЛИТЕРАТУРА
1. Королёв А.Л. Компьютерное моделирование. - М.: БИНОМ, 2010.
2. Фаулер М. Рефакторинг: улучшение существующего кода. - Пер. с англ. - СПб: Символ-плюс,
2003. - 432 с., ил.
3. Черемных С. В. Моделирование и анализ систем. IDEF-технологии: практикум / С.В. Черемных,
И.О. Семенов, B.C. Ручкин. - М.: Финансы и статистика, 2006. - 192 с.: ил. - (Прикладные информационные технологии).
4. Щенников С.Ю. Реинжиниринг бизнес-процессов. Экспертное моделирование, управление, планирование и оценка. - М.: «Ось-89», 2004. - 288 с.
