STD (State Transition Diagrams) — диаграммы переходов состояний.

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

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

 

Рис. 6. Взаимосвязь графических нотаций при структурном анализе

Нужно отметить, что для функционального моделирования наряду с DFD достаточно часто применяется и другая нотация — SADT (точнее, ее стандартизированное подмножество IDEF0)..

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

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

Сравнительный анализ этих двух методологий можно осуществить по таким параметрам:

а) адекватность средств проблеме, которая рассматривается;

б) согласованность с другими средствами структурного анализа;

в) интеграция со следующими этапами разработки (в первую очередь с этапом проектирования).

Рис. 7. Пример DFD-диаграммы

1) Адекватность. Выбор той или иной структурной методологии непосредственно зависит от предметной области, для которой создается модель. В нашем случае методологии применяются к автоматизированным системам управления предприятием, а не к системам вообще, как это предусматривается в SADT. Для задач, которые рассматриваются, DFD — вне конкуренции. На рис. 7 и.8 приведены модели требований к системе автоматизации управления предприятием, которое занимается распределением товаров под заказ.

Во-первых, SADT-диаграммы значительно менее четкие и удобные для моделирования АИСУП (сравните рис.7 и рис..8). Да, дуги в SADT жестко типизируют (вход, выход, управление, механизм). В то же время касательно АИСУП стирается смысловое отличие между входами и выходами, с одной стороны, и управлениями и механизмами — с другого: входы, выходы, механизмы и управления, являются потоками данных и/или управления и правилами их трансформации. Анализ системы с помощью потоков данных и процессов, которые их преобразуют, является более прозрачным и недвусмысленным.

 

Рис. 8. Пример SADT-диаграммы

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

2) Согласованность. Главным достоинством любых моделей является возможность интеграции их с моделями других типов. В этом случае идет речь о согласованности функциональных моделей со средствами информационного и подійного (часового) моделирования. Согласование SАDТ-модели с ЕRD и/или SТD практически невозможно или имеет тривиальный характер. В свою очередь DFD, ЕRD и SТD взаимно дополняют друг друга и являются в сущности согласованными представлениями разных аспектов одной и той же модели. В табл. 1 отражена возможность такой интеграции для DFD и SADT-моделей.

 

Таблица.1

Название	ЕRD	STD	Структурные карты
DFD	+	+	+
SADT	+	–	–

 

3) Интеграция с последующими этапами. Важная характеристика методологии — ее совместимость с последующими этапами применения результатов анализа (и прежде всего с этапом проектирования, которое идет непосредственно за анализом и опирается на его результаты). DFD могут быть легко преобразованы в модели проектирования (структурные карты) — это близкие модели. Более того, известный ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты разных видов, что обеспечивает логический и безболезненный переход от этапа анализа требований к проектированию системы. С другой стороны, неизвестны формальные методы преобразования SADT-диаграмм в проектные решения АИСУП.

3.1.2. Структурное проектирование

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

1) Модуль состоит из множества операторов языка программирования, записанных последовательно.

2) Модуль имеет имя, по которому на него можно ссылаться как к единственному фрагменту.

3) Модуль может принимать и/или передавать данные как параметры в последовательности вызова или связывать данные через фиксированные ячейки или общие области.

Во время структурного проектирования выполняются два вида работ:

