Handbook по дисциплине ...€¦ · Московский финансово-промышленный университет «Синергия» Кафедра Информационных

Московский финансово-промышленный университет

«Синергия»

Кафедра Информационных систем

Култыгин О.П.

Handbook

по дисциплине

«Методология и технология

проектирования информационных

систем»

Программа магистерской подготовки

Москва

2013

2

Содержание

Аннотация ............................................................................................................................ 4

Тема 1. Основы организации проектирования информационных систем ......................... 8

Вопрос 1. Понятия «проект», «проектирование». Основные требования к

проектированию. .............................................................................................................. 8

Вопрос 2. Технология, методология и методы проектирования. ................................... 8

Вопрос 3. Нормативно-методическое обеспечение создания программного

обеспечения. ................................................................................................................... 11

Вопрос 4. Общие принципы проектирования систем. .................................................. 12

Вопросы для самопроверки: .......................................................................................... 13

Литература по теме: ....................................................................................................... 13

Тесты для самопроверки: ............................................................................................... 13

Тема 2. Жизненный цикл ПО. Модели жизненного цикла ПО ........................................ 16

Вопрос 1. Понятие жизненного цикла ПО. ................................................................... 16

Вопрос 2. Структура жизненного цикла ПО: основные, вспомогательные,

организационные процессы. .......................................................................................... 16

Вопрос 3. Модели жизненного цикла ПО. Каскадная и спиральная модели

жизненного цикла ИС. ................................................................................................... 17




Тема 3. Технология проектирования ИС .......................................................................... 22

Вопрос 1. Основные понятия, история развития CASE-технологий............................ 22

Вопрос 2. Классификация CASE-средств. ..................................................................... 23

Вопрос 3. Архитектура CASE-средств. ......................................................................... 24

Вопрос 4. Функционально-ориентированные и объектно-ориентированные CASE-

средства. Обзор пакета инструментальных средств AllFusion Modeling Suite 7.1. ..... 25

Вопрос 5. Прототипное проектирование (RAD-технологии). ...................................... 28




Тема 4. Состав и содержание работ по этапам жизненного цикла ПО. Проектная

документация ..................................................................................................................... 34

Вопрос 1. Состав и содержание проектной документации........................................... 34

Вопрос 2. Предпроектное исследование и техническое задание. ................................ 35

Вопрос 3. Техно-рабочее проектирование. ................................................................... 37

Вопрос 4. Состав и содержание работ на стадиях внедрения, эксплуатации и

сопровождения проекта. ................................................................................................ 39




3

Тема 5. Проектирование информационного и программного обеспечения .................... 43

Вопрос 1. Основные принципы построения объектной модели. Основные

элементы объектной модели. ......................................................................................... 43

Вопрос 2. Унифицированный язык моделирования UML. ........................................... 45

Вопрос 3. Методология моделирования Rational Unified Process. ............................... 63




Тема 6. Структурные методы анализа и проектирования ПО .......................................... 68

Вопрос 1. Метод функционального проектирования SADT. ....................................... 68

Вопрос 2. Методология формализации и описания бизнес-процессов IDEF0

(общие сведения, состав функциональной модели, функциональная

декомпозиция). ............................................................................................................... 69

Вопрос 3. Функциональное проектирование в среде AllFusion Process Modeler

(модели AS-IS и TO-BE). ............................................................................................... 70

Вопрос 4. Реинжиниринг бизнес-процессов. ................................................................ 76

Вопрос 5. Моделирование процессов в нотации IDEF3. .............................................. 77

Вопрос 6. Моделирование потоков данных, диаграммы потоков данных (DFD). ...... 81

Вопрос 7. Моделирование данных, методология проектирования реляционных баз

данных IDEF1X, моделирование данных в среде AllFusion ERwin Data Modeler. ...... 84




Литература ......................................................................................................................... 92

Основная литература: ..................................................................................................... 92

Дополнительная литература: ......................................................................................... 92

Практические задания ........................................................................................................ 93

Контрольный тест ............................................................................................................ 139

Ответы на тестовые задания ............................................................................................ 149

4

Аннотация

Предметом изучения являются процессы формирования

требований, моделирования разрабатываемых информационных систем.

Объектом изучения выступают информационные системы на этапах

формирования требований, проектирования и разработки.

Место дисциплины в учебном процессе.

Дисциплина «Методология и технология проектирования

информационных систем» посвящена изучению методологических

основ проектирования информационных систем (ИС). Она формирует

системных подход к реализации поставленных задач по разработке

программного обеспечения (ПО). Дисциплина развивает ряд

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

проекты информационных систем с использованием средств

программной инженерии.

Для успешного освоения настоящего курса необходимо

предварительно завершить изучение следующих дисциплин:

Информационные системы.

Информационные технологии.

Управление данными.

Проектирование баз данных.

Администрирование баз данных.

Цель и задачи дисциплины.

Целью дисциплины «Методология и технология проектирования

информационных систем» являются изучение методологических основ

проектирования современных информационных систем, развитие

навыков работы с современными CASE-средствами, подготовка

студентов к профессиональной деятельности в сфере разработки

программного обеспечения.

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

базовых вопросов:

раскрытие сущности и содержания основных понятий и

категорий проектирования информационных систем (проекта,

проектирования, методологии, технологии, методов проектирования);

ознакомление с методологическими основами спецификации

предметной области и формирования моделей будущих

информационных систем на основе структурного и объектно-

ориентированного подхода;

изучение истории развития программной инженерии;

развитие системного мышления по решению задач

проектирования ИС;

5

формирование навыков коллективной и индивидуальной работы

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

CASE-средств и созданию проектной документации.

Компетенции, формируемые в результате освоения учебной

дисциплины.

Процесс изучения дисциплины направлен на формирование

следующих профессиональных компетенций (ПК), предусмотренных

Федеральным государственным образовательным стандартом высшего

профессионального образования по направлению подготовки 230700.68

Прикладная информатика (квалификация (степень) «магистр»), согласно

которому выпускник:

способен исследовать современные проблемы и методы

прикладной информатики и научно-технического развития

информационно-коммуникационных технологий (ПК-1);

способен исследовать закономерности становления и развития

информационного общества в конкретной прикладной области (ПК-2);

способен на практике применять новые научные принципы и

методы исследований (ПК-3);

способен к профессиональной эксплуатации современного

электронного оборудования в соответствии с целями ООП магистратуры

(ПК-4);

способен использовать и развивать методы научных

исследований и инструментария в области проектирования и управления

информационными системами в прикладных областях (ПК-5);

способен ставить и решать прикладные задачи в условиях

неопределенности и устанавливать методы и средства их эффективного

решения (ПК-7);

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

результаты (ПК-8);

способен исследовать применение различных научных подходов

к автоматизации информационных процессов и информатизации

предприятий и организаций (ПК-9);

способен выбирать методологию и технологию проектирования

ИС с учетом проектных рисков (ПК-11);

способен анализировать данные и оценивать требуемые знания

для решения нестандартных задач с использованием математических

методов и методов компьютерного моделирования (ПК-12);

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

информационные процессы (ПК-13);

способен проводить маркетинговый анализ ИКТ и

вычислительного оборудования для рационального выбора

инструментария автоматизации и информатизации прикладных задач

(ПК-14);

6

способен применять современные методы и инструментальные

средства прикладной информатики для автоматизации и

информатизации решения прикладных задач различных классов и

создания ИС (ПК-15);

способен проектировать архитектуру и сервисы

информационных систем предприятий и организаций в прикладной

области (ПК-16);

способен проектировать информационные процессы и системы

с использованием инновационных инструментальных средств,

адаптировать современные ИКТ к задачам прикладных ИС (ПК-17);

способен принимать эффективные проектные решения в

условиях неопределенности и риска (ПК-18);

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

процессов и создания прикладных ИС в соответствии со стратегией

развития предприятий (ПК-19);

способен организовывать работы по моделированию

прикладных ИС и реинжинирингу прикладных и информационных

процессов предприятия и организации (ПК-20);

способен управлять информационными ресурсами и

информационными системами (ПК-21);

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

задач и созданию ИС предприятий и организаций (ПК-22);

способен в условиях функционирования ИС брать на себя

ответственность за выполнение производственных задач ИТ-служб,

эффективно использовать современные приемы и методы работы с ИТ-

персоналом (ПК-24);

способен интегрировать компоненты и сервисы

информационных систем (ПК-28).

В результате изучения дисциплины обучаемый должен:

Знать:

понятия «методы», «методология проектирования»;

классификацию методов проектирования;

понятие жизненного цикла ПО, моделей жизненного цикла ПО;

основные нормативные документы, регламентирующие

деятельность разработчиков по созданию ПО;

классификацию, архитектуру CASE-средств;

основные подходы к разработке ПО;

основные этапы разработки и принципы функционирования ИС;

особенности функционального (структурного) подхода к

проектированию ПО;

особенности объектно-ориентированного подхода к

проектированию ПО;

7

особенности проектирования систем распределенной обработки;

стандарты ГОСТ на разработку проектной документации.

Уметь:

разрабатывать информационную модель предметной области;

осуществлять формализованное описание предметной области в

нотациях IDEF0, IDEF1X, IDEF3, DFD;

формировать объектные модели предметной области;

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

систему.

Приобрести навыки:

выбора оптимальной технологии проектирования и модели

жизненного цикла в соответствии со спецификой решаемой задачи по

автоматизации;

формализованного описания моделей предметной области;

работы с CASE-средствами.

Иметь представление:

о перспективах развития CASE-средств;

о проблемах создания информационных систем различной

архитектуры и сложности;

о методах и современных средствах моделирования

информационных систем;

об организации оптимального управления ИТ-проектом;

об особенностях проектирования систем защиты данных.

8

Тема 1. Основы организации проектирования информационных

систем

Цель темы: раскрытие сущности и содержания основных понятий

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

Задачи темы: формирование у студентов теоретических основ

дисциплины.

Вопросы темы:

1. Понятия «проект», «проектирование». Основные требования к

проектированию.

2. Технология, методология и методы проектирования.

3. Нормативно-методическое обеспечение создания программного

обеспечения.

4. Общие принципы проектирования систем.

Вопрос 1. Понятия «проект», «проектирование». Основные

требования к проектированию.

Проект ИС – это проектно-конструкторская и технологическая

документация, содержащая описание проектных решений по созданию и

эксплуатации информационной системы в конкретной программно-

технической среде.

Процесс проектирования ИС представляет собой преобразование

входной информации об объекте и методах проектирования в проект ИС

в соответствии с ГОСТом.

Объекты проектирования ИС – это элементы (задачи), комплекс

задач функциональной и обеспечивающей частей. В состав

обеспечивающей части ИС входят элементы и их комплексы

информационного, программного и технического обеспечения системы.

Субъектами проектирования ИС являются проектная

организация и организация-заказчик.

Вопрос 2. Технология, методология и методы проектирования.

Технология проектирования ИС – это комплекс методологий и

средств проектирования, а также методов и средств организации

проектирования.

Технологию проектирования ИС можно представить в виде

технологического процесса проектирования ИС, отображающего

последовательность действий, необходимые средства и ресурсы для

выполнения этих действий и состав исполнителей.

9

В процессе работы над проектом необходимо знать ЧТО, КАК,

КОМУ и В КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть

сделано.

Требования к выбираемой технологии проектирования:

соответствие проекта по выбранной технологии требованиям

заказчика;

максимальное отображение всех этапов жизненного цикла

проекта;

обеспечение min трудовых и стоимостных затрат на

проектирование и сопровождение проекта;

способствование технологии росту производительности труда

проектировщика;

простота ведения проектной документации;

обеспечение технологией надежности процесса проектирования

и эксплуатации проекта.

Методология проектирования предполагает наличие концепции,

принципов проектирования, реализуемых набором методов, которые

должны поддерживаться средствами проектирования.

Методы проектирования ИС можно классифицировать:

1) по степени автоматизации:

ручное проектирование (без использования специальных

инструментальных программных средств, программирование на

алгоритмических языках);

компьютерное проектирование (генерация или конфигурация

(настройка) проектных решений на основе использования специальных

инструментальных программных средств).

2) по степени использования типовых проектных решений:

оригинальное, или индивидуальное проектирование (разработка

с «нуля»);

типовое проектирование (настройка ИС из готовых типовых

проектных решений (программных модулей)).

3) по степени адаптивности проектных решений:

метод реконструкции (адаптация путем программирования

модулей);

метод параметризации (настройка в соответствии с

изменяемыми параметрами);

метод реструктуризации модели (изменение модели проблемной

области, на основе которой автоматически перегенерируются проектные

решения).

10

Сочетание различных признаков классификации методов

проектирования обусловливает характер используемой технологии

проектирования ИС. Технологии проектирования ИС делятся на два

основных класса:

1) канонические технологии (для небольших локальных ИС);

2) индустриальные технологии, подразделяющиеся на:

автоматизированные (использование CASE-технологий);

типовые (параметрически-ориентированные или модельно-

ориентированные).

Конкретные виды технологий проектирования требуют выбора

средств проектирования, которые по своим характеристикам

максимально соответствовали бы требованиям конкретного

предприятия.

Средства проектирования должны обладать следующими

качествами:

охватывать все этапы жизненного цикла ИС;

быть совместимыми технически, программно и информационно;

быть простыми в освоении и применении;

быть экономически целесообразными.

Средства проектирования ИС можно разделить на два класса:

1) без использования ЭВМ на всех стадиях проектирования

(средства организационно-методического обеспечения операций

проектирования, куда входят стандарты, регламентирующие процесс

проектирования систем, Единая Система Классификации и Кодирования

информации, унифицированная система документации (УСД), модели

описания и анализа потоков информации и т.п.);

2) с использованием ЭВМ (подразделяются на четыре подкласса

(см. таблица 1)).

11

Таблица 1.

Средства проектирования с использованием ЭВМ

I II III IV

Операционные

средства:

Средства общесистемного

назначения:

Функциональные

средства:

Средства

автоматизации

проектирования

ЭИС

алгоязыки;

библиотеки

стандартных

подпрограмм и классов объектов;

средства для

тестирования и

отладки программ, поддержки процесса

документирования

проекта и т.д.

СУБД;

методоориентированные ППП

(задачи дискретного

программирования, мат. статистики);

табл. процессоры;

статистические ППП;

граф., текстовые редакторы;

оболочки экспертных систем;

интегрированные ППП.

типовые

проектные решения;

функциональные

ППП;

типовые проекты.

средства,

поддерживающие

разработку проекта – CASE-

технологии.

Вопрос 3. Нормативно-методическое обеспечение создания

программного обеспечения.

Нормативно-методическое обеспечение (НМО) – комплекс

документов, регламентирующих различные аспекты процессов

деятельности разработчиков.

Эти документы регламентируют:

порядок разработки, внедрения, сопровождения ПО;

общие требования к составу ПО и связям между его

компонентами, а также к его качеству;

виды, состав и содержание проектной и программной

документации.

Нормативной базой НМО являются международные и

отечественные стандарты в области информационных технологий и

прежде всего:

международные стандарты ISO/IEC;

стандарты Российской Федерации ГОСТ Р;

стандарты организации-заказчика.

В результате для каждого серьезного проекта приходится

создавать комплекты нормативных и методических документов,

регламентирующих процессы, этапы, работы, документы конкретных

программных продуктов, поэтому в отечественных разработках

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

12

Вопрос 4. Общие принципы проектирования систем.

Одной из основных проблем, которые приходится решать при

создании больших и сложных систем любой природы, в том числе и ПО,

является проблема сложности. Ни один разработчик не в состоянии

выйти за пределы человеческих возможностей и понять всю систему в

целом. Единственный эффективный подход к решению этой проблемы,

который выработало человечество за всю свою историю, заключается в

построении сложной системы из небольшого количества крупных

частей. Каждая часть, в свою очередь, строится из частей меньшего

размера до тех пор, пока самые небольшие части можно будет строить

из имеющегося материала. Этот подход известен под самыми разными

названиями: «разделяй и властвуй» (divide et impera), иерархическая

декомпозиция и др. По отношению к проектированию сложной

программной системы это означает, что ее необходимо разделить

(декомпозировать) на небольшие подсистемы, каждую из которых

можно разрабатывать независимо от других. Это позволяет при

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

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

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

ПО. Понятие «правильная» по отношению к декомпозиции означает

следующее:

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

быть минимальным (принцип «слабой связанности» – Low Coupling);

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

быть максимальной (принцип «сильного сцепления» – High Cohesion).

Более подробно эти принципы будут рассмотрены в рамках

объектно-ориентированного анализа.

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

между ее подсистемами укладывались в ограниченные, стандартные

рамки, т.е.:

каждая подсистема должна инкапсулировать свое содержимое

(скрывать его от других подсистем);

каждая подсистема должна иметь четко определенный

интерфейс с другими подсистемами.

Инкапсуляция (принцип «черного ящика») позволяет

рассматривать структуру каждой подсистемы независимо от других

подсистем. Интерфейсы помогают строить систему более высокого

уровня, рассматривая каждую подсистему как единое целое и игнорируя

ее внутреннее устройство.

13

Существуют два основных подхода к декомпозиции систем.

Первый подход называют функционально-модульным, он является

частью более общего структурного подхода. В его основу положен

принцип функциональной декомпозиции, при которой структура

системы описывается в терминах иерархии ее функций и передачи

информации между отдельными функциональными элементами. Второй,

объектно-ориентированный подход, использует объектную

декомпозицию. При этом структура системы описывается в терминах

объектов и связей между ними, а поведение системы описывается в

терминах обмена сообщениями между объектами.

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

1. Назовите основные составляющие проекта ИС.

2. Дайте определение объекту и субъекту проектирования.

3. Что включает в себя технология проектирования ИС?

4. Каковы требования к технологии проектирования ИС?

5. Что такое методология проектирования ИС?

6. Как классифицируются методы проектирования?

7. Какие признаки характеризуют автоматизированное

проектирование?

8. Как классифицируются средства проектирования?

9. Каковы требования к проектированию ИС?

10. Что входит в состав нормативно-методологической базы

проектирования ИС?

Литература по теме:

1. Вендров А.М. Проектирование программного обеспечения

экономических информационных систем: учебник. – 2-е изд., перераб. и

доп. – М.: Финансы и Статистика, 2006 – 544 с. – С. 37–39, 104–108.

2. Проектирование экономических информационных систем:

учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред.

Ю.Ф. Тельнова. – М.: Финансы и Статистика, 2003 – 512 с. – С. 27–35.

Тесты для самопроверки:

1. Проектирование ИС – это …

а) написание программного кода и его отладка для будущей ИС

б) преобразование входной информации об объекте и методах

проектирования в проект ИС в соответствии с ГОСТом

в) разработка нормативных документов для будущей ИС

г) преобразование требований к ИС в алгоритм

14

2. Комплекс методологий и средств проектирования, а также

методов и средств организации проектирования – это …

а) нормативно-методологическая база создания ИС

б) объект проектирования

в) проект ИС

г) технология проектирования

3. Последовательность действий, необходимые средства и

ресурсы для выполнения действий и состав исполнителей – это …

а) технологическая операция

б) технологический процесс

в) методы проектирования

г) принципы проектирования

4. Оригинальный метод проектирования – это …

а) разработка ИС «с нуля»

б) разработка ИС без использования специальных программных

средств

в) разработка ИС в соответствии с требованиями заказчика

5. Автоматизированное проектирование относят к …

а) каноническому проектированию

б) типовому проектированию

в) индустриальному проектированию

г) реструктуризации модели

6. По степени адаптивности различают методы проектирования:

а) ручные и компьютерные

б) параметризация и реструктуризация модели

в) оригинальные и типовые

г) канонические и спиральные

7. Настройка ИС в соответствии с изменяемыми параметрами –

это …

а) реконструкция

б) параметризация

в) реконструктуризация

8. Методоориентированные пакеты прикладных программ

относят к …

а) операционным средствам

б) средствам общесистемного назначения

в) функциональным средствам

г) средствам организации проектирования

15

9. Комплекс документов, регламентирующие различные аспекты

процессов деятельности разработчиков – это …

а) нормативно-методическое обеспечение

б) методология проектирования

в) объект проектирования

г) проект ИС

10. К нормативно-методической базе создания ИС не относят …

а) международные стандарты

б) стандарты Российской Федерации

в) стандарты организации-заказчика

г) CASE-средства

16

Тема 2. Жизненный цикл ПО. Модели жизненного цикла ПО

Цель темы: раскрытие понятий «жизненный цикл ПО» и «модель

жизненного цикла ПО».

Задачи темы: формирование у студентов понятия жизненного

цикла ПО, модели жизненного цикла.


1. Понятие жизненного цикла ПО.

2. Структура жизненного цикла ПО: основные, вспомогательные,

организационные процессы.

3. Модели жизненного цикла ПО. Каскадная и спиральная модели

жизненного цикла ИС.

Вопрос 1. Понятие жизненного цикла ПО.

Жизненный цикл (ЖЦ) ИС – совокупность стадий и этапов,

которые проходит ИС в своем развитии от момента принятия решения о

создании системы до момента прекращения ее функционирования.

Вопрос 2. Структура жизненного цикла ПО: основные,

вспомогательные, организационные процессы.

На рис. 1 представлена структура жизненного цикла

информационных систем согласно стандарту ISO/IEC 12207.

Три группы процессов

Основные Вспомогательные Организационные

Приобретение

Поставка

Разработка

Эксплуатация

Сопровождение

Документирование

Управление конфигурацией

Обеспечение качества

Верификация

АттестацияОценка

Решение проблем

Управление проектами

Создание

инфраструктуры

проекта

ОбучениеУсовершенствование

Рис. 1. Структура жизненного цикла ИС по стандарту ISO/IEC 12207

17

Процесс приобретения состоит из действий и задач заказчика,

приобретающего ПО. Процесс поставки охватывает действия и задачи,

выполняемые поставщиком.

Разработка ПО – все работы по созданию ПО и его компонент в

соответствии с заданными требованиями, включая оформление

проектной и эксплуатационной документации.

Эксплуатация – работы по внедрению компонентов ПО,

конфигурирование БД и рабочих мест.

Процесс сопровождения активизируется при изменениях

программного продукта и соответствующей документации. Внесение

изменений в ПО в целях исправления ошибок, повышения

производительности или адаптации к изменившимся условиям.

Управление конфигурацией – поддержка основных процессов ЖЦ

ПО, прежде всего процессов разработки и сопровождения ПО.

Обеспечение качества проекта – верификация, проверка и

