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е характеризуется тем, что сопровождается проект, а не программные коды. Средства реинжиниринга и реверсивного инжиниринга позволяют продуцировать схемы системы из ее кодов и интегрировать получение схемы в проект, автоматически обновлять документацию во время замены кодов, автоматически изменять спецификации при редактировании кодов и т.п.