1) проектирование архитектуры АИСУП, которая включает разработку структуры и интерфейсов ее компонентов (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;

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

При этом происходит расширение модели требований:

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

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

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

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

Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт отвечают модулям и областям данных, потоки отражают межмодульные вызовы (в том числе циклические, условные и параллельные). Межмодульные связки по данным и управлению также моделируются специальными узлами, привязанными к потокам, стрелками указываются направления потоков и связей. Фундаментальные элементы структурных карт Константайна стандартизированы ИВМ, ISO и АNSI.

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

3.2. Объектно-ориентированный подход

3.2.1. Объектно-ориентированные методы анализа

Важное место в разработках АИСУП занимают объектно-ориентированные методологии, основанные на объектной декомпозиции предметной области, которая представляется в виде совокупности объектов, которые взаимодействуют между собой с помощью передачи сообщений. Данный подход не является противопоставлением структурному подходу, более того, фрагменты методологий структурного анализа (а именно его базовые модели: DFD, ЕRD и SТD) используются при объектно-ориентированном анализе для моделирования структуры и поведения самих объектов.

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

Объекты и классы организуются с соблюдением таких принципов:

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

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

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

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

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

· объектной модели, которая отражает иерархию классов, которые связаны общностью структуры и поведения и отражают специфику атрибутов и операций каждого из них (при этом одной из базовых нотаций объектной модели является диалект ЕRD);

· динамической модели, которая отражает временные аспекты и последовательность операций (при этом достаточно часто используют SТD);

· функциональной модели, которая описывает потоки данных (с использованием DFD).

Основными недостатками объектно-ориентированных методологий являются такие:

· отсутствие стандартизации в отрасли программотехники, которая рассматривается (например, для представления объектов и взаимосвязей между ними);

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

3.2.2. Объектно-ориентированное проектирование

Если методы структурного проектирования имели целью упрощение системной разработки на основе алгоритмического подхода, то объектно-ориентированные методы решают аналогичную задачу, используя описания классов и объектов, то есть четкие средства объект­но-ориентированного программирования. Г. Буч определил объектно-ориентированное проектирование как «методологию проектирования, которое сочетает в себе процесс объектной декомпозиции и приемы представления как логической и физической, так и статической и динамической моделей системы, которая проектируется».

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

На этапе проектирования используются следующие диаграммные техники:

· унаследованные от этапа анализа требований и такие, которые развиваются на этапе проектирования, диаграммы классов и диаграммы объектов, которые являются основой статической логической модели;

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

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

 

3.3. Процессно-ориентированный подход

3.3.1. Реинжиниринг бизнеса как основапроцессно-ориентированного подходак созданию информационных систем

Современный подход к управлению предприятием основывается на конвергенции управленческих и информационных технологий. Классика теории современного менеджмента — Хаммер, Чампи, Давенпорт, Джонсон, Моррис, Брандон и другие, — сходятся во мнении, что автоматизированное управление строится на других принципах, чем управление предприятиями в предкомпьютерную эпоху, и требует коренной перестройки всей системы управления. Процесс внедрения информационной системы в организации тесно связан с перестройкой самой системы управления — оптимизацией организационной структуры, процессов и функций, которые описывают взаимодействие звеньев этой структуры, а также с изменением мотивации персонала.

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

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

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

Бизнес-процессы — это деловые, административные, технологические процедуры функционирования предприятия, к которым принадлежат: документооборот, управление финансовыми, материальными потоками, персоналом, организационно хозяйственными и технологическими процессами, процессами проектирования изделий и т.п. Анализ и оптимизация бизнес-процессов ради достижения компанией стратегических целей и есть реинжиниринг, который выполняется с помощью анализа внутренней среды предприятия. Его методологической основой является системный и структурный анализ, теория управления большими системами, а также методы управления качеством, промышленная инженерия и тому подобное. Соответствующая разработка методологии позволила превратить реинжиниринг в инженерный процесс (подчеркивается определением!), поддерживаемый инструментами и технологиями проектирования деловых процессов. Сначала рассматривается существующая система управления предприятием: выявляются расходные центры, формируются модели: структурные, функциональные (процессные), модели данных, а также комплексные — «как есть» и «как должно быть». Затем составляется план мероприятий по переходу с состояния «как есть» в состояние «как должно быть» и при необходимости проектируется информационная система, которая повышает эффективность функционирования предприятия.

 

4. САSЕ-ТЕХНОЛОГии — ИНСТРУМЕНТАРИЙ ПОДДЕРЖКИ ЖИзненного ЦИКЛа ИНФОРМАЦИОННЫХ СИСТЕМ

Практически ни один серьезный проект по созданию АИСУП не осуществляется без использования САSЕ-средств. Саsе (Computer-Aided Software / System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем, поддержанную комплексом взаимосвязанных средств автоматизации. Саsе — это инструментарий для системных аналитиков, разработчиков и программистов, который заменяет им бумагу и карандаш компьютером для автоматизации процесса проектирования и разработки программного обеспечения.

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

Кроме автоматизации методологий и, как следствие, возможности применения современных методов системной и программной инженерии Саsе имеют такие основные преимущества:

1) улучшают качество системы, которая создается, при помощи средствах автоматического контроля (прежде всего контроля проекта);

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

3) ускоряют процесс проектирования и разработки;

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

5) поддерживают развитие и сопровождение разработки;

6) поддерживают технологии повторного использования компонентов разработки.

Сейчас существует два поколения Саsе. Средства первого поколения предназначены для анализа требований, проектирования спецификаций и структуры системы, и является первой технологией, адресованной непосредственно системным аналитикам и проектировщикам. Они включают средства для поддержки графических моделей, проектирования спецификаций, редактирования словарей данных, и концентрируют внимание на первоначальных шагах проекта — системном анализе, определении требований, системном проектировании, логическом проектировании БД. Средства второго поколения предназначены для поддержки полного жизненного цикла разработки. В них в первую очередь используются средства поддержки автоматической кодогенерации, а также обеспечивается полная функциональная поддержка для создания графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации, а также информации, относительно управления проектированием; построения прототипов и моделей системы; тестирования, верификации и анализа сгенерированных программ; генерации документов с проекта; контроля на соответствие стандартам по всем этапам ЖЦ.

Ниже сжато характеризуются основные функциональные возможности САSЕ-средств.

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

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

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

3) Интеграция средств. На основе репозитария осуществляются интеграция САSЕ-средств и распределение системной информации между разработчиками. При этом возможности репозитария обеспечивают несколько уровней интеграции: общий интерфейс пользователя по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представлений фаз ЖЦ, передачу данных и средств, между аппаратными платформами.

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

5) Прототипирование. Важную роль в автоматизации ранних этапов ЖЦ играют возможности поддержки прототипирования. Саsе позволяет строить быстрые прототипы системы, которая дает возможность на ранних этапах разработки оценить, насколько будущая система устраивает заказчика и насколько «дружественная» она будущему пользователю.

6) Генерация документации. Вся документация из проекта генерируется автоматически на базе репозитария (как правило, на базе требований соответствующих стандартов). Бесспорное преимущество Саsе заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитарии. Известно, что при традиционных подходах к разработке АИСУП документация больше запаздывает, а ряд модификаций вообще не находит в ней отражения.

7) Верификация проекта. Саsе обеспечивает автоматическую верификацию и контроль проекта на полноту и возможность на ранних этапах разработки, которая влияет на успех разработки в целом.

8) Автоматическая кодогенерация. Кодогенерация осуществляется на основе репозитария и позволяет автоматически построить порядка 80—90% объектных кодов или текстов программ языками высокого уровня. При этом различными САSЕ-пакетами поддерживаются практически все известные языки программирования, однако чаще всего как целевые языки выступают Совоl, C и Аdа.

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