тестирование ПО.

Управление проектом – планирование и организация работ,

создание коллектива разработчиков, контроль за сроками и качеством

выполняемых работ.

Вопрос 3. Модели жизненного цикла ПО. Каскадная и

спиральная модели жизненного цикла ИС.

Модель жизненного цикла – структура, определяющая

последовательность выполнения и взаимосвязи процессов, действий и

задач, выполняемых на протяжении ЖЦ.

Модель жизненного цикла зависит от специфики информационной

системы и условий, сложности и масштаба проекта. Технологии

проектирования ЭИС, определяющие порядок выполнения стадий и

этапов, претерпевали существенные изменения. Среди известных

моделей ЖЦ ИС можно выделить каскадную и спиральную модели.

Каскадная модель ЖЦ ИС была разработана в 1970 году

экспертом в области ПО Уинстоном Ройсом. Каскадная модель

предполагала последовательный переход на следующий этап после

полного завершения предыдущего (см. рис. 2). Данная модель

применима для отдельных несвязных задач, не требующих выполнения

информационной интеграции и совместимости программного,

технического и организационного сопровождения. Применение

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

длительности процесса проектирования и изменчивости за это время

требований, приводит к их практической нереализуемости.

18

Рис. 2. Каскадная модель ЖЦ ИС

Достоинства каскадной модели:

на каждой стадии формируется законченный набор проектной

документации, отвечающий критериям полноты и согласованности;

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

позволяют планировать сроки завершения всех работ и

соответствующие затраты.

Недостатки каскадной модели:

позднее обнаружение проблем;

выход из календарного графика, запаздывание в получении

результатов;

избыточное количество документации;

невозможность разбить систему на части (весь продукт

разрабатывается за один раз);

высокий риск создания системы, не удовлетворяющей

изменившимся потребностям пользователей.

Каскадная модель может использоваться при создании ПО, для

которого в самом начале разработки можно достаточно точно и полно

сформулировать все требования, с тем, чтобы предоставить

разработчикам свободу реализовать их технически как можно лучше.

Однако реальный процесс создания ПО никогда полностью не

укладывается в такую жесткую схему. Процесс создания ПО носит, как

правило, итерационный характер: результаты очередной стадии часто

вызывают изменения в проектных решениях, выработанных на более

ранних стадиях. Таким образом, постоянно возникает потребность в

возврате к предыдущим стадиям и уточнении или пересмотре ранее

принятых решений. Каскадная модель в последнее время не

используется в чистом виде из-за сложности и масштабности

современных проектов по разработке ИС.

19

В середине 1980-х годов Барри Боэм предложил спиральную

модель ЖЦ ИС. Проектирование ИС осуществляется «сверху-вниз», при

этом сначала определяется состав функциональных подсистем ИС

(комплекс задач с высокой степенью информационных обменов (связей)

между задачами). При использовании данной модели ПО создается в

несколько итераций (витков спирали, см. рис. 3) методом

прототипирования. Каждый виток спирали соответствует отдельной

версии ПО или прототипу.

Рис. 3. Спиральная модель ЖЦ ИС

Прототип – действующий программный компонент,

реализующий отдельные функции и внешние интерфейсы

разрабатываемого ПО.

Достоинства спиральной модели:

ускорение разработки;

постоянное участие заказчика в процессе разработки;

разбивка большого объема работы на небольшие части;

снижение риска (снижение вероятности непредсказуемого

поведения системы).

Недостатки спиральной модели:

сложность планирования;

сложность применения модели с точки зрения менеджеров и

заказчика;

напряженный режим работы для разработчиков.

20

Основная проблема спирального цикла – определение момента

перехода на следующую стадию. Для ее решения необходимо ввести

временные ограничения на каждую из стадий ЖЦ. Переход

осуществляется в соответствии с планом, даже если не вся

запланированная работа закончена. План составляется на основе

статистических данных, полученных в предыдущих проектах, и личного

опыта разработчиков.


1. Что такое жизненный цикл программного обеспечения?

2. Чем регламентируется ЖЦ ПО?

3. Какие группы процессов входят в состав ЖЦ ПО? Какие

процессы входят в состав каждой группы?

4. Какие из процессов, по вашему мнению, наиболее часто

используются в реальных проектах? Какие – в меньшей степени?

Почему?

5. Сформулируйте понятие модели ЖЦ.

6. Каковы принципиальные особенности каскадной модели?

7. В чем заключаются преимущества и недостатки каскадной

модели?

8. Каковы принципиальные особенности итерационной модели?

9. В чем состоят преимущества и недостатки спиральной модели?




доп. – М.: Финансы и Статистика, 2006 – 544 с. – Глава 1.


учебник/ Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред.

Ю.Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с. – С. 35–41.


1. Жизненный цикл информационной системы начинается с

момента …

а) принятия решения о создании информационной системы

б) создания и утверждения модели разрабатываемой

информационной системы

в) установки на пользовательские места

г) введения данных

2. Управление конфигурацией относится к …

а) основным процессам ЖЦ ПО

б) вспомогательным процессам ЖЦ ПО

в) организационным процессам ЖЦ ПО

21

3. Все работы по созданию ПО и его компонент в соответствии с

заданными требованиями – это …

а) процесс приобретения

б) процесс разработки

в) процесс поставки

г) процесс сопровождения

4. Модель жизненного цикла не зависит от:

а) субъекта проектирования

б) специфики ИС

в) специфики условий

г) масштаба проекта

5. Разработчик каскадной модели ЖЦ:

а) Уинстон Ройс

б) Барри Боэм

в) Градди Буч

г) Эдгар Кодд

6. Позднее обнаружение проблем характерно для:

а) каскадной модели

б) спиральной модели

в) итерационной модели

7. Для спиральной модели характерен следующий недостаток:

а) избыточное количество документации

б) невозможность разбить систему на части

в) запаздывание с результатами

г) сложность планирования

8. Каждый виток спирали в спиральной модели соответствует:

а) одному из этапов ЖЦ

б) одной из групп процессов ЖЦ

в) версии ПО

г) определенному набору проектной документации

22

Тема 3. Технология проектирования ИС

Цель темы: изучение истории развития и текущего состояния

технологий проектирования ИС.

Задачи темы: раскрытие понятия «CASE-средства»; выявление

основных причин появления и развития CASE-средств; ознакомление

обучающихся с современными CASE-средствами, которые

используются для разработки ПО.


1. Основные понятия, история развития CASE-технологий.

2. Классификация CASE-средств.

3. Архитектура CASE-средств.

4. Функционально-ориентированные и объектно-ориентированные

CASE-средства. Обзор пакета инструментальных средств AllFusion

Modeling Suite 7.1.

5. Прототипное проектирование (RAD-технологии).

Вопрос 1. Основные понятия, история развития CASE-

технологий.

Термин «CASE-средства» (Computer Aided Software Engineering)

означает программные средства, поддерживающие процессы создания и

сопровождения ИС, включая анализ и формулировку требований,

проектирование прикладного ПО (приложений) и баз данных,

генерацию кода, тестирование, документирование, обеспечение

качества, конфигурационное управление и управление проектом, а

также другие процессы.

Появлению CASE-технологий и CASE-средств предшествовали

исследования в области программирования: разработка и внедрение

языков высокого уровня, методов структурного и модульного

программирования, языков проектирования и средств их поддержки и

т.д. Кроме того, этому способствовали следующие факторы:

подготовка аналитиков и программистов, восприимчивых к

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

широкое внедрение и постоянный рост производительности

компьютеров, позволившие использовать эффективные графические

средства и автоматизировать большинство этапов проектирования;

внедрение сетевой технологии, предоставившей возможность

объединения усилий отдельных исполнителей в единый процесс


23

Наибольшая потребность в CASE-средствах наблюдается на

начальных этапах анализа и спецификации требований. Это объясняется

тем, что цена ошибок, допущенных на начальных этапах, на несколько

порядков превышает цену ошибок, выявленных на более поздних этапах

разработки.

Преимущества CASE-технологии по сравнению с традиционной

технологией оригинального (ручного) проектирования:

улучшение качества разрабатываемого программного

приложения за счет средств автоматического контроля и генерации;

возможность повторного использования компонентов

разработки;

поддержание адаптивности и сопровождения ЭИС;

снижение времени на создание системы (это позволит на ранних

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

его);

освобождение разработчиков от рутинной работы по

документированию проекта за счет использования встроенного

документатора;

возможность коллективной разработки ЭИС в режиме реального

времени.

Вопрос 2. Классификация CASE-средств.

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

1) по поддерживаемым методологиям проектирования:

функционально (структурно)-ориентированные, объектно-

ориентированные и комплексно-ориентированные (набор методологий

проектирования);

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

диаграмм: с фиксированной нотацией, отдельными нотациями и

наиболее распространенными нотациями;

3) по степени интегрированности: tools (отдельные локальные

средства), toolkit (набор интегрированных средств, охватывающих

большинство этапов разработки ЭИС) и workbench (полностью

интегрированные средства, связанные общей базой проектных данных –

репозиторием);

4) по типу и архитектуре вычислительной техники:

ориентированные на ПЭВМ, ЛВС, ГВС и смешанного типа;

5) по режиму коллективной разработки проекта:

поддерживающие коллективную разработку, ориентированные на режим

реального времени и режим объединения подпроектов;

6) по типу операционной системы (ОС): Windows, UNIX, OS/2 и

др.

24

Вопрос 3. Архитектура CASE-средств.

Архитектура CASE-средства представлена на рис. 4.

Рис. 4. Архитектура CASE-средства

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

данных), представляющий собой специализированную базу данных,

предназначенную для отображения состояния проектируемой ИС в

каждый момент времени.

Репозиторий содержит информацию об объектах проектируемой

ЭИС и взаимосвязях между ними, все подсистемы обмениваются

данными. В репозитории хранятся описания:

проектировщиков и их права доступа к различным компонентам

системы;

организационных структур;

диаграмм и связей между ними;

компонентов диаграмм;

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

программных модулей;

процедур;

библиотеки модулей и т.д.

Графический редактор позволяет выполнять следующие

операции:

создавать элементы диаграмм, их взаимосвязи и описания;

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

редактировать элементы диаграмм, их взаимосвязи и описания.

25

Графические средства моделирования предметной области

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

систему, перестраивать ее в соответствии с поставленными целями и

ограничениями.

Верификатор служит для контроля правильности построения

диаграмм в заданной методологии проектирования ЭИС.

Документатор проекта позволяет получать информацию о

состоянии проекта в виде различных отчетов, которые строятся по

нескольким признакам (времени, автору, элементам диаграмм,

диаграмме или проекту в целом).

Администратор проекта – это инструменты, необходимые для

выполнения таких функций, как:

инициализация проекта;

задания начальных параметров проекта;

назначения и изменения прав доступа к элементам проекта;

мониторинга выполнения проекта.

Сервис – набор системных утилит по обслуживанию репозитория

(архивация данных, восстановление данных и создание нового

репозитория).

Вопрос 4. Функционально-ориентированные и объектно-

ориентированные CASE-средства. Обзор пакета инструментальных

средств AllFusion Modeling Suite 7.1.

Большинство существующих CASE-систем ориентировано на

автоматизацию проектирования ПО и основано на методологиях

структурного (в основном) или объектно-ориентированного

проектирования и программирования, использующих спецификации в

виде диаграмм или текстов для описания системных требований, связей

между моделями системы и т.д.

Одним из наиболее популярных CASE-средств, поддерживающих

методологию структурного (функционального) проектирования,

является пакет AllFusion Modeling Suite, выпущенный компанией

Computer Associates (CA).

В этот пакет входит пять продуктов:

1. AllFusion Process Modeler является новым именем хорошо

известного BPwin. В документации и пресс-релизах CA используются

оба наименования – новое AllFusion Process Modeler и старое BPwin.

2. AllFusion ERwin Data Modeler – инструмент создания моделей

данных и генерации схем баз данных. Старое название – ERwin.

3. AllFusion Data Model Validator – система поиска и исправления

ошибок модели данных. Прежнее название – ERwin Examiner.

26

4. AllFusion Model Manager – система организации коллективной

работы, хранилище моделей BPwin и ERwin. Старое название –

ModelMart.

5. AIIFusion Component Modeler – инструмент создания объектных

моделей. Прежнее – Paradigm Plus.

AllFusion Data Model

Navigator

AllFusion Model

Manager

AllFusion Process

Manager

AllFusion ERWin

Data Modeler

СУБД

(1)

(2)

(3)(4)

(5)

(6)

Рис. 5. Общая схема взаимодействия инструментальных средств

AllFusion Modeling Suite

Для проведения анализа и реорганизации бизнес-процессов

предназначено CASE-средство верхнего уровня AllFusion Process

Modeler (BPwin), поддерживающее методологии IDEF0

(функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow

Diagram). Функциональная модель предназначена для описания

существующих бизнес-процессов на предприятии (так называемая

модель AS-IS) и идеального положения вещей (того, к чему нужно

стремиться (модель TO-BE)). Методология IDEF0 предписывает

построение иерархической системы диаграмм – единичных описаний

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

ее взаимодействия с окружающим миром (контекстная диаграмма),

после чего проводится функциональная декомпозиция (система

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

(диаграммы декомпозиции)). Затем каждая подсистема разбивается на

более мелкие и т.д. до достижения нужной степени подробности. После

каждого сеанса декомпозиции проводится сеанс экспертизы: каждая

27

диаграмма проверяется экспертами предметной области,

представителями заказчика, людьми, непосредственно участвующими в

бизнес-процессе. Такая технология создания модели позволяет

построить модель, адекватную предметной области на всех уровнях

абстрагирования. Если в процессе моделирования нужно осветить

специфические стороны технологии предприятия, BPwin позволяет

переключиться на любой ветви модели на нотацию IDEF3 или DFD и

создать смешанную модель. Нотация DFD включает понятия «внешняя

ссылка» и «хранилище данных», что делает ее более удобной (по

сравнению с IDEF0) для моделирования документооборота.

Методология IDEF3 включает элемент «перекресток», что позволяет

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

На основе модели BPwin можно построить модель данных. Для

построения модели данных Computer Associates предлагает мощный и

удобный инструмент – AIIFusion ERwin Data Modeler (ERwin). Хотя

процесс преобразования модели BPwin в модель данных плохо

формализуется и поэтому полностью не автоматизирован, Computer

Associates предлагает удобный инструмент для облегчения построения

модели данных на основе функциональной модели – механизм

двунаправленной связи BPwin – ERwin (стрелка 1 на рис. 5). ERwin

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

Модель данных может содержать как оба этих уровня, так и только один

из них. Модели, содержащие только один уровень, могут быть

синхронизированы, что особенно удобно при создании гетерогенных

информационных систем. На логическом уровне данные не связаны с

конкретной СУБД, поэтому могут быть наглядно представлены даже для

неспециалистов. Физический уровень данных – это отображение

системного каталога, который зависит от конкретной реализации СУБД.

Создание одного логического уровня и нескольких соответствующих

ему физических уровней позволяет вести одновременную разработку баз

данных для нескольких СУБД. ERwin позволяет проводить процессы

прямого и обратного проектирования баз данных (стрелка 2 на рис. 5).

Это означает, что по модели данных можно сгенерировать схему базы

данных или автоматически создать модель данных на основе

информации системного каталога. Кроме того, ERwin помогает

выравнивать модель и содержимое системного каталога после

редактирования.

Для больших, содержащих сотни таблиц моделей данных

существенной проблемой становится поиск и исправление ошибок.

Решение этой проблемы вручную – слишком трудоемкая задача, которая

может недопустимо затянуть выполнение проекта. AllFusion Data Model

Validator (ERwin Examiner) – основанный на базе знаний инструмент,

который позволяет анализировать структуру баз данных с целью

выявления недочетов и ошибок проектирования. ERwin Examiner

дополняет функциональность ERwin, автоматизируя трудоемкую задачу

28

поиска и исправления ошибок. ERwin Examiner может использовать в

качестве источника метаданных готовую модель ERwin, DDL-скрипт

или проводить обратное проектирование базы данных (стрелки 3 и 4 на

рис. 5).

При проектировании больших ИС ключевой проблемой является

создание качественной документации по моделям. BPwin и ERwin

позволяют генерировать разнообразные отчеты, которые могут быть

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

экспортируются в распространенные форматы (текстовый, MS Office,

HTML и др.). Результаты экспорта используются для создания отчетов с

помощью средств других производителей, например Crystal Reports.

BPwin поддерживает также экспорт и импорт модели в текстовый файл

формата IDL, который является стандартом для экспорта и импорта

моделей IDEF0, позволяет разрабатывать функциональные модели

одновременно инструментальными средствами различных

производителей.

Создание современных ИС, основанных на широком

использовании распределенных вычислений, объединении

традиционных и новейших информационных технологий, требует

тесного взаимодействия всех участников проекта: менеджеров, бизнес-

аналитиков и системных аналитиков, администраторов баз данных,

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

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

объединены общей системой организации совместной работы. Фирма

Computer Associates предлагает систему ModelMart – хранилище

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

ИС (стрелка 5 на рис. 5).

Вопрос 5. Прототипное проектирование (RAD-технологии).

С появлением корпоративных экономических информационных

систем, базирующихся на архитектуре «клиент-сервер», появляется

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

параллельного создания клиентской и серверной частей. Основное

желание заказчика ИС – быстро получить готовое приложение высокого

качества при минимальных затратах на его разработку. Кроме того,

вкладывая значительные средства на создание системы, заказчики

желают контролировать процесс разработки. Критерием качества

должно быть наиболее полное удовлетворение требований заказчиков на

момент введения системы в эксплуатацию.

Одним из условий обеспечения высокого качества создаваемых

ИС является активное вовлечение конечных пользователей в процесс

разработки предназначенных для них интерактивных систем, что нашло

отражение в методологии прототипного проектирования. Ядром этой

методологии является быстрая разработка приложений RAD (Rapid

29

Application Development), в основе которой заложена спиральная модель

жизненного цикла ИС.

Под RAD обычно понимается процесс разработки ПО,

содержащий три элемента:

небольшую команду программистов (от двух до десяти

человек);

короткий, но тщательно проработанный производственный

график (от двух до шести месяцев);

повторяющийся цикл, при котором разработчики, по мере того,

как приложение начинает обретать форму, запрашивают и реализуют в

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

Команда разработчиков должна представлять из себя группу

профессионалов, имеющих опыт в анализе, проектировании, генерации

кода и тестировании ПО с использованием CASE-средств.

Члены коллектива должны также уметь трансформировать в

рабочие прототипы предложения конечных пользователей.

Область самостоятельной разработки информационных систем

(приложений) конечными пользователями ограничена. Такой вариант

может быть применим для решения простых задач информационно-

поискового и сводного характера.

При создании более сложных корпоративных ИС пользователям

необходимо работать совместно с проектировщиками на протяжении

всего периода разработки. Для повышения качества и эффективности

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

прототипного проектирования. Она обеспечивает создание на ранней

стадии реализации действующей интерактивной модели системы, так

называемой системы-прототипа, позволяющей наглядно

продемонстрировать пользователю будущую систему, уточнить его

требования, оперативно модифицировать элементы интерфейса (формы

ввода сообщений, меню, выходные документы, структуру диалога,

состав реализуемых функций).

Достоинства. В процессе работы с системой-прототипом

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

определяет наиболее удобный для него режим обработки данных, что

значительно повышает качество создаваемых систем. Осуществляются

проверка принципиальных проектных решений по составу и структуре

ЭИС и оценка основных ее эксплуатационных характеристик.

Вовлечение пользователей в процесс проектирования и

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

дополнения к требованиям непосредственно в процессе проектирования

приложения, сокращая время разработки. Представители заказчика

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

влиять на ее функциональное наполнение. Результатом является сдача в

эксплуатацию системы, учитывающей большинство потребностей

30

заказчиков.

Согласованная система-прототип служит спецификацией для

дальнейшей разработки ЭИС, что позволяет на ранних этапах

проектирования выявить возможные ошибки проектирования и

определить параметры будущей системы.

Основные возможности и преимущества быстрой разработки

прототипа ИС представлены на рис. 6.

Рис. 6. Основные возможности и преимущества RAD-технологий

Все приемы для быстрой разработки приложений RAD служат

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

стоимости разработки. К числу этих приемов относятся:

1) разработка приложения итерациями;

2) необязательность полного завершения работ на каждом из

этапов ЖЦ для начала работ на следующем;

3) обязательное вовлечение пользователей в процесс

проектирования и построения системы;

4) высокая параллельность работ;

5) повторное использование частей проекта;

6) необходимое применение CASE-cpeдств, обеспечивающих

техническую целостность на этапах анализа и проектирования;

7) применение средств управления конфигурациями,

облегчающее внесение изменений в проект и сопровождение готовой

системы;

31

8) использование автоматических генераторов (мастеров);

9) использование прототипирования, позволяющего полнее

выяснить и удовлетворить потребности конечного пользователя;

10) тестирование и развитие проекта, осуществляемые

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

Каждое из перечисленных положений в отдельности способствует

повышению скорости, улучшению качества, но только их совместное

применение вызывает качественные изменения в процессе разработки.

Итерационное использование прототипного подхода к

разработке ИС обеспечивает экономию ресурсов на проектирование,

резкое сокращение времени на разработку и внедрение системы, а

также значительное снижение объема доработок ИС при ее внедрении.


1. Дайте определение CASE-средств.

2. Какие факторы способствовали проявлению CASE-средств?

3. Какова структура CASE-средств?

4. Как классифицируются CASE-средства?

5. Назовите основные составляющие и их предназначение

программного пакета AllFusion Modeling Suite.

6. В чем заключается сущность прототипного (RAD)

проектирования?

7. Каковы основные возможности и преимущества быстрой

разработки прототипа?




доп. – М.: Финансы и Статистика, 2006 – 544 с. – С. 24–36.



Ю.Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с. – Глава 13.

3. Уткин В.Б. Информационные системы в экономике: учебник для

студ. высш. учеб. заведений / В.Б. Уткин, К.В. Балдин. – М.:

Издательский центр «Академия», 2004. – 288 с. – Глава 4.


1. CASE-средства – это …

а) средства генерации схем баз данных

б) системы управление базами данных

в) средства генерации программного кода

г) средства автоматизации всего процесса проектирования

32

2. Наибольшая потребность в CASE-средствах возникает на:

а) этапах написания проектной документации

б) начальных этапах анализа и спецификации требований

в) этапах генерации программного кода

