Модели бизнес процессов case средства

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

К настоящему моменту наиболее интенсивное развитие получили два главных направления применения CASE-средств.

1) BPR (business process reengineering) — перепроектирование бизнес-процессов. Под перепроектированием понимается «фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов, имеющее целью резко улучшить их выполнение с точки зрения затрат, качества обслуживания и скорости». При этом бизнес-процесс представляет собой некоторую деятельность, получающую входные данные одного или нескольких типов и выдающую результат, имеющий ценность для клиента. Например, процесс выполнения заказа на входе получает заказ и выдает в качестве результата заказанные товары. Другими словами, доставка заказанных товаров клиенту и есть та ценность, которую создает процесс.

ООП, CASE — средства

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

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

В таблице 1 приведен перечень доступных на российским рынке CASE-средств и поддерживаемые ими виды проектной деятельности.

Проектирование ИС. Анализ вакансий и обзор Case-средств.

Для моделирования бизнес-процессов обычно используется методология SADT (точнее, ее подмножество IDEF0), поддерживаемая пакетами BPWin и Design/IDEF. Однако статическая SADT-модель не обеспечивает полного решения задач перепроектирования, необходимо иметь возможность исследования динамических характеристик бизнес-процессов. Одним из решений является использование системы динамического моделирования Design/CPN, основанной на цветных (раскрашенных) сетях Петри. Фактически Design/IDEF и Design/CPN являются компонентами интегрированной методологии перепроектирования: статические SADT-диаграммы автоматически преобразуются в прообраз динамической модели, которая дорабатывается вручную и затем исполняется в различных режимах с целью получения соответствующих оценок.

Другой возможный подход реализуется пакетом Designer/2000: моделирование бизнес-процессов является первым этапом разработки системы, а соответствующая модель является основой для разработки концептуальных моделей и проектирования системы. Нотация для моделирования бизнес-процессов включает следующие элементы: базовый процесс, шаг процесса, хранилище, поток, событие и организационная единица. Для каждого элемента можно задать разнообразные количественные параметры (временные затраты, ресурсы и т. п.), а затем с помощью специальной процедуры анимации проследить поведение модели в динамике с учетом введенных параметров. Использование средств мультимедиа, включая визуализацию, видеоизображение, звуковое сопровождение и т. п., позволяет существенно повысить выразительность построенной бизнес-модели.

Следует отметить, что не существует принципиальных ограничений в использовании в качестве средства построения статических моделей бизнес-процессов и традиционных диаграмм потоков данных (DFD — data flow diagrams). Более того, в настоящий момент за рубежом доступен ряд продуктов динамического моделирования (INCOME Mobile, CPN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи перепроектирования.

Средства функционального моделирования

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

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

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

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

Наконец, в части автоматизированной поддержки моделей приблизительно 85-90% существующих CASE-пакетов поддерживают DFD и лишь 2-3% — SADT.

Средства событийного моделирования

Традиционный подход к моделированию аспектов поведения системы основывается на расширении диаграмм потоков данных за счет введения управляющих потоков (сигналов) и управляющих процессов, фактически являющихся интерфейсом между DFD и спецификациями управления, собственно моделирующими поведение. Наиболее часто спецификации управления формализуются с помощью диаграмм переходов состояний (STD — state transition diagrams), позволяющих задавать состояния различных объектов системы (например, лицевой счет может иметь состояния ОТКРЫТ, ЗАКРЫТ, ЗАБЛОКИРОВАН и т. п.), условия переходов из одного состояния в другое (как внешние по отношению к системе, так и внутренние, возникающие в самой системе), а также совершаемые при переходах действия.

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

Средства информационного моделирования

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

Выбор CASE-средств

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

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

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

3) Выбор в качестве первого опыта недорогих продуктов с учетом информации о реальных проектах, выполненных с их использованием. Например, известен ряд фирм и банков, использующих на начальных этапах проектирования автоматизированных банковских систем пакеты CASE. Аналитик для построения функциональной, а ERWin для построения информационной моделей.

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

5) Обязательная поддержка автоматической верификации на полноту и состоятельность проекта и генерации отчетов по верификации.

6) Автоматическая генерация проектной документации в соответствии с общепринятыми стандартами (отечественных заказчиков вполне удовлетворяют ГОСТы, зарубежных — DOD STD-2167A).

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

8) Для информационного моделирования — наличие средств генерации схем БД для широкого спектра СУБД, а также поддержки обратного проектирования (reverse engineering), т. е. создания информационных моделей из существующих БД.

Источник: www.osp.ru

ХАРАКТЕРИСТИКИ CASE СРЕДСТВ

§ Наличие графического интерфейса. Для представления моделей процессов CASE средства должны обладать возможностью отображать процессы в виде схем..

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

§ Гибкость применения. Эта характеристика дает возможность представлять бизнес процессы в различных вариантах, важных с точки зрения анализа. CASE средства должны позволять проводить анализ процессов и создавать модели, сфокусированные на различных аспектах деятельности предприятия.

