Реализация продукции на основе Case-средств

Основные характеристики BPwin:

 

• Развитая методология функционального моделирования на основе IDEF0
• Мощные редакторы для описания операций, связей и вычисления затрат на выполнение работ
• Иерархическая структура диаграмм, облегчающая последовательное уточнение элементов модели
• Контекстные диаграммы для описания границ системы, области действия, назначения объектов
• Декомпозиционные диаграммы для описания особенностей взаимодействия различных процессов
• Расширенные возможности по поддержанию ссылочной целостности
• Поддержка методологии IDEF3
• Экспорт моделей в средства имитационного моделирования
• Интеграция и связь со средством проектирования баз данных ERwin (методология IDEF1X)
• Поддержка свойств, определяемых пользователем. Описание моделей может быть расширено за счет свойств, определяемых пользователем, включая мультимедийные документы.
• Интеграция с ModelMart, поддерживающим мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.
• Удобный интерфейс пользователя. В распоряжении пользователей имеется проводник, ставший привычным в среде Windows 95/NT, позволяющий легко переходить с одной диаграммы на другую простым перемещением по "дереву" проводника.
• Расширенная архитектура. BPwin поддерживает 16- и 32-х разрядные системы, позволяя организовать совместную работу для всех участников проекта.
• Автоматическая поддержка изменения размеров. BPwin поддерживает автоматическую настройку размеров диаграмм и возможность изменения масштабов изображения моделей.

 

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.

BPwin поддерживает три методологии  моделирования: функциональное моделирование  (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

BPwin имеет достаточно простой  и интуитивно понятный интерфейс  пользователя. При запуске BPwin по  умолчанию появляется основная  панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer .

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

Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические  задачи. В BPwin возможно построение смешанных  моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

 

 

1.2 Характеристика  Rational Rose

С 1998 года стала набирать силу технология Rational Rose, основанная на объектно-ориентированном подходе и на последовательно уточняющихся графических моделях.

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

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

Что может делать Rational Rose

1. Проектировать системы любой сложности
2. Давать развернутое представление о проекте в сочетании со средствами документирования (SoDA)
3. Проводить кодогенерацию
4. Проводить обратное проектирование имеющихся систем
5. Имеет открытый для дополнений интерфейс
6. Интегрируется со средствами разработки (Visual Studio)
7. Поддержка языка UML
8. Наличие средств автоматического контроля, в том числе проверки соответствия двух моделей
9. Удобный для пользователя графический интерфейс
10. Многоплатформенность
11. Интегрируемость с другими инструментальными средствами, поддерживающими жизненный цикл программных систем, в том числе со средством управления требованиями (Requisite Pro), со средствами тестирования (SQA Suite, Performance Studio), со средствами конфигурационного управления (ClearCase, PVCS).

 

Итак, что умеет делать CASE Rational Rose. Являясь объектно-ориентированным  инструментом моделирования, Rose базируется на UML (Universal Modeling Language) - универсальном  языке моделирования, который был  разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:

1. Activity diagram (диаграммы описаний технологий, процессов, функций).
2. Use case diagram (диаграммы функций).
3. Class diagram (диаграммы классов).
4. State diagram (диаграммы состояний);
5. Sequence diagram (диаграммы последовательностей действий);
6. Collaboration diagram (диаграммы взаимодействий
7. Component diagram (диаграммы компонент);
8. Deployment diagram (диаграммы топологии).

 

Для того чтобы наиболее полно покрыть  весь сегмент рынка средств проектирования и разработки, выпускается несколько  версий продукта:

 

• Rational Rose Modeler

Эта версия позволит аналитикам и  проектировщикам проводить анализ бизнес-процессов и проектировать  систему. Данная редакция, увы, не поддерживает кодогенерацию.

 

• Rational Rose Professional

Как видно из названия, это профессиональная редакция продукта. В зависимости от выбранного языка программирования позволяет выполнять прямое и обратное проектирование. Rose Professional заказывается только в определенной конфигурации (например, Rose Professional С++ или Rose Professional С++ DataModeler). Rational Rose Professional, конечно, не создает 100 % исполняемого кода. На выходе разработчик получает каркасный код информационной системы на определенном (заказанном) языке программирования, который впоследствии нужно еще программировать и программировать. Продукт нацелен и на аналитиков, и на разработчиков.

 

• Rational Rose RealTime

Версия продукта, созданная специально для получения 100 % исполняемого кода в реальном масштабе времени. Конечно, RealTime позволяет проводить прямое и обратное проектирование на языках С или С++. По заверениям разработчиков, на выходе модель автоматически компилируется и собирается в исполняемый файл. Само собой, продукт предназначен именно для разработчиков.

 

• Rational Rose Enterprise

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

 

• Rational Rose DataModeler

Это не конкретный вариант продукта, а функциональность по проектированию баз данных. Функции DataModeler входят в  состав Rose Enterprise или Professional.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Глава 2.Постороение функциональной модели деятельности мебельной фабрики ООО «Вернисаж» по методологии IDEF0

 

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

Наиболее известная и  распространенная методика моделирования  бизнес-процессов – методология IDEF0, относящаяся к семейству IDEF. Она принята в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ. IDEF0 можно использовать для моделирования широкого класса систем. Для новых систем она применяется с целью определения требований и функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам методология IDEF0 может быть использована для анализа функций, осуществляемых системой, и отображения механизмов, посредством которых эти функции выполняются.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.

 

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").

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

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

В IDEF0 различают пять типов стрелок:

Вход (input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1.5 - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны, например, на выходе - "Заполненная карта пациента". Очень часто сложно определять, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются (изменяются) ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.