г) этапах внедрения и сопровождения

3. По поддерживаемым методологиям CASE-средства бывают:

а) структурно-ориентированные и объектно-ориентированные

б) локальные и сетевые

в) типовые и оригинальные

г) каскадные и спиральные

4. Для получения информации о состоянии проекта в виде

различных отчетов в CASE-средстве служит:

а) репозитарий

б) документатор

в) верификатор

г) администратор

5. AllFusion Modeling Suite выпущен компанией:

а) IBM

б) Computer Associates

в) Oracle

г) Microsoft

6. Для создания моделей данных и генерации схем баз данных в

AllFusion Modeling Suite служит:

а) Process Modeler

б) Data Modeler

в) Data Model Validator

г) Model Manager

7. Методологию IDEF0 поддерживает:

а) Process Modeler

б) Data Modeler

в) Data Model Validator

г) Model Manager

8. Критерий качества систем должен заключаться в:

а) полноте проектной документации

б) своевременной сдаче системы

в) низкой стоимости сопровождения

г) наиболее полном удовлетворении требований заказчиков

33

9. Для методологии RAD не характерно:

а) небольшая команда разработчиков

б) короткий график

в) каскадная модель ЖЦ

г) вовлечение пользователей в процесс проектирования

10. Снижение стоимости разработки при использовании RAD

происходит преимущественно из-за:

а) повторного использования компонент

б) высокой параллельности работ

в) использования CASE-средств

34

Тема 4. Состав и содержание работ по этапам жизненного цикла ПО.

Проектная документация

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

структуры проектной документации.

Задачи темы: ознакомление со стандартами проектной

документации и этапами ее создания; формирование навыков по

разработке Технического задания и Постановки задачи; изучение

особенностей формирования проектной документации на этапах

внедрения.


1. Состав и содержание проектной документации.

2. Предпроектное исследование и техническое задание.

3. Техно-рабочее проектирование.

4. Состав и содержание работ на стадиях внедрения, эксплуатации

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

Вопрос 1. Состав и содержание проектной документации.

Состав и содержание проектной документации будет

рассматриваться в этой главе на примере канонического

проектирования. Каноническое проектирование ИС отражает

особенности ручной технологии индивидуального (оригинального)

проектирования без использования инструментальных средств.

Каноническое проектирование применяется для небольших локальных

ИС.

В основе канонического проектирования ИС лежит каскадная

модель ЖЦ ИС, включающая следующие стадии:

исследование и обоснование создания системы;

разработка технического задания (ТЗ);

создание эскизного проекта (ЭП);

техническое проектирование (ТП);

рабочее проектирование (РП);

ввод в действие;

функционирование, сопровождение, модернизация.

Перечисленные стадии процесса разработки ИС можно

представить в сгруппированном виде (см. рис. 7).

35

Рис. 7. Технологическая сеть проектирования ИС

где

Д1.1 – предметная область;

Д1.2 – материалы обследования;

Д1.3 – ТЭО, ТЗ на проектирование;

Д1.4 – ЭП (эскизный проект);

Д2.1 – ТРП (техно-рабочий проект);

Д3.1 – исправленный ТРП, переданный в эксплуатацию;

Д3.2 – акт о приеме проекта в промышленную эксплуатацию;

Д4.1 – модернизированный ТРП;

П 1. – предпроектная стадия;

П 2. – стадия проектирования;

П 3. – стадия внедрения;

П 4. – стадия эксплуатации и сопровождения.

ТЭО содержит расчеты и обоснование необходимости разработки

ЭИС.

ТЗ включает в себя требования к системе и ее компонентам

(программному, техническому и информационному обеспечению) и

целевую установку на проектирование новой ЭИС.

ЭП содержит сформулированные выше требования, которые

являются основой для разработки предварительных решений по ЭИС.

Прорабатываются информационные потребности на уровне документов

и показателей.

Вопрос 2. Предпроектное исследование и техническое задание.

Анализ материалов обследования позволяет разработчикам:

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

(отделов технико-экономического планирования, оперативного

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

производства, МТС, реализации и сбыта готовой продукции,

бухгалтерии);

36

выявить список автоматизируемых задач (связь с другими

задачами, трудоемкость и оперативность расчета показателей, их

достаточность, достоверность выходных данных, очередность

проектирования решаемых задач и т.д.);

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

средств, типа операционных систем, способа организации

информационной базы (ИБ) (локальные, интегрированные1) и

программного средства ведения ИБ (выбираются исходя из класса

хранения данных: систем управления файлами, или СУБД), методов и

средств проектирования ПО системы (зависит от выбранной технологии

проектирования).

Выполнение всех этих операций завершается составлением ТЭО и

формированием ТЗ. Цель ТЭО разработки проекта – оценка параметров

(организационных, информационных и экономических).

Параметризация позволяет определить требования к системе, оценить

существующую ИС, определить пригодность типовых решений в

проекте ИС, выбрать проектные решения в соответствии с требованиями

к ИС.

На основе ТЭО разрабатываются основные требования к

будущему проекту ИС и составляется «Техническое задание» согласно

ГОСТ 34.602 – 89 «Техническое задание на создание АС», включающего

следующие разделы:

1) «Общие сведения о проекте» (наименование и код системы,

код договора, наименования организации-разработчика и организации-

заказчика, перечень документов, являющихся основой для создания

системы, сроки начала и окончания разработки ЭИС, источники

финансирования, порядок оформления и предъявления заказчику

результатов работ по созданию системы (ее частей)).

2) «Назначение и цели создания ЭИС».

3) «Характеристика объекта автоматизации».

4) «Требования к системе» состоят из следующих подразделов:

требования к системе в целом: к структуре и

функционированию системы; численности квалифицированных

работников; надежности и безопасности работы системы; эксплуатации,

техническому обслуживанию; сохранности информации при аварийных

ситуациях; унификации и стандартизации и т.д.;

требования к функциям (задачам), выполняемым системой: к

очередности их создания; временному регламенту и качеству

выполнения каждой функции, задачи или комплекса задач; форме

представления выходной информации; достоверности и т.д.;

требования к видам обеспечения (математическому,

программному, техническому, информационному и методическому).

1 Интегрированная БД – совокупность взаимосвязанных, хранящихся вместе данных, используемых

для одного или нескольких приложений.

37

5) «Состав и содержание работ по созданию системы»

(перечень стадий и этапов работ по созданию системы в соответствии с

ГОСТ 34.601 – 90 «Информационная технология. Комплекс стандартов

на автоматизированные системы. Автоматизированные системы. Стадии

создания»; сроки выполнения работ; перечень документов по ГОСТ

34.201 – 89 «Виды, комплектность и обозначение документов при

создании АС» и т.д.).

6) «Порядок контроля приемки системы» (виды, состав, методы

испытания системы и ее частей, общие требования к приемке работ по

стадиям, порядок утверждения приемных документов, статус

приемочной комиссии).

7) «Требования к составу и содержанию работ по подготовке

объекта автоматизации к вводу системы в действие» (перечень

мероприятий и исполнителей (приведение информации к виду

пригодному для ее ввода в ЭВМ, создание для функционирования

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

штатов, обучение персонала)).

8) «Требования к документированию» (разработка документов в

соответствии с ГОСТ 34.201 – 89 и научно-технической документации

отрасли заказчика).

9) «Источники разработки» (документы и информационные

материалы (ТЭО, отчеты о законченных научно-исследовательских

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

др.)).

Техническое задание включает в себя утвержденные методики,

приложения с расчетами экономической эффективности системы,

оценку научно-технического уровня системы.

Вопрос 3. Техно-рабочее проектирование.

На основе утвержденного ТЗ начинается стадия «Техно-рабочего

проектирования», включающая два этапа работ: техническое и рабочее

проектирование.

Техническое проектирование содержит:

1) разработку общесистемных проектных решений (уточняются

цели создания ИС и выполняемые ею функции, устанавливается ее

взаимосвязь с другими системами; уточняется и изменяется

организационная структура; разрабатывается функциональная

архитектура ЭИС);

2) разработку локальных проектных решений, к числу которых

относятся следующие операции:

разработка «Постановки задачи» (рис. 8) для задач, входящих в

состав функциональных подсистем;

38

проектирование форм входных и выходных документов,

макетов экранных форм документов, классификаторов экономической

информации;

проектирование состава и структур файлов информационной

базы;

проектирование внемашинной и внутримашинной технологий

решения каждой задачи;

уточнение состава технических средств.

Рис. 8. Содержание «Постановки задачи»

В состав «Характеристика задачи» входят:

описание цели автоматизации решения задачи (получение

экономического эффекта в сфере управления процессами системы,

снижение стоимостных и трудовых затрат на обработку информации,

повышение качества и достоверности получаемой информации,

оперативности ее обработки и т.д.);

описание экономической сущности решаемой задачи (состава

экономических показателей, рассчитываемых при ее решении;

документов, куда заносятся эти показатели);

описание организационной сущности задачи (порядка решения

задачи, режима решения, состава файлов с постоянной и переменной

информацией, способами и формами ввода и вывода результатной

информации и т.д.);

39

описание алгоритма (формализованное описание входных и

результатных показателей, перечень формул расчета, описание

математической модели, экономико-математических методов и т.д.);

для каждой задачи разрабатываются все компоненты

информационного, технического, математического и лингвистического

обеспечения, а также компоненты программного обеспечения.

Наиболее ответственной работой, выполняемой на этапе

«Рабочего проектирования» является «Кодирование и составление

программной документации», в состав которой входит:

описание программ;

спецификация программ;

тексты программ;

контрольные примеры;

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

В состав «Рабочего проекта» входит технологическая

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

на процессы обработки информации при решении задач, и

инструкционные карты, составляемые на каждую технологическую

операцию. Технологическая документация разрабатывается в

соответствии с ГОСТ 3.11.09-82 «Система технологической

документации. Термины и определения основных понятий».

Вопрос 4. Состав и содержание работ на стадиях внедрения,

эксплуатации и сопровождения проекта.

Внедрение проекта проходит три этапа:

1. Подготовка объекта к внедрению (изменяется организационная

структура, набор квалифицированных кадров в области обработки

информации и эксплуатации системы и сопровождения проектной

документации; приобретение и установка ВТ, оргтехники и т.д.;

установка каналов связи; разработка новых документов и

классификаторов; создание информационной базы с нормативно-

справочной информацией. Результатом является «Акт готовности

объекта к внедрению»).

2. Опытное внедрение (подготовка исходных оперативных

данных; ввод данных в ЭВМ и реализация поставленных решений;

анализ результатных данных на наличие ошибок. При выявлении

ошибочных ситуаций, вносятся коррективы в программы, технологию

обработки информации, в работу технических средств и т.п. После

устранения ошибок составляется «Акт о проведении опытного

внедрения»).

40

3. Сдача проекта в промышленную эксплуатацию сопровождается

следующей документацией:

договорная документация;

«Приказ на разработку ЭИС»;

исправленный «ТРП»;

«Приказ о начале промышленного внедрения»;

«Программа проведения испытаний»;

«Требования к научно-техническому уровню проекта системы».

В процессе сдачи проекта в промышленную эксплуатацию

осуществляются такие работы, как проверка соответствия выполненной

работы договорной документации, соответствие проектной

документации ГОСТам и ОСТам, проверка качества функционирования

информационной базы, оперативности и полноты ответов на запросы и

т.д.

Приемная комиссия определяет научно-технический уровень

проекта и возможности расширения проектных решений за счет

включения новых компонентов. В результате выполнения работ на

данном этапе осуществляется доработка «ТРП» за счет выявления

системных и локальных ошибок и составляется «Акт сдачи проекта в

промышленную эксплуатацию.

На стадии «Эксплуатация и сопровождение проекта»

осуществляется устранение сбоев в системе, регистрация их в журналах,

отслеживание технико-экономических характеристик системы и

накопление статистики о качестве работы всех компонентов системы,

определение объемов доработок, сроков и стоимости на выполнение

этих работ.


1. Что такое каноническое проектирование и каковы особенности

его содержания?

2. Перечислите основные этапы канонического проектирования.

3. Каково назначение этапа «Анализ материалов обследования»?

4. Перечислите основные нормативные документы,

регламентирующие состав и содержание «Технического задания».

5. Каково назначение и состав «Технического задания»?

6. Какие работы «Техно-рабочего проектирования» относятся к

разработке общесистемных проектных решений? Каково их

содержание?

7. Что такое «Постановка задачи»? Каков состав компонентов

этого документа?

8. Каков состав разделов «Технического проекта»?

9. Каковы состав, последовательность выполнения работ на

стадии внедрения проекта?

41

10. Что входит в состав работ по подготовке объекта к внедрению

проекта ИС?




Ю.Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с. – Глава 3.

2. Уткин В.Б. Информационные системы в экономике: учебник для

студ. высш. учеб. заведений / В.Б. Уткин, К.В. Балдин. – М.:

Издательский центр «Академия», 2004. – 288 с. – Глава 2.


1. Основные нормативные документы, регламентирующие состав

и содержание проектной документации – это …

а) международные стандарты и методологии

б) стандарты РФ, ГОСТы

в) стандарты организации-заказчика

2. Неверно, что …

а) разработка технического задания начинается после

исследования предметной области

б) техническому проектированию предшествует эскизный проект

в) модернизация системы начинается сразу после внедрения

г) на этапе внедрения заканчивается жизненный цикл ИС

3. Оценка экономических, организационных и информационных

параметров будущей ИС является целью:

а) технического задания

б) техно-экономического обоснования

в) эскизного проекта

г) анализа материалов обследования

4. К предпроектной стадии не относят:

а) техническое задание

б) сбор материалов для обследования

в) технико-экономическое обоснование проекта

г) техно-рабочий проект

42

5. Основное назначение Технического задания это …

а) формулировка требований к будущей ИС

б) оценка эффективности функционирования и срока

окупаемости будущей ИС

в) выбор программных средств реализации

г) отражение общих сведений о проекте

6. Неверно, что техническое задание включает …

а) постановку задачи

б) требования к системе

в) характеристику объекта автоматизации

г) состав и содержание работ по созданию системы

7. Общесистемные и локальные проектные решения

разрабатываются на этапе:

а) Эскизного проекта

б) Технического проекта

в) Рабочего проекта

г) Постановки задачи

8. Основная работа на этапе рабочего проектирования – это …

а) непосредственно программирование

б) апробация всей системы

в) проектирование форм документов

г) разработка структуры базы данных

9. В стадию внедрения проекта не входит …

а) подготовка объекта к внедрению

б) опытное внедрение

в) сдача проекта в промышленную эксплуатацию

г) тестирования программы

10. Переподготовка и реорганизация кадров в связи с внедрением

новой ИС фиксируется в:

а) Акте о проведение опытного внедрения

б) Приказе о начале промышленного внедрения

в) Акте о готовности объекта к внедрению

г) Программе проведения испытаний

43

Тема 5. Проектирование информационного и программного

обеспечения

Цель темы: освоение разработки программного обеспечения с

помощью средств и методов объектно-ориентированного


Задачи темы: изучение методологии проектирования ПО в рамках

объектно-ориентированного подхода, формирование навыков

использования языка UML и объектно-ориентированных CASE-средств

для спецификации предметной области и формирования моделей

будущих информационных систем.


1. Основные принципы построения объектной модели. Основные

элементы объектной модели.

2. Унифицированный язык моделирования UML.

3. Методология моделирования Rational Unified Process.

Вопрос 1. Основные принципы построения объектной модели.

Основные элементы объектной модели.

При проектировании сложной или достаточно объемной

программной системы ее, как правило, делят на части, каждую из

которых затем рассматривают и разрабатывают отдельно. При этом

используется либо функциональное деление системы, либо объектная

декомпозиция.

При функциональном делении программной системы ее структура

может быть описана блок-схемой, узлы которой обозначают

выполняемые функции, а связи указывают последовательность их

выполнения. Программные модули, реализующие функции, обычно

используются только в составе данной системы.

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

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

сообщениями. Сообщения описывают или представляют собой

некоторые события. Получение объектом сообщения активизирует его и

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

В результате программная система перестает быть последовательностью

определенных на этапе кодирования действий, а становится событийно-

управляемой. Инициаторами событий могут быть не только объекты

системы, но и ее внешнее окружение, например, пользователи.

44

Объекты имеют определенные свойства и методы.

Свойства объекта – это значения, которые устанавливаются для

определения его вида и поведения.

Методы объекта – это программные процедуры, обеспечивающие

выполнение им определенных действий.

Совокупность объектов, имеющих общий набор свойств и

характеризующихся одинаковым поведением, называется классом.

Классы могут строиться по иерархическому принципу, когда один класс

может быть подклассом другого класса. Из определения класса следует,

что каждый объект является экземпляром одного определенного класса.

Важной особенностью объекта является его автономность и

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

языка программирования. Таким образом, однажды разработанный и

отлаженный программный код может многократно применяться в

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

необходимые действия достаточно установить его свойства и вызвать

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

программирования развитой библиотеки компонентов разработка

программ сводится в основном к связыванию имеющихся объектов, что

существенно облегчает и ускоряет процесс проектирования. Такая

технология разработки программных модулей получила название

объектно-ориентированного программирования.

Основными принципами объектно-ориентированного

программирования являются наследование, инкапсуляция и

полиморфизм.

Принцип, в соответствии с которым знание о более общей

категории разрешается применять для более узкой категории,

называется наследованием. Наследование тесно связано с иерархией

классов. При этом если некоторый родительский класс обладает

фиксированным набором свойств и поведением, то производный от него

класс должен содержать этот же набор свойств и обладать таким же

поведением, а также дополнительными свойствами и видами поведения,

которые будут определять уникальность созданного таким образом

класса.

Принцип инкапсуляции характеризует сокрытие деталей

внутреннего устройства классов от внешних по отношению к нему

объектов или пользователей. То есть взаимодействующему с классом

объекту или пользователю не нужно знать, каким образом реализован

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

Полиморфизм в объектно-ориентированном программировании

означает, что действия, выполняемые одноименными методами, могут

отличаться в зависимости от того, к какому из классов они относятся.

45

Вопрос 2. Унифицированный язык моделирования UML.

В настоящее время для объектно-ориентированного

моделирования проблемной области широко используется

унифицированный язык моделирования UML (Unified Modeling

Language), который фактически является стандартом по объектно-

ориентированным технологиям.

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании

Rational Software, объединили свои усилия для создания нового языка

объектно-ориентированного моделирования. За основу языка ими были

взяты методы моделирования, разработанные Бучем (Booch) и Рамбо

(Object-Modeling Technique – OMT). OMT был ориентирован на анализ, а

Booch – на проектирование программных систем. В октябре 1995 года

была выпущена предварительная версия 0.8 унифицированного метода

(англ. Unified Method). Осенью 1995 года к компании Rational

присоединился Айвар Якобсон, автор метода Object-Oriented Software

Engineering – OOSE. OOSE обеспечивал превосходные возможности для

спецификации бизнес-процессов и анализа требований при помощи

сценариев использования. OOSE был также интегрирован в

унифицированный метод.

Система объектно-ориентированных моделей в соответствии с

нотациями UML включает в себя следующие диаграммы:

1) диаграмма вариантов использования, или прецедентов (use

case diagram) отображает функциональность ЭИС в виде совокупности

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

2) диаграмма классов (class diagram) отображает структуру

совокупности взаимосвязных классов объектов аналогично ER-

диаграмме функционально-ориентированного подхода;

3) диаграмма состояний (statechart diagram) отображает

динамику состояний объектов одного класса и связных с ними событий;

4) диаграммы взаимодействия (interaction diagrams)

отображают динамическое взаимодействие объектов в рамках одного

варианта использования;

5) диаграмма деятельности (activity diagram) отображает потоки

работ во взаимосвязных вариантах использования;

6) диаграмма пакетов (package diagram) отображает

распределение объектов по функциональным или обеспечивающим

подсистемам;

7) диаграмма компонентов (component diagram) отображает

физические модули программного кода;

8) диаграмма размещения (deployment diagram) отображает

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

46

Диаграмма вариантов использования.

Идея описания функциональных требований в виде вариантов

использования (use case) была сформулирована в 1986 г. Иваром

Якобсоном. Эта идея была признана конструктивной и получила

широкое одобрение. Впоследствии наиболее значительный вклад в

решение проблемы определения сущности вариантов использования и

способов их описания внес Алистер Коберн.

Вариант использования представляет собой последовательность

действий (транзакций), выполняемых системой в ответ на событие,

которое было инициировано некоторым внешним объектом

(действующим лицом). Вариант использования описывает типичное

взаимодействие между пользователем и системой и отражает

представление о поведении системы с точки зрения пользователя. В

простейшем случае вариант использования определяется в процессе

обсуждения с пользователем тех функций, которые он хотел бы

реализовать, или целей, которые он преследует по отношению к

разрабатываемой системе.

Действующее лицо (actor) – это роль, которую пользователь

играет по отношению к системе. Действующие лица представляют собой

роли, а не конкретных людей или наименования работ.

Несмотря на то, что на диаграммах вариантов использования

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

фигурок, они могут также быть внешней системой, которой необходима

некоторая информация от данной системы.

Действующие лица делятся на три основных типа:

пользователи системы;

другие системы, взаимодействующие с данной системой;

время.

Время становится действующим лицом, если от него зависит

запуск каких-либо событий в системе.

Для наглядного представления вариантов использования

применяются диаграммы вариантов использования. На рис. 9 показан

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

47

Рис. 9. Пример диаграммы вариантов использования

На диаграмме вариантов использования показано взаимодействие

между вариантами использования и действующими лицами. Она

отражает функциональные требования к системе с точки зрения

пользователя. Таким образом, варианты использования – это функции,

выполняемые системой, а действующие лица – это заинтересованные

лица (stakeholders) по отношению к создаваемой системе. Такие

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

использования. Из них также видно, когда действующее лицо получает

информацию от варианта использования. Направленная от варианта

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

использования предоставляет некоторую информацию, используемую

действующим лицом. В данном случае вариант использования «Сделать

платеж» предоставляет Кредитной системе информацию об оплате по

48

кредитной карточке. Действующие лица могут играть различные роли

по отношению к варианту использования. Они могут пользоваться его

результатами или сами непосредственно в нем участвовать. Значимость

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

используются его связи.

Цель построения диаграмм вариантов использования –

документирование функциональных требований к системе в самом

общем виде (поэтому они должны быть предельно простыми).

При построении диаграмм вариантов использования нужно

придерживаться следующих правил:

