Классификация case-средств

По поддерживаемым методам проектирования:

• функционально-ориентированные (BPWin)

• объектно-ориентированные (Rational Rose)

• комплексно-ориентированные

По поддерживаемым графическим нотациям:

• с жестко установленными нотациями (ERWin)

• с более свободными нотациями (visio)

По типу ОС…

По этапам ЖЦ, на от они исп-ся

• на этапе анализа и проектирования

• на этапе разработки БД (ERWin)

• на этапе управления проектом (MS Project)

• на этапе реализации (поддерживающие автоматическую генерацию кода на основе разработанного проета) (ERWin, Rational Rose)

По архитектуре

• отдельное рабочее место

• локальная сеть

• глобальная сеть

По режиму коллективной разработки

• поддерживается

• не поддерживается

2.10.13

Подход RAD (Rapid Application Development)

В последнее время широкое применение в рамках спиральной модели является RAD. Его обязательные элементы:

• небольшая команда разработчиков 2-10 чел

• короткий, но тщательно спланированный график

• повторяющийся цикл в рамках спирали с использованием прототипирования

• тесное взаимодействие заказчиком

Подход RAD хорошо использовать для относительно небольших проектов. Следование этому подходу означает обязательное применение CASE-средств и генераторов кода, сред программирования.

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

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

Функционально-ориентированная методика IDEF0

Как стандарт эта методика была разработана в 1981 году в рамках обширной программы автоматизации предприятий США, которая называлась ICAM (Integrated Computer Aided Manufacturing).

Семейство методик IDEF унаследовало название от программы – только I, DEF от definition. Последняя редакция стандарта была выпущена в декабре 1993г нац. институтом стандартизации технологии США (NIST)

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

Основные понятия:

1. Функциональный блок (Activity Box) (работа) – используется для представления конкретной ф-и в рассматриваемой системе

По стандарту имя блока – глагольная фраза. каждая из сторон блока имеет определенное начение. Леваz – вход(input), верхняя – управление (control), правая – выход (output), нижняя – механизм(mechanism)

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

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

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

Виды диаграмм IDEF0

1. Контекстная

2. Диаграмма декомпозиции

3. Диаграмма дерева узлов

4. Диаграмма только для экспозиции (FEO)

Контекстная диаграмма – в каждой модели может быть 1 и только 1 конт. диагр.

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

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

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

После декомпозиции контекстной диаграммы мы получаем диаграмму декомпозиции первого уровня и т.д.

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

Каждая из работ на диаграмме декомпозиции первого уровня может быть в свою очередь декомпозирована далее, естественно что при этом должен быть прянят порядок нумерации:

нумерация диаграмм и работ используется следующая:

диаграммы: контекстная диаграмма имеет номер A-0

декомпозиция контекстной диаграммы А0

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

Нумерация работ: Работа, которая представлена на контекстной диаграмме имеет номер А0

работы на декомпозиции нумеруются от 1: А1, А2, А3…

А1 декомпозируется на А11, А12, А13, А14…..

*рекомендуется от 3 до 7 работ на одном уровне декомпозиции

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

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

Виды внутренних стрелок:

• связь-по-входу (Output-Input) – результат одной работы является входной И для другой работы

• связь-по-управлению (Output-control) – используется когда результат доминирующей работы является управляющей для ниже стоящей работы

• обратная связь по входу (Output-Input feedback) – результат нижестоящей работы передается на вход вышестоящей, указывает на наличие цикличности

• обратная связь по управлению (Output-control feedback) – выход нижестоящей работы может являться управляющим для доминирующей, такая связь свидетельствует об эффективности какого-либо бизнес процесса,

• выход-механиз (Output-control) – по выходу получили ресурс, обеспечивающий работы нижестоящей работы.

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

9.10.13

Правила именования для разветвляющихся стрелок:

- стрелка м\б именована до разветвления. В этом случае каждая из ветвей имеет это же имя

- одна из ветвей м\б после разветвления именована иначе, для уточнения соответствующего объекта

- может отсутствовать имя до разветвления, в таком случае каждая из ветвей дложна быть именована

те же правила используются и при слиянии стрелок.

При разработке модели наряду с декомпозицией работ осуществляется и декомпозиция стрелок.

Моделирование в BPWin

в отдельном окне можно задать свойства модли и для каждого отдельного блока

туннелирование стрелок

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

При добавлении такой стрелки она появляется с квадратными скобками, что не допусается синтаксисом IDEF0. Чтобы исправить это нужно щелкнуть правой кнопкой мыши по этим скобкам и выбрать команду ArrowTunnel, после чего в окне при выборе ResolveBorderArrow стрелка мигрирует на диаграмму верхнего уровня, а при выборе Change To Tunnel

Другим примером туннелирования является случай, когда стрелка мигрирует с верхнего уровня на нижние, при чем на нижних она используется одинаково во всех работах. Тут можно на верхнем уровне поместить в туннель стрелку, чтобы она не отображалась на диаграммах более низкого уровня. Такой способ называется «не-в-дочрней-работе». Отобразится с круглыми скобками.

Диаграмма дерево узлов

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

Диаграмма только для экспозиции.

FEO – For Exposition Only

используется в модели для иллюстрации других представлений и деталей, которые не поддерживаются IDEF0, т.е. позволяют нарушить синтаксис, ибо исп-ся только как картинки и не включены в анализ синтаксиса модели. Имя диограмма FEO образуется по имени родительской работы с добавлением F после имени (А23F например).

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

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

