Рыбаченко Олег Павлович : другие произведения.

Основы организации проектирования информационных систем - в помощь студентов от Олега Рыбаченко получающего четвертое высшее образование

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
Ссылки:
 Ваша оценка:
  • Аннотация:
    Тут очень интересные проекты для студентов.
  
  
  
  
  
  љ Култыгин О.П., 2016
  љ Московский финансово-промышленный университет "Синергия", 2016
  
  Содержание
  
  
  
  Аннотация
  
  
  Тема 1. Основы организации проектирования информационных систем
  
  Вопрос 1. Понятия проект, проектирование. Основные требования к проектированию.
  
  Вопрос 2. Технология, методология и методы проектирования.
  
  Вопрос 3. Нормативно-методическое обеспечение создания программного обеспечения.
  
  Вопрос 4. Общие принципы проектирования систем.
  
  Вопросы для самопроверки:
  
  Литература по теме:
  
  
  Тема 2. Жизненный цикл ПО. Модели жизненного цикла ПО
  
  Вопрос 1. Понятие жизненного цикла ПО.
  
  Вопрос 2. Структура жизненного цикла ПО: основные, вспомогательные, организационные процессы.
  
  Вопрос 3. Модели жизненного цикла ПО. Каскадная и спиральная модели жизненного цикла ИС.
  
  Вопросы для самопроверки:
  
  Литература по теме:
  
  
  Тема 3. Технология проектирования ИС
  
  Вопрос 1. Основные понятия, история развития CASE-технологий.
  
  Вопрос 2. Классификация CASE-средств.
  
  Вопрос 3. Архитектура CASE-средств.
  
  Вопрос 4. Функционально-ориентированные и объектно-ориентированные CASE-средства. Обзор пакета инструментальных средств AllFusion Modeling Suite 7.1.
  
  Вопрос 5. Прототипное проектирование (RAD-технологии).
  
  Вопросы для самопроверки:
  
  Литература по теме:
  
  
  Тема 4. Состав и содержание работ по этапам жизненного цикла ПО. Проектная документация
  
  Вопрос 1. Состав и содержание проектной документации.
  
  Вопрос 2. Предпроектное исследование и Техническое задание.
  
  Вопрос 3. Техно-рабочее проектирование.
  
  Вопрос 4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта.
  
  Вопросы для самопроверки:
  
  Литература по теме:
  
  
  Тема 5. Проектирование информационного и программного обеспечения
  
  Вопрос 1. Основные принципы построения объектной модели. Основные элементы объектной модели.
  
  Вопрос 2. Унифицированный язык моделирования UML.
  
  Вопрос 3. Методология моделирования Rational Unified Process.
  
  Вопросы для самопроверки:
  
  Литература по теме:
  
  
  Тема 6. Структурные методы анализа и проектирования ПО
  
  Вопрос 1. Метод функционального проектирования SADT.
  
  Вопрос 2. Методология формализации и описания бизнес-процессов IDEF0 (общие сведения, состав функциональной модели, функциональная декомпозиция).
  
  Вопрос 3.Функциональное проектирование в среде AllFusion Process Modeler (модели AS-IS и TO-BE).
  
  Вопрос 4. Pеинжиниринг бизнес-процессов.
  
  Вопрос 5. Моделирование процессов в нотации IDEF3.
  
  Вопрос 6. Моделирование потоков данных, диаграммы потоков данных (DFD).
  
  Вопрос 7. Моделирование данных, методология проектирования реляционных баз данных IDEF1X, моделирование данных в среде AllFusion ERwin Data Modeler.
  
  Вопросы для самопроверки:
  
  Литература по теме:
  
  
  Литература
  
  Основная литература:
  
  Дополнительная литература:
  
  
  
  Аннотация
  
  
  Предметом изучения является процессы формирования требований, моделирования разрабатываемых информационных систем. Объектом изучения выступают информационные системы на этапах формирования требований, проектирования и разработки.
  
  
  
  Место дисциплины в учебном процессе.
  
  Дисциплина "Методы и средства проектирования информационных систем и технологий" посвящена изучению методологических основ проектирования информационных систем (ИС), формирует системных подход к реализации поставленных задач по разработке программного обеспечения (ПО). Дисциплина развивает ряд практических навыков и умений, позволяющих студентам создавать проекты информационных систем с использованием средств программной инженерии.
  
  Для успешного освоения настоящего курса необходимо предварительно завершить изучение следующих дисциплин:
  
  Ј Информационные технологии.
  
  Ј Управление данными.
  
  Ј Архитектура информационных систем.
  
  
  
  Цели и задачи дисциплины.
  
  Целью дисциплины "Методы и средства проектирования информационных систем и технологий" является изучение методологических основ проектирования современных информационных систем, развитие навыков работы с современными CASE-средствами, подготовка студентов к профессиональной деятельности в сфере разработки программного обеспечения.
  
  
  
  Прикладной задачей является изучение студентом следующих базовых вопросов:
  
  Ј раскрытие сущности и содержания основных понятий и категорий проектирования информационных систем: проект, проектирование, методология, технология, методы проектирования;
  
  Ј ознакомление с методологическими основами спецификации предметной области и формирования моделей будущих информационных систем на основе структурного и объектно-ориентированного подхода;
  
  Ј изучение истории развития программной инженерии;
  
  Ј развитие системного мышления по решению задач проектирования ИС;
  
  Ј формирование навыков коллективной и индивидуальной работы по исследованию предметной области с использованием современных CASE-средств и созданию проектной документации.
  
  
  
  Компетенции, формируемые в результате освоения учебной дисциплины.
  
  Процесс изучения дисциплины направлен на формирование следующих общекультурных (ОК) и профессиональных (ПК) компетенций, предусмотренных Федеральным государственным образовательным стандартом высшего профессионального образования по направлению подготовки 09.03.02 Информационные системы и технологии (квалификация (степень) "бакалавр"):
  
  Ј Способность проводить предпроектное обследование объекта проектирования, системный анализ предметной области, их взаимосвязей (ПК-1);
  
  Ј Способность проводить техническое проектирование (ПК-2);
  
  Ј Способность проводить рабочее проектирование (ПК-3);
  
  Ј Способность проводить выбор исходных данных для проектирования (ПК-4);
  
  Ј Способность проводить моделирование процессов и систем (ПК-5);
  
  Ј Способность оценивать надежность и качество функционирования объекта проектирования (ПК-6);
  
  Ј Способность осуществлять сертификацию проекта по стандартам качества (ПК-7);
  
  Ј Способность проводить расчет экономической эффективности (ПК-9);
  
  Ј Способность к инсталляции, отладке программных и настройке технических средств для ввода информационных систем в опытную и промышленную эксплуатацию (ПК-28);
  
  Ј Способность проводить сборку информационной системы из готовых компонентов (ПК-29);
  
  Ј Способность к инсталляции, отладке программных и настройке технических средств для ввода информационных систем в опытную и промышленную эксплуатацию (ПК-34);
  
  Ј Способность адаптировать приложения к изменяющимся условиям функционирования (ПК-32).
  
  
  
  В результате изучения дисциплины обучаемый должен:
  
  знать:
  
  Ј понятия методы, методология проектирования;
  
  Ј классификацию методов проектирования;
  
  Ј понятие жизненного цикла ПО, моделей жизненного цикла ПО;
  
  Ј основные нормативные документы, регламентирующие деятельность разработчиков по созданию ПО;
  
  Ј классификацию, архитектуру CASE-средств;
  
  Ј основные подходы к разработке ПО;
  
  Ј основные этапы разработки и принципы функционирования ИС;
  
  Ј особенности функционального (структурного) подхода к проектированию ПО;
  
  Ј особенности объектно-ориентированного подхода к проектированию ПО;
  
  Ј особенности проектирования систем распределенной обработки;
  
  Ј стандарты ГОСТ на разработку проектной документации;
  
  
  
  уметь:
  
  Ј разрабатывать информационную модель предметной области;
  
  Ј осуществлять формализованное описание предметной области в нотациях IDEF0, IDEF1X, IDEF3, DFD;
  
  Ј формировать объектные модели предметной области;
  
  Ј составлять проектную документацию на разрабатываемую систему;
  
  
  
  приобрести навыки:
  
  Ј выбора оптимальной технологии проектирования и модели жизненного цикла в соответствии со спецификой решаемой задачи по автоматизации;
  
  Ј формализованного описания моделей предметной области;
  
  Ј работы с CASE-средствами;
  
  
  
  иметь представление:
  
  Ј о перспективах развития CASE-средств;
  
  Ј о проблемах создания информационных систем различной архитектуры и сложности;
  
  Ј о методах и современных средствах моделирования информационных систем;
  
  Ј об организации оптимального управления ИТ-проектом;
  
  Ј об особенностях проектирования систем защиты данных.
  
  
  
  Тема 1. Основы организации проектирования информационных систем
  
  
  Цель темы: раскрытие сущности и содержания основных понятий и категорий проектирования информационных систем.
  
  
  
  Задачи темы: формирование у студентов теоретических основ дисциплины.
  
  
  
  Вопросы темы:
  
  1. Понятия проект, проектирование, основные требования к проектированию.
  
  2. Технология, методология и методы проектирования.
  
  3. Нормативно-методическое обеспечение создания программного обеспечения.
  
  4. Общие принципы проектирования систем.
  
  
  
  Вопрос 1. Понятия проект, проектирование. Основные требования к проектированию.
  
  
  Проект ИС - это проектно-конструкторская и технологическая документация, содержащая описание проектных решений по созданию и эксплуатации информационной системы в конкретной программно-технической среде.
  
  Процесс проектирования ИС представляет собой преобразование входной информации об объекте и методах проектирования в проект ИС в соответствии с ГОСТом.
  
  Объекты проектирования ИС - это элементы (задачи), комплекс задач функциональной и обеспечивающей частей. В состав обеспечивающей части ИС входят элементы и их комплексы информационного, программного и технического обеспечения системы.
  
  Субъектами проектирования ИС являются проектная организация и организация заказчик.
  
  
  
  Вопрос 2. Технология, методология и методы проектирования.
  
  
  Технология проектирования ИС - это комплекс методологий и средств проектирования, а также методов и средств организации проектирования.
  
  Технологию проектирования ИС можно представить в виде технологического процесса проектирования ИС, отображающего последовательность действий, необходимые средства и ресурсы для выполнения этих действий и состав исполнителей.
  
  В процессе работы над проектом необходимо знать ЧТО, КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано.
  
  Требования к выбираемой технологии проектирования:
  
  Ј проект по выбранной технологии должен отвечать требованиям заказчика;
  
  Ј максимальное отображение всех этапов жизненного цикла проекта;
  
  Ј обеспечение min трудовых и стоимостных затрат на проектирование и сопровождение проекта;
  
  Ј технология должна способствовать росту производительности труда проектировщика;
  
  Ј простота ведения проектной документации;
  
  Ј технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта.
  
  
  
  Методология проектирования предполагает наличие концепции, принципов проектирования, реализуемых набором методов, которые должны поддерживаться средствами проектирования.
  
  Методы проектирования ИС можно классифицировать:
  
  по степени автоматизации:
  
  Ј ручное - без использования специальных инструментальных программных средств, а программирование на алгоритмических языках;
  
  Ј компьютерное - генерация или конфигурация (настройка) проектных решений на основе использования специальных инструментальных программных средств;
  
  
  
  по степени использования типовых проектных решений:
  
  Ј оригинальное (индивидуальное) - разработка с "нуля";
  
  Ј типовое - настройка ИС из готовых типовых проектных решений - программных модулей;
  
  
  
  по степени адаптивности проектных решений методы проектирования классифицируются на методы:
  
  Ј реконструкции - адаптация, путем программирования модулей;
  
  Ј параметризации - настройка в соответствии с изменяемыми параметрами;
  
  Ј реструктуризации модели - изменение модели проблемной области, на основе которой автоматически перегенерируются проектные решения.
  
  
  
  Сочетание различных признаков классификации методов проектирования обуславливает характер используемой технологии проектирования ИС, среди которых можно выделить два основных класса:
  
  o каноническая - для небольших локальных ИС;
  
  o индустриальная технология, подразделяющаяся на:
  
  Ј автоматизированное - использование CASE-технологий;
  
  Ј типовое - параметрически-ориентированное или модельно-ориентированное.
  
  
  
  Конкретные виды технологий проектирования требуют выбора средств проектирования, которые по своим характеристикам максимально соответствовали бы требованиям конкретного предприятия.
  
  Средства проектирования должны обладать следующими качествами:
  
  Ј охватывать все этапы жизненного цикла ИС;
  
  Ј совместимы технически, программно и информационно;
  
  Ј просты в освоении и применении;
  
  Ј экономически целесообразны.
  
  
  
  Средства проектирования ИС можно разделить на два класса:
  
  1. без использования ЭВМ на всех стадиях проектирования (средства организационно-методического обеспечения операций проектирования, куда входят стандарты, регламентирующие процесс проектирования систем, Единая Система Классификации и Кодирования информации, унифицированная система документации (УСД), модели описания и анализа потоков информации и т.п.);
  
  2. с использованием ЭВМ, которые подразделяются на 4 подкласса (см. Таблица 1):
  
  
  
  Таблица 1.
  
  
  
  Средства проектирования с использованием ЭВМ
  
  
  
  I
  
  II
  
  III
  
  IV
  
  Операционные средства:
  
  Средства общесистемного
  
  назначения:
  
  Функциональные средства:
  
  Средства авт-ции проектирования ЭИС
  
  Алгоязыки, библиотеки стандартных подпрограмм и классов объектов, ...
  
  Средства для тестирования и отладки программ, поддержки процесса документирования проекта и т.д.
  
  Ј СУБД,
  
  Ј методоориентированные ППП (задачи дискретного программирования, мат. Статистики),
  
  Ј табл. процессоры ,
  
  Ј статистические ППП,
  
  Ј граф., текстовые редакторы,
  
  Ј оболочки экспертных систем,
  
  Ј интегрированные ППП
  
  Ј типовые проектные решения,
  
  Ј функциональные ППП,
  
  Ј типовые проекты
  
  Средства, поддерживающие разработку проекта - CASE -технологии.
  
  
  
  Вопрос 3. Нормативно-методическое обеспечение создания программного обеспечения.
  
  
  Нормативно-методическое обеспечение (НМО) - комплекс документов, регламентирующих различные аспекты процессов деятельности разработчиков.
  
  Эти документы регламентируют:
  
  Ј порядок разработки, внедрения, сопровождения ПО;
  
  Ј общие требования к составу ПО и связям между его компонентами, а также к его качеству;
  
  Ј виды, состав и содержание проектной и программной документации.
  
  
  
  Нормативной базой НМО являются международные и отечественные стандарты в области информационных технологий и прежде всего:
  
  Ј международные стандарты ISO/IEC;
  
  Ј стандарты Российской Федерации ГОСТ Р;
  
  Ј стандарты организации-заказчика.
  
  
  
  В результате для каждого серьезного проекта приходится создавать комплекты нормативных и методических документов, регламентирующих процессы, этапы, работы, документы конкретных программных продуктов, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.
  
  
  
  Вопрос 4. Общие принципы проектирования систем.
  
  
  Одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как "разделяй и властвуй" {divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие "правильная" по отношению к декомпозиции означает следующее:
  
  Ј количество связей между отдельными подсистемами должно быть минимальным (принцип "слабой связанности" - Low Coupling);
  
  Ј связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип "сильного сцепления" - High Cohesion).
  
  
  
  Более подробно эти принципы будут рассмотрены в рамках объектно-ориентированного анализа.
  
  Структура системы должна быть такой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки, т.е.:
  
  Ј каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
  
  Ј каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
  
  
  
  Инкапсуляция (принцип "черного ящика") позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
  
  Существуют два основных подхода к декомпозиции систем. Первый подход называют функционально-модульным, он является частью более общего структурного подхода. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход, использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.-
  
  
  
  Вопросы для самопроверки:
  1. Назовите основные составляющие проекта ИС.
  
  2. Дайте определение объекту и субъекту проектирования.
  
  3. Что включает в себя технология проектирования ИС?
  
  4. Каковы требования к технологии проектирования ИС?
  
  5. Что такое методология проектирования ИС?
  
  6. Как классифицируются методы проектирования?
  
  7. Какие признаки характеризуют автоматизированное проектирование?
  
  8. Как классифицируются средства проектирования?
  
  9. Каковы требования к проектированию ИС?
  
  10. Что входит в состав нормативно-методологической базы проектирования ИС?
  
  
  
  Литература по теме:
  1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. И доп. - М.: Финансы и Статистика, 2006 - 544с., с.37-39, с.104-108.
  
  2. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М.: Финансы и Статистика, 2003 - 512 с., с.27-35.
  
  
  
  Тема 2. Жизненный цикл ПО. Модели жизненного цикла ПО
  
  
  Цель темы: раскрытие понятия жизненный цикл ПО и модель жизненного цикла ПО.
  
  
  
  Задачи темы: формирование у студентов понятия жизненного цикла ПО, модели жизненного цикла.
  
  
  
  Вопросы темы:
  
  1. Понятие жизненного цикла ПО.
  
  2. Структура жизненного цикла ПО: основные, вспомогательные, организационные процессы.
  
  3. Модели жизненного цикла ПО. Каскадная и спиральная модели жизненного цикла ИС.
  
  
  
  Вопрос 1. Понятие жизненного цикла ПО.
  
  
  Жизненный цикл (ЖЦ) ИС - совокупность стадий и этапов, которые проходит ИС в своем развитии от момента принятия решения о создании системы до момента прекращения ее функционирования.
  
  
  
  Вопрос 2. Структура жизненного цикла ПО: основные, вспомогательные, организационные процессы.
  
  
  На рис. 1 представлена структура жизненного цикла информационных систем согласно стандарту ISO/IEC 12207.
  
  
  
  
  
  
  
  Рис. 1. Структура жизненного цикла ИС по стандарту ISO/IEC 12207
  
  
  
  Процесс приобретения состоит из действий и задач заказчика, приобретающего ПО. Процесс поставки охватывает действия и задачи, выполняемые поставщиком.
  
  Разработка ПО - все работы по созданию ПО и его компонент в соответствии с заданными требованиями., включая оформление проектной и эксплуатационной документации.
  
  Эксплуатация - работы по внедрению компонентов ПО, конфигурирование БД и рабочих мест.
  
  Процесс сопровождения активизируется при изменениях программного продукта и соответствующей документации. Внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям.
  
  Управление конфигурацией - поддержка основных процессов ЖЦ ПО, прежде всего процессов разработки и сопровождения ПО.
  
  Обеспечение качества проекта - верификация, проверка и тестирование ПО.
  
  Управление проектом - планирование и организация работ, создание коллектива разработчиков, контроль за сроками и качеством выполняемых работ.
  
  
  
  Вопрос 3. Модели жизненного цикла ПО. Каскадная и спиральная модели жизненного цикла ИС.
  
  
  Модель жизненного цикла - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ.
  
  Модель жизненного цикла зависит от специфики информационной системы, специфики условий и от сложности и масштаба проекта. Технологии проектирование ЭИС, определяющие порядок выполнения стадий и этапов претерпевали существенные изменения. Среди известных моделей ЖЦ ИС можно выделить каскадную и спиральную модели.
  
  Каскадная модель ЖЦ была разработана в 1970 году экспертом в области ПО Уинстоном Ройсом. Каскадная модель предполагала последовательный переход на следующий этап после полного завершения предыдущего (см. рис. 2). Данная модель применима для отдельных несвязных задач, не требующая выполнения информационной интеграции и совместимости программного, технического и организационного сопровождения. Применение каскадной модели к большим и сложным проектам вследствие большой длительности процесса проектирования и изменчивости за это время требований, приводит к их практической не реализуемости.
  
  
  
  Картинка 6 из 9
  
  
  
  Рис. 2. Каскадная модель ЖЦ ИС
  
  
  
  Достоинства каскадной модели:
  
  Ј На каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности.
  
  Ј Выполняемые в логической последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
  
  
  
  Недостатки каскадной модели:
  
  Ј Позднее обнаружение проблем.
  
  Ј Выход из календарного графика, запаздывание с получением результатов.
  
  Ј Избыточное количество документации.
  
  Ј Невозможность разбить систему на части (весь продукт разрабатывается за один раз).
  
  Ј Высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.
  
  
  
  Каскадная модель может использоваться при создании ПО, для которого в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. Однако, реальный процесс создания ПО никогда полностью не укладывается в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. Ввиду сложности и масштабности современных проектов по разработке ИС, каскадная модель в последнее время не используется в чистом виде.
  
  В середине 1980-х годов Барри Боэм предложил спиральную модель ЖЦ ИС. Проектирование ИС осуществляется "сверху - вниз", при котором сначала определяется состав функциональных подсистем ИС (комплекс задач с высокой степенью информационных обменов (связей) между задачами). При использовании данной модели ПО создается в несколько итераций (витков спирали, см рис. 3.) методом прототипирования. Каждый виток спирали соответствует отдельной версии ПО или прототипу.
  
  
  
  Картинка 5 из 9
  
  
  
  Рис. 3. Спиральная модель ЖЦ ИС
  
  
  
  Прототип - действующий программный компонент, реализующий отдельные функции и внешние интерфейса разрабатываемого ПО.
  
  
  
  Достоинства спиральной модели:
  
  Ј Ускорение разработки.
  
  Ј Постоянное участие заказчика в процессе разработки.
  
  Ј Разбиение большого объема работы на небольшие части.
  
  Ј Снижение риска (снижение вероятности непредсказуемого поведения системы).
  
  
  
  Недостатки спиральной модели:
  
  Ј Сложность планирования.
  
  Ј Сложность применения модели с точки зрения менеджеров и заказчика.
  
  Ј Напряженный режим работы для разработчиков.
  
  
  
  Основная проблема спирального цикла - определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.
  
  
  
  Вопросы для самопроверки:
  1. Что такое жизненный цикл программного обеспечения?
  
  2. Чем регламентируется ЖЦ ПО?
  
  3. Какие группы процессов входят в состав ЖЦ ПО и какие процессы входят в состав каждой группы?
  
  4. Какие из процессов, по вашему мнению, наиболее часто используются в реальных проектах, какие в меньшей степени и почему?
  
  5. Сформулируете понятие модели жизненного цикла.
  
  6. Каковы принципиальные особенности каскадной модели?
  
  7. В чем заключаются преимущества и недостатки каскадной модели?
  
  8. Каковы принципиальные особенности итерационной модели?
  
  9. В чем состоят преимущества и недостатки спиральной модели?
  
  
  
  Литература по теме:
  1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. И доп. - М.: Финансы и Статистика, 2006 - 544 с., Глава 1.
  
  2. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М.: Финансы и Статистика, 2003. - 512 с., с.35-41.
  
  
  
  Тема 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-средств предшествовали исследования в области программирования: разработка и внедрение языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки и т.д. Кроме того, этому способствовали следующие факторы:
  
  Ј подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
  
  Ј широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
  
  Ј внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования.
  
  
  
  Наибольшая потребность в CASE-средствах - начальные этапы анализа и спецификации требований. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.
  
  Преимущества CASE-технологии по сравнению с традиционной технологией оригинального (ручного) проектирования сводятся к следующему:
  
  Ј улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;
  
  Ј возможность повторного использования компонентов разработки;
  
  Ј поддержание адаптивности и сопровождения ЭИС;
  
  Ј снижение времени на создание системы, что позволит на ранних стадиях проектирования получить прототип будущей системы и оценить его;
  
  Ј освобождение разработчиков от рутинной работы по документированию проекта, за счет использования встроенного документатора;
  
  Ј возможность коллективной разработки ЭИС в режиме реального времени.
  
  
  
  Вопрос 2. Классификация CASE-средств.
  
  
  CASE-системы классифицируются по следующим признакам:
  
  1. по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);
  
  2. по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными;
  
  3. по степени интегрированности: tools (отдельные локальные средства), toolkit (набор интегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
  
  4. по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ЛВС, ГВС и смешанного типа;
  
  5. по режиму коллективной разработки проекта: на поддерживающие коллективную разработку, ориентированные на режим реального времени и на режим объединения подпроектов;
  
  6. по типу операционной системы (ОС): Windows, UNIX, OS/2 и др.
  
  
  
  Вопрос 3. Архитектура CASE-средств.
  
  
  Архитектура CASE-средства представлена на рис. 4.
  
  
  
  
  
  
  
  Рис. 4. Архитектура CASE-средства
  
  
  
  Ядро системы - база данных проекта - Репозиторий (словарь данных), представляющий собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени.
  
  Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными. В репозитории хранятся описания следующих объектов:
  
  Ј проектировщиков и их права доступа к различным компонентам системы;
  
  Ј организационных структур;
  
  Ј диаграмм, и связей между ними;
  
  Ј компонентов диаграмм;
  
  Ј структур данных;
  
  Ј программных модулей;
  
  Ј процедур;
  
  Ј библиотеки модулей и т.д.
  
  
  
  Графический редактор позволяет выполнять следующие операции:
  
  Ј создавать элементы диаграмм, их взаимосвязи и описания;
  
  Ј задавать описания элементов диаграмм и связей между ними;
  
  Ј редактировать элементы диаграмм, их взаимосвязи и описания.
  
  
  
  Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую систему, перестраивать ее в соответствии с поставленными целями и ограничениями.
  
  Верификатор - служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС.
  
  Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов, которые строятся по нескольким признакам (по времени, автору, элементам диаграмм, диаграмме или проекту в целом).
  
  Администратор проекта - это инструменты, необходимые для выполнения таких функций, как:
  
  Ј инициализация проекта:
  
  Ј задания начальных параметров проекта;
  
  Ј назначения и изменения прав доступа к элементам проекта;
  
  Ј мониторинга выполнения проекта.
  
  
  
  Сервис - набор системных утилит по обслуживанию репозитория (архивация данных, восстановления данных и создания нового репозитория).
  
  
  
  Вопрос 4. Функционально-ориентированные и объектно-ориентированные CASE-средства. Обзор пакета инструментальных средств AllFusion Modeling Suite 7.1.
  
  
  Большинство существующих CASE - систем ориентировано на автоматизацию проектирования ПО и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, и т.д.
  
  Одним из наиболее популярных CASE-средств, поддерживающих методологию структурного (функционального проектирования) является пакет AllFusion Modeling Suite, выпущенный компанией Computer Associates (CA).
  
  В этот пакет входит 5 продуктов:
  
  1. AllFusion Process Modeler .AllFusion Process Modeler является новым именем хорошо известного BPwin. Вообще говоря, в документации и пресс-релизах CA используются оба наименования - новое AllFusion Process Modeler и "старое" BPwin.
  
  2. AllFusion ERwin Data Modeler - инструмент создания моделей данных и генерации схем баз данных. "Старое" название - ERwin.
  
  3. AllFusion Data Model Validator - система поиска и исправления ошибок модели данных. Прежнее название - ERwin Examiner.
  
  4. AllFusion Model Manager Система организации коллективной работы, хранилище моделей BPwin и ERwin. "Старое" название - ModelMart .
  
  5. AIIFusion Component Modeler -инструмент создания объектных моделей. "Старое" название - Paradigm Plus.
  
  
  
  
  
  
  
  Рис. 5. Общая схема взаимодействия инструментальных средств AllFusion Modeling Suite
  
  
  
  Для проведения анализа и реорганизации бизнес-процессов предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как "внешняя ссылка" и "хранилище данных", что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.
  
  На основе модели BPwin можно построить модель данных. Для построения модели данных Computer Associates предлагает мощный и удобный инструмент - AIIFusion ERwin Data Modeler (ERwin). Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Computer Associates предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin (стрелка 1 на рис. 5). ERwin имеет два уровня представления модели - логический и физический, причем модель данных может содержать как оба этих уровня, так и только один из них. Модели, содержащие только один уровень, могут быть синхронизированы, что особенно удобно при создании гетерогенных информационных систем. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это, по существу, отображение системного каталога, который зависит от конкретной реализации СУБД. Создание одного логического уровня и нескольких соответствующих ему физических позволяет вести одновременную разработку баз данных для нескольких СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования баз данных (стрелка 2). Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования.
  
  Для больших, содержащих сотни таблиц моделей данных существенной проблемой становится поиск и исправление ошибок. Решение этой проблемы вручную - слишком трудоемкая задача, которая может недопустимо затянуть выполнение проекта. AllFusion Data Model Validator (ERwin Examiner) - основанный на базе знаний инструмент, который позволяет анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу поиска и исправления ошибок. ERwin Examiner может использовать в качестве источника метаданных готовую модель ERwin, DDL - скрипт или провести обратное проектирование базы данных (стрелки 3 и 4).
  
  При проектировании больших ИС ключевой проблемой является создание качественной документации по моделям. BPwin и ERwin позволяют генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования моделей. Отчеты могут быть экспортированы в распространенные форматы - текстовый, MS Office, HTML и др. Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin поддерживает также экспорт и импорт модели в текстовый файл формата IDL, который является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.
  
  Создание современных ИС, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Computer Associates предлагает систему ModelMart - хранилище моделей, к которому открыт доступ для участников проекта создания ИС (стрелка 5 на рисунке).
  
  
  
  Вопрос 5. Прототипное проектирование (RAD-технологии).
  
  
  С появлением корпоративных экономических информационных систем, базирующихся на архитектуре "клиент-сервер", появляется естественная возможность ускорения разработки приложений за счет параллельного создания клиентской и серверной частей. Основное желание заказчика ИС - получить быстро готовое приложение высокого качества при минимальных затратах на его разработку. Кроме того, вкладывая значительные средства на создание системы, заказчики желают контролировать процесс разработки. Критерием качества должно быть наиболее полное удовлетворение требований заказчиков на момент введения системы в эксплуатацию.
  
  Одним из условий обеспечения высокого качества создаваемых ИС является активное вовлечение конечных пользователей в процесс разработки предназначенных для них интерактивных систем, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD (Rapid Application Development), в основе которой заложена спиральная модель жизненного цикла ИС.
  
  Под RAD обычно понимается процесс разработки ПО, содержащий 3 элемента:
  
  Ј небольшую команду программистов (от 2 до 10 человек);
  
  Ј короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
  
  Ј повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
  
  
  
  Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств.
  
  Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
  
  Область самостоятельной разработки информационных систем (точнее, приложений) конечными пользователями ограничена. Такой вариант может быть применим для решения простых задач информационно-поискового и сводного характера.
  
  При создании более сложных корпоративных ИС пользователям необходимо работать совместно с проектировщиками на протяжении всего периода разработки. Для повышения качества и эффективности, создаваемых таким образом систем используется технология прототипного проектирования, которая обеспечивает создание на ранней стадии реализации действующей интерактивной модели системы, так называемой системы-прототипа, позволяющей наглядно продемонстрировать пользователю будущую систему, уточнить его требования, оперативно модифицировать элементы интерфейса: формы ввода сообщений, меню, выходные документы, структуру диалога, состав реализуемых функций.
  
  Достоинства. В процессе работы с системой-прототипом пользователь реально осознает возможности будущей системы и определяет наиболее удобный для него режим обработки данных, что значительно повышает качество создаваемых систем. Осуществляются проверка принципиальных проектных решений по составу и структуре ЭИС и оценка основных ее эксплуатационных характеристик.
  
  Вовлечение пользователей в процесс проектирования и конструирования приложения позволяет получать замечания и дополнения к требованиям непосредственно в процессе проектирования приложения, сокращая время разработки. Представители заказчика получают возможность контролировать процесс создания системы и влиять на ее функциональное наполнение. Результатом является сдача в эксплуатацию системы, учитывающей большинство потребностей заказчиков.
  
  Согласованная система-прототип служит спецификацией для дальнейшей разработки ЭИС, что позволяет на ранних этапах проектирования выявить возможные ошибки проектирования и определить параметры будущей системы.
  
  Основные возможности и преимущества быстрой разработки прототипа ИС представлены на рис. 6.
  
  
  
  
  
  
  
  Рис. 6. Основные возможности и преимущества RAD-технологий
  
  
  
  Все приемы для быстрой разработки приложений RAD служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся:
  
  1) разработка приложения итерациями;
  
  2) необязательность полного завершения работ на каждом из этапов ЖЦ для начала работ на следующем;
  
  3) обязательное вовлечение пользователей в процесс проектирования и построения системы;
  
  4) высокая параллельность работ;
  
  5) повторное использование частей проекта;
  
  6) необходимое применение CASE-cpeдств, обеспечивающих техническую целостность на этапах анализа и проектирования;
  
  7) применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы;
  
  8) использование автоматических генераторов (мастеров);
  
  9) использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;
  
  10) тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа.
  
  
  
  Каждое из перечисленных положений в отдельности способствует повышению скорости, улучшению качества, но только их совместное применение вызывает качественные изменения в процессе разработки.
  
  Вывод. Итерационное использование прототипного подхода к разработке ИС обеспечивает экономию ресурсов на проектирование, резкое сокращение времени на разработку и внедрение системы, а также значительное снижение объема доработок ИС при ее внедрении.
  
  
  
  Вопросы для самопроверки:
  1. Дайте определение CASE-средств.
  
  2. Какие факторы способствовали проявлению CASE-средств?
  
  3. Какова структура CASE-средств?
  
  4. Как классифицируются CASE-средства?
  
  5. Назовите основные составляющие и их предназначение программного пакета AllFusion Modeling Suite.
  
  6. В чем заключается сущность прототипного (RAD) проектирования?
  
  7. Каковы основные возможности и преимущества быстрой разработки прототипа.
  
  
  
  Литература по теме:
  1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. И доп. - М.: Финансы и Статистика, 2006 - 544 с., с.24-36.
  
  2. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М.: Финансы и Статистика, 2003. - 512 с., Глава 13.
  
  3. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. - М.: Издательский центр "Академия", 2004. - 288с., Глава 4.
  
  
  
  Тема 4. Состав и содержание работ по этапам жизненного цикла ПО. Проектная документация
  
  
  Цель темы: изучение состава и содержания работ, а также структуры проектной документации.
  
  
  
  Задачи темы: ознакомление со стандартами проектной документации и этапами ее создания, формирование навыков по разработке Технического задания и Постановки задачи, изучение особенностей формирования проектной документации на этапах внедрения.
  
  
  
  Вопросы темы:
  
  1. Состав и содержание проектной документации.
  
  2. Предпроектное исследование и техническое задание.
  
  3. Документация на этапе техно-рабочего проектирования.
  
  4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта.
  
  
  
  Вопрос 1. Состав и содержание проектной документации.
  
  
  Состав и содержание проектной документации будет рассматриваться в этой главе на примере канонического проектирования. Каноническое проектирование ИС отражает особенности ручной технологии индивидуального (оригинального) проектирования без использования инструментальных средств. Каноническое проектирование применяется для небольших локальных ИС.
  
  В основе канонического проектирования ИС лежит каскадная модель ЖЦ ИС, включающая следующие стадии:
  
  Ј Исследование и обоснование создания системы.
  
  Ј Разработка технического задания (ТЗ).
  
  Ј Создание эскизного проекта (ЭП).
  
  Ј Техническое проектирование (ТП).
  
  Ј Рабочее проектирование (РП).
  
  Ј Ввод в действие.
  
  Ј Функционирование, сопровождение, модернизация.
  
  
  
  Перечисленные стадии процесса разработки ИС можно представить в сгруппированном виде, представленном на рис. 7
  
  
  
  
  
  
  
  Рис. 7. Технологическая сеть проектирования ИС
  
  
  
  Д1.1 - предметная область;
  
  Д1.2 - материалы обследования;
  
  Д1.3 - ТЭО, ТЗ на проектирование;
  
  Д1.4 - ЭП (эскизный проект);
  
  Д2.1 - ТРП (техно-рабочий проект);
  
  Д3.1 - исправленный ТРП, переданный в эксплуатацию;
  
  Д3.2 - акт о приеме проекта в промышленную эксплуатацию;
  
  Д4.1 - модернизированный ТРП.
  
  П 1. - Предпроектная стадия;
  
  П 2. - Стадия проектирования;
  
  П 3. - Стадия внедрения;
  
  П 4. - Стадия эксплуатации и сопровождения.
  
  ТЭО - содержит расчеты и обоснование необходимости разработки ЭИС;
  
  ТЗ - содержит требования к системе и ее компонентам: программному, техническому и информационному обеспечению и целевую установку на проектирование новой ЭИС;
  
  ЭП - эскизный проект содержит сформулированные выше требования, которые являются основой для разработки предварительных решений по ЭИС. Прорабатываются информационные потребности на уровне документов и показателей.
  
  
  
  Вопрос 2. Предпроектное исследование и Техническое задание.
  
  
  Анализ материалов обследования позволяет разработчикам выделить и составить список автоматизируемых подразделений (отделы технико-экономического планирования, оперативного управления основным производством, технической подготовки производства, МТС, реализации и сбыта готовой продукции, бухгалтерия; выявить список автоматизируемых задач (связь с другими задачами, трудоемкость и оперативность расчета показателей, их достаточность, достоверность выходных данных, очередность проектирования решаемых задач и т.д.); предварительный выбор комплекса технических средств; выбор типа операционных систем; выбор способа организации информационной базы (ИБ) (локальные, интегрированные*) и программного средства ведения ИБ (выбираются исходя из класса хранения данных: систем управления файлами, или СУБД); выбор методов и средств проектирования ПО системы, зависящий от выбранной технологии проектирования.
  
  Выполнение всех этих операций завершается составлением ТЭО и формированием ТЗ. Цель ТЭО разработки проекта - оценка параметров: организационных, информационных и экономических. Параметризация позволяет определить требования к системе, оценить существующую ИС, определить пригодность типовых решений в проекте ИС, выбрать проектные решения в соответствии с требованиями к ИС.
  
  На основе ТЭО разрабатываются основные требования к будущему проекту ИС и составляется "Техническое задание" согласно ГОСТ 34.602 - 89 "Техническое задание на создание АС", включающего следующие разделы:
  
  Ј "Общие сведения о проекте" - наименование и код системы, код договора, наименования организации-разработчика и организации-заказчика, перечень документов, являющихся основой для создания системы, сроки начала и окончания разработки ЭИС, источники финансирования, порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей).
  
  Ј "Назначение и цели создания ЭИС".
  
  Ј "Характеристика объекта автоматизации".
  
  Ј "Требования к системе" состоят из следующих подразделов:
  
  o требования к системе в целом - к структуре и функционированию системы; к численности квалифицированных работников; к надежности и безопасности работы системы; эксплуатации, техническому обслуживанию; к сохранности информации при аварийных ситуациях; требования к унификации и стандартизации и т.д.
  
  o требования к функциям (задачам), выполняемым системой - очередность их создания; временной регламент и качество выполнения каждой функции, задачи или комплекса; форма представления выходной информации; достоверность и т.д.
  
  o требования к видам обеспечения - математическому, программному, техническому, информационному и методическому.
  
  
  
  Ј "Состав и содержание работ по созданию системы" - перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601 - 90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания"; сроки выполнения работ; перечень документов по ГОСТ 34.201 - 89 "Виды, комплектность и обозначение документов при создании АС" и т.д.
  
  Ј "Порядок контроля приемки системы" - виды, состав, методы испытания системы и ее частей, общие требования к приемке работ по стадиям, порядок утверждения приемных документов, статус приемочной комиссии.
  
  Ј "Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие" - перечень мероприятий и исполнителей (приведение информации к ввиду пригодному для ввода ее в ЭВМ, создание для функционирования системы подразделений и служб, сроки и порядок комплектования штатов и обучение персонала).
  
  Ј "Требования к документированию" -разработка документов в соответствии с ГОСТ 34.201 - 89 и научно-технической документации отрасли заказчика.
  
  Ј "Источники разработки" - приводятся документы и информационные материалы (ТЭО, отчеты о законченных научно-исслед. разработках, данные на отечественные, зарубежные системы-аналоги и др.).
  
  
  
  Техническое задание включает в себя утвержденные методики, приложения с расчетами экономической эффективности системы, оценку научно-технического уровня системы.
  
  
  
  Вопрос 3. Техно-рабочее проектирование.
  
  
  На основе утвержденного ТЗ начинается стадия "Техно-рабочего проектирования", включающая два этапа работ: техническое и рабочее проектирование.
  
  Техническое проектирование содержит:
  
  Ј разработку общесистемных проектных решений (уточняются цели создания ИС и выполняемые ею функции, устанавливается ее взаимосвязь с другими системами); уточняется и изменяется организационная структура; разрабатывается функциональная архитектура ЭИС;
  
  Ј разработку локальных проектных решений, к числу которых относятся следующие операции:
  
  o разработка "Постановки задачи" (рис. 8), для задач, входящих в состав функциональных подсистем;
  
  o проектирование форм входных и выходных документов, макетов экранных форм документов, классификаторов экономической информации;
  
  o проектирование состава и структур файлов информационной базы;
  
  o проектирование внемашинной и внутримашинной технологии решения каждой задачи;
  
  o уточнение состава технических средств.
  
  
  
  
  
  
  
  Рис. 8. Содержание "Постановки задачи"
  
  
  
  В состав "Характеристика задачи" входят:
  
  Ј описание цели автоматизации решения задачи (получение эк. эффекта в сфере управления процессами системы, снижение стоимостных и трудовых затрат на обработку информации, повышение качества и достоверности получаемой информации, оперативности её обработки и т.д.;
  
  Ј описание экономической сущности решаемой задачи, т.е. состава экономических показателей, рассчитываемых при ее решении, документов, куда заносятся эти показатели;
  
  Ј описание организационной сущности задачи - описание порядка решения задачи, режима решения, состава файлов с постоянной и переменной информацией, способами и формами ввода и вывода результатной информации и т.д.;
  
  Ј описание алгоритма - формализованное описание входных и результатных показателей, перечень формул расчета, описание математической модели, экономико-математических методов и т.д.;
  
  Ј для каждой задачи разрабатываются все компоненты информационного, технического, математического и лингвистического обеспечения, а также компоненты программного обеспечения.
  
  
  
  Наиболее ответственной работой, выполняемой на этапе "Рабочего проектирования" является "Кодирование и составление программной документации", в состав которой входит:
  
  Ј описание программ;
  
  Ј спецификация программ;
  
  Ј тексты программ;
  
  Ј контрольные примеры;
  
  Ј инструкции для программиста, оператора и пользователя.
  
  
  
  В состав "Рабочего проекта" входит технологическая документация, включающая технологические карты разрабатываемые на процессы обработки информации при решении задач, и инструкционные карты, составляемые на каждую технологическую операцию. Технологическая документация разрабатывается в соответствии с ГОСТ 3.11.09 - 82 "Система технологической документации. Термины и определения основных понятий".
  
  
  
  Вопрос 4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта.
  
  
  Внедрение проекта проходит три этапа:
  
  1. Подготовка объекта к внедрению (изменяется организационная структура, набор квалифицированных кадров в области обработки информации и эксплуатации системы и сопровождения проектной документации; приобретение и установка ВТ, орг.техники и т.д.; установка каналов связи, разработка новых документов и классификаторов, создание информационной базы с нормативно-справочной информацией. Результатом является - "Акт готовности объекта к внедрению".
  
  2. Опытное внедрение - подготовка исходных оперативных данных; ввод данных в ЭВМ и реализация поставленных решений; анализ результатных данных на наличие ошибок. При выявлении ошибочных ситуаций, вносятся коррективы в программы, технологию обработки информации, в работу технических средств и т.п. После устранения ошибок составляется "Акт о проведении опытного внедрения".
  
  3. Сдача проекта в промышленную эксплуатацию сопровождается следующей документацией:
  
  Ј договорная документация;
  
  Ј "Приказ на разработку ЭИС";
  
  Ј исправленный "ТРП";
  
  Ј "Приказ о начале промышленного внедрения";
  
  Ј "Программа проведения испытаний";
  
  Ј "Требования к научно-техническому уровню проекта системы".
  
  
  
  В процессе сдачи проекта в промышленную эксплуатацию осуществляются такие работы, как проверка соответствия выполненной работы договорной документации, соответствие проектной документации ГОСТам и ОСТам, проверка качества функционирования информационной базы, оперативности и полноты ответов на запросы и т.д.
  
  Приемная комиссия определяет научно-технический уровень проекта и возможности расширения проектных решений за счет включения новых компонентов. В результате выполнения работ на данном этапе осуществляется доработка "ТРП" за счет выявления системных и локальных ошибок и составляется "Акт сдачи проекта в промышленную эксплуатацию.
  
  На стадии "Эксплуатация и сопровождение проекта" осуществляется устранение сбоев в системе и регистрация их в журналах, отслеживание технико-экономических характеристик системы и накопление статистики о качестве работы всех компонентов системы, определение объемов доработок, сроков и стоимости на выполнение этих работ.
  
  
  
  Вопросы для самопроверки:
  1. Что такое каноническое проектирование и каковы особенности его содержания?
  
  2. Перечислите основные этапы канонического проектирования.
  
  3. Каково назначение этапа "Анализ материалов обследования"?
  
  4. Перечислите основные нормативные документы, регламентирующие состав и содержание "Технического задания".
  
  5. Каково назначение и состав "Технического задания"?
  
  6. Какие работы "Техно-рабочего проектирования" относятся к разработке общесистемных проектных решений и каково их содержание?
  
  7. Что такое "Постановка задачи" и каков состав компонентов этого документа?
  
  8. Каков состав разделов "Технического проекта"?
  
  9. Каковы состав, последовательность выполнения работ на стадии внедрения проекта?
  
  10. Что входит в состав работ по подготовке объекта к внедрению проекта ИС?
  
  
  
  Литература по теме:
  1. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М.: Финансы и Статистика, 2003. - 512 с., Глава 3.
  
  2. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. - М.: Издательский центр "Академия", 2004. - 288 с., Глава 2.
  
  
  
  Тема 5. Проектирование информационного и программного обеспечения
  
  
  Цель темы: освоение разработки программного обеспечения с помощью средств и методов объектно-ориентированного проектирования.
  
  
  
  Задачи темы: изучение методологии проектирования ПО в рамках объектно-ориентированного подхода, формирование навыков использования языка UML и объектно-ориентированных CASE-средств для спецификации предметной области и формирования моделей будущих информационных систем.
  
  
  
  Вопросы темы:
  
  1. Основные принципы построения объектной модели. Основные элементы объектной модели.
  
  2. Унифицированный язык моделирования UML.
  
  3. Методология моделирования Rational Unified Process.
  
  
  
  Вопрос 1. Основные принципы построения объектной модели. Основные элементы объектной модели.
  
  
  При проектировании сложной или достаточно объёмной программной системы её, как правило, делят на части, каждую из которых затем рассматривают и разрабатывают отдельно. При этом используется либо функциональное деление системы, либо объектная декомпозиция.
  
  При функциональном делении программной системы её структура может быть описана блок-схемой, узлы которой обозначают выполняемые функции, а связи указывают последовательность их выполнения. Программные модули, реализующие функции, обычно, используются только в составе данной системы.
  
  При объектной декомпозиции система разбивается на объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями. Сообщения описывают или представляют собой некоторые события. Получение объектом сообщения активизирует его и побуждает выполнять предписанные его программным кодом действия. Как следствие, программная система перестает быть последовательностью определенных на этапе кодирования действий, а становится событийно-управляемой. Инициаторами событий могут быть не только объекты системы, но и её внешнее окружение, например, пользователи.
  
  Объекты имеют свойства и методы.
  
  Свойства объекта - это значения, которые устанавливаются для определения его вида и поведения.
  
  Методы объекта - это программные процедуры, обеспечивающие выполнение им определенных действий.
  
  Совокупность объектов, имеющих общий набор свойств и характеризующихся одинаковым поведением, называется классом. Классы могут строится по иерархическому принципу, когда один класс может быть подклассом другого класса. Из определения класса следует, что каждый объект является экземпляром одного определенного класса.
  
  Важной особенностью объекта является его автономность и возможность использования в качестве библиотечного компонента языка программирования. Таким образом, однажды разработанный и отлаженный программный код может многократно применяться в различных программных модулях. Чтобы побудить объект выполнить необходимые действия достаточно установить его свойства и вызвать соответствующий метод. При наличии для используемого языка программирования развитой библиотеки компонентов разработка программ сводится, в большей своей части, к связыванию имеющихся объектов, что существенно облегчает и ускоряет процесс проектирования. Такая технология разработки программных модулей получила название объектно-ориентированного программирования.
  
  Основными принципами объектно-ориентированного программирования являются наследование, инкапсуляция и полиморфизм.
  
  Принцип, в соответствии с которым знание о более общей категории разрешается применять для более узкой категории, называется наследованием. Наследование тесно связано с иерархией классов. При этом, если некоторый родительский класс обладает фиксированным набором свойств и поведением, то производный от него класс должен содержать этот же набор свойств и обладать таким же поведением, а также дополнительными свойствами и видами поведения, которые будут определять уникальность созданного таким образом класса.
  
  Принцип инкапсуляции характеризует сокрытие деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. То есть, взаимодействующему с классом объекту или пользователю не нужно знать, каким образом реализован тот или иной метод класса, чтобы им воспользоваться.
  
  Полиморфизм в объектно-ориентированном программировании означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов они относятся.
  
  
  
  Вопрос 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) - отображает распределение объектов по узлам вычислительной сети.
  
  
  
  Диаграмма вариантов использования.
  
  Идея описания функциональных требований в виде вариантов использования (use case) была сформулирована в 1986 г. Иваром Якобсоном. Эта идея была признана конструктивной и получила широкое одобрение. Впоследствии наиболее значительный вклад в решение проблемы определения сущности вариантов использования и способов их описания внес Алистер Коберн.
  
  Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении системы с точки зрения пользователя. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой системе.
  
  Действующее лицо (actor) - это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ.
  
  Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы.
  
  Действующие лица делятся на три основных типа - пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.
  
  Для наглядного представления вариантов использования применяются диаграммы вариантов использования. На рис. 9 показан пример такой диаграммы для банковской системы.
  
  
  
  
  
  
  
  Рис. 9. Пример диаграммы вариантов использования
  
  
  
  На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами. Она отражает функциональные требования к системе с точки зрения пользователя. Таким образом, варианты использования - это функции, выполняемые системой, а действующие лица - это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом. В данном случае вариант использования "Сделать платеж" предоставляет Кредитной системе информацию об оплате по кредитной карточке. Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами или сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи.
  
  Цель построения диаграмм вариантов использования - документирование функциональных требований к системе в самом общем виде, поэтому они должны быть предельно простыми.
  
  При построении диаграмм вариантов использования нужно придерживаться следующих правил:
  
  Ј Не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции.
  
  Ј Не соединяйте стрелкой два варианта использования непосредственно. Диаграммы данного типа описывают только сами варианты использования, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельности.
  
  Ј Каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования.
  
  
  
  Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования - это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.
  
  
  
  Диаграммы взаимодействия.
  
  Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов (в рамках варианта использования или некоторой операции класса). Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного потока событий варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
  
  Сообщение (message) - средство, с помощью которого объект-отправитель запрашивает у объекта-получателя выполнение одной из его операций.
  
  Информационное (informative) сообщение - сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.
  
  Сообщение-запрос (interrogative) - сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.
  
  Императивное (imperative) сообщение - сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.
  
  Существуют два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы.
  
  Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования.
  
  Например, вариант использования "Снять деньги со счета" предусматривает несколько возможных потоков событий, таких как снятие денег, попытка снять деньги, не имея их достаточного количества на счете, попытка снять деньги по неправильному PIN-коду и некоторых других. Нормальный сценарий (основной поток событий) снятия некоторой суммы денег со счета показан на рис. 10.
  
  
  
  
  
  
  
  Рис. 10. Диаграмма последовательности
  
  
  
  Все действующие лица показаны в верхней части диаграммы; в приведенном примере изображено действующее лицо Клиент (Customer). Объекты, требуемые системе для выполнения варианта использования "Снять деньги со счета", также представлены в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций.
  
  На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
  
  Вторым видом диаграммы взаимодействия является кооперативная диаграмма (рис. 11).
  
  
  
  
  
  
  
  Рис. 11. Кооперативная диаграмма
  
  
  
  Подобно диаграммам последовательности кооперативные диаграммы отображают поток событий варианта использования. Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы концентрируют внимание на связях между объектами. На рис. 11 приведена кооперативная диаграмма, описывающая, как клиент снимает деньги со счета. На ней представлена та же информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее уяснить последовательность событий. По этой причине часто для какого-либо сценария создают диаграммы обоих типов. Хотя они служат одной и той же цели и содержат одну и ту же информацию, но представляют ее с различных точек зрения.
  
  На кооперативной диаграмме так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность, однако, указывается путем нумерации сообщений.
  
  
  
  Диаграмма классов и диаграмма пакетов.
  
  Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними.
  
  На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Диаграмма классов для варианта использования "Снять деньги со счета" показана на рис. 12.
  
  
  
  
  
  
  
  Рис. 12. Диаграмма классов
  
  
  
  На этой диаграмме присутствуют четыре класса: Card Reader (устройство для чтения карточек). Account (счет), ATM Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом ATM Screen, потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Card Reader не связан с классом Cash Dispenser, поскольку они не сообщаются друг с другом непосредственно.
  
  На диаграмме классов в прямоугольниках в верхней части даны имена классов, в средней части - имена атрибутов, в нижней части - имена методов.
  
  Для группировки классов, обладающих некоторой общностью, применяются пакеты. Пакет - общий механизм для организации элементов модели в группы. Пакет может включать другие элементы. Каждый элемент модели может входить только в один пакет. Пакет является средством организации модели в процессе разработки, повышения ее управляемости и читаемости, а также единицей управления конфигурацией.
  
  Существуют несколько подходов к группировке классов. Во-первых, можно сгруппировать их по стереотипу (типу класса). Например, один пакет содержит классы-сущности предметной области (Entities), другой - классы пользовательского интерфейса (Boundaries), а третий - управляющие классы (Control). Этот подход может быть полезен с точки зрения размещения системы в среде реализации.
  
  Если между любыми двумя классами, находящимися в разных пакетах, существует некоторая зависимость, то имеет место зависимость и между этими двумя пакетами. Таким образом, диаграмма пакетов (рис. 13) представляет собой диаграмму, содержащую пакеты классов и зависимости между ними.
  
  
  
  
  
  
  
  Рис. 13. Диаграмма пакетов
  
  
  
  Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т.е. диаграмма пакетов - это форма диаграммы классов. Диаграммы пакетов можно считать основным средством управления общей структурой системы.
  
  
  
  Диаграммы состояний.
  
  Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.
  
  На рис. 14 приведен пример диаграммы состояний для банковского счета. Из данной диаграммы видно, в каких состояниях может существовать счет. Можно также видеть процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, он переходит в состояние "закрыт". Требование клиента называется событием (event), именно такие события и вызывают переход из одного состояния в другое.
  
  
  
  
  
  
  
  Рис. 14. Диаграмма состояний для класса Account
  
  
  
  На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). На диаграмме состояний может быть только одно начальное состояние, а конечных состояний может быть столько, сколько нужно, или их может не быть вообще.
  
  С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния. Рассмотрим каждый из них в контексте диаграммы состояний для класса Account банковской системы.
  
  Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Например, когда счет находится в состоянии "Закрыт", происходит возврат кредитной карточки пользователю. Деятельность - это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность изображают внутри самого состояния, ей должно предшествовать слово do (выполнять) и двоеточие.
  
  Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Когда счет в банке переходит в состояние "Превышение кредита", выполняется действие "Временно заморозить счет" независимо оттого, откуда объект перешел в это состояние. В отличие от деятельности, входное действие рассматривается как непрерываемое. Входное действие также показывают внутри состояния, ему предшествует слово entry (вход) и двоеточие.
  
  Выходное действие (exit action) подобно входному, однако оно осуществляется как составная часть процесса выхода из данного состояния. Так, при выходе объекта Account из состояния "Превышение кредита" независимо оттого, куда он переходит, выполняется действие "Разморозить счет". Оно является частью процесса такого перехода. Как и входное, выходное действие является непрерываемым. Выходное действие изображают внутри состояния, ему предшествует слово exit (выход) и двоеточие.
  
  Переходом (transition) называется перемещение объекта из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся на последующем. Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии. У перехода существует несколько спецификаций, основными из которых являются события, ограждающие условия и действия.
  
  Событие (event) вызывает переход из одного состояния в другое. Событие "Клиент требует закрыть" вызывает переход счета из открытого в закрытое состояние. Событие размещают на диаграмме вдоль линии перехода. Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться.
  
  Тем не менее, бывают и автоматические переходы, не имеющие событий. При этом объект сам перемещается из одного состояния в другое со скоростью, позволяющей осуществиться входным действиям, деятельности и выходным действиям.
  
  Ограничивающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться. В примере событие "Вклад денег" переведет счет из состояния "Превышение кредита" в состояние "Открыт", но только если баланс будет больше нуля. В противном случае переход не осуществится. Ограничивающие условия изображают на диаграмме вдоль линии перехода после имени события, заключая их в квадратные скобки. Ограничивающие условия задавать необязательно. Однако, если существует несколько автоматических переходов из состояния, необходимо определить для них взаимно исключающие ограждающие условия, чтобы понять, какой путь перехода будет автоматически выбран. Действие изображают вдоль линии перехода после имени события, ему предшествует косая черта.
  
  Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него может потребоваться такая диаграмма.
  
  
  
  Диаграммы деятельности.
  
  Диаграммы деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме.
  
  На рис. 15 приведена диаграмма деятельности для потока событий, связанного с системой бронирования авиабилетов. Рассмотрим ее нотацию.
  
  
  
  
  
  
  
  Рис. 15. Диаграмма деятельности
  
  
  
  Основным элементом диаграммы является деятельность (activity). Интерпретация этого термина зависит от той точки зрения, с которой строится диаграмма (это может быть некоторая задача, которую необходимо выполнить вручную или автоматизированным способом, или операция класса). Деятельность изображается в виде закругленного прямоугольника с текстовым описанием.
  
  Любая диаграмма деятельности должна иметь начальную точку, определяющую начало потока событий. Конечная точка необязательна. На диаграмме может быть несколько конечных точек, но только одна начальная.
  
  На диаграмме могут присутствовать объекты и потоки объектов (objectflow). Объект может использоваться или изменяться в одной из деятельностей. Показ объектов и их состояний (в дополнение к диаграммам состояний) помогает понять, когда и как происходит смена состояний объекта.
  
  Объекты связаны с деятельностями через потоки объектов. Поток объектов отмечается пунктирной стрелкой от деятельности к изменяемому объекту или от объекта к деятельности, использующей объект.
  
  Переход (стрелка) показывает, как поток управления переходит от одной деятельности к другой. Если для перехода определено событие, то переход выполняется только после наступления такого события. Ограничивающие условия определяют, когда переход может, а когда не может осуществиться. Если необходимо показать, что две или более ветвей потока выполняются параллельно, используются линейки синхронизации. В данном примере параллельно выполняются резервирование места, формирование номера подтверждения и отправка почтового сообщения, а после завершения всех трех процессов пользователю выводится номер подтверждения.
  
  Любая деятельность может быть подвергнута дальнейшей декомпозиции. Описание декомпозированной деятельности может быть представлено в виде другой диаграммы деятельности.
  
  Диаграммы деятельности предпочтительнее использовать в следующих ситуациях:
  
  Ј анализ потоков событий в конкретном варианте использования. Здесь нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание действий и объектов выполняется позднее с помощью диаграмм взаимодействия;
  
  Ј анализ потоков событий в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, на диаграмме деятельности удобно представить и проанализировать все их потоки событий (в этом случае диаграмма с помощью вертикальных пунктирных линий разделяется на зоны - так называемые "плавательные дорожки" (swimlanes). В каждой зоне изображаются потоки событий одного из вариантов использования, а связи между разными потоками - в виде переходов или потоков объектов).
  
  
  
  Диаграммы компонентов.
  
  Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
  
  Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы.
  
  На рис. 16. изображена одна из диаграмм компонентов для банковской системы.
  
  
  
  
  
  
  
  Рис. 16. Диаграмма компонентов для клиентской части
  
  
  
  Компоненты соединены зависимостями. Например, класс Card Reader зависит от класса ATM Screen. Это означает, что, для того чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe.
  
  Банковская система содержит два потока управления и, таким образом, получаются два исполняемых файла. Один из них - это клиентская часть системы, она содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл - это сервер, включающий в себя компонент Account. Диаграмма компонентов для сервера показана на рис. 17.
  
  
  
  
  
  
  
  Рис. 17. Диаграмма компонент для серверной части
  
  
  
  Как видно из примера, в модели системы может быть несколько диаграмм компонентов, в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов.
  
  Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы. Они нужны там, где начинается генерация кода.
  
  
  
  Диаграмма размещения.
  
  Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать размещение объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом.
  
  
  
  
  
  
  
  Рис. 18. Диаграмма размещения для банковской системы
  
  
  
  Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основные элементы:
  
  Ј узел (node) - вычислительный ресурс - процессор или другое устройство (дисковая память, контроллеры различных устройств и тд.). Для узла можно задать выполняющиеся на нем процессы;
  
  Ј соединение (connection) - канал взаимодействия узлов (сеть).
  
  
  
  Например, банковская система состоит из большого количества подсистем, выполняемых на отдельных физических устройствах, или узлах. Диаграмма размещения для такой системы показана на рис. 18.
  
  Из данной диаграммы можно узнать о физическом размещении системы. Клиентские программы будут работать в нескольких местах на различных сайтах. Через закрытые сети будет осуществляться их сообщение с региональным сервером системы. На нем будет работать ПО сервера. В свою очередь, посредством локальной сети региональный сервер будет сообщаться с сервером банковской базы данных, работающим под управлением Oracle. Наконец, с региональным сервером соединен принтер.
  
  Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных подсистем.
  
  
  
  Вопрос 3. Методология моделирования Rational Unified Process.
  
  
  Rational Unified Process (RUP) - методология разработки программного обеспечения, созданная компанией Rational Software.
  
  В основе RUP лежат следующие основные принципы:
  
  Ј Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
  
  Ј Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).
  
  Ј Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
  
  Ј Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
  
  Ј Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
  
  Ј Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
  
  
  
  RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта. Полный жизненный цикл разработки продукта, представленный на рис. 19, состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций.
  
  
  
  Процесс разработки по RUP
  
  
  
  Рис. 19. Графическое представление процесса разработки по RUP
  
  
  
  1. Начало (Inception).
  
  На этом этапе:
  
  Ј Формируются видение и границы проекта.
  
  Ј Создается экономическое обоснование (business case).
  
  Ј Определяются основные требования, ограничения и ключевая функциональность продукта.
  
  Ј Создается базовая версия модели прецедентов.
  
  Ј Оцениваются риски.
  
  
  
  При завершении начальной стадии оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.
  
  
  
  2. Проектирование (Elaboration).
  
  На этапе проектирования производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
  
  Ј Документирование требований (включая детальное описание для большинства прецедентов).
  
  Ј Спроектированную, реализованную и оттестированную исполняемую архитектуру.
  
  Ј Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
  
  Ј Сниженные основные риски.
  
  
  
  Успешное выполнение фазы проектирования означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).
  
  
  
  3. Построение (Construction).
  
  Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
  
  
  
  4. Внедрение (Transition).
  
  Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
  
  
  
  Вопросы для самопроверки:
  1. Что такое свойства и методы объекта?
  
  2. По какому принципу объекты группируются в классы?
  
  3. Какой язык используется для объектно-ориентированного моделирования?
  
  4. Каково основное предназначение диаграмм вариантов использования?
  
  5. Дайте характеристику двум видам диаграмм взаимодействия.
  
  6. Опишите основные элементы диаграммы классов.
  
  7. Что такое пакет?
  
  8. Опишите основные элементы диаграммы деятельности.
  
  9. Опишите основные элементы диаграммы состояний.
  
  10. Какие диаграммы моделируют физический уровень подсистемы? Перечислите их основные элементы.
  
  11. Перечислите основные принципы и фазы методики RUP.
  
  
  
  Литература по теме:
  1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. - М.: Финансы и Статистика, 2006 - 544 с., с.162-209.
  
  2. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М.: Финансы и Статистика, 2003. - 512 с., с.351-373.
  
  
  
  Тема 6. Структурные методы анализа и проектирования ПО
  
  
  Цель темы: освоение разработки программного обеспечения с помощью средств и методов структурного проектирования.
  
  
  
  Задачи темы: изучение различных методологий проектирования ПО в рамках структурного подхода (IDEF0, IDEF1X, IDEF3), формирование навыков использования функционально-ориентированных CASE-средств для спецификации предметной области и формирования моделей будущих информационных систем, ознакомление с принципами реинжиниринга бизнес-процессов.
  
  
  
  Вопросы для самопроверик:
  
  1. Метод функционального проектирования SADT.
  
  2. Методология формализации и описания бизнес-процессов IDEF0 (общие сведения, состав функциональной модели, функциональная декомпозиция).
  
  3. Функциональное проектирование в среде AllFusion Process Modeler (модели AS-IS и TO-BE).
  
  4. Pеинжиниринг бизнес-процессов.
  
  5. Моделирование процессов в нотации IDEF3.
  
  6. Моделирование потоков данных, диаграммы потоков данных (DFD).
  
  7. Моделирование данных, методология проектирования реляционных баз данных IDEF1X, моделирование данных в среде AllFusion ERwin Data Modeler.
  
  
  
  Вопрос 1. Метод функционального проектирования SADT.
  
  
  Сущность структурного подхода к разработке ИС заключается в её декомпозиции (разбиении) на автоматизируемые функции. Система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
  
  Структурное (функциональное) проектирование - это метод определения подсистем, компонентов и способов их соединения, задающий ограничения, при которых система должна функционировать, выбирающий наиболее эффективное сочетание людей, машин и программного обеспечения для реализации системы.
  
  В качестве примера рассмотрим одну из широко используемых систем такого проектирования - 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.
  
  В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
  
  Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
  
  Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозриельно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
  
  Графическая реализация методологии IDEF0 будет рассмотрена в следующем параграфе.
  
  
  
  Вопрос 3. Функциональное проектирование в среде AllFusion Process Modeler (модели AS-IS и TO-BE).
  
  
  Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
  
  Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие.
  
  IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 20). Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition -определение модели и описание области.
  
  
  
  Диалог задания свойств модели
  
  
  
  Рис. 20. Диалог задания свойств модели
  
  
  
  Во вкладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). Во вкладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Вкладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и TO-BE.
  
  Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
  
  Модель может содержать четыре типа диаграмм:
  
  Ј контекстную (в каждой модели может быть только одна контекстная диаграмма);
  
  Ј декомпозиции;
  
  Ј дерева узлов;
  
  Ј только для экспозиции (FEO).
  
  
  
  Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (рис. 21). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции (рис. 22). После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т. д., до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы-эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
  
  
  
  
  
  
  
  Рис. 21. Контекстная диаграмма IDEF0
  
  
  
  
  
  
  
  Рис. 22. Диаграмма декомпозиции IDEF0
  
  
  
  Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
  
  Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения либо для специальных целей.
  
  Основные элементы диаграмм: работы и стрелки.
  
  Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено сочетанием отглагольного существительного, обозначающего процесс, например: "Изготовление детали", "Прием заказа" и т. д. Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 21).
  
  Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и обозначаются существительными (например, "Заготовка", Изделие", "Заказ") или именными сочетаниями (например, "Готовое изделие").
  
  В IDEF0 различают пять типов стрелок.
  
  Вход (Input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 21-это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.
  
  Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 21 стрелки "Задание" и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.
  
  Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 21 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".
  
  Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 21 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.
  
  Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. На рис. 21 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
  
  Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы и наоборот. Такие стрелки называются граничными.
  
  Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изменения существующей структуры организации бизнеса. Анализ недостатков и "узких мест" начинают с построения модели AS-IS (Как есть), т. е. модели существующей организации работы. Модель AS-lS может строиться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов и т. п.), анкетирования и опроса служащих предприятия, создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели TO-BE (Как будет) - модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей TO-BE, среди которых определяют наилучший вариант. Выбор оптимальной модели может осуществляться, например, с помощью метрик BPwin. Следует указать на распространенную ошибку при создании модели AS-IS - это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям, и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD BE (Как должно бы быть).
  
  Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели TO-BE, и только на основе модели TO-BE строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.
  
  Иногда текущая модель AS-lS и будущая TO-BE различаются очень сильно, так что переход от начального состояния к конечному становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход - это тоже бизнес-процесс.
  
  Переход от модели AS-IS к модели TO-BE является реинжинирингом бизнес-процессов.
  
  
  
  Вопрос 4. Pеинжиниринг бизнес-процессов.
  
  
  Современные предприятия (корпорации) имеют сложную структуру, обусловленную многофункциональностью деятельности, территориальной распределенностью подразделений, большим числом корпоративных связей с партнерами. Рост динамичности деловых процессов (БП), связанной с постоянно изменяющимися потребностями рынка, ориентацией производства товаров и услуг на потребности заказчиков и клиентов, непрерывном совершенствованием технических возможностей и сильной конкуренцией требует смещения акцентов с управления отдельными ресурсами и соответственно функциональными подразделениями на управление сквозными бизнес-процессами, объединяющих деятельность подразделений предприятия.
  
  Бизнес-процесс (БП) - совокупность взаимосвязанных работ по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов. В управлении бизнес-процессами все материальные, финансовые и информационные потоки рассматриваются во взаимодействии.
  
  Управление БП на уровне взаимодействия различных предприятий требует координации деятельности предприятий-партнеров в потоках товародвижения или в логических процессах по принципу "точно в срок".
  
  Современные информационные технологии дают возможность проведения инжиниринга и реинжиниринга бизнес-процессов.
  
  Цель реинжиниринга БП - системная реорганизация материальных, финансовых и информационных потоков, направленных на упрощение организационной структуры, перераспределение и минимизацию использования различных ресурсов, сокращение сроков реализации потребностей клиентов, повышение качества их обслуживания.
  
  Реинжиниринг БП обеспечивает решение следующих задач:
  
  Ј Определение оптимальной последовательности выполняемых функций, способствующих сокращению длительности цикла изготовления и продажи товаров и услуг, обслуживания клиентов, следствием чего служат повышение оборачиваемости капитала и рост всех экономических показателей фирмы;
  
  Ј Оптимизация использования ресурсов, приводящих к минимизации издержек;
  
  Ј Построение адаптивных БП, нацеленных на быструю адаптацию к изменениям потребностей конечных потребителей продукции, производственных технологий, повышение качества обслуживания клиентов в условиях динамичности внешней среды;
  
  Ј Определение рациональных схем взаимодействия с партнерами и клиентами и, как следствие, рост прибыли, оптимизация финансовых потоков.
  
  
  
  Вопрос 5. Моделирование процессов в нотации IDEF3.
  
  
  Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
  
  IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
  
  Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
  
  IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
  
  Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
  
  Точка зрения на модель должна быть документирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо документировать цель модели - те вопросы, на которые призвана ответить модель.
  
  Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
  
  Единицы работы - Unit of Work (UOW) - также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.
  
  Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style:
  
  Старшая (Precedence) сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
  
  Отношения (Relational Link) пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
  
  Потоки объектов (Object Flow) стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
  
  Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка.
  
  Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.
  
  Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка - (добавить в диаграмму перекресток - Junction) в палитре инструментов. В диалоге 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 контекстного меню), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями.
  
  
  
  
  
  
  
  Рис. 23. Пример диаграммы IDEF3
  
  
  
  В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.
  
  
  
  Вопрос 6. Моделирование потоков данных, диаграммы потоков данных (DFD).
  
  
  Диаграммы потоков данных (Data Flow Diagramming, DFD) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD (как было сказано выше) - процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).
  
  В AllFusion Process Modeler для построения диаграмм потоков данных используется нотация Гейна-Сарсона. Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count "кликнуть" по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
  
  Ј - добавить в диаграмму внешнюю ссылку;
  
  Ј - добавить в диаграмму хранилище данных;
  
  Ј - ссылка на другую страницу. В отличие от IDEF0 этот инструмент позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).
  
  
  
  В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов, хранение объектов, поставка и распространение объектов. Пример диаграммы потоков данных представлен на рис. 24.
  
  
  
  
  
  
  
  Рис. 24. Пример диаграммы DFD
  
  
  
  В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0 (блоки "Проверка и внесение клиентов", "Внесение заказов" на рис. 24).
  
  Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы (рис. 24, блок "Звонки клиентов). Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок.
  
  Потоки работ изображаются стрелками и описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (см. рис. 24).
  
  В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое ("Список клиентов", "Список продуктов", "Список заказов" на рис. 24).
  
  В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
  
  В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. В DFD номер каждой работы может включать префикс (A), номер родительской работы и номер объекта. Номер объекта - это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.
  
  
  
  Вопрос 7. Моделирование данных, методология проектирования реляционных баз данных IDEF1X, моделирование данных в среде AllFusion ERwin Data Modeler.
  
  
  Одной из основных частей информационного обеспечения является информационная база. Разработка базы данных выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD - диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).
  
  Сущность (Entity) - множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
  
  Ј иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
  
  Ј иметь один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь;
  
  Ј иметь один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности.
  
  
  
  Каждая сущность может обладать любым количеством связей с другими сущностями модели.
  
  Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.
  
  Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Экземпляр атрибута - это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
  
  Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEF1. Метод IDEF1 основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEF1 создана его новая версия - метод IDEF1X, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEF1X-диаграммы используются в ряде распространенных CASE-средств (в частности AllFusion Data Modeler).
  
  AllFusion Data Modeler имеет два уровня представления модели - логический и физический.
  
  Логический уровень - это абстрактный взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
  
  Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д.
  
  Для переключения между логической и физической моделью данных служит список выбора в центральной части панели инструментов. Фрагмент панели инструментов представлен на рис. 25.
  
  
  
  Переключение между логической и физической моделью
  
  
  
  Рис. 25. Переключение между логической и физической моделью
  
  
  
  Основные компоненты диаграммы ERwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.
  
  Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. Для внесения дополнительных комментариев и определений к сущности служат свойства, определенные пользователем (UDP). Использование (UDP) аналогично их использованию в Process Modeler.
  
  Как было указано выше, каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом.
  
  Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии.
  
  Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (см. рис. 26).
  
  Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
  
  Связь является логическим соотношением между сущностями.
  
  Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя).
  
  На логическом уровне можно установить идентифицирующую связь "один-ко-многим", связь "многие-ко-многим" и неидентифицирующую связь "один-ко-многим".
  
  Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей. Пример неидентифицирующей связи приведен на рис. 26. Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - FK.
  
  Пунктирная линия изображает неидентифицирующую связь (см. рис. 26). При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей.
  
  Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (см. рис. 26).
  
  
  
  Неидентифицирующая связь
  
  
  
  Рис. 26. Пример ERD-модели с неидентифицирующей связью
  
  
  
  Физическая модель содержит всю информацию, необходимую для реализации конкретной БД, при этом необходимо учитывать, что физическая модель не поддерживает связь "многие-ко-многим". Различают два уровня физической модели: трансформационную модель и модель СУБД.
  
  Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. Данная модель позволяет проектировщикам и администраторам БД лучше представить, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель удовлетворяет требованиям к ИС.
  
  Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД.
  
  Физический уровень представления модели зависит от выбранного сервера. AllFusion Data Modeler поддерживает более 20 реляционных и нереляционных БД.
  
  По умолчанию AllFusion Data Modeler генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели, которые в дальнейшем могут быть откорректированы вручную. Имена таблиц и колонок будут сгенерированы по умолчанию на основе имен сущностей и атрибутов логической модели.
  
  
  
  Вопросы для самопроверки:
  1. В чем состоит сущность структурного подхода к проектированию ИС?
  
  2. Что представляет из себя модель в нотации IDEF0?
  
  3. В чем суть декомпозиции работ?
  
  4. Назовите основные виды стрелок на диаграмме IDEF0.
  
  5. Для чего служит диаграмма FEO?
  
  6. Какая основная цель реинжиниринга бизнес-процессов?
  
  7. В чем отличие модели AS-IS от модели TO-BE?
  
  8. Каковы основные элементы диаграмм IDEF3?
  
  9. В чем состоит суть перекрестков на диаграммах IDEF3?
  
  10. Зачем создаются диаграммы потоков данных и каковы их основные элементы?
  
  11. Каковы основные элементы диаграммы IDEF1X?
  
  12. Что такое логическая модель данных?
  
  13. Что такое физическая модель данных?
  
  14. Какой тип связи между сущностями не поддерживается на физическом уровне?
  
  15. Что такое внешний ключ?
  
  16. Что такое идентифицирующая связь "один-ко-многим"? Какие сущности она связывает?
  
  17. Для чего нужна трансформационная модель?
  
  
  
  Литература по теме:
  1. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. - 2-е изд., доп. - М.: Издательство Диалог-МИФИ, 2007 - 400 с.
  
  2. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М.: Финансы и Статистика, 2003. - 512 с., Глава 11, с. 330-351.
  
  3. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. - 5-е изд., доп. - М.: Бином-Пресс; СПб.: КОРОНА принт, 2006 - 736 с.
  
  
  
  Литература
  
  
  Основная литература:
  1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем - М.: ИУИТ, 2012 - 300 с.
  
  2. Коваленко В.В. Проектирование информационных систем, учебник - М.: Форум - 2012, 320 с.
  
  
  
  Дополнительная литература:
  1. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. - 2-е изд., испр. и. дополн. - М.: Издательство Диалог-МИФИ, 2007 - 400 с.
  
  2. Проектирование экономических информационных систем: Учебник/Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под. ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2003. - 512 с.
  
  3. Вендеров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. - М.: Финансы и Статистика, 2006. - 544 с.
  
  4. Г. Буч, А. Якобсон, Дж. Рамбо UML [пер. с англ. А. Вахитов, Д. Солнышков]. - 2-е изд. - М.: Питер, 2006 - 735 с.
  
  5. Дубейковкий В.И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM - М.: ДИАЛОГ-МИФИ, 2007 - 384 с.
  
  6. Дубейковкий В.И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? - М.: ДИАЛОГ-МИФИ, 2007 - 464 с.
  
  7. Маклаков С.В. Моделирование бизнес-процессов с AllFusion PM. - 2-е изд., испр. и. дополн. - М.: Издательство Диалог-МИФИ, 2007 - 224 с.
  
  8. У. Боггс, М. Боггс UML и Rational Rose секреты эффективного проектирования объектно-ориентированных приложений - М.: ЛОРИ, 2004 - 509 с.
  
  9. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. - М.: Издательский центр "Академия", 2004. - 288 с.
  
  10. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. - 5-е изд., доп. - М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. - 736 с.
  
  11. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум. - М.: Горячая линия - Телеком, 2005 - 160 с.
  
  
  
   * Интегрированная БД - совокупность взаимосвязанных, хранящихся вместе данных, используемых для одного или нескольких приложений.
 Ваша оценка:
Связаться с программистом сайта.

Новые книги авторов СИ, вышедшие из печати:
О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

Как попасть в этoт список
Сайт - "Художники" .. || .. Доска об'явлений "Книги"