Не следует моделировать связи между действующими лицами.

По определению действующие лица находятся вне сферы действия

системы. Это означает, что связи между ними также не относятся к ее

компетенции.

Не нужно соединять стрелкой два варианта использования

непосредственно. Диаграммы данного типа описывают только сами

варианты использования, а не порядок их выполнения. Для отображения

порядка выполнения вариантов использования применяют диаграммы

деятельности.

Каждый вариант использования должен быть инициирован

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

начинающаяся на действующем лице и заканчивающаяся на варианте

использования.

Варианты использования являются необходимым средством на

стадии формирования требований к ПО. Каждый вариант

использования – это потенциальное требование к системе, и пока оно не

выявлено, невозможно запланировать его реализацию.

Диаграммы взаимодействия.

Диаграммы взаимодействия описывают поведение

взаимодействующих групп объектов (в рамках варианта использования

или некоторой операции класса). Как правило, диаграмма

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

потока событий варианта использования. На такой диаграмме

отображается ряд объектов и те сообщения, которыми они

обмениваются между собой.

Сообщение (message) – средство, с помощью которого объект-

отправитель запрашивает у объекта-получателя выполнение одной из

его операций.

Информационное (informative) сообщение – сообщение,

снабжающее объект-получатель некоторой информацией для

обновления его состояния.

Сообщение-запрос (interrogative) – сообщение, запрашивающее

выдачу некоторой информации об объекте-получателе.

49

Императивное (imperative) сообщение – сообщение,

запрашивающее у объекта-получателя выполнение некоторых действий.

Существуют два вида диаграмм взаимодействия: диаграммы

последовательности и кооперативные диаграммы.

Диаграммы последовательности отражают временную

последовательность событий, происходящих в рамках варианта

использования.

Например, вариант использования «Снять деньги со счета»

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

попытка снять деньги, не имея их достаточного количества на счете,

попытка снять деньги по неправильному PIN-коду и др.). Нормальный

сценарий (основной поток событий) снятия некоторой суммы денег со

счета показан на рис. 10.

50

Рис. 10. Диаграмма последовательности

Все действующие лица показаны в верхней части диаграммы; в

приведенном примере изображено действующее лицо Клиент

(Customer). Объекты, необходимые системе для выполнения варианта

использования «Снять деньги со счета», также представлены в верхней

части диаграммы. Стрелки соответствуют сообщениям, передаваемым

между действующим лицом и объектом или между объектами для

выполнения требуемых функций.

51

На диаграмме последовательности объект изображается в виде

прямоугольника на вершине пунктирной вертикальной линии. Эта

вертикальная линия называется линией жизни (lifeline) объекта. Она

представляет собой фрагмент жизненного цикла объекта в процессе

взаимодействия.

Вторым видом диаграммы взаимодействия является

кооперативная диаграмма (рис. 11).

Рис. 11. Кооперативная диаграмма

52

Подобно диаграммам последовательности кооперативные

диаграммы отображают поток событий варианта использования.

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

кооперативные диаграммы концентрируют внимание на связях между

объектами. На рис. 11 приведена кооперативная диаграмма,

описывающая, как клиент снимает деньги со счета. На ней представлена

та же информация, которая была и на диаграмме последовательности, но

кооперативная диаграмма по-другому описывает поток событий. Из нее

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

последовательность событий. По этой причине часто для какого-либо

сценария создают диаграммы обоих типов. Хотя они служат одной и той

же цели и содержат одну и ту же информацию, но представляют ее с

различных точек зрения.

На кооперативной диаграмме так же, как и на диаграмме

последовательности, стрелки обозначают сообщения, обмен которыми

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

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

сообщений.

Диаграмма классов и диаграмма пакетов.

Диаграмма классов определяет типы классов системы и

различного рода статические связи, которые существуют между ними.

На диаграммах классов изображаются также атрибуты классов,

операции классов и ограничения, которые накладываются на связи

между классами. Диаграмма классов для варианта использования «Снять

деньги со счета» показана на рис. 12.

53

Рис. 12. Диаграмма классов

На этой диаграмме присутствуют четыре класса: Card Reader

(устройство для чтения карточек), Account (счет), ATM Screen (экран

ATM) и Cash Dispenser (кассовый аппарат). Связывающие классы линии

отражают взаимодействие между классами. Так, класс Account связан с

классом ATM Screen, потому что они непосредственно сообщаются и

взаимодействуют друг с другом. Класс Card Reader не связан с классом

54

Cash Dispenser, поскольку они непосредственно не сообщаются друг с

другом.

На диаграмме классов в прямоугольниках в верхней части даны

имена классов, в средней части – имена атрибутов, в нижней части –

имена методов.

Для группировки классов, обладающих некоторой общностью,

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

элементов модели в группы. Пакет может включать другие элементы.

Каждый элемент модели может входить только в один пакет. Пакет

является средством организации модели в процессе разработки,

повышения ее управляемости и читаемости, а также единицей

управления конфигурацией.

Существуют несколько подходов к группировке классов. Во-

первых, их можно сгруппировать по стереотипу (типу класса).

Например, один пакет содержит классы-сущности предметной области

(Entities), другой – классы пользовательского интерфейса (Boundaries), а

третий – управляющие классы (Control). Этот подход может быть

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

Если между любыми двумя классами, находящимися в разных

пакетах, существует некоторая зависимость, то имеет место зависимость

и между этими двумя пакетами. Таким образом, диаграмма пакетов

(рис. 13) представляет собой диаграмму, содержащую пакеты классов и

зависимости между ними.

Рис. 13. Диаграмма пакетов

Пакеты и зависимости являются элементами диаграммы классов,

т.е. диаграмма пакетов – это форма диаграммы классов. Диаграммы

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

структурой системы.

55

Диаграммы состояний.

Диаграммы состояний определяют все возможные состояния, в

которых может находиться конкретный объект, а также процесс смены

состояний объекта в результате наступления некоторых событий.

Существует много форм диаграмм состояний, незначительно

отличающихся друг от друга семантикой.

На рис. 14 приведен пример диаграммы состояний для

банковского счета. Из данной диаграммы видно, в каких состояниях

может существовать счет. Можно также видеть процесс перехода счета

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

открытый счет, он переходит в состояние «закрыт». Требование клиента

называется событием (event). Именно такие события и вызывают

переход из одного состояния в другое.

Рис. 14. Диаграмма состояний для класса Account

56

На диаграмме имеются два специальных состояния – начальное

(start) и конечное (stop). На диаграмме состояний может быть только

одно начальное состояние, а конечных состояний может быть столько,

сколько нужно, или их может не быть вообще.

С состоянием можно связывать данные пяти типов: деятельность,

входное действие, выходное действие, событие и история состояния.

Рассмотрим каждый из них в контексте диаграммы состояний для класса

Account банковской системы.

Деятельность (activity) – это поведение, реализуемое объектом,

пока он находится в данном состоянии. Например, когда счет находится

в состоянии «Закрыт», происходит возврат кредитной карточки

пользователю. Деятельность – это прерываемое поведение. Оно может

выполняться до своего завершения, пока объект находится в данном

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

состояние. Деятельность изображают внутри самого состояния, ей

должно предшествовать слово do (выполнять) и двоеточие.

Входное действие (entry action) – это поведение, которое

выполняется, когда объект переходит в данное состояние. Когда счет в

банке переходит в состояние «Превышение кредита», выполняется

действие «Временно заморозить счет» независимо оттого, откуда объект

перешел в это состояние. В отличие от деятельности, входное действие

рассматривается как непрерываемое. Входное действие также

показывают внутри состояния, ему предшествует слово entry (вход) и

двоеточие.

Выходное действие (exit action) подобно входному, однако оно

осуществляется как составная часть процесса выхода из данного

состояния. Так, при выходе объекта Account из состояния «Превышение

кредита» независимо оттого, куда он переходит, выполняется действие

«Разморозить счет». Оно является частью процесса такого перехода. Как

и входное, выходное действие является непрерываемым. Выходное

действие изображают внутри состояния, ему предшествует слово exit

(выход) и двоеточие.

Переходом (transition) называется перемещение объекта из одного

состояния в другое. На диаграмме все переходы изображают в виде

стрелки, начинающейся на первоначальном состоянии и

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

рефлексивными. Объект может перейти в то же состояние, в котором он

в настоящий момент находится. Рефлексивные переходы изображают в

виде стрелки, начинающейся и завершающейся на одном и том же

состоянии. У перехода существует несколько спецификаций, основными

из которых являются события, ограждающие условия и действия.

Событие (event) вызывает переход из одного состояния в другое.

Событие «Клиент требует закрыть» вызывает переход счета из

открытого в закрытое состояние. Событие размещают на диаграмме

57

вдоль линии перехода. Большинство переходов должны иметь события,

так как именно они заставляют переход осуществиться.

Однако бывают и автоматические переходы, не имеющие событий.

При этом объект сам перемещается из одного состояния в другое со

скоростью, позволяющей осуществиться входным действиям,

деятельности и выходным действиям.

Ограничивающие условия (guard conditions) определяют, когда

переход может, а когда не может осуществиться. В примере событие

«Вклад денег» переведет счет из состояния «Превышение кредита» в

состояние «Открыт», но только если баланс будет больше нуля. В

противном случае переход не осуществится. Ограничивающие условия

изображают на диаграмме вдоль линии перехода после имени события,

заключая их в квадратные скобки. Ограничивающие условия задавать

необязательно. Однако если существует несколько автоматических

переходов из состояния, необходимо определить для них взаимно

исключающие ограждающие условия, чтобы понять, какой путь

перехода будет выбран автоматически. Действие изображают вдоль

линии перехода после имени события, ему предшествует косая черта.

Диаграммы состояний не надо создавать для каждого класса, они

применяются только в сложных случаях. Если объект класса может

существовать в нескольких состояниях и в каждом из них ведет себя по-

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

Диаграммы деятельности.

Диаграммы деятельности можно применять для описания потоков

событий в вариантах использования. С помощью текстового описания

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

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

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

ту же информацию, что и текстовое описание потока событий, но в

наглядной графической форме.

На рис. 15 приведена диаграмма деятельности для потока событий,

связанного с системой бронирования авиабилетов. Рассмотрим ее

нотацию.

58

Рис. 15. Диаграмма деятельности

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

(activity). Интерпретация этого термина зависит от той точки зрения, с

которой строится диаграмма (это может быть некоторая задача, которую

необходимо выполнить вручную или автоматизированным способом,

или операция класса). Деятельность изображается в виде закругленного

прямоугольника с текстовым описанием.

59

Любая диаграмма деятельности должна иметь начальную точку,

определяющую начало потока событий. Конечная точка необязательна.

На диаграмме может быть несколько конечных точек, но только одна

начальная.

На диаграмме могут присутствовать объекты и потоки объектов

(objectflow). Объект может использоваться или изменяться в одной из

деятельностей. Показ объектов и их состояний (в дополнение к

диаграммам состояний) помогает понять, когда и как происходит смена

состояний объекта.

Объекты связаны с деятельностями через потоки объектов. Поток

объектов отмечается пунктирной стрелкой от деятельности к

изменяемому объекту или от объекта к деятельности, использующей

объект.

Переход (стрелка) показывает, как поток управления переходит

от одной деятельности к другой. Если для перехода определено событие,

то переход выполняется только после наступления такого события.

Ограничивающие условия определяют, когда переход может, а когда не

может осуществиться. Если необходимо показать, что две или более

ветвей потока выполняются параллельно, используются линейки

синхронизации. В данном примере параллельно выполняются

резервирование места, формирование номера подтверждения и отправка

почтового сообщения, а после завершения всех трех процессов

пользователю выводится номер подтверждения.

Любая деятельность может быть подвергнута дальнейшей

декомпозиции. Описание декомпозированной деятельности может быть

представлено в виде другой диаграммы деятельности.

Диаграммы деятельности предпочтительнее использовать в

следующих ситуациях:

анализ потоков событий в конкретном варианте использования.

Здесь нас не интересует связь между действиями и объектами; нужно

только понять, какие действия должны иметь место и каковы

зависимости в поведении системы. Связывание действий и объектов

выполняется позднее с помощью диаграмм взаимодействия;

анализ потоков событий в различных вариантах использования.

Когда варианты использования взаимодействуют друг с другом, на

диаграмме деятельности удобно представить и проанализировать все их

потоки событий (в этом случае диаграмма с помощью вертикальных

пунктирных линий разделяется на «плавательные дорожки» (swimlanes)

(зоны). В каждой зоне изображаются потоки событий одного из

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

переходов или потоков объектов).

60

Диаграммы компонентов.

Диаграммы компонентов моделируют физический уровень

системы. На них изображаются компоненты ПО и связи между ними. На

такой диаграмме обычно выделяют два типа компонентов: исполняемые

компоненты и библиотеки кода.

Каждый класс модели (или подсистема) преобразуется в

компонент исходного кода. Между отдельными компонентами

изображают зависимости, соответствующие зависимостям на этапе

компиляции или выполнения программы.

На рис. 16 изображена одна из диаграмм компонентов для

банковской системы.

Рис. 16. Диаграмма компонентов для клиентской части

Компоненты соединены зависимостями. Например, класс Card

Reader зависит от класса ATM Screen. Это означает, что для того чтобы

класс Card Reader мог быть скомпилирован, класс ATM Screen должен

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

исполняемый файл ATMClient.exe.

61

Банковская система содержит два потока управления и, таким

образом, получаются два исполняемых файла. Один из них является

клиентской частью системы, которая содержит компоненты Cash

Dispenser, Card Reader и ATM Screen. Второй файл – это сервер,

включающий в себя компонент Account. Диаграмма компонентов для

сервера показана на рис. 17.

Рис. 17. Диаграмма компонент для серверной части

Как видно из примера, в модели системы может быть несколько

диаграмм компонентов. Это зависит от числа подсистем или

исполняемых файлов. Каждая подсистема является пакетом

компонентов.

Диаграммы компонентов применяются теми участниками проекта,

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

начинается генерация кода.

Диаграмма размещения.

Диаграмма размещения отражает физические взаимосвязи между

программными и аппаратными компонентами системы. Она является

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

компонентов в распределенной системе. Каждый узел на диаграмме

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

устройства (в большинстве случаев, часть аппаратуры). Эта аппаратура

может быть простым устройством или мэйнфреймом.

62

Рис. 18. Диаграмма размещения для банковской системы

Диаграмма размещения показывает физическое расположение сети

и местонахождение в ней различных компонентов. Ее основные

элементы:

узел (node) – вычислительный ресурс – процессор или другое

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

Для узла можно задать выполняющиеся на нем процессы;

соединение (connection) – канал взаимодействия узлов (сеть).

Например, банковская система состоит из большого количества

подсистем, выполняемых на отдельных физических устройствах, или

узлах. Диаграмма размещения для такой системы показана на рис. 18.

Из данной диаграммы можно узнать о физическом размещении

системы. Клиентские программы будут работать в нескольких местах на

различных сайтах. Через закрытые сети будет осуществляться их

сообщение с региональным сервером системы. На нем будет работать

ПО сервера. Посредством локальной сети региональный сервер будет

сообщаться с сервером банковской базы данных, работающим под

управлением Oracle. Наконец, с региональным сервером соединен

принтер.

63

Диаграмма размещения используется менеджером проекта,

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

персоналом, чтобы понять физическое размещение системы и

расположение ее отдельных подсистем.

Вопрос 3. Методология моделирования Rational Unified Process.

Rational Unified Process (RUP) – методология разработки

программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие основные принципы:

ранняя идентификация и непрерывное (до окончания проекта)

устранение основных рисков;

концентрация на выполнении требований заказчиков к

исполняемой программе (анализ и построение модели прецедентов);

ожидание изменений в требованиях, проектных решениях и

реализации в процессе разработки;

компонентная архитектура, реализуемая и тестируемая на

ранних стадиях проекта;

постоянное обеспечение качества на всех этапах разработки

проекта (продукта);

работа над проектом в сплоченной команде, ключевая роль в

которой принадлежит архитекторам.

RUP использует итеративную модель разработки. В конце каждой

итерации (в идеале продолжающейся от двух до шести недель)

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

итерацию целей, создать или доработать проектные артефакты и

получить промежуточную, но функциональную версию конечного

продукта. Итеративная разработка позволяет быстро реагировать на

меняющиеся требования, обнаруживать и устранять риски на ранних

стадиях проекта, а также эффективно контролировать качество

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

представленный на рис. 19, состоит из четырех фаз, каждая из которых

включает в себя одну или несколько итераций.

64

Рис. 19. Графическое представление процесса разработки по RUP

1. Начало (Inception).

На этом этапе:

формируются видение и границы проекта;

создается экономическое обоснование (business case);

определяются основные требования, ограничения и ключевая

функциональность продукта;

создается базовая версия модели прецедентов;

оцениваются риски.

При завершении начальной стадии оценивается достижение вехи

целей жизненного цикла (англ. Lifecycle Objective Milestone), которое

предполагает соглашение заинтересованных сторон о продолжении

проекта.

2. Проектирование (Elaboration).

На этапе проектирования производится анализ предметной

области и построение исполняемой архитектуры. Это включает в себя:

документирование требований (включая детальное описание для

большинства прецедентов);

спроектированную, реализованную и оттестированную

исполняемую архитектуру;

65

обновленное экономическое обоснование и более точные

оценки сроков и стоимости;

сниженные основные риски.

Успешное выполнение фазы проектирования означает достижение

вехи архитектуры жизненного цикла (англ. Lifecycle Architecture

Milestone).

3. Построение (Construction).

Во время этой фазы происходит реализация большей части

функциональности продукта. Данная фаза завершается первым внешним

релизом системы и вехой начальной функциональной готовности (Initial

Operational Capability).

4. Внедрение (Transition).

Во время фазы внедрения создается финальная версия продукта,

которая передается от разработчика к заказчику. Это включает в себя

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

определение качества продукта. Если качество не соответствует

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

фаза внедрения повторяется снова. Выполнение всех целей означает

достижение вехи готового продукта (Product Release) и завершение

полного цикла разработки.


1. Что такое свойства и методы объекта?

2. По какому принципу объекты группируются в классы?

3. Какой язык используется для объектно-ориентированного

моделирования?

4. Каково основное предназначение диаграмм вариантов

использования?

5. Дайте характеристику двум видам диаграмм взаимодействия.

6. Опишите основные элементы диаграммы классов.

7. Что такое пакет?

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

9. Опишите основные элементы диаграммы состояний.

10. Какие диаграммы моделируют физический уровень

подсистемы? Перечислите их основные элементы.

11. Перечислите основные принципы и фазы методики RUP.

66




доп. – М.: Финансы и Статистика, 2006 – 544 с. – С. 162–209.



Ю.Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с. – С. 351–

373.


1. Значения, которые устанавливаются для определения вида и

поведения объекта – это …

а) свойства объекта

б) методы объекта

в) классы объекта

г) полиморфизм

2. Требования к системе фиксируется в диаграммах …

а) вариантов использования

б) классов

в) деятельности

г) кооперации

3. В качестве действующего лица (актера) на диаграммах

вариантов использования не может выступать …

а) пользователь системы

б) клиент

в) Иванов И.И.

г) время

4. Диаграммы взаимодействия отражаются в виде …

а) диаграммы деятельности

б) кооперативной диаграммы

в) диаграммы последовательности

г) диаграммы классов

5. На диаграммах взаимодействия стрелки являются …

а) вариантами использования

б) сообщениями

в) классами

г) условиями

67

6. В UML не существует стереотипа (типа класса) …

а) сущность

б) управление

в) пользовательский интерфейс

г) состояние

7. На диаграмме состояний переход от одного состояния к

другому вызывает …

а) определяющее условие

б) входное действие

в) событие

г) выходное действие

8. Для описания потоков событий в вариантах использования

используют …

а) диаграмму деятельности

б) диаграмму состояний

в) диаграмму кооперации

г) диаграмму взаимодействия

9. Исполняемые компоненты и библиотеки кода иллюстрируются

на диаграмме …

а) размещения

б) классов

в) компонентов

г) состояний

10. В методологии RUP фаза Проектирование не включает в себя:

а) создание базовой версии модели прецедентов

б) документирование требований

в) построение исполняемой архитектуры

г) более точные оценки сроков и стоимости

68

Тема 6. Структурные методы анализа и проектирования ПО

Цель темы: освоение разработки программного обеспечения с

помощью средств и методов структурного проектирования.

Задачи темы: изучение различных методологий проектирования

ПО в рамках структурного подхода (IDEF0, IDEF1X, IDEF3);

формирование навыков использования функционально-

ориентированных CASE-средств для спецификации предметной области

и формирования моделей будущих информационных систем;

ознакомление с принципами реинжиниринга бизнес-процессов.


1. Метод функционального проектирования SADT.

2. Методология формализации и описания бизнес-процессов

IDEF0 (общие сведения, состав функциональной модели,

функциональная декомпозиция).

3. Функциональное проектирование в среде AllFusion Process

Modeler (модели AS-IS и TO-BE).

4. Реинжиниринг бизнес-процессов.

5. Моделирование процессов в нотации IDEF3.

6. Моделирование потоков данных, диаграммы потоков данных

(DFD).

7. Моделирование данных, методология проектирования

реляционных баз данных IDEF1X, моделирование данных в среде

AllFusion ERwin Data Modeler.

Вопрос 1. Метод функционального проектирования SADT.

Сущность структурного подхода к разработке ИС заключается в ее

декомпозиции (разбиении) на автоматизируемые функции. Система

разбивается на функциональные подсистемы, которые делятся на

подфункции, подразделяемые на задачи и т.д. Процесс разбиения

продолжается вплоть до конкретных процедур. При этом

автоматизируемая система сохраняет целостное представление, в

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

системы «снизу-вверх» от отдельных задач ко всей системе целостность

теряется, возникают проблемы при информационной стыковке

отдельных компонентов.

Структурное (функциональное) проектирование – это метод

определения подсистем, компонентов и способов их соединения,

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

выбирающий наиболее эффективное сочетание людей, машин и

программного обеспечения для реализации системы.

69

В качестве примера рассмотрим одну из широко используемых

систем такого проектирования – SADT (Structured Analysis and Design

Technique – технология структурного анализа и проектирования) –

это графические обозначения и подход к описанию систем.

SADT создана для описания системы и ее среды до определения

требований к программному обеспечению и др. Она облегчает описание

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

используется графический язык и набор процедур анализа для

понимания системы прежде, чем можно представить себе ее

воплощение. Она, как правило, применяется на ранних этапах процесса

создания системы, который часто называют «жизненным циклом

системы».

SADT-модель – иерархически организованная совокупность

диаграмм. Диаграммы обычно состоят из трех-шести блоков, каждый из

которых потенциально может быть детализирован на другой диаграмме.

Каждая диаграмма представляет некоторую законченную часть всей

модели.

Каждый блок может пониматься как отдельный тщательно

определенный объект. Разделение такого объекта на его структурные

части (блоки и дуги, составляющие диаграмму) называется

декомпозицией.

Метод SADT реализован в виде стандарта IDEF0.

Вопрос 2. Методология формализации и описания бизнес-

процессов IDEF0 (общие сведения, состав функциональной модели,

функциональная декомпозиция).

На начальных этапах создания ИС необходимо понять, как

работает организация, которую собираются автоматизировать. Для

описания работы предприятия необходимо построить модель. Такая

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

содержать в себе знания всех участников бизнес-процессов организации.

Наиболее удобным языком моделирования бизнес-процессов

является 1DEF0, предложенный более 20 лет назад Дугласом Россом

(SoftTech, Inc.) и называвшийся первоначально SADT-Structured Analysis

and Design Technique (подробно методология SADT излагается в книге

Дэвида А. Марка и Клемента Мак-Гоуэна «Методология структурного

анализа и проектирования SADT»). В начале 70-х годов вооруженные

силы США применили подмножество SADT, касающееся

моделирования процессов для реализации проектов в рамках программы

ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это

подмножество SADT было принято в качестве федерального стандарта

США под наименованием IDEF0. Подробные спецификации на

стандарты IDEF можно найти на сайте http://www.idef.com/.

http://www.idef.com/

70

В IDEF0 система представляется как совокупность

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

ориентация является принципиальной (функции системы анализируются

независимо от объектов, которыми они оперируют). Это позволяет более

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

Под моделью в IDEF0 понимают описание системы (текстовое и

графическое), которое должно дать ответ на некоторые заранее

определенные вопросы.

Моделируемая система рассматривается как произвольное

подмножество Вселенной. Произвольное, потому что, во-первых, мы

сами умозрительно определяем, будет ли некий объект компонентом

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

вторых, оно зависит от точки зрения на систему. Система имеет границу,

которая отделяет ее от остальной Вселенной. Взаимодействие системы с

окружающим миром описывается как вход (нечто, что перерабатывается

системой), выход (результат деятельности системы), управление

(стратегии и процедуры, под управлением которых производится

работа) и механизм (ресурсы, необходимые для проведения работы).

Находясь под управлением, система преобразует входы в выходы с

помощью механизмов.

Графическая реализация методологии IDEF0 будет рассмотрена в

следующем параграфе.

Вопрос 3. Функциональное проектирование в среде AllFusion

Process Modeler (модели AS-IS и TO-BE).

Процесс моделирования какой-либо системы в IDEF0 начинается с

определения контекста, т.е. наиболее абстрактного уровня описания

системы в целом. В контекст входит определение субъекта

моделирования, цели и точки зрения на модель.

Под субъектом понимается сама система, при этом необходимо

точно установить, что входит в систему, а что лежит за ее пределами;

другими словами, мы должны определить, что мы будем в дальнейшем

рассматривать как компоненты системы, а что – как внешнее

воздействие.

IDEF0-модель предполагает наличие четко сформулированной

цели, единственного субъекта моделирования и одной точки зрения. Для

внесения области, цели и точки зрения в модели IDEF0 в BPwin следует

выбрать пункт меню Model/Model Properties, вызывающий диалог Model

Properties (см. рис. 20). Во вкладку Purpose следует внести цель и точку

зрения, а во вкладку Definition – определение модели и описание

области.

71

Рис. 20. Диалог задания свойств модели

Во вкладке Status того же диалога можно описать статус модели

(черновой, рабочий, окончательный вариант и т.д.), время создания и

последнего редактирования (отслеживается в дальнейшем

автоматически по системной дате). Во вкладке Source описываются

источники информации для построения модели (например, «Опрос

экспертов предметной области и анализ документации»). Вкладка

General служит для внесения имени проекта и модели, имени и

инициалов автора и временных рамок модели (AS-IS и TO-BE).

Диаграммы IDEF0. Основу методологии IDEF0 составляет

графический язык описания бизнес-процессов. Модель в нотации IDEF0

представляет собой совокупность иерархически упорядоченных и

взаимосвязанных диаграмм. Каждая диаграмма является единицей

описания системы и располагается на отдельном листе.

Модель может содержать четыре типа диаграмм:

контекстную (в каждой модели может быть только одна

контекстная диаграмма);

декомпозиции;

дерева узлов;

только для экспозиции (FEO).

72

Контекстная диаграмма является вершиной древовидной

структуры диаграмм и представляет собой самое общее описание

системы и ее взаимодействия с внешней средой (см. рис. 21). После

описания системы в целом проводится разбиение ее на крупные

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

диаграммы, которые описывают каждый фрагмент и взаимодействие

фрагментов, – диаграммами декомпозиции (см. рис. 22). После

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

каждого большого фрагмента системы на более мелкие и т.д. до

достижения нужного уровня подробности описания. После каждого

сеанса декомпозиции проводятся сеансы экспертизы: эксперты

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

процессов созданным диаграммам. Найденные несоответствия

исправляются; приступать к следующему сеансу декомпозиции можно

только после прохождения экспертизы без замечаний. Так достигается

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

модели. Синтаксис описания системы в целом и каждого ее фрагмента

одинаков во всей модели.

Рис. 21. Контекстная диаграмма IDEF0

73

Рис. 22. Диаграмма декомпозиции IDEF0

Диаграмма дерева узлов показывает иерархическую зависимость

работ, а не взаимосвязи между работами. Диаграмм деревьев узлов в

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

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

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

отдельных фрагментов модели, альтернативной точки зрения или

специальных целей.

Основными элементами диаграмм являются работы и стрелки.

Работы обозначают поименованные процессы, функции или

задачи, которые происходят в течение определенного времени и имеют

распознаваемые результаты. Работы изображаются в виде

прямоугольников. Все работы должны быть названы и определены. Имя

работы должно быть выражено сочетанием отглагольного

существительного, обозначающего процесс, например, «Изготовление

детали», «Прием заказа» и т.д. Работа «Изготовление детали» может

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

изготовления изделия от контроля качества сырья до отгрузки готового

упакованного изделия». При создании новой модели (меню File/New)

автоматически создается контекстная диаграмма с единственной

работой, изображающей систему в целом (см. рис. 21).

74

Взаимодействие работ с внешним миром и между собой

описывается в виде стрелок. Стрелки представляют собой некую

информацию и обозначаются существительными (например,

«Заготовка», Изделие», «Заказ») или именными сочетаниями

(например, «Готовое изделие»).

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

Вход (Input) – материал или информация, которые используются

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

Допускается, что работа может не иметь ни одной стрелки входа.

Каждый тип стрелок подходит к определенной стороне прямоугольника,

изображающего работу, или выходит из нее. Стрелка входа рисуется как

входящая в левую грань работы. При описании технологических

процессов (для этого и был создан IDEF0) не возникает проблем

определения входов. Действительно, «Сырье» на рис. 21 – это нечто, что

перерабатывается в процессе «Изготовление изделия» для получения

результата. При моделировании ИС, когда стрелками являются не

физические объекты, а данные, не все так очевидно. Например, при

«Приеме пациента» карта пациента может быть и на входе, и на выходе,

между тем качество этих данных меняется. Другими словами, в нашем

примере для оправдания своего назначения стрелки входа и выхода

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

действительно были переработаны (например, на выходе – «Заполненная

карта пациента»). Очень часто сложно определить, являются ли данные

входом или управлением. В этом случае подсказкой может служить то,

перерабатываются/изменяются ли данные в работе или нет. Если они

изменяются, то, скорее всего, это вход, если нет – управление.

Управление (Control) – правила, стратегии, процедуры или

стандарты, которыми руководствуется работа. Каждая работа должна

иметь хотя бы одну стрелку управления. Стрелка управления рисуется

как входящая в верхнюю грань работы. На рис. 21 стрелки «Задание» и

«Чертеж» – управление для работы «Изготовление изделия».

Управление влияет на работу, но не преобразуется ей. Если целью

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

процедура или стратегия будут для работы входом. В случае

возникновения неопределенности в статусе стрелки (управление или

контроль) рекомендуется рисовать стрелку управления.

Выход (Output) – материал или информация, которые

производятся работой. Каждая работа должна иметь хотя бы одну

стрелку выхода. Работа без результата не имеет смысла и не должна

моделироваться. Стрелка выхода рисуется как исходящая из правой

грани работы. На рис. 21 стрелка «Готовое изделие» является выходом

для работы «Изготовление изделия».

75

Механизм (Mechanism) – ресурсы, которые выполняют работу,

например, персонал предприятия, станки, устройства и т.д. Стрелка

механизма рисуется как входящая в нижнюю грань работы. На рис. 21

стрелка «Персонал предприятия» является механизмом для работы

«Изготовление изделия». По усмотрению аналитика стрелки механизма

могут не изображаться в модели.

Вызов (Call) – специальная стрелка, указывающая на другую

модель работы. Стрелка механизма рисуется как исходящая из нижней

грани работы. На рис. 21 стрелка «Другая модель работы» является

вызовом для работы «Изготовление изделия». Стрелка вызова

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

пределами моделируемой системы. В BPwin стрелки вызова

используются в механизме слияния и разделения моделей.

Граничные стрелки. Стрелки на контекстной диаграмме служат

для описания взаимодействия системы с окружающим миром. Они

могут начинаться у границы диаграммы и заканчиваться у работы, и

наоборот. Такие стрелки называются граничными.

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

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

анализ преимуществ новых бизнес-процессов и степени изменения

существующей структуры организации бизнеса. Анализ недостатков и

«узких мест» начинают с построения модели AS-IS (Как есть),

т.е. модели существующей организации работы. Модель AS-IS может

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

положений о предприятии, приказов, отчетов и т.п.), анкетирования и

опроса служащих предприятия, создания фотографии рабочего дня и

других источников. Полученная модель AS-IS служит для выявления

неуправляемых работ, работ не обеспеченных ресурсами, ненужных и

неэффективных работ, дублирующихся работ и других недостатков в

организации деятельности предприятия. Исправление недостатков,

перенаправление информационных и материальных потоков приводит к

созданию модели TO-BE (Как будет) – модели идеальной организации

бизнес-процессов. Как правило, строится несколько моделей TO-BE,

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

модели может осуществляться, например, с помощью метрик BPwin.

Распространенная ошибка при создании модели AS-IS – создание

идеализированной модели. Примером может служить создание модели

на основе знаний руководителя, а не конкретного исполнителя работ.

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

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

самом деле подчиненные выполняют рутинные работы. В результате

получается приукрашенная, искаженная модель, которая несет ложную

информацию и которую невозможно в дальнейшем использовать для

анализа. Такая модель называется SHOULD BE (Как должно бы быть).

76

Технология проектирования ИС подразумевает сначала создание

модели AS-IS, ее анализ и улучшение бизнес-процессов, т.е. создание

модели TO-BE, и только на основе модели TO-BE строится модель

данных, прототип и затем окончательный вариант ИС. Построение

системы на основе модели AS-IS приводит к автоматизации

предприятия по принципу «все оставить как есть, только чтобы

компьютеры стояли», т.е. ИС автоматизирует несовершенные бизнес-

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

В результате внедрение и эксплуатация такой системы приводит лишь к

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

программного обеспечения и сопровождение того и другого.

Иногда текущая модель AS-IS и будущая TO-BE различаются

очень сильно, так что переход от начального состояния к конечному

становится неочевидным. В этом случае необходима третья модель,

описывающая процесс перехода от начального состояния системы к

конечному, поскольку такой переход – это тоже бизнес-процесс.

Переход от модели AS-IS к модели TO-BE является

реинжинирингом бизнес-процессов.

Вопрос 4. Реинжиниринг бизнес-процессов.

Современные предприятия (корпорации) имеют сложную

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

территориальной распределенностью подразделений, большим числом

корпоративных связей с партнерами. Рост динамичности деловых

процессов, связанной с постоянно изменяющимися потребностями

рынка, ориентацией производства товаров и услуг на потребности

заказчиков и клиентов, непрерывным совершенствованием технических

возможностей и сильной конкуренцией, требует смещения акцентов с

управления отдельными ресурсами и, соответственно,

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

процессами, которые объединяют деятельность подразделений

предприятия.

Бизнес-процесс (БП) – совокупность взаимосвязанных работ по

изготовлению готовой продукции или выполнению услуг на основе

потребления ресурсов. В управлении бизнес-процессами все

материальные, финансовые и информационные потоки рассматриваются

во взаимодействии.

Управление БП на уровне взаимодействия различных предприятий

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

товародвижения или логических процессах по принципу «точно в срок».

Современные информационные технологии дают возможность

проведения инжиниринга и реинжиниринга бизнес-процессов.

77

Цель реинжиниринга БП – системная реорганизация

материальных, финансовых и информационных потоков, направленных

на упрощение организационной структуры, перераспределение и

минимизацию использования различных ресурсов, сокращение сроков

реализации потребностей клиентов, повышение качества их

обслуживания.

Реинжиниринг БП обеспечивает решение следующих задач:

Определение оптимальной последовательности выполняемых

функций, способствующих сокращению длительности цикла

изготовления и продажи товаров и услуг, обслуживания клиентов,

следствием чего служат повышение оборачиваемости капитала и рост

всех экономических показателей фирмы.

Оптимизация использования ресурсов, приводящих к

минимизации издержек.

Построение адаптивных БП, нацеленных на быструю адаптацию

к изменениям потребностей конечных потребителей продукции,

производственных технологий, повышение качества обслуживания

клиентов в условиях динамичности внешней среды.

Определение рациональных схем взаимодействия с партнерами

и клиентами и, как следствие, рост прибыли, оптимизация финансовых

потоков.

Вопрос 5. Моделирование процессов в нотации IDEF3.

Для описания логики взаимодействия информационных потоков

более подходит IDEF3 (Workflow diagramming) – методология

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

потоков, взаимоотношений между процессами обработки информации и

объектов, являющихся частью этих процессов. Диаграммы Workflow

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

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

помощью можно описывать сценарии действий сотрудников

организации, например, последовательность обработки заказа или

события, которые необходимо обработать за конечное время. Каждый

сценарий сопровождается описанием процесса и может быть

использован для документирования каждой функции.

IDEF3 – это метод, имеющий основной целью дать возможность

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

определенной последовательности, а также описать объекты,

участвующие совместно в одном процессе.

78

Техника описания набора данных IDEF3 является частью

структурного анализа. В отличие от некоторых методик описаний

процессов IDEF3 не ограничивает аналитика чрезмерно жесткими

рамками синтаксиса, что может привести к созданию неполных или

противоречивых моделей.

IDEF3 может быть также использован как метод создания

процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для

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

для имитационного анализа.

Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-

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

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

именовались отглагольным существительным, обозначающим процесс

действия, или фразой, содержащей такое существительное.

Точка зрения на модель должна быть документирована. Обычно

это точка зрения человека, ответственного за работу в целом. Также

необходимо документировать цель модели (те вопросы, на которые

призвана ответить модель).

Диаграмма является основной единицей описания в IDEF3. Важно

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

чтения другими людьми (а не только автором).

Единицы работы (Unit of Work (UOW)), также называемые

работами (activity), являются центральными компонентами модели. В

IDEF3 работы изображаются прямоугольниками с прямыми углами и

имеют имя, выраженное отглагольным существительным (одиночным

или в составе фразы), которое обозначает процесс действия, и номер

(идентификатор). Другое имя существительное в составе той же фразы

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

«Изготовление изделия»). Часто имя существительное в имени работы

меняется в процессе моделирования, поскольку модель может

уточняться и редактироваться. Идентификатор работы присваивается

при создании и не меняется никогда. Даже если работа будет удалена, ее

идентификатор не будет вновь использоваться для других работ.

Обычно номер работы состоит из номера родительской работы и

порядкового номера на текущей диаграмме.

Связи показывают взаимоотношения работ. Все связи в IDEF3

однонаправлены и могут быть направлены куда угодно, но обычно

диаграммы IDEF3 стараются построить так, чтобы связи были

направлены слева направо. В IDEF3 различают три типа стрелок,

изображающих связи, стиль которых устанавливается через меню

Edit/Arrow Style:

Старшая (Precedence) – сплошная линия, связывающая единицы

работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что

работа-источник должна закончиться прежде, чем начнется работа-цель.

79

Отношения (Relational Link) – пунктирная линия,

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

(UOW), а также между единицами работ и объектами ссылок.

Потоки объектов (Object Flow) – стрелка с двумя

наконечниками, применяющаяся для описания того факта, что объект

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

порождается в одной работе и используется в другой.

Старшая связь показывает, что работа-источник заканчивается

ранее, чем начинается работа-цель. Часто результатом работы-источника

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

случае стрелку, обозначающую объект, изображают с двойным

наконечником. Имя стрелки должно ясно идентифицировать

отображаемый объект. Поток объектов имеет ту же семантику, что и

старшая стрелка.

Отношение показывает, что стрелка является альтернативой

старшей стрелке или потоку объектов в смысле задания

последовательности выполнения работ: работа-источник не обязательно

должна закончиться, прежде чем работа-цель начнется. Более того,

работа-цель может закончиться прежде, чем закончится работа-

источник.

Окончание одной работы может служить сигналом к началу

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

окончания нескольких работ. Для отображения логики взаимодействия

стрелок при слиянии и разветвлении или для отображения множества

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

следующей работы, используются перекрестки (Junction). Различают

перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out

Junction) стрелок. Перекресток не может использоваться одновременно

для слияния и для разветвления. Для внесения перекрестка служит

кнопка (добавить в диаграмму перекресток – Junction) на палитре

80

инструментов. В диалоге Select Junction Type необходимо указать тип

перекрестка. Смысл каждого типа приведен в таблице 2.

Таблица 2.

Типы перекрестков IDEF3

Обозначение Наименование Смысл в случае слияния

стрелок (Fan-in Junction)

Смысл в случае

разветвления стрелок (Fan-

out Junction)

Asynchronous

AND

Все предшествующие процессы

должны быть завершены

Все следующие процессы

должны быть запущены

Synchronous

AND

Все предшествующие процессы

завершены одновременно

Все следующие процессы

запускаются одновременно

Asynchronous OR

Один или несколько

предшествующих процессов

должны быть завершены


следующих процессов должны

быть запущены

Synchronous OR


предшествующих процессов завершены одновременно


следующих процессов запускаются одновременно

XOR (Exclusive

OR)

Только один предшествующий

процесс завершен

Только один следующий

процесс запускается

Все перекрестки на диаграмме нумеруются, и каждый номер имеет

префикс J. Можно редактировать свойства перекрестка при помощи

диалога Junction Properties, который вызывается в контекстном меню

перекрестка командой Definition/Note. В отличие от IDEF0 и DFD в

IDEF3 стрелки могут сливаться и разветвляться только через

перекрестки.

Объект ссылки в IDEF3 выражает некую идею, концепцию или

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

Для внесения объекта ссылки служит кнопка (добавить в диаграмму

объект ссылки – Referent) на палитре инструментов. Объект ссылки

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

работы. Имя объекта ссылки задается в диалоге Referent (пункт Name

контекстного меню); в качестве имени можно использовать имя какой-

либо стрелки с других диаграмм или имя сущности из модели данных.

Объекты ссылки должны быть связаны с единицами работ или

перекрестками пунктирными линиями.

81

Рис. 23. Пример диаграммы IDEF3

В IDEF3 декомпозиция используется для детализации работ.

Методология IDEF3 позволяет декомпозировать работу многократно,

т.е. работа может иметь множество дочерних работ. Это позволяет в

одной модели описать альтернативные потоки. Возможность

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

к нумерации работ. Так, номер работы состоит из номера родительской

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

диаграмме.

Вопрос 6. Моделирование потоков данных, диаграммы потоков

данных (DFD).

Диаграммы потоков данных (Data Flow Diagramming, DFD)

являются основным средством моделирования функциональных

требований к проектируемой системе. Требования представляются в

виде иерархии процессов, связанных потоками данных. Диаграммы

потоков данных показывают, как каждый процесс преобразует свои

входные данные в выходные, и выявляют отношения между этими

процессами. DFD-диаграммы успешно используются как дополнение к

модели IDEF0 для описания документооборота и обработки

информации. Подобно IDEF0, DFD представляет моделируемую

82

систему как сеть связанных работ. Основные компоненты DFD, как

утверждалось выше, – процессы или работы, внешние сущности, потоки

данных, накопители данных (хранилища).

В AllFusion Process Modeler для построения диаграмм потоков

данных используется нотация Гейна-Сарсона. Для того чтобы дополнить

модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в

диалоге Activity Box Count «кликнуть» по радио-кнопке DFD. На

палитре инструментов на новой диаграмме DFD появляются новые

кнопки:

Добавить в диаграмму внешнюю ссылку.

Добавить в диаграмму хранилище данных.

Ссылка на другую страницу. В отличие от IDEF0 этот инструмент

позволяет направить стрелку на любую диаграмму (а не только на

верхний уровень).

В отличие от стрелок IDEF0, которые представляют собой жесткие

взаимосвязи, стрелки DFD показывают, как объекты (включая данные)

двигаются от одной работы к другой. Это представление потоков

совместно с хранилищами данных и внешними сущностями делает

модели DFD более похожими на физические характеристики системы

(движение объектов, хранение объектов, поставка и распространение

объектов). Пример диаграммы потоков данных представлен на рис. 24.

Рис. 24. Пример диаграммы DFD

83

В DFD работы (процессы) представляют собой функции системы,

преобразующие входы в выходы. Хотя работы изображаются

прямоугольниками со скругленными углами, смысл их совпадает со

смыслом работ IDEF0 и IDEF3. Как и процессы IDEF3, они имеют входы

и выходы, но не поддерживают управления и механизмы, как IDEF0

(блоки «Проверка и внесение клиентов», «Внесение заказов» на рис. 24).

Внешние сущности изображают входы в систему и/или выходы

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

тенью и обычно располагаются по краям диаграммы (рис. 24, блок

«Звонки клиентов). Одна внешняя сущность может быть использована

многократно на одной или нескольких диаграммах. Обычно такой прием

используют, чтобы не рисовать слишком длинных и запутанных

стрелок.

Потоки работ изображаются стрелками и описывают движение

объектов из одной части системы в другую. Поскольку в DFD каждая

сторона работы не имеет четкого назначения, как в IDEF0, стрелки

могут подходить и выходить из любой грани прямоугольника работы. В

DFD также применяются двунаправленные стрелки для описания

диалогов типа «команда-ответ» между работами, между работой и

внешней сущностью и между внешними сущностями (см. рис. 24).

В отличие от стрелок, описывающих объекты в движении,

хранилища данных изображают объекты в покое («Список клиентов»,

«Список продуктов», «Список заказов» на рис. 24).

В материальных системах хранилища данных изображаются там,

где объекты ожидают обработки, например, в очереди. В системах

обработки информации хранилища данных являются механизмом,

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

В DFD стрелки могут сливаться и разветвляться, что позволяет

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

или разветвляющейся стрелки может иметь собственное имя.

Диаграммы DFD могут быть построены с использованием

традиционного структурного анализа, подобно тому, как строятся

диаграммы IDEF0. В DFD номер каждой работы может включать

префикс (A), номер родительской работы и номер объекта. Номер

объекта – это уникальный номер работы на диаграмме. Например,

работа может иметь номер А.12.4. Уникальный номер имеют хранилища

данных и внешние сущности независимо от их расположения на

диаграмме. Каждое хранилище данных имеет префикс D и уникальный

номер, например, D5. Каждая внешняя сущность имеет префикс Е и

уникальный номер, например, Е5.

84

Вопрос 7. Моделирование данных, методология

проектирования реляционных баз данных IDEF1X, моделирование

данных в среде AllFusion ERwin Data Modeler.

Одной из основных частей информационного обеспечения

является информационная база. Разработка базы данных выполняется с

помощью моделирования данных. Цель моделирования данных состоит

в обеспечении разработчика ИС концептуальной схемой базы данных в

форме одной модели или нескольких локальных моделей, которые

относительно легко могут быть отображены в любую систему баз

данных. Наиболее распространенным средством моделирования данных

являются диаграммы «сущность-связь» (ERD). С помощью ERD

осуществляется детализация накопителей данных DFD-диаграммы, а

также документируются информационные аспекты бизнес-системы,

включая идентификацию объектов, важных для предметной области

(сущностей), свойств этих объектов (атрибутов) и их связей с другими

объектами (отношений).

Сущность (Entity) – множество экземпляров реальных или

абстрактных объектов (людей, событий, состояний, идей, предметов и

пр.), обладающих общими атрибутами или характеристиками. Любой

объект системы может быть представлен только одной сущностью,

которая должна быть уникально идентифицирована. При этом имя

сущности должно отражать тип или класс объекта, а не его конкретный

экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Каждая сущность

должна обладать уникальным идентификатором. Каждый экземпляр

сущности должен однозначно идентифицироваться и отличаться от всех

других экземпляров данного типа сущности. Каждая сущность должна

обладать некоторыми свойствами:

иметь уникальное имя; к одному и тому же имени должна всегда

применяться одна и та же интерпретация; одна и та же интерпретация не

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

псевдонимами;

иметь один или несколько атрибутов, которые либо

принадлежат сущности, либо наследуются через связь;

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

идентифицируют каждый экземпляр сущности.

Каждая сущность может обладать любым количеством связей с

другими сущностями модели.

Связь (Relationship) – поименованная ассоциация между двумя

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

Атрибут (Attribute) – любая характеристика сущности, значимая

для рассматриваемой предметной области и предназначенная для

квалификации, идентификации, классификации, количественной

характеристики или выражения состояния сущности. Экземпляр

85

атрибута – это определенная характеристика отдельного элемента

множества. Экземпляр атрибута определяется типом характеристики и

ее значением, называемым значением атрибута. На диаграмме

«сущность-связь» атрибуты ассоциируются с конкретными сущностями.

Таким образом, экземпляр сущности должен обладать единственным

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

Наиболее распространенными методами для построения ERD-

диаграмм являются метод Баркера и метод IDEF1. Метод IDEF1 основан

на подходе Чена и позволяет построить модель данных, эквивалентную

реляционной модели в третьей нормальной форме. На основе

совершенствования метода IDEF1 создана его новая версия – метод

IDEF1X, разработанный с учетом таких требований, как простота для

изучения и возможность автоматизации. IDEF1X-диаграммы

используются в ряде распространенных CASE-средств (в частности

AllFusion Data Modeler).

AllFusion Data Modeler имеет два уровня представления модели –

логический и физический.

Логический уровень – это абстрактный взгляд на данные, когда

данные представляются так, как выглядят в реальном мире, и могут

называться так, как они называются в реальном мире, например,

«Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты

модели, представляемые на логическом уровне, называются сущностями

и атрибутами. Логическая модель данных может быть построена на

основе другой логической модели, например, на основе модели

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

не связана с конкретной реализацией СУБД.

Физическая модель данных, напротив, зависит от конкретной

СУБД, фактически являясь отображением системного каталога. В

физической модели содержится информация обо всех объектах БД.

Поскольку стандартов на объекты БД не существует (например, нет

стандарта на типы данных), физическая модель зависит от конкретной

реализации СУБД. Следовательно, одной и той же логической модели

могут соответствовать несколько разных физических моделей. Если в

логической модели не имеет значения, какой конкретно тип данных

имеет атрибут, то в физической модели важно описать всю информацию

о конкретных физических объектах (таблицах, колонках, индексах,

процедурах и т.д.).

Для переключения между логической и физической моделью

данных существует список выбора в центральной части панели

инструментов. Фрагмент панели инструментов представлен на рис. 25.

86

Рис. 25. Переключение между логической и физической моделью

Основные компоненты диаграммы ERwin – это сущности,

атрибуты и связи. Каждая сущность является множеством подобных

индивидуальных объектов, называемых экземплярами. Каждый

экземпляр индивидуален и должен отличаться от всех остальных

экземпляров. Атрибут выражает определенное свойство объекта. С

точки зрения БД (физическая модель) сущности соответствует таблица,

экземпляру сущности – строка в таблице, а атрибуту – колонка

таблицы.

Построение модели данных предполагает определение сущностей

и атрибутов, т.е. необходимо определить, какая информация будет

храниться в конкретной сущности или атрибуте. Сущность можно

определить как объект, событие или концепцию, информация о которых

должна сохраняться. Сущности должны иметь наименование с четким

смысловым значением, обозначаться существительным в единственном

числе, не носить «технических» наименований и быть достаточно

важными для того, чтобы их моделировать. Именование сущности в

единственном числе облегчает в дальнейшем чтение модели.

Фактически имя сущности дается по имени ее экземпляра. Примером

может быть сущность Заказчик (но не Заказчики!) с атрибутами Номер

заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической

модели ей может соответствовать таблица Customer с колонками

Customer_number, Customer_name и Customer_address. Каждая сущность

должна быть полностью определена с помощью текстового описания.

Для внесения дополнительных комментариев и определений к сущности

служат свойства, определенные пользователем (UDP). Использование

(UDP) аналогично их использованию в Process Modeler.

Как было указано выше, каждый атрибут хранит информацию об

определенном свойстве сущности, а каждый экземпляр сущности

должен быть уникальным. Атрибут или группа атрибутов, которые

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

Первичный ключ (primary key) – это атрибут или группа

атрибутов, однозначно идентифицирующая экземпляр сущности.

Атрибуты первичного ключа на диаграмме не требуют специального

обозначения; это те атрибуты, которые находятся в списке атрибутов

выше горизонтальной линии.

87

Атрибуты изображаются в виде списка имен внутри блока

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

наверху списка и отделяются от других атрибутов горизонтальной

чертой (см. рис. 26).

Каждой сущности присваиваются уникальные имя и номер,

разделяемые косой чертой «/» и помещаемые над блоком.

Связь является логическим соотношением между сущностями.

Связь может дополнительно определяться с помощью указания

степени или мощности (количества экземпляров сущности-потомка,

которое может порождать каждый экземпляр сущности-родителя).

На логическом уровне можно установить идентифицирующую

связь «один-ко-многим», связь «многие-ко-многим» и

неидентифицирующую связь «один-ко-многим».

Если экземпляр сущности-потомка однозначно определяется своей

связью с сущностью-родителем, то связь называется

идентифицирующей, в противном случае – неидентифицирующей.

Пример неидентифицирующей связи приведен на рис. 26.

Идентифицирующая связь между сущностью-родителем и сущностью-

потомком изображается сплошной линией. Сущность-потомок в

идентифицирующей связи является зависимой от идентификатора

сущностью. При установлении идентифицирующей связи атрибуты

первичного ключа родительской сущности автоматически переносятся в

состав первичного ключа дочерней сущности. Эта операция дополнения

атрибутов дочерней сущности при создании связи называется миграцией

атрибутов. В дочерней сущности новые атрибуты помечаются как

внешний ключ (FK).

Пунктирная линия изображает неидентифицирующую связь (см.

рис. 26). При установлении неидентифицирующей связи дочерняя

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

родительской сущности мигрируют в состав неключевых компонентов

родительской сущности. Неидентифицирующая связь служит для

связывания независимых сущностей.

Сущности могут иметь также внешние ключи (Foreign Key),

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

ключа или неключевого атрибута. Для обозначения внешнего ключа

внутрь блока сущности помещают имена атрибутов, после которых

следуют буквы FK в скобках (см. рис. 26).

88

Рис. 26. Пример ERD-модели с неидентифицирующей связью

Физическая модель содержит всю информацию, необходимую для

реализации конкретной БД, при этом необходимо учитывать, что

физическая модель не поддерживает связь «многие-ко-многим».

Различают два уровня физической модели: трансформационную модель

и модель СУБД.

Трансформационная модель содержит информацию для

реализации отдельного проекта, который может быть частью общей ИС

и описывать подмножество предметной области. Данная модель

позволяет проектировщикам и администраторам БД лучше представить,

какие объекты БД хранятся в словаре данных, и проверить, насколько

физическая модель удовлетворяет требованиям к ИС.

Модель СУБД автоматически генерируется из трансформационной

модели и является точным отображением системного каталога СУБД.

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

сервера. AllFusion Data Modeler поддерживает более 20 реляционных и

нереляционных БД.

По умолчанию AllFusion Data Modeler генерирует имена таблиц и

индексов по шаблону на основе имен соответствующих сущностей и

ключей логической модели, которые в дальнейшем могут быть

откорректированы вручную. Имена таблиц и колонок будут

сгенерированы по умолчанию на основе имен сущностей и атрибутов

логической модели.


1. В чем состоит сущность структурного подхода к

проектированию ИС?

2. Что представляет собой модель в нотации IDEF0?

3. В чем суть декомпозиции работ?

4. Назовите основные виды стрелок на диаграмме IDEF0.

5. Для чего служит диаграмма FEO?

6. Какова основная цель реинжиниринга бизнес-процессов?

7. В чем отличие модели AS-IS от модели TO-BE?

89

8. Каковы основные элементы диаграмм IDEF3?

9. В чем состоит суть перекрестков на диаграммах IDEF3?

10. Зачем создаются диаграммы потоков данных? Каковы их

основные элементы?

11. Каковы основные элементы диаграммы IDEF1X?

12. Что такое логическая модель данных?

13. Что такое физическая модель данных?

14. Какой тип связи между сущностями не поддерживается на

физическом уровне?

15. Что такое внешний ключ?

16. Что такое идентифицирующая связь «один-ко-многим»? Какие

сущности она связывает?

17. Для чего нужна трансформационная модель?


1. Маклаков С.В. Создание информационных систем с AllFusion

Modeling Suite. – 2-е изд., доп. – М.: Издательство Диалог-МИФИ,

2007 – 400 с.



Ю.Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с. – Глава 11.–

С. 330–351.

3. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных:

учебник для высших учебных заведений / под. ред. проф.

А.Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА

принт, 2006 – 736 с.


1. Метод SADT реализован в виде стандарта:

а) IDEF0

б) IDEF1X

в) IDEF3

г) DFD

2. Контекстная диаграмма IDEF0 – это …

а) диаграмма декомпозиции

б) диаграмма верхнего уровня

в) диаграмма модели данных

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

3. Разбиение системы на фрагменты в IDEF0 называется …

а) реструктуризацией

б) детализацией

в) анализом

90

г) декомпозиция

4. Неверно, что у блока работы на диаграмме IDEF0 …

а) всегда должна быть стрелка входа

б) всегда должна быть стрелка управления

в) всегда должна быть стрелка выхода

г) по усмотрению разработчиком можно не указывать механизмы

5. Переход от модели AS-IS к модели TO-BE – это по сути …

а) моделирование бизнес-процессов

б) реинжиниринг бизнес-процессов

в) декомпозиция системы

г) прототипирование

6. Неверно, что …

а) диаграмму IDEF3 можно декомпозировать в IDEF0

б) диаграмму IDEF0 можно декомпозировать в IDEF3

в) диаграмму IDEF0 можно декомпозировать в IDEF0

г) диаграмму IDEF3 можно декомпозировать в DFD

7. Перекресток «исключающего ИЛИ» в IDEF3 отображается:

а)

б)

в)

г)

8. На диаграмме DFD вход в систему и/или выход из системы

изображается с помощью …

а) внешних сущностей

б) стрелок

в) хранилищ данных

г) блоков работ

9. Для IDEF1X неверно, что …

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

б) на логическом уровне используются понятия сущность и

атрибут

в) и на логическом, и на физическом уровне поддерживается

связь «многие-ко-многим»

г) одному логическому уровню может соответствовать несколько

физических уровней

91

10. Множество подобных индивидуальных объектов, называемых

экземплярами – это …

а) атрибут

б) сущность

в) класс

г) колонка

92

Литература

Основная литература:

1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование

информационных систем – М.: ИУИТ, 2012. – 300 с.

2. Коваленко В.В. Проектирование информационных систем:

учебник – М.: Форум, 2012. – 320 с.

Дополнительная литература:

1. Вендеров А.М. Проектирование программного обеспечения


доп. – М.: Финансы и Статистика, 2006. – 544 с.

2. Г. Буч, А. Якобсон, Дж. Рамбо. UML / пер. с англ. А. Вахитов,

Д. Солнышков. – 2-е изд. – М.: Питер, 2006. – 735 с.

3. Дубейковкий В.И. Практика функционального моделирования

с AllFusion Process Modeler 4.1. Где? Зачем? Как? – М.: ДИАЛОГ-

МИФИ, 2007 – 464 с.

4. Дубейковкий В.И. Эффективное моделирование с AllFusion

Process Modeler 4.1.4 и AllFusion PM – М.: ДИАЛОГ-МИФИ, 2007 –

384 с.

5. Маклаков С.В. Моделирование бизнес-процессов с AllFusion

PM. – 2-е изд., испр. и. дополн. – М.: Издательство Диалог-МИФИ,

2007 – 224 с.

6. Маклаков С.В. Создание информационных систем с AllFusion

Modeling Suite. – 2-е изд., испр. и. дополн. – М.: Издательство Диалог-

МИФИ, 2007 – 400 с.


учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под. ред.

Ю.Ф. Тельнова. – М.: Финансы и статистика, 2003. – 512 с.

8. У. Боггс, М. Боггс. UML и Rational Rose: секреты

эффективного проектирования объектно-ориентированных

приложений – М.: ЛОРИ, 2004 – 509 с.

9. Уткин В.Б. Информационные системы в экономике: учебник

для студ. высш. учеб. заведений / В.Б. Уткин, К.В. Балдин. – М.:

Издательский центр «Академия», 2004. – 288 с.

10. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии:

практикум. – М.: Горячая линия – Телеком, 2005 – 160 с.

11. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных:

учебник для высших учебных заведений / под. ред. проф.

А.Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА

принт, 2006. – 736 с.

93

Практические задания

Практические задания по данной теме предусматривают работу с

CASE-средством AllFusion Process Modeler и AllFusion Erwin Data

Modeler и создание с помощью данных инструментальных средств

моделей предметной области будущей информационной системы с

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

Задание 1.

Создание контекстной диаграммы IDEF0.

В качестве примера рассматривается деятельность вымышленной

компании. Компания занимается в основном сборкой и продажей

настольных компьютеров и ноутбуков. Компания не производит

компоненты самостоятельно, а только собирает и тестирует

компьютеры.

Основные процедуры, которые выполняются в компании:

продавцы принимают заказы от клиентов;

операторы группируют заказы по типам компьютеров;

операторы собирают и тестируют компьютеры;

операторы упаковывают компьютеры согласно заказам;

кладовщики отгружают клиентам заказы.

Компания использует купленную бухгалтерскую ИС, которая

позволяет оформить заказ, счет и отследить платежи по счетам.

Начало работы с Process Modeler:

1. Запустите AllFusion Process Modeler.

2. Если появляется диалог ModelMart Connection Manager,

нажмите на кнопку Cancel.

3. Появляется диалог I would like to (см. рис. 27). Внесите имя

модели «Деятельность компании» и выберите Type – IDEF0. Нажмите

ОК.

94

Рис. 27. Диалог создания модели

4. Автоматически создается контекстная диаграмма.

5. Перейдите в меню Model/Model Properties. Во вкладке General

диалога Model Properties следует внести имя модели «Деятельность

компании», имя проекта – «Модель деятельности компании», имя автора

и тип модели – Time Frame: AS-IS.

6. Во вкладке Purpose внесите цель «Purpose: Моделировать

текущие (AS-IS) бизнес-процессы компании» и точку зрения «Viewpoint:

Директор».

7. Во вкладке Definition внесите определение «Это учебная

модель, описывающая деятельность компании» и цель «Scope: Общее

управление бизнесом компании: исследование рынка, закупка

компонентов, сборка, тестирование и продажа продуктов».

8. Перейдите на контекстную диаграмму и правой кнопкой мыши

щелкните по работе. В контекстном меню выберите Name. Во вкладку

Name внесите имя «Деятельность компании».

9. Во вкладке Definition внесите определение «Текущие бизнес-

процессы компании».

10. Создайте стрелки на контекстной диаграмме (см. таблицу 3).

95

Таблица 3.

Стрелки контекстной диаграммы

Имя стрелки

(Arrow Name)

Определение стрелки

(Arrow Definition)

Тип стрелки

(Arrow Type)

Бухгалтерская система Оформление счетов, оплата счетов, работа с заказами Mechanism

Звонки клиентов Запросы информации, заказы, техподдержка и др. Input

Правила и процедуры Правила продаж, инструкции по сборке, процедуры

тестирования. Критерии производительности Control

Проданные продукты Настольные и портативные компьютеры Output

11. С помощью кнопки внесите текст в поле диаграммы (точку

зрения и цель (рис. 28)).

Рис. 28. Добавление текстовых элементов в диаграмму

Результат создания контекстной диаграммы показан на рис. 29.

96

Рис. 29. Контекстная диаграмма IDEF0

12. Создайте отчет по модели. Меню Tools – Reports – Model

Report. В диалоге настройки (см. рис. 30) следует выбрать необходимые

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

информации в отчет. Результат представлен на рис. 31.

Рис. 30. Настройки отчета Model Report

97

Рис. 31. Отчет по модели

Задание 2.

Создание диаграммы декомпозиции.

1. Выберите кнопку перехода на нижний уровень на палитре

инструментов и в диалоге Activity Box Count (см. рис. 25), установите

число работ на диаграмме нижнего уровня – 3 – и нажмите ОК.

Рис. 32. Диалог Activity Box Count

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

кнопкой мыши щелкните по работе, выберите Name и внесите имя

работы. Повторите операцию для всех трех работ. Затем внесите

определение, статус и источник для каждой работы согласно таблице 3.

98

Таблица 4.

Названия работ для диаграммы декомпозиции

Имя работы (Active Name) Определение (Definition)

Продажи и маркетинг Телемаркетинг и презентации, выставки

Сборка и тестирование компьютеров Сборка и тестирование настольных компьютеров и

ноутбуков

Отгрузка и получение Отгрузка заказов клиентам и получение

компонентов от поставщиков

2. Для изменения свойств работ после их внесения в диаграмму

можно воспользоваться словарем работ. Вызов словаря – меню

Dictionary/Activity. Если описать имя и свойства работы в словаре, ее

можно будет внести в диаграмму позже с помощью кнопки на

палитре инструментов. Невозможно удалить работу из словаря, если она

используется на какой-либо диаграмме. Если работа удаляется из

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

могут быть использованы в дальнейшем. Для добавления работы в

словарь необходимо перейти в конец списка и щелкнуть правой кнопкой

по последней строке. Возникает новая строка, в которую нужно внести

имя и свойства работы. Для удаления всех имен работ, не

использующихся в модели, щелкните по кнопке (Purge).

3. Перейдите в режим рисования стрелок (кнопка на палитре

инструментов). Свяжите граничные стрелки так, как показано на рис. 33.

99

Рис. 33. Диаграмма декомпозиции. Связывание граничных стрелок

4. Правой кнопкой мыши щелкните по ветви стрелки управления

работы «Сборка и тестирование компьютеров» и переименуйте ее в

«Правила сборки и тестирования « (рис. 34).

Рис. 34. Результат переименования ветви стрелки

100

Внесите определение для новой ветви «Инструкции по сборке,

процедуры тестирования, критерии производительности и т.д.». Правой

кнопкой мыши щелкните по ветви стрелки механизма работы «Продажи

и маркетинг» и переименуйте ее в «Систему оформления заказов».

Альтернативный метод внесения имен и свойств стрелок –

использование словаря стрелок (вызов словаря – меню

Dictionary/Arrow). Если внести имя и свойства стрелки в словарь, ее

можно будет внести в диаграмму позже. Стрелку нельзя удалить из

словаря, если она используется на какой-либо диаграмме. Если удалить

стрелку из диаграммы, из словаря она не удаляется. Имя и описание

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

стрелки необходимо перейти в конец списка и щелкнуть правой кнопкой

по последней строке. Возникает новая строка, в которую нужно внести

имя и свойства стрелки.

5. Создайте новые внутренние стрелки так, как показано на рис.

35.

Рис. 35. Внутренние стрелки диаграммы декомпозиции

6. Создайте стрелку обратной связи (по управлению) «Результаты

сборки и тестирования», идущую от работы «Сборка и тестирование

компьютеров» к работе «Продажи и маркетинг». Измените стиль

стрелки (толщина линий) и установите опцию Extra Arrowhead (из

контекстного меню). Методом drag & drop перенесите имена стрелок

