Основные элементы диаграммы деятельности

4.7. Классификация, примеры CASE-средств
и их характери­стика

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

· локальные CASE-средства, служащие для анализа информа­ционной системы и разработки автоматизированных рабочих мест (иногда такой подход называют «кусочной» автоматизацией), под­держивающие один-два типа моделей и методов. Примерами таких CASE-средств являются: Design/IDEF, CASE.Аналитик;

· малые интегрированные CASE-средства, используемые для создания небольших интегрированных ИС и поддерживающие не­сколько типов моделей и методов. В эту категорию попадают: AllFusion Erwin Data Modeler (прежнее название Erwin), AllFusion Model Manager (прежнее название Bpwin), Silverrun;

· средние интегрированные CASE-средства, поддерживаю­щие от 4 до 10–15 типов моделей и методов. К данному типу сле­дует отнести: Rational Rose, Designer/2000;

· крупные интегрированные CASE-средства, поддерживаю­щие более 15 типов моделей и методов. В эту разновидность входит семейство программных продуктов ARIS.

Помимо приведенной выше классификации, возможны и дру­гие классификации, например, по следующим признакам:

· по поддерживаемым подходам к проектированию – функцио­нально-ориентированные, объектно-ориентированные и ком­плекс­но-ориентированные (поддерживающие оба подхода);

· по поддерживаемым графическим нотациям построения диа­грамм – с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

· по режиму коллективной разработки проекта – не поддержи­вающие коллективную разработку, ориентированные на режим ре­ального времени коллективной разработки проекта, ориентирован­ные на режим объединения подпроектов;

· по типу операционной системы (ОС) – работающие под управ­лением Windows; работающие под управлением UNIX, и т. д.

Рассмотрим примеры наиболее распространенных CASE-средств.

К числу локальных CASE-средств можно отнести программ­ный продукт Design/IDEF (Meta Software). Наиболее эффективно применение пакета при описании и анализе деятельности предпри­ятия.

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

Основными преимуществами Design/IDEF перед другими па­кетами (например, перед Bpwin) являются: малый объем про­граммы и небольшие потребности в аппаратных ресурсах, а также доступность Design/IDEF, поскольку это средство распространяется бесплатно и его можно получить через Интернет (www.idefine.com).

4.7.1. Малые CASE-средства

К числу малых интегрированных CASE-средств относится программный продукт Silverrun американской фирмы «Silver­run_Technologies,_Inc.».

Рассматриваемое CASE-средство обеспечивает построение функциональной и информационной модели в виде диаграмм пото­ков данных и диаграмм «сущность–связь». Silverrun ориентировано на спиралевидную модель создания информационной системы.

Имеется возможность настройки на разные нотации.

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

Рис. 4.22. Взаимосвязь модулей CASE-средства Silverrun

1. Модуль построения моделей бизнес-процессов в форме диа­грамм потоков данных (BPM – Business Process Modeler) по­зволяет моделировать существующую или создаваемую инфор­мационную систему (ее функциональную часть).

2. Модуль концептуального моделирования данных (ERX – Entity-Relationship eXpert) обеспечивает построение моделей дан­ных «сущность–связь», не привязанных к конкретной реализации. ERX имеет встроенную экспертную систему, позволяющую создать мо­дель данных посредством ответов на вопросы о взаимосвязи данных. Так создается модель первичной структуры данных (PDS – Primary Data Structure). Концептуальная модель не требует норма­лизации данных, а представляет их в таком виде, в каком они су­ществуют на предприятии. Концептуальная модель передается в модуль RDM.

3. Модуль реляционного моделирования (RDM – Relational Data Modeler) позволяет создавать реляционные модели данных для конкретных СУБД. Для автоматической генерации схем баз данных используются мосты для работы с наиболее распространенными СУБД, в том числе с ORACLE, SQLBase и др. Для передачи данных средств разработки приложений имеются мосты к языкам 4-го по­коления (4GL): Delphi, SQLWindows и др.

4. Модуь репозитория рабочей группы (WRM – Workgroup Repository Manager) предназначен для хранения общей для всех разработчиков информации проекта и интеграции всех модулей Silverrun в единую систему.