• обе сливаемые модели должны быть открыты в BPWin

• имя модели источника, которую присоединяют к модели – цели должно совпадать с именем стрелки вызова в модели цели

• стрелка вызова должна исходить из недекомпозированной работы

• имена контекстной работы источника и работы на модели цели должны совпадать

• модель источник должна иметь пкм одну диаграмму декомпозиции

16.10.13

Каркас диаграммы

Каждая диаграмма строится на отдельном листе, который имеет граничные рамки, называемые каркасом. Верхняя – заголовок, нижняя – подвал.

Поля заголовка каркаса:

• User At – используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством вызова

• Author. Date, Rev, Project – автор, дата, номер последней версии, название проекта

• Notes 1 2 3 4 5 6 7 8 9 10 - исп-ся для проведения сеанса экспертизы. Эксперт на бумажной копии диаграммы указывает количество замечаний, вычеркивая цифру каждый раз при внесении замечания

• Статус диаграммы, определяющий стадии её создания: Working (новая диаграмма, кардинально обновленная или новый автор), Draft (диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению), Recommended (диаграмма прошла эспертизу и новых изменений не ожидаетс), Publication(диаграмма готова к окончательной публикации)

• Reader, Date – эксперт (имя), дата экспертизы

• Context – определяет располоэение родительской работы в диаграмме верхнего уровня, она указчывается закрашенным прямоугольником. В левом ниэнем кглу показывается номер по узлу родительской диаграммы. На контекстной диаграмме пишется слово Top

Нижняя часть – подвал, содержит элементы:

• Node – номер родительской работы

• Title – имя диограммы (по умолчанию - имя родительской работы

• Number – номер сраницы диаграммы в общей папке отдельно

Виды отчетов BPWIN

Генерации отчетов осуществляются из пунктов мен. Report – включает И о модели (имя, точка зрения, автр, дата создания, область

Вшыпкыткузщке

- отчет по конкретной диаграмме: списрк и подробное описание работ

Diagramm Odject Report – наиболее полный отчет о модели, вкдючает

Фсешмшен Сщые Кузщке – отчет о результатах основного анализа

Arrow Report – содержит И из словаря стрелок, такую как о работе источники, раоте приемнике о разветвлении и принятии стрелок

Вфеф Гыупу Кузщке – о функциональной модели и и модели данных

Model Consist Report – отчет, со списком симантических моделей.

диаграммы потоков данных - Data Flow Diagramma (DFD)

Наряду с IDEF0 диаграммы ДФД являются одним из основных средств моделирования

Если при проектировании с помощью IDEF0 на первом месте были ф-и или процессы, то диаграмма ДФД показывает каким образом процесс (работа) преобразует свои входные данные в выходные. Диаграмм ДФД усешно используются как дополненеи к модли IDEF0 для описания пмодели оборота и описания процесса обработки

Существует несколько нотаций, наиболее популярны нотация Йордана-ДеМарко и нотация Гейна-Сарсона, обе предложены в 1979

BPWin поддерживает вторую

элементы диограммы ДФД

		Йордана	Гейна-Сарсона
Процесс (работа)	для представления на лиаграмме нект ф-и, преобразующей вход в выход. имя – глагольная фраза. Поддерживает вход и выход, но не поддерживает управление и механизм. направление стрелок - произвольное
Поток данных	описывают движение объекта из одной части системы в другую. могут использоваться двунаправленные стрелки. В ДФД стрелки могут сливаться и разветвляться, что позволяет описать их декомпозицию.
Хранилище данных	В отличии от стрелок, описывающих объекты в движении, хранилища Д отображают объекты в покое. Хранилища Д изображаются там, где объекты ожидают обрадотки и являются механизмом, который позволяет отобразть сохранение Д для их последующей обработки. Как правило физически существующей таблице БД на ДФД соответствует хранилище
Внешняя сущность	сущность вне контекста системы, являющаяся приемником или источником Д, имя – существительное. Напр – клинт, склад товаров. Предполагается, что объекты, представленные этим элементом не участвуют в обработке
Сущность		нет	нет
		нет	нет
Группировка потоков
Разветвление

Имя потока и хранилища – имя сущ, могут совпадать. Одно и то же хранилище м\б представлено на ДФД несколько раз для того чтобы избежать изображения длинных пересекающихся потоков Д.

Аналогично IDEF0 в ДФД разработка начинается с контекстной диаграммы. Вся деятельность представлена одним процессом, потоки показывают связь с внешней средой.

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

Имя хранилища Д начинается с D, процесс с буквы А , внешняя сущнсть с буквы Е. После соответствующих элементу диаграмм букв автоматически проставляется номер элемента(аналогично IDEF0)

Расширения реального времени

Используются для дополнения модели ДФД средствами описания управляющих аспектов в системах реального времени (элементы очерчиваются пунктирной линией):

• управляющий процесс – моделирует управляющую деятельность на диаграмме, т.е представляет собой преобразователь входного управляющего потока в выходной управляющий поток.

• управляющий поток – поток, по которому проходит управляющая И. имя потока – имя существительное.

• управляющее хранилище – содржит управляющую И, кот может быть использована в любое время

Виды управляющих потоков:

• Т-поток (Trigger flow) – вызывает выполнение процесса.

• А-поток (Activator flow) – может изменять выполнение отдельного процесса, т.е. процесс выполняется, пока поток «включен».

• E/D-поток (Enable/Disable flow) – может переключать выполнение процесса.