так, чтобы их было удобнее читать. Если необходимо, установите

101

Squiggle (из контекстного меню или кнопкой ). Результат изменений

показан на рис. 36.

Рис. 36. Результат редактирования стрелок на диаграмме

декомпозиции

7. Создайте новую граничную стрелку выхода «Маркетинговые

материалы», выходящую из работы «Продажи и маркетинг». Эта

стрелка автоматически не попадает на диаграмму верхнего уровня и

имеет квадратные скобки на конце ( ). Щелкните правой кнопкой

мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel. B

диалоге Border Arrow Editor выберите опцию Resolve it to Border Arrow.

Для стрелки «Маркетинговые материалы» выберите опцию Trim из

контекстного меню. Результат выполнения показан на рис. 37.

102

Рис. 37. Результат создания диаграммы декомпозиции

Задание 3.

Создание диаграммы декомпозиции A.2 IDEF0.

Декомпозируем работу «Сборка и тестирование компьютеров».

В результате проведения экспертизы получена следующая

информация:

Производственный отдел получает заказы клиентов от отдела

продаж по мере их поступления.

Диспетчер координирует работу сборщиков, сортирует заказы,

группирует их и дает указание на отгрузку компьютеров, когда они

готовы.

Каждые два часа диспетчер группирует заказы (отдельно для

настольных компьютеров и ноутбуков) и направляет на участок сборки.

Сотрудники участка сборки собирают компьютеры согласно

спецификациям заказа и инструкциям по сборке. Когда группа

компьютеров, соответствующая группе заказов, собрана, она

направляется на тестирование. Тестировщики тестируют каждый

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

компоненты.

103

Тестировщики направляют результаты тестирования

диспетчеру, который на основании этой информации принимает

решение о передаче компьютеров, соответствующих группе заказов, на

отгрузку.

На основе этой информации внесите новые работы и стрелки (см.

таблицу 5 и 6).

Таблица 5.

Работы диаграммы декомпозиции А2

Имя работы Определение работы

Отслеживание расписания и

управление сборкой и

тестированием

Просмотр заказов, установка расписания выполнения заказов, просмотр

результатов тестирования, формирование групп заказов на сборку и

отгрузку

Сборка настольных

компьютеров

Сборка настольных компьютеров в соответствии с инструкциями и

указаниями диспетчера

Сборка ноутбуков Сборка ноутбуков в соответствии с инструкциями и указаниями

диспетчера

Тестирование компьютеров Тестирование компьютеров и компонентов. Замена неработающих

компонентов

Таблица 6.

Стрелки диаграммы декомпозиции А2

Имя стрелки Источник стрелки

Тип

источника

стрелки

Назначение

стрелки

Тип

назначения

стрелки

Персонал производственного

отдела

«Tunnel» Mechanism



Mechanism

Сборка

ноутбуков Mechanism

Заказы клиентов Граница диаграммы Control

Отслеживание

расписания и



Control

Заказы на настольные

компьютеры



управление сборкой и тестированием

Output Сборка

настольных


Control

Заказы на ноутбуки

Отслеживание расписания и



Output Сборка

ноутбуков Control

104

Компоненты «Tunnel» Input



Input

Сборка

ноутбуков Input

Тестирование Input

Настольные компьютеры

Сборка настольных компьютеров

Output Тестирование Input

Ноутбуки Сборка ноутбуков Output Тестирование Input

Правила сборки и

тестирования Граница диаграммы

Сборка

настольных компьютеров

Control

Сборка ноутбуков

Control

Тестирование Control

Результаты сборки и

тестирования


компьютеров Output

Граница

диаграммы Output

Сборка ноутбуков Output

Тестирование Output

Результаты тестирования

Тестирование Output



управление

сборкой и тестированием

Input

Собранные компьютеры

Тестирование компьютеров

Output Граница

диаграммы Output

Тестировщик Персонал

производственного

отдела

Тестирование

компьютеров Mechanism

Указание передать компьютеры на

отгрузку



управление сборкой и тестированием

Output Тестирование

компьютеров Control

Тоннелируйте и свяжите на верхнем уровне граничные стрелки,

если это необходимо. Результат выполнения показан на рис. 38.

105

Рис. 38. Результат декомпозиции работы «Сборка и тестирование

компьютеров»

Проведите самостоятельно декомпозицию работы «Продажи и

маркетинг» согласно данным, приведенным на рис. 39.

106

Рис. 39. Результат декомпозиции работы «Продажи и маркетинг»

В дальнейшем на основе полученных диаграмм декомпозиции

будут построены диаграммы в нотациях IDEF3 и DFD.

Задание 4.

Создание диаграммы дерева узлов.

Выберите меню Diagram/Add Node Tree. В первом шаге мастера

Node Tree Wizard внесите имя диаграммы (Node Tree Name), укажите

диаграмму корня дерева (Top Level activity) и количество уровней

(Number of levels) (см. рис. 40).

107

Рис. 40. Создание диаграммы дерева узлов. Первый шаг

На втором шаге мастера укажите внешний вид диаграммы (см.

рис. 41). После создание диаграммы дерева узлов к данному

диалоговому окну можно будет вернуться, щелкнув правой кнопкой

мыши по свободному месту, не занятому объектами, и выбрав меню

Node tree Diagram Properties.

108

Рис. 41. Создание диаграммы дерева узлов. Второй шаг мастера

Щелкните по Finish/Готово. Создается диаграмма дерева узлов.

Результат можно посмотреть на рис. 42.

Рис. 42. Диаграмма дерева узлов

109

Для перехода между стандартной диаграммой, деревом узлов и

FEO используйте кнопку на палитре инструментов.

Задание 5.

Создание FEO-диаграммы.

Предположим, что при обсуждении бизнес-процессов возникла

необходимость детально рассмотреть взаимодействие работы «Сборка и

тестирование компьютеров» с другими работами. Чтобы не портить

диаграмму декомпозиции, создайте FEO-диаграмму, на которой будут

только стрелки работы «Сборка и тестирование компьютеров».

1. Выберите пункт меню Diagram/Add FEO Diagram.

2. В диалоге Add New FEO Diagram выберите тип и внесите имя

диаграммы FEO. Щелкните по ОК.

Рис. 43. Создание диаграммы FEO

3. Для определения диаграммы перейдите в Diagram/Diagram

Properties и во вкладку Diagram Text внесите определение.

4. Откорректируете стрелки на диаграмме FEO. Результат показан

на рис. 44.

110

Рис. 44. Результат создания диаграммы FEO

Для перехода между стандартной диаграммой, деревом узлов и

FEO используйте кнопку на палитре инструментов.

Задание 6.

Модели AS-IS и TO-BE. Реинжиниринг бизнес-процессов.

Модель TO-BE создается на основе анализа модели AS-IS. Анализ

может проводиться как по формальным признакам (отсутствие выходов

или управлений у работ, отсутствие обратных связей и т.д.), так и по

неформальным (на основе знаний предметной области). Допустим, в

результате анализа принимается решение реорганизовать функции

производства и тестирования компьютеров и пока оставить

функциональности «Продажи и маркетинг» и «Отгрузка и

получение» без изменений. Принято решение создать отдел дизайна,

который должен формировать конфигурацию компьютеров,

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

поставщиков, разрабатывать инструкции по сборке, процедуры

тестирования и устранения неполадок для всего производственного

отдела.

111

Работа «Сборка и тестирование компьютеров» должна быть

реорганизована и названа «Производство продукта». Будут созданы

работы «Разработать конфигурацию», «Планировать производство»

и «Собрать продукт».

Рассмотрим новые роли персонала. Дизайнер должен

разрабатывать систему, стандарты на продукцию, документировать и

передавать спецификации в отдел маркетинга и продаж. Он должен

определять, какие компоненты (аппаратные и программные) нужно

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

управлять процедурами сборки, тестирования и устранения неполадок.

Функции диспетчера в работе «Сборка и тестирование компьютеров»

должны быть заменены на функции планировщика. Планировщик

должен обрабатывать заказы клиентов и генерировать заказы на сборку,

получать коммерческий прогноз из отдела маркетинга, формировать

требования на закупку компонентов и собирать информацию от

поставщиков. Диспетчер должен составлять расписание производства на

основании заказов на сборку, полученных в результате работы

«Планировать производство», принимать копии заказов клиентов и

отвечать за упаковку и комплектацию заказанных компьютеров,

передаваемых в работу «Отгрузка и получение».

1. Измените свойства модели «Деятельность компании»:

Model Name: Предлагаемая модель компании.

Time Frame: TO-BE.

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

процессов компании.

2. Переименуйте работу «Сборка и тестирование компьютеров»

в «Производство продукта». Расщепите эту работу в модель с тем же

названием.

3. Модифицируйте отщепленную модель. Переместите работу

«Тестирование компьютеров» с диаграммы А0 «Производство

продукта» на диаграмму A2.1 «Сборка настольных компьютеров».

4. Переименуйте работу «Сборка настольных компьютеров» на

диаграмме А0 в «Сборку продукта».

5. Удалите работу «Сборка ноутбуков».

6. Переименуйте стрелку «Заказы на настольные компьютеры» в

«Заказы на изготовление».

7. Переименуйте работу «Отслеживание расписания и

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

8. Создайте работу «Разработать конфигурацию».

9. Создайте ветвь стрелки «Персонал производственного

отдела», назовите ее «Дизайнер» и направьте как механизм к работе

«Разработать конфигурацию».

112

10. Создайте стрелку «Стандарты на продукцию» и направьте ее

от выхода «Разработать конфигурацию» к границе диаграммы.

Тоннелируйте эту стрелку (Resolve Border Arrow). Создайте ветвь этой

стрелки, идущую к управлению работы «Планирование производства»,

и назовите ее «Списком необходимых компонентов».

11. Удалите стрелку «Правила сборки и тестирования». Создайте

ветвь стрелки «Стандарты на продукцию», идущую к управлению

работы «Сборка продукта», и назовите ее «Правилами сборки и

тестирования».

12. Переименуйте стрелку «Диспетчер» в «Планировщика

производства».

13. Добавьте стрелку «Прогноз продаж» как граничную

управляющую к работе «Планирование производства».

14. Добавьте стрелку «Информация от поставщика» как

граничную управляющую к работе «Планирование производства».

15. Добавьте стрелку «Заказ поставщику» как граничную стрелку

выхода от работы «Планирование производства».

16. Тоннелируйте эти стрелки (Resolve Border Arrow).

17. На диаграмме А0 тоннелируйте стрелку (Resolve Border Arrow)

«Собранные компьютеры» и свяжите ее на диаграмме АО с выходом

работы «Сборка продукта».

Результат выполнения задания приведен на рис. 45.

113

Рис. 45. Результат выполнения задания

Задание 7.

Моделирование процессов в нотации IDEF3.

Для описания логики взаимодействия информационных потоков

подходит методология IDEF3. IDEF3 – методология моделирования и

стандарт документирования процессов, происходящих в системе. Метод

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

документирования и сбора информации о процессах. IDEF3 показывает

причинно-следственные связи между ситуациями и событиями в

понятной эксперту форме, используя структурный метод выражения

знаний о том, как функционирует система, процесс или предприятие.

114

1. Перейдите на диаграмму A2 и декомпозируйте работу «Сборка

настольных компьютеров». В диалоге Activity Box Count (см. рис. 46)

установите число работ 4 и нотацию IDEF3.

Рис. 46. Создание диаграммы IDEF3

Возникает диаграмма IDEF3, содержащая работы (UOW). Правой

кнопкой мыши щелкните по работе, выберите в контекстном меню Name

и внесите имя работы «Подготовка компонентов». Затем во вкладке

Definition внесите определение «Подготавливаются все компоненты

компьютера согласно спецификации заказа».

2. Во вкладку UOW внесите свойства работы (см. таблицу 7).

Таблица 7.

Свойства UOW

Объект Параметр

Objects Компоненты: винчестеры, корпуса, материнские платы, видеокарты, дисководы,

модемы.

Facts Доступные операционные системы: Windows XP/Vista/7.

Constrains Установка модема требует установки дополнительного программного обеспечения.

3. Внесите в диаграмму еще три работы (кнопка ). Внесите

имена следующих работ:

Установка материнской платы и винчестера.

Установка модема.

Установка дисковода.

Установка флоппи-дисковода.

Инсталляция операционной системы.

Инсталляция дополнительного программного обеспечения.

4. С помощью кнопки палитры инструментов создайте объект

ссылки. Внесите имя объекта внешней ссылки «Компоненты». Свяжите

стрелкой объект ссылки и работу «Подготовка компонентов».

115

5. Свяжите стрелкой работы «Подготовка компонентов» (выход)

и «Установка материнской платы и винчестера». Измените стиль

стрелки на Object Flow. В IDEF3 имя стрелки может отсутствовать, хотя

BPwin показывает отсутствие имени как ошибку.

6. С помощью кнопки на палитре инструментов внесите два

перекрестка типа асинхронного «или» и свяжите работы с

перекрестками, как показано на рис. 47.

Рис. 47. Диаграмма IDEF3 после создания перекрестков

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

(fan-out), выберите Name и внесите имя «Компоненты, требуемые в

спецификации заказа».

Создайте два перекрестка типа исключающего «ИЛИ» и свяжите

работы, как показано на рис. 48.

116

Рис. 48. Результат создания диаграммы IDEF3

Создание сценария:

1) Выберите пункт меню Diagram/Add IDEF3 Scenario.

Создайте диаграмму сценария на основе диаграммы IDEF3

«Сборка настольных компьютеров» (A22.1).

2) Удалите элементы, не входящие в сценарий (рис. 49).

Рис. 49. Результат создания сценария

117

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

частный случай реализации технологического процесса, описанного в

нотации IDEF3.

Задание 8.

Моделирование потоков данных, диаграммы потоков данных

(DFD).

При оформлении заказа важно проверить, существует ли такой

клиент в базе данных. Если он не существует, нужно внести его в базу

данных и затем оформить заказ. Оформление заказа начинается со

звонка клиента. В процессе оформления заказа база данных клиентов

может просматриваться и редактироваться. Заказ должен включать как

информацию о клиенте, так и информацию о заказанных продуктах.

Оформление заказа подразумевает чтение и запись информации о

прочих заказах.

В процессе декомпозиции, согласно правилам DFD, необходимо

преобразовать граничные стрелки во внутренние, начинающиеся и

заканчивающиеся на внешних ссылках.

1. Декомпозируйте работу «Оформление заказов» на диаграмме

A2.

2. В диалоге Activity Box Count выберите количество работ 2 и

нотацию DFD.

3. Щелкните по OK и внесите в новую диаграмму DFD A22 имена

работ:

Проверка и внесение клиента.

Внесение заказа.

4. Используя кнопку на палитре инструментов, внесите

хранилища данных:

Список клиентов.

Список продуктов.

Список заказов.

5. Удалите граничные стрелки с диаграммы DFD A22.

6. Используя кнопку на палитре инструментов, внесите

внешнюю ссылку:

Звонки клиентов.

7. Создайте внутренние ссылки согласно рис. 50. При именовании

стрелок используйте словарь.

118

Рис. 50. Диаграмма DFD

8. Обратите внимание, что стрелки «Информация о клиентах» и

«Заказы клиентов» двунаправленные. Для того чтобы сделать стрелку

двунаправленной, щелкните правой кнопкой по стрелке, выберите в

контекстном меню пункт Style и во вкладке Style выберите опцию

Bidirectional.

9. На родительской диаграмме A1 туннелируйте (Change to Tunnel)

стрелки, подходящие к работе «Оформление заказов» и исходящие из

нее (см. рис. 51).

Рис. 51. Работа «Оформление заказов»

Тоннелирование показывает, что указанных стрелок нет в

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

119

Задание 9.

Моделирование данных, методология проектирования

реляционных баз данных IDEF1X.

Изучение возможностей логического и физического уровня

представления данных. Переключение уровней представления данных в

AllFusion ERWin Data Modeler.

IDEF1X является методом для разработки реляционных баз

данных и использует условный синтаксис, специально разработанный

для удобного построения схемы базы данных. Основные элементы

диаграммы – сущности и связи. Сущность в IDEF1X описывает собой

совокупность или набор экземпляров, похожих по свойствам, но

однозначно отличаемых друг от друга по одному или нескольким

признакам. Каждый экземпляр является реализацией сущности. Таким

образом, сущность в IDEF1X описывает конкретный набор экземпляров

реального мира. Примером сущности IDEF1X может быть сущность

«СОТРУДНИК», которая представляет собой всех сотрудников

предприятия, а один из них, скажем, Иванов Петр Сергеевич, является

конкретной реализацией этой сущности или экземпляром сущности. В

примере, разобранном в данной теме, каждый экземпляр сущности

СОТРУДНИК содержит следующую информацию: ID сотрудника, имя

сотрудника, адрес сотрудника и т.п. В IDEF1X модели эти свойства

называются атрибутами сущности. Каждый атрибут содержит только

часть информации о сущности.

AllFusion Data Modeler имеет два уровня представления модели –

логический и физический.

Логический уровень – это абстрактный взгляд на данные, когда

данные представляются так, как выглядят в реальном мире, и могут

называться так, как они называются в реальном мире, например,

«Постоянный клиент», «Отдел» или «Фамилия сотрудника».

Физическая модель данных, напротив, зависит от конкретной

СУБД, фактически являясь отображением системного каталога. В

физической модели содержится информация обо всех объектах БД.

Поскольку стандартов на объекты БД не существует (например, нет

стандарта на типы данных), физическая модель зависит от конкретной

реализации СУБД.

Для переключения между логической и физической моделью

данных существует список выбора в центральной части панели

инструментов. Фрагмент панели инструментов представлен на рис. 52.

120

Рис. 52. Фрагмент панели инструментов AllFusion ERwin Data Modeler

Основные компоненты диаграммы ERwin – это сущности,

атрибуты и связи. Каждая сущность является множеством подобных

индивидуальных объектов, называемых экземплярами. Каждый

экземпляр индивидуален и должен отличаться от всех остальных

экземпляров. Атрибут выражает определенное свойство объекта.

С точки зрения БД (физическая модель) сущности соответствует

таблица, экземпляру сущности – строка в таблице, а атрибуту –

колонка таблицы.

Задание 10.

Создание диаграммы IDEF1X в среде AllFusion ERwin Data

Modeler.

Рассмотрим в качестве предметной области предприятие, в

структуре которого имеются отделы, и спроектируем БД для хранения

сведений о служащих, работающих в отделах, и их детях. Основные

сущности – СОТРУДНИК, ОТДЕЛ, РЕБЕНОК.

1. Для создания новой модели запустите Erwin, выберете File

New. В результате появится диалоговое окно, представленное на рис. 53.

121

Рис. 53. Диалоговое окно создания новой модели

В данном окне установите переключатель на Logical/Physical. Это

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

данных, так и соответствующая ей физическая модель данных для СУБД

Access.

2. Для создания сущности кликните на значок на панели

инструментов. Задайте имя сущности СОТРУДНИК.

3. Для определения атрибутов щелкните правой кнопкой мыши по

сущности и выберите в контекстном меню пункт Attributes. Появится

диалоговое окно, представленное на рис. 54.

122

Рис. 54. Диалоговое окно редактирования атрибутов сущности

Щелкните по кнопке New… для создания нового атрибута. В

появившемся диалоговом окне укажите тип данных (Number), имя