Система позволяет проводить оценку бизнес-процессов по времени и стоимости. Стоимость затрат ресурсов для данного про­цесса рассчитывается как сумма произведений стоимости каждого ресурса на степень его использования процессом. Осуществляется проверка целостности диаграмм потоков данных (например, выяв­ляются процессы без имени; процессы, не соединенные с другими объектами; потоки связанные только с одним объектом). Сущест­вует однопользовательская и сетевая версии. В сетевой версии воз­можна групповая работа с моделями, хранящимися в общем сете­вом репозитории на базе СУБД ORACLE.

4.7.2. Средние CASE-средства

К числу средних интегрированных CASE-средств можно от­нести Rational Rose – семейство объектно-ориентированных CASE-средств фирмы «Rational Sofware Corporation», предназначенное для автоматизации процессов анализа и проектирования, генерации ко­дов на различных языках и выпуска проектной документации в виде диаграмм и спецификаций. Работа этого средства основана на языке моделирования UML и технологии Rational Unified Process (RUP).

В составе Rational Rose можно выделить восемь основных структурных компонентов.

Моделирование проводится как «поуровневый спуск» от кон­цептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде «диаграмм прецедентов» (Use Case Diagram). Логическая позволяет определять два различных взгляда на системы: статический и ди­намический. Статические модели представлены диаграммами клас­сов (Class Diagram) и взаимодействия объектов (Collaboration Dia­gram). Динамические модели задаются тремя типами диаграмм: деятель­ности (Activity Diagram), состояний (Statechart Diagram) и последовательности взаимодействий (Sequence Dia­gram). Физическая модель задается компонентной диаграммой (Component Diagram), описывающей распределение классов по мо­дулям, и диаграммой развертывания (Deployment Diagram).

4.7.3. Большие CASE-средства

К числу крупных интегрированных CASE-средств относится среда описания и анализа бизнес-процессов ARIS, включающая в себя методологическую основу ARIS (Architecture of Integrated Information Systems) и ее программную реализацию в виде семей­ства продуктов ARIS, разработанных компанией IDS Scheer AG.

Методология профессора Шеера рассматривает предприятие как совокупность четырех взглядов (views):

· на организационную структуру системы;

· на функции и цели системы;

· на структуру данных;

· на структуру бизнес-процессов, протекающих в системе.

Эта методика предусматривает трехфазную модель разработки системы:

· анализ и разработка требований;

· формирование спецификаций;

· реализация разработки.

Сочетание четырех взглядов по методологии профессора Шеера и трех фаз модели разработки системы иллюстрируется до­миком профессора Шеера (рис. 4.23).

Процессы, Функции, Данные и Организация являются «ком­натами» домика профессора Шеера. Главной комнатой являются Процессы, отражающие процессный подход в управлении и моде­лировании.

Рис. 4.23. Домик профессора Шеера

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

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

eEPC (expended Event-Driven Process Chain) – метод расши­ренного описания процессов под управлением событий;

ERM (Entity Relationship Model) – модель «сущность–связь» для описания структуры данных;

UML (Unified Modeling Language) – объектно-ориентиро­ван­ный язык моделирования.

Вопросы для самопроверки по главе 4

1. Охарактеризуйте CASE-технологию проектирования ИС.

2. Какие существуют принципы CASE-технологии?

3. Назовите факторы эффективности CASE-технологии.

4. В чем состоят особенности функционально-ориентированного под­хода в проектировании ИС?

5. В чем состоит особенность объектно-ориентированного подхода в проектировании ИС?

6. Перечислите свойства объектов в объектно-ориентированном под­ходе проектирования ИС.

7. Что представляет собой RAD-технология?

8. Охарактеризуйте спиральную модель создания ИС.

9. По каким признакам осуществляется классификация CASE-средств?

10. Приведите примеры функционально- и объектно-ориенти­ро­ван­ных CASE-средств.

11. Перечислите стадии и этапы создания ИС на основе CASE-техноло­гии.

12. Для чего предназначена DFD-диаграмма?

13. Охарактеризуйте классификацию методов построения моделей биз­нес-процессов.

Глава 5. ТИПОВОЕ ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

· знать содержание понятия типового элемента;

· знать особенности и экономико-математические модели проектирова­ния сервисно-ориентированной ИС и уметь использовать мате­матические программные продукты для расчетов по моделям;

· уметь проектировать систему информационной безопасности и оце­нить уровень информационной защищенности бизнес-процессов;

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

· уметь осуществлять настройку типовой ИС, используя соответствую­щие технологии конфигурирования.