§ Возможность коллективной работы. Анализ и моделирование процессов может требовать совместной работы нескольких человек.

§ Построение прототипов. Прототипы процессов необходимы для того, чтобы на ранних стадиях изменения процессов можно было понять, насколько процесс будет соответствовать требованиям.

§ Построение отчетов. CASE средства должны обеспечивать построение отчетов по всем моделям процессов с учетом взаимосвязи элементов. Такие отчеты необходимы для анализа моделей и определения возможностей по оптимизации. БАЗОВЫЕ ФАКТОРЫ ВЫБОР CASE СРЕДСТВ

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

Применение стандартных методологий. За счет стандартизации обеспечивается упрощение взаимодействия между CASE средствами и различными информационными системами.

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

Трудоемкость. При выборе следует учесть, сколько времени потребуется на обучение пользователей.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

CASE-система

CASE (Computer Aided Software Engineering) — средства разработки программных и организационно-управляющих систем. Они охватывают большую часть поддержки огромного числа технологий проектирования КИС: начиная с простых средств анализа и документирования и заканчивая масштабными средствами автоматизации, охватывающими весь жизненный цикл программного обеспечения.

Назначение CASE-систем

Окно программы EasyCase в среде Windows.

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

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

Компонентная база CASE-системы

В состав интегрированного CASE-средства входят следующие элементы:

• репозиторий — главное CASE-средство. Его задача — обеспечить сохранность вариантов проекта и его определенных компонентов, синхронизацию приема информации от разных разработчиков в процессе групповой разработки, проверка метаданных на полноту и непротиворечивость;
• средства разработки приложений, с использованием языков 4GL и генераторов кодов;
• средства тестирования;
• средства документирования;
• графические средства анализа и проектирования, которые дают возможность создавать и редактировать иерархически связанные диаграммы (например, DFD, ER-диаграмма и др.), создающие модели информационных систем;
• средства реинжиниринга.
• средства конфигурационного управления;
• средства управления проектом.

Классификация

В настоящее время существует классификация CASE-средств по следующим признакам:

• по типам — данная классификация демонстрирует функциональную ориентацию CASE-средств на какие-либо процессы жизненного цикла;
• по категориям – такая квалификация определяет уровень интегрированности по выполняемым функциям. Сюда относятся отдельные локальные средства, которые решают мелкие автономные задачи, комплект частично интегрированных средств, который затрагивает большую часть этапов жизненного цикла информационных систем. Также включает в себя полностью интегрированные средства, которые поддерживают весь жизненный цикл информационных систем и связанны общим репозиторием;
• по степени интегрированности с СУБД;
• по доступным платформам;
• по применяемым методологиям и моделям систем и БД.

Типовая классификация практически полностью совпадает с элементами, входящими в состав CASE-средств и состоит из следующих типов:

• верхние CASE–системы (Upper CASE) — средства анализа, которые используются для построения и анализа моделей предметной области ( BPwin (Logic Works)). В связи с тем, что эти системы соответствуют основным понятиям термина CASE, их также называют нормальными;
• средние CASE–системы (Middle CASE) — средства анализа и проектирования, корорые придерживаются более распространенные методологии проектирования и используются для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA)). Выход этих средств — спецификация архитектуры системы, составляющих и интерфейсов системы, алгоритмов и устройств данных;
• средства разработки приложений (PowerBuilder (Sybase), JAM (JYACC), Developer/2000 (Oracle), New Era (Informix Software) , Delphi (Borland), средства 4GL (Uniface (Compuware), SQLWindows (Gupta), а также генераторы кодов, которые входят в состав Vantage Team Builder, PRO-IV и отчасти в Silverrun;
• средства реинжиниринга, предназначенные для анализа программных кодов и схем баз данных и создания на их базе различного рода моделей и проектных спецификаций. Средства анализа схем баз данных и формирования ER-диаграмм являются составляющими Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В сфере анализа программных кодов наиболее широко распространены объектно-ориентированные CASE-средства, способствующие реинжинирингу программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)).
• средства проектирования баз данных, предоставляющие возможность моделировать данные и генерировать схемы баз данных, как правило, на языке SQL, для самых распространенных систем управления базами данных (например, ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE);

В состав вспомогательных типов входят средства планирования и управления проектом (SE Companion, Microsoft Project и др.), средства конфигурационного управления (PVCS (Intersolv));

• средства тестирования (Quality Works (Segue Software));
• средства документирования (SoDA (Rational Software)).

Существующие CASE-системы

• ERwin+BPwin
• Designer/2000
• Silverrun
• S-Designor
• Vantage Team Builder
• Westmount I-CASE
• CASE.Аналитик
• PRO-IV
• CASE /4/0, System Architect
• EasyCASE,
• Visible Analyst Workbench

Ссылки

• Что такоеCASE-система
• CASE: все только начинаетсяМоделированиеИнформационные технологии
• Назначение и разновидности CASE-систем
• Современные средства разработки, CASE-системы
• citforum.ru: CASE-технологии

Источник: www.tadviser.ru