атрибута для отображения на логической модели (Attribute Name:

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

модели (Column Name: EmpID). Далее для сущности СОТРУДНИК

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

таблице 8.

Таблица 8.

Структура сущности СОТРУДНИК

Имя атрибута Название колонки Тип данных

Табельный номер EmpID Number

Фамилия Familyname String

Имя Name String

Дата рождения Birthday Datetime

Адрес Address String

Пол Gender String

4. В качестве первичного ключа укажите Табельный номер (см.

рис. 55).

123

Рис. 55. Определение первичного ключа

Результат выполнения данного этапа представлен на рис. 56.

Рис. 56. Сущность СОТРУДНИК

По аналогии создайте сущности ОТДЕЛ и РЕБЕНОК согласно

данным, представленным в таблицах 9 и 10.

124

Таблица 9.

Структура сущности ОТДЕЛ


Номер отдела DepID Number

Название отдела DepName String

Таблица 10.

Структура сущности РЕБЕНОК


Код ребенка ChildID Number

Имя ребенка ChildName String

Дата рождения ребенка ChildDate Datetime

1. После создания сущностей необходимо задать связи между

ними.

Сущности СОТРУДНИК и ОТДЕЛ будут связаны

неидентифицирующей связью «один-ко-многим» (в данном примере в

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

числится только в одном отделе). Для этого необходимо щелкнуть по

кнопке на панели инструментов, далее кликнуть мышкой по

сущности ОТДЕЛ (сторона «один»), а затем по сущности СОТРУДНИК

(сторона «многим»). В сущности СОТРУДНИК появился новый атрибут

Номер отдела, который является внешним ключом.

Несмотря на то, что каждый служащий «подчинен» отделу, он

идентифицируется своим табельным номером независимо от отдела, в

котором работает. Так как при установлении неидентифицирующей

связи первичный ключ сущности ОТДЕЛ мигрирует в состав

непервичных атрибутов сущности СОТРУДНИК, независимая сущность

изображается в виде прямоугольного блока, внутри которого указан

список атрибутов.

2. Сущности СОТРУДНИК и РЕБЕНОК будут связаны

идентифицирующей связью «один-ко-многим». Для этого необходимо

щелкнуть по кнопке на панели инструментов, далее кликнуть

мышкой по сущности СОТРУДНИК (сторона «один»), а затем по

сущности РЕБЕНОК (сторона «многим»). В сущности, РЕБЕНОК

появился новый атрибут Табельный номер, который является внешним

ключом и входит в состав первичных атрибутов данной сущности.

Таким образом, сущность РЕБЕНОК является зависимой,

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

125

информации о его родителе. Зависимая сущность – это сущность,

однозначная идентификация экземпляра которой зависит от его

подчиненности другой сущности. Зависимая сущность изображается в

виде блока с закругленными углами.

Результат создания связей между сущностями приведен на рис. 57.

На данном рисунке отображена логическая модель данных, а

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

Рис. 57. Результат создания связей между сущностями

Согласно методологии IDEF1X необходимо задать имена связей

между сущностям. Связи именуются глаголами. В нашем случае связи

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

СОТРУДНИК имеет РЕБЕНКА;

РЕБЕНОК принадлежит СОТРУДНИКУ;

ОТДЕЛ состоит из СОТРУДНИКОВ;

СОТРУДНИКИ принадлежат ОТДЕЛУ.

Для задания имени связи необходимо вызвать контекстное меню

связи и выбрать пункт Relationship Properties. Появится диалоговое окно,

представленное на рис. 58. В появившемся диалоговом окне, находясь во

вкладке General, в область Verb Phrase вводятся имена связи в обоих

направлениях. В данном примере для связи СОТРУДНИК-РЕБЕНОК в

поле Parent-to-Child указываем имя имеет, а в поле Child-to-Parent –

принадлежит.

126

Рис. 58. Диалоговое окно Relationship

Аналогичным образом задаем имена для связи СОТРУДНИК-

ОТДЕЛ.

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

отображения имени связи следует в контекстном меню поля диаграммы

выбрать пункт меню Relationship Display и затем щелкнуть Verb Phraze.

Результат представлен на рис. 59.

Рис. 59. Логическая модель данных с именованным связями

127

На данном рисунке отображена логическая модель данных, а

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

Рис. 60. Физическая модель данных

В результате выполнения данного пункта мы получили

инфологическую модель базы данных и соответствующую ей

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

каталога выбранной нами СУБД.

Задание 11.

Задание правил валидации и значений по умолчанию.

На этапе создания физической модели данных вводятся правила

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

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

значений и/или правила проверки допустимых значений. Значение по

умолчанию – значение, которое нужно ввести в колонку, если никакое

другое значение не задано явным образом во время ввода данных.

Для задания правил валидации необходимо, находясь в режиме

редактирования физической модели данных, вызвать контекстное меню

необходимой таблицы, выбрать пункт меню Columns, в появившемся

диалоговом окне Columns выбрать название нужной колонки, перейти во

вкладку Constraint и там щелкнуть по кнопке в области Validation

Constraint. Появится диалоговое окно, представленное на рис. 61.

128

Рис. 61. Диалоговое окно для создания правил валидации

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

пределах 01/01/1920 и 01/01/1990. Для этого в появившемся диалоговом

окне щелкнем на кнопке New. В результате появится диалоговое окно

для задания имени нового правила валидации (рис. 62).

Рис. 62. Задание имени для нового правила валидации

После задания имени для правила валидации в окне Validation

Rules во вкладке General выберем Min/Max и укажем соответствующий

диапазон (рис. 63).

129

Рис. 63. Задания правила валидации для проверки возраста

После создания правила валидации проассоциируем его с

необходимой нам колонкой (в данном случае – Birthday). Результат

представлен на 64.

130

Рис. 64. Результат создания правила валидации для колонки Birthday

По аналогии зададим список допустимых значений: «М» и «Ж»

для колонки Gender. Для этого необходимо создать новое правило

валидации для соответствующей колонки. Далее во вкладке General

диалогового окна Validation Rules необходимо установить

переключатель на Valid Values List и в появившейся таблице Valid Value

в колонку Valid Value ввести значения М и Ж.

Задание 12.

Виды ключей и создание индексов.

Чтобы решить проблему поиска данных, СУБД использует особый

объект, называемый индексом. Он подобен содержанию книги, которое

указывает на все номера страниц, посвященных конкретной теме.

Индекс содержит отсортированную по колонке или нескольким

колонкам информацию и указывает на строки, в которых хранится

конкретное значение колонки.

При генерации схемы физической базы данных ERwin

автоматически создает отдельный индекс на основе первичного ключа

каждой таблицы, а также всех альтернативных и ключей и

инверсионных входов, поскольку эти колонки наиболее часто

используются для поиска данных. Можно отказаться от генерации

индексов по умолчанию и для повышения производительности создать

собственные индексы. Администратор СУБД должен анализировать

наиболее часто выполняемые запросы и создавать индексы с

131

различными колонками и порядком сортировки для увеличения

эффективности поиска при работе конкретных приложений.

Альтернативный ключ (Alternate Кеу) – это потенциальный

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

альтернативных ключей, по которым в дальнейшем по умолчанию при

генерации схемы базы данных будет генерироваться уникальный

индекс.

Инверсионный вход (Inversion Entry) – это атрибут или группа

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

образом, но часто используются для обращения к экземплярам

сущности. ERwin генерирует неуникальный индекс для каждого

Inversion Entry.

К примеру, для сущности РЕБЕНОК определим альтернативный

ключ Код ребенка.

Создать альтернативные ключи и инверсионные входы можно во

вкладке диалога Attributes, щелкнув по кнопке , или из контекстного

меню сущности выбрать пункт Key Group. В результате появится

диалоговое окно, представленное на рис. 65.

132

Рис. 65. Диалоговое окно Key Groups

В приведенном диалоговом окне необходимо щелкнуть по кнопке

New, в результате чего появится окно New Key Group (см. рис. 66) для

задания имени и типа нового ключа.

Рис. 66. Диалоговое окно New Key Group

Каждому ключу соответствует индекс, имя которого также

присваивается автоматически (XAKNENTITY для альтернативного

ключа и XIENENTITY для инверсионного входа, где N – порядковый

номер ключа, ENTITY – имя сущности). Имена ключа и индекса при

желании можно изменить вручную.

После указания имени и типа нового ключа в окне Key Groups для

данного ключа во вкладке Members указываем состав атрибутов

создаваемого ключа. В данном случае – Код ребенка. Выполнение

данных действий приведено на рис. 67.

133

Рис. 67. Указание атрибутного состава ключа

Например, если часто перед пользователями будет вставать задача

по поиску сотрудника по фамилии, то для этой колонки можно будет

создать индекс. Однако следует учитывать, что данный индекс не будет

уникальным (наверняка на предприятии работают сотрудники с

одинаковыми фамилиями), поэтому изначально для атрибута Фамилия

создадим инверсионный вход по вышеприведенной аналогии. При

создании инверсионного входа в окне New Key Group (см. рис. 66)

необходимо поставить переключатель на Inversion Entry.

Задание 13.

Трансформация связи «многие-ко-многим».

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

данных, проводит различные курсы для детей своих сотрудников. В

данной ситуации возможны случаи, когда один ребенок будет записан

на несколько курсов, и на один курс, в свою очередь, будут записаны

несколько детей.

134

Сначала создадим новую сущность КУРС с атрибутами Номер

курса и Название курса. С помощью кнопки свяжем отношения

РЕБЕНОК и КУРС связью «многие-ко-многим». Результат показан на

рис. 68.

Рис. 68. Связывание сущностей связью «многие-ко-многим»

Связь «многие ко многим» может быть создана только на уровне

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

«многие-ко-многим» была преобразована. По умолчанию при переходе к

физическому уровню ERwin автоматически не преобразует связь

«многие-ко-многим». В этом случае на физическом уровне диаграмма

выглядит так же, как и на логическом, однако при генерации схемы

такая связь игнорируется.

Для преобразования связи «многие-ко-многим» принудительно

необходимо щелкнуть по связи правой кнопкой мыши и выбрать пункт

меню Create Association Table или щелкнуть по кнопке на панели

инструментов. В результате появится мастер преобразования связи

«многие-ко-многим», окно которого приведено на рис. 69.

135

Рис. 69. Мастер преобразования связи «многие-ко-многим»

Диалог Many-To-Many Relationship Transform Wizard предлагает

четыре шага для преобразования связи. Для перехода к следующему

шагу надо щелкнуть по кнопке Next (Далее). На втором и третьем шаге

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

(ЗАПИСЬ). Результат трансформации представлен на рис. 70. В

результате появилась переходная сущность, в состав первичных

атрибутов которой входят первичные атрибуты двух исходных

сущностей.

Рис. 70. Результат трансформации связи «многие-ко-многим»

136

Следует отметить, что из сущности РЕБЕНОК в сущность

ЗАПИСЬ мигрировали два атрибута составного первичного ключа (Код

ребенка и Табельный номер). Очевидно, что атрибут Табельный номер

является лишним и не несет для данной сущности никакой информации.

Следовательно, необходимо сделать так, чтобы в итоге в сущность

ЗАПИСЬ из сущности РЕБЕНОК мигрировал только атрибут Код

ребенка.

ERwin позволяет создавать связи, при которых в дочернюю

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

создания такой связи необходимо создать идентифицирующую или

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

выбрать пункт меню Relationship Properties и в списке выбора Migrated

Key (диалог Relationships, вкладка Rolename) выбрать ключ, атрибуты

которого будут мигрировать в дочернюю сущность. В нашем случае в

качестве мигрирующего ключа выберем альтернативный ключ Код

ребенка. Выполнения данных действий приведено на рис. 71.

Рис. 71. Выбор мигрирующих атрибутов

В итоге получаем новую структуру сущности ЗАПИСЬ,

представленную на рис. 72.

137

Рис. 72. Результат изменения мигрирующих атрибутов

Добавим в сущность ЗАПИСЬ еще один атрибут Оплата (рис. 73).

Рис. 73. Результат добавления нового атрибута

Результат построения логической и физической моделей всей

предметной области в нотации IDEF1X приведен соответственно на рис.

74 и рис. 75.

Рис. 74. Логическая модель предметной области

138

Рис. 75. Физическая модель предметной области

Настроить внешний вид логической модели можно, вызвав

контекстное меню из пустого места диаграммы и в пунктах Entity

Display (для настройки внешнего вида сущности) и Relationship Display

(для настройки внешнего вида связи) выбрать необходимые элементы

для отображения. Настроить внешний вид физической модели можно,

вызвав контекстное меню из пустого места диаграммы и в пункте Table

Display также выбрать необходимые элементы для отображения.

139

Контрольный тест

1. Проект информационной системы – это …

а) проектно-конструкторская и технологическая документация

б) совокупность моделей, описывающих основные функции


в) совокупность требований к информационной системе

г) абстрактное представление предметной области

информационной системы в виде диаграмм

2. По степени адаптивности различают методы проектирования:

а) ручные и компьютерные

б) параметризация и реструктуризация модели

в) оригинальные и типовые

г) канонические и спиральные

3. «Ручное» проектирование – это проектирование …

а) каскадное

б) каноническое

в) индустриальное

г) типовое

4. Проектирование информационной системы, когда происходит

адаптация проектных решений путем переработки соответствующих

компонентов – это …

а) реконструкция

б) параметризация

в) реструктуризация

г) модификация

5. Жизненный цикл информационной системы начинается с

момента …

а) принятия решения о создании информационной системы

б) создания и утверждения модели разрабатываемой


в) установки на пользовательские места

г) введения данных

6. Основные стандарты жизненного цикла информационных

систем:

а) ГОСТ Р ИСО/ИЭК 12207:1995; Oracle CDM; Rational Rose

Process; Microsoft Solution Framework; Extreme Programming

б) ГОСТ 34.601-90; РД IDEF-2000; MIL-STD-188

в) Семейство стандартов IDEF

г) Стандарты SADT

140

7. Жизненный цикл ИС состоит из групп процессов:

а) разработка, сопровождение, эксплуатация

б) основная, вспомогательная, организационная

в) рост, зрелость, упадок

г) моделирование, документирование, разработка

8. В каскадной модели …

а) каждый новый этап жизненного цикла начинается только после

полного завершения предыдущего этапа

б) требования к системе могут меняться на протяжении всего

жизненного цикла

в) заказчик постоянно контролирует процесс разработки

г) весьма трудно планировать строки работ

9. В спиральной модели …

а) пока не завершен очередной этап, не производится перехода к

следующему этапу

б) каждому витку спирали соответствует определенная стадия


в) высок риск получить систему, не удовлетворяющую

требованиям заказчика

г) идет разбиение большого объема работ на небольшие части

10. В итерационной (этапной) модели …

а) присутствуют обратные связи между этапами

б) переход к следующему этапу происходит только после

окончания предыдущего

в) начальные этапы требуют наибольших затрат

г) каждый следующий этап аккумулирует результаты

предыдущего этапа

11. Прототип – это …

а) разрабатываемый программный компонент, реализующий

отдельные функции и внешние интерфейсы разрабатываемого ПО

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

отдельные функции и внешние интерфейсы разрабатываемого ПО

в) модель информационной системы, построенная на начальных

«витках спирали»

г) окончательный вариант разрабатываемого ПО

141

12. Жизненный цикл ПО по методологии RAD состоит из:

а) анализа и планирования требований, проектирования,

построения, внедрения

б) сбора сведения и опроса пользователей, планирования,

построения модели, разработки и построения

в) согласования, уведомления, приведения и построения

г) моделирования, проектирования, построения, согласования

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

а) для разработки небольших локальных ИС

б) на начальных этапах анализа и проектирования ИС

в) для генерации кода программы

г) в процессе внедрения системы в опытную эксплуатацию

14. Репозиторий CASE-средства – это …

а) совокупность системной информации о конкретном CASE-

средстве

б) специализированная база данных, предназначенная для

отображения состояния проектируемой ЭИС в каждый момент времени

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

предметной области разрабатываемой ИС

г) резервная база данных, предназначенная для отображения

состояния проектируемой ЭИС

15. Контроль правильности построение диаграмм в CASE-средстве

осуществляется с помощью …

а) документатора проекта

б) верификатора проекта

в) администратора проекта

г) набора сервисных утилит

16. По степени интегрированности CASE-средства различают:

а) локальные и распределенные

б) CASE-средства, поддерживающие какой-либо один этапов

жизненного цикла ИС и CASE-средства, поддерживающие несколько

этапов жизненного цикла ИС

в) tools, toolkit, workbench

г) функицонально-ориентированные, объектно-ориентированные

и смешанные

142

17. … является функционально-ориентированным CASE-

средством.

а) AllFusion Modeling Suite

б) Rational Rose

в) MS SQL Server

г) ARIS

18. IDEF – это …

а) стандарт жизненного цикла ИС

б) пакет международных стандартов для структурного анализа

бизнес-процессов

в) набор средств реинжиниринга бизнес-процессов

г) методология структурного анализа и проектирования

19. Целью построения модели AS-IS является …

а) выявление слабых и уязвимых мест деятельности организации

б) определение требований к будущей информационной системе

в) реинжиниринг бизнес-процессов предприятия

г) адаптация разрабатываемой ИС к условиям деятельности

организации

20. Для модели AS-IS …

а) строится несколько моделей TO-BE

б) разрабатывается информационная система

в) составляется проектная документация

г) разрабатывается ER-модель

21. IDEF1X – это …

а) использующий условный синтаксис метод разработки

реляционных баз данных

б) вариация IDEF1, основанная на использовании концептуальной

схемы

в) методология проектирования реляционных баз данных

г) методология для построения концептуальной схемы

логической структуры реляционной базы данных, которая была бы

независимой от программной платформы ее конечной реализации

22. IDEF3 – это …

а) средство для удобного описания рабочих процессов, для

которых важно отразить логическую последовательность выполнения

процедур

б) стандарт для описания последовательностей и логики

взаимодействия операций и событий в анализируемой системе

в) представление сценария бизнес-процесса

г) методология документирования процессов, происходящих в

143

системе

23. В AllFusion Process Modeler диаграмма дерева узлов

показывает …

а) то же, что диаграмма IDEF0

б) то же, что и диаграмма IDEF3

в) иерархию работ

г) альтернативную точку зрения на бизнес-процессы

24. На этапе физического проектирования понятиям «сущность» и

«атрибут» соответствуют понятия:

а) таблица и столбец

б) таблица и строка

в) таблица и ключ

г) таблица связь

25. Неверно, что на физическом уровне поддерживается связь …

а) идентифицирующая «один-ко-многим»

б) неидентифицирующая «один-ко-многим»

в) «один-ко-одному»

г) «многие-ко-многим»

26. Программные процедуры, обеспечивающие выполнение

объектом определенных действий, называются …

а) свойства объекта

б) методы объекта

в) варианты использования объекта

г) кооперация объекта

27. Класс объектов – это совокупность объектов, …

а) относящихся к одной предметной области

б) отображенных на одной диаграмме

в) использующих одинаковые методы

г) имеющих общий набор свойств и характеризующихся

одинаковым поведением

28. Физический уровень системы моделируют:

а) диаграмма компонентов и диаграмма размещения

б) диаграмма деятельности и диаграмма классов

в) диаграмма классов и диаграмма размещения

г) диаграмма размещения и диаграмма деятельности

144

29. Потоки работ во взаимосвязанных вариантах использования

отображаются на диаграмме …

а) кооперации

б) компонентов

в) размещения

г) деятельности

30. На диаграмме классов объектов при описании конкретного

класса указывают имена …

а) экземпляров класса

б) атрибутов

в) методов

г) вариантов использования

31. Методология RAD применима для …

а) сложных расчетных программ, операционных систем и других

программ большого объема

б) экономических информационных систем

в) банковских информационных систем

г) информационных киосков метрополитена

32. Методология быстрой разработки RAD содержит:

а) небольшую команду программистов, короткий и тщательно

проработанный график и повторяющийся цикл, обеспечивающий

доработку продукта через взаимодействие с заказчиком

б) требования к анализу, проектированию и генерации кода, а

также тестированию ПО, позволяющие сократить сроки и затраты на

разработку ПО

в) рекомендации по трансформированию предложений конечных

пользователей в схемы рабочих прототипов

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

программного продукта

33. Цель реинжиниринга бизнес-процессов …

а) перераспределение ресурсов (трудовых, финансовых и др.) и

минимизация затрат, направленный на оптимизацию организационной

структуры предприятия, повышение эффективности его

функционирования при внедрении новой информационной системы

б) перераспределение ресурсов предприятия с целью повышения

прибыли и увеличения доли на рыке

145

в) системная реорганизация материальных, финансовых и

информационных потоков, направленных на упрощение

организационной структуры, перераспределение и минимизацию

использования различных ресурсов, сокращение сроков реализации

потребностей клиентов, повышение качества их обслуживания

г) системная реорганизация информационных потоков,

перераспределение ресурсов и сокращение сроков выполнения заказов,

повышение качества обслуживания клиентов в условиях новой


34. Верным утверждением, является «…».

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

могут не отображаться механизмы

б) каждая работа на функциональной диаграмме обязательно

должна иметь хотя бы одну стрелку входа

в) каждая работа на функциональной диаграмме обязательно

должна иметь хотя бы одну стрелку управления

г) каждая работа на функциональной диаграмме обязательно

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

35. На диаграммах потоков данных отображается …

а) внешняя сущность

б) работа

в) перекресток

г) хранилище данных

36. В разработке языка UML принимал участие …

а) Гради Буч

б) Дуглас Росс

в) Уинстон Ройс

г) Джеймс Рамбо

37. В Rational Suite …

а) поддерживается язык UML

б) поддерживается методология SADT

в) имеются средства генерации проектной документации

г) имеются средства быстрой разработки приложений

38. Каноническое проектирование …

а) это ручная технология индивидуального (оригинального)

проектирования

б) поддерживается большинством CASE-средств

в) это технология, в основе которой лежит спиральная модель


146

г) это технология, в которой основной упор делается на

начальные этапы проектирования

39. Государственный стандарт ГОСТ 19.102-77 устанавливает

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

а) Техническое задание, Эскизный проект, Технический проект,

Рабочий проект, Внедрение

б) Технико-экономическое обоснование, Техническое задание,

Эскизный проект, Техно-рабочий проект, Внедрение

в) Техническое задание, Эскизный проект, Технический проект,

Рабочий проект, Акт о внедрение, Акт о сдачи в эксплуатацию

г) Технико-экономическое обоснование, Техническое задание,

Эскизный проект, Технический проект, Рабочий проект, Внедрение

40. Результатом предпроектной стадии является …

а) техническое задание

б) сбор материалов для обследования

в) технико-экономическое обоснование проекта

г) техно-рабочий проект

41. В техническое задание включают …

а) постановку задачи

б) требования к системе

в) характеристику объекта автоматизации

г) состав и содержание работ по созданию системы

42. Принцип, в соответствии с которым система должна обладать

характеристиками отказоустойчивости, называется …

а) надежность

б) окупаемость

в) гибкость

г) безопасность

43. Средства проектирования должны …

а) зависеть от конкретной ОС и СУБД

б) охватывать начальные этапы жизненного цикла ИС

в) охватывать весь жизненный цикл ИС

г) экономически целесообразны

44. В объектно-ориентированном проектировании вариант

использования – это …

а) последовательность действий, выполняемых пользователем

при осуществлении бизнес-операций

б) одно из состояний, которое может принимать объект в ответ на

действие пользователя

147

в) работа, которая может быть декомпозирована на совокупность

других вариантов использования

г) последовательность действий (транзакций), выполняемых

системой в ответ на событие, инициируемое некоторым внешним

объектом

45. Принцип, в соответствии с которым на разработку системы

затрачивается меньше финансовых средств, при условии получения

высокой эффективности, называется …

а) окупаемость

б) надежность

в) гибкость


46. Принцип, в соответствии с которым система должна легко

адаптироваться к изменению требований к ней называется …

а) гибкость

б) надежность

в) безопасность

г) дружественность

47. Принцип, в соответствии с которым система должна

обеспечивать сохранность информации, используя специальное

оборудование и шифры, называется …

а) безопасность

б) дружественность

в) окупаемость

г) надежность

48. Принцип, в соответствии с которым система должна быть

простой, удобной для освоения и использования, называется …

а) дружественность

б) окупаемость

в) надежность


49. Набор программ, выполняющий функции эксперта при

решении какой-либо задачи, называется …

а) экспертной системой

б) автоматизированной системой

в) системой управления базами данных

г) открытой системой

148

50. Структура технического задания на разработку

информационной системы регламентируется …

а) договором на создание информационной системы

б) государственным стандартом ГОСТ 34.602-89

в) международным стандартом ISO/IEC 12207

г) структурой предметной области

149

Ответы на тестовые задания

Тема 1.

Вопрос 1 2 3 4 5 6 7 8 9 10

Ответ б г б а б в б г а г

Тема 2.

Вопрос 1 2 3 4 5 6 7 8

Ответ а б б а а а г в

Тема 3.

Вопрос 1 2 3 4 5 6 7 8 9 10

Ответ г б а б б б а г в а

Тема 4.

Вопрос 1 2 3 4 5 6 7 8 9 10

Ответ а г б г а г в а г в

Тема 5.

Вопрос 1 2 3 4 5 6 7 8 9 10

Ответ а а г б б в в б в г

Тема 6.

Вопрос 1 2 3 4 5 6 7 8 9 10

Ответ а б г а б а г б в б

Documents

Handbook по дисциплине ...€¦ · Московский финансово-промышленный университет «Синергия» Кафедра Информационных