5.1. Понятие типового элемента
и анализ методов типового проектирования

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

Под типовым проектным решением (ТПР)понимается про­ектное решение, представленное в виде проектной документации, включая программные модули, пригодное к многократному ис­пользованию.

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

Принципом классификации типового проектирования явля­ется степень охвата информационной системы типовым реше­нием.

В зависимости от уровня декомпозиции системы различают элементный, подсистемный и системный методы типового проек­тирования (рис. 5.1).

Рис. 5.1. Классификация методов типового проектирования

При элементном методе типового проектирования ИС в каче­стве типового элемента системы используется типовое проектное решение (ТПР) по задаче или по отдельному виду обеспечения (информационному, программному, техническому, математиче­скому, организационному). Структура типового проектного реше­ния по задаче представлена на рис. 5.2.

Достоинство элементного метода типового проектирования ИС связано с применением модульного подхода к проектированию и документированию ИС.

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

Рис. 5.2. Структура типового проектного решения по задаче

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

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

Достоинством подсистемного метода по сравнению с эле­ментным является более высокая степень интеграции типовых эле­ментов ИС.

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

· модульное проектирование;

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

· сокращение затрат на проектирование и программирование взаимосвязанных компонентов;

· хорошее документирование процессов обработки информа­ции в подсистеме.

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

В качестве примеров широко распространенных функцио­нальных ППП можно назвать: «1C:Бухгалтерия» (автоматизация бухгалтерского учета), «Фолио-Склад» (автоматизация складского учета), ИНЭК (финансовый анализ) и др.

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

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

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

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

Несомненное достоинство системного метода типового проек­тирования ИС перед подсистемным методом заключается в обеспе­чении интеграции всех компонентов за счет методологического единства и информационной, программной и технической совмес­тимости компонентов.

К недостаткам системного метода типового проектирования можно отнести то, что при параметрической настройке типовых информационных систем, таких, например, как «Галактика», «Па­рус», «БОСС» и другие, возникают проблемы привязки типового проекта к конкретному объекту управления так же, как и при под­системном подходе.

Однако в настоящее время развивается модельно-ориенти­ро­ванный подход реализации системного метода типового проекти­рования ИС, известный по применению типовых информационных систем R/З (SAP) и BAAN IV (BAAN). Особенность этого подхода заключается в конфигурировании типового проекта путем на­стройки модели типовой системы на модель предметной области (5.9).

5.2. Особенности проектирования
сервисно-ориентированной информационной системы

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

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

По данным опроса AMR Research, средние затраты компании на организацию сервисно-ориентированной информационной сис­темы составили 1,4 млн долл. В исследовании участвовали ИТ-ди­ректора из США, Германии и Китая: в этих странах рынок сер­висно-ориентированных систем растет наиболее быстро, более чем на 100% в год. В 2008 г. емкость мирового рынка сервисно-ориентированных информационных систем составил более 3 млрд долл. Средняя стоимость проекта равнялась 500 тыс. долл. Наибо­лее затратными этапами при создании сервисно-ориентированной информационной системы принято считать: приобретение про­граммного обеспечения, организацию процессного подхода к управлению и выбор варианта сервисной поддержки основных биз­нес-процессов с учетом соглашения об уровне сервисов. Большая разница в стоимости сервисов при необходимости выполнения со­глашения об уровне сервисной поддержки порождает актуальную экономическую задачу – минимизация затрат на сервисную под­держку при выполнении качественных характеристик на требуемом уровне.

Можно предложить две модели решения этой задачи: модель условной оптимизации и модель безусловной оптимизации. В мо­дели условной оптимизации требуется выполнениея условий на со­блюдение уровня показателей качества сервисов, представленных в соглашении об уровне сервисов между поставщиком и потребите­лем сервисов (Service Level Agreement, SLA) . При соблюдении этого уровня внешний экономический эффект остается постоянным и не зависящим от выбора вариантов сервисной поддержки. Выбор этого варианта влияет лишь на внутренний экономический эффект, т. е. на сокращение затрат на информатизацию. Сказанное иллюст­рируется рис. 5.3.

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

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

Рис. 5.3. Влияние варианта сервисной поддержки
на экономическую прибыль предприятия

Модель условной оптимизации выбора варианта
сервисной поддержки комплекса бизнес-процессов

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

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

Таблица 5.1