Информационные процессы и системы. Лекция № 3

1.

Проектирование и дизайн
информационных систем
Лекция № 3 (23.03.2024 г.)
ИНФОРМАЦИОННЫЕ
ПРОЦЕССЫ И СИСТЕМЫ

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

Информационные процессы – процессы,
связанные с поиском, хранением, передачей,
обработкой и использованием информации.
2

3. Виды информационных процессов

Поиск информации – процесс извлечение хранимой
информации.
Методы поиска: наблюдение, общение со специалистами,
чтение литературы, просмотр видео, прослушивание
передач и аудиозаписей, работа в библиотеках и архивах,
запросы к информационным системам, поиск в
Интернет.
Сбор информации – деятельность субъекта, в результате
которой он получает информацию об интересующем его
объекте.
Хранение информации – процесс поддержания исходной
информации в виде, обеспечивающем выдачу данных по
запросам пользователей в установленные сроки.
3

4. Виды информационных процессов

Передача информации – процесс, в ходе которой передатчик
(источник) передает, а приемник (потребитель) получает
информацию.
Виды каналов связи:
симплексный (телевидение);
полудуплексный (рация, обмен сообщениями);
дуплексный (телефон).
4

5. Виды информационных процессов

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

6. Уровни информационных процессов

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

7. Процессы в ИС

7

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

Информационная
деятельность
Поиск информации
Интерпретация
информации
Основная
деятельность
Решение задачи
Создание сообщений
Информационная
деятельность
8
Распространение
информации
Информационные
системы

9. Автоматизированные информационные системы

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

10. Основные технологические процессы АИС

Другие ИС, АИС, внешние БД
Сбор данных
Обработка ручная
Оператор
Ввод данных
Обработка машинная
База
данных
Администратор
Хранение, обновление,
поддержка
Поиск информации
Модель
объекта
Формирование
выходных
документов
Анализ данных
Принятие решений
10
Пользователь

11. Структура ИС

11

12. Информационное обеспечение

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

13. Техническое обеспечение

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

14. Математическое и программное обеспечение

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

15. Организационное и правовое обеспечение

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

16.  ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ

ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ
Жизненный цикл программного
обеспечения информационных систем

17. Жизненный цикл программного обеспечения ИС

ЖЦ ПО - это непрерывный процесс, который начинается с момента
принятия решения о необходимости создания ПО и заканчивается в
момент его полного изъятия из эксплуатации.
Нормативный документ ЖЦ ПО - международный стандарт ISO/IEC 12207 (ISO - International
Organization of Standardization - Международная организация по стандартизации, IEC International Electrotechnical Commission - Международная комиссия по электротехнике). Он
определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть
выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах
процессов:
основных
процессах
(приобретение,
эксплуатация, сопровождение);
поставка,
разработка,
вспомогательных процессах, обеспечивающих выполнение основных
процессов
(документирование,
управление
обеспечение качества, верификация, аттестация,
решение проблем);
организационных
конфигурацией,
оценка, аудит,
процессах (управление проектами, создание
инфраструктуры проекта, определение, оценка и улучшение самого
ЖЦ, обучение).

18. Жизненный цикл программного обеспечения ИС

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

19. Жизненный цикл программного обеспечения ИС

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

20. Модели жизненного цикла ПО

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

21. Модели жизненного цикла ПО

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

22. Модели жизненного цикла ПО

Каскадная схема разработки ПО

23. Модели жизненного цикла ПО

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

24. Модели жизненного цикла ПО

Реальный процесс разработки ПО по каскадной схеме

25. Модели жизненного цикла ПО

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

26. Модели жизненного цикла ПО

Спиральная модель ЖЦ

27. Модели жизненного цикла ПО

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

28. Модели жизненного цикла ПО

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

29. Модели жизненного цикла ПО

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

30.  ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ

ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ
Понятие технологии
проектирования

31. Понятие технологии проектирования

Технология
(греч.) – искусство, мастерство,
умение, совокупность методов изготовления
продукции.
Технология проектирования определяется как
совокупность трех составляющих:
пошаговой
процедуры,
определяющей
последовательность
технологических
операций
проектирования;
критериев и правил, используемых для оценки
результатов выполнения технологических операций
(соответствие стандартам);
нотаций
(графических
и
текстовых
средств),
используемых для описания проектируемой системы.
31

32.

Технологическая операция проектирования – это
относительно
самостоятельный
фрагмент
технологического процесса проектирования, в котором
определены: вход; выход; преобразователь; ресурсы;
средства.
32

33. Понятие технологии проектирования

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

34. ПОНЯТИЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

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

35. Требования, предъявляемые к технологии проектирования ИС

Технология
должна поддерживать полный
жизненный цикл системы;
технология
должна
обеспечивать
гарантированное достижение целей разработки
ИС с заданным качеством и в установленное
время;
технология должна обеспечивать возможность
выполнения крупных проектов в виде подсистем;
технология должна обеспечивать возможность
ведения работ по проектированию отдельных
подсистем небольшими группами;
35

36. Требования, предъявляемые к технологии проектирования ИС

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

37.

Методы
проектирования
По степени
автоматизации
проектных работ
Методы
проектирования
По степени
использования
типовых проектов
ТПР
По степени
адаптивности
проектных решений
Ручное
проектирование
Оригинальное
проектирование
Методы
реконструкции
Автоматизированное
проектирование
Типовое
проектирование
Методы
параметризации
37
Методы
реструктуризации
модели

38.

Технологии
проектирования
Каноническое
проектирование
Индустриальное
проектирование
Автоматизированное
проектирование
Прототипное
проектирование
38
Классы технологий
проектирования ИС
Процессноориентированное
проектирование
Типовое
проектирование
Параметрическиориентированное
Модельноориентированное

39. Каноническое проектирование

Каноническое
проектирование ИС отражает
особенности
ручной
технологии
индивидуального
(оригинального)
проектирования, осуществляемого на уровне
исполнителей без использования каких-либо
инструментальных средств, позволяющих
интегрировать
выполнение
элементарных
операций.
Модель жизненного цикла ИС: каскадная.
39

40. Технологическая сеть канонического проектирования

П1
Д1.1
Предпроектная
стадия
Д1.2
Д1.3
П2
Стадия
проектирования
Д2.1
Д1.4
П3
Стадия
внедрения
Д3.1
Д3.2
П4
Стадия
эксплуатации и
сопровождения
Д4.1
Д 1.1. ─ предметная область; Д 1.2. ─ материалы обследования; Д 1.3. ─ ТЭО;
Д 1.4. ─ техническое задание (ТЗ) на проектирование;
Д 2.1. ─ техно-рабочий проект (ТРП);
Д 3.1. ─ исправленный ТРП, переданный в эксплуатацию; Д 3.2. ─ акт о
приемке проекта в промышленную эксплуатацию;
40 Д 4.1. ─ модернизированный ТРП.

41. ТИПОВОЕ ПРОЕКТИРОВАНИЕ

Необходимость типизации проектных решений
связана с:
сложностью обеспечения высокого научно-
технического уровня разработки при индивидуальном
проектировании;
существенным снижением затрат на проектирование
при внедрении типовой системы.
Требования к экономическому объекту :
управление предприятием осуществляется на основе
41
единых положений;
структура системы управления во всех подразделениях
предприятия одинакова и зависит только от размера
предприятия;
технические средства ИС стандартизированы;
возможность декомпозиции проектируемой ИС на
множество составляющих компонентов.

42. Классификация типовых решений по уровню декомпозиции

ТИПОВОЕ ПРОЕКТИРОВАНИЕ
Классификация типовых решений по уровню
декомпозиции
Элементные ТПР - типовые решения по задаче
или по отдельному виду обеспечения задачи
(информационному, программному, техническому,
математическому, организационному)
Подсистемные ТПР - в качестве элементов
типизации выступают отдельные подсистемы,
разработанные
с
учетом
функциональной
полноты
и
минимизации
внешних
информационных связей;
Модельные
(объектные) ТПР - типовые
отраслевые проекты, которые включают полный
набор функциональных и обеспечивающих
подсистем ИС.
42

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

ТИПОВОЕ ПРОЕКТИРОВАНИЕ
Элементный метод типового проектирования
Достоинство
применение модульного подхода к проектированию и
документированию ИС.
Недостатки:
необходимость разработки недостающих компонентов
ИС вручную;
большие затраты времени на доработку и сопряжение
разнородных элементов вследствие информационной,
программной и технической несовместимости ТПР;
плохая адаптивность элементов к особенностям
предприятия.
43

44. Подсистемный метод типового проектирования

ТИПОВОЕ ПРОЕКТИРОВАНИЕ
Подсистемный метод типового проектирования
Достоинства:
модульное проектирование;
параметрическая настройку программных компонентов
на различные объекты управления;
сокращение затрат на проектирование и
программирование взаимосвязанных компонентов;
хорошее документирование отображаемых процессов
обработки информации.
Недостатки:
адаптивность ТПР недостаточна с позиции
непрерывного инжиниринга бизнес-процессов;
проблемы в обеспечении комплексного использования
разных функциональных подсистем от нескольких
производителей программного обеспечения
44

45. Объектный (модельный) метод типового проектирования

ТИПОВОЕ ПРОЕКТИРОВАНИЕ
Объектный (модельный) метод типового
проектирования
Достоинства:
возможность комплексного использования всех
компонентов ИС за счет методологического единства и
информационной, программной и технической
совместимости;
открытость архитектуры;
масштабируемость;
конфигурируемость.
Недостатки:
проблемы привязки типового проекта к конкретному
45
объекту управления, связанные с изменением
организационно-экономической структуры объекта
автоматизации

46. ПАРАМЕТРИЧЕСКИ-ОРИЕНТИРОВАННОЕ ТИПОВОЕ ПРОЕКТИРОВАНИЕ

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

47. МОДЕЛЬНО-ОРИЕНТИРОВАННОЕ ТИПОВОЕ ПРОЕКТИРОВАНИЕ

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

48. Структура типового модельно-ориентированного проектного решения

МОДЕЛЬНО-ОРИЕНТИРОВАННОЕ ТИПОВОЕ ПРОЕКТИРОВАНИЕ
Структура типового модельно-ориентированного
проектного решения
48

49.

МОДЕЛЬНО-ОРИЕНТИРОВАННОЕ ТИПОВОЕ ПРОЕКТИРОВАНИЕ
Репозиторий
Базовая модель ИС
Типовые модели
определенных
классов ИС
Описание объектов, функций,
бизнес-правил, орг. структуры,
которые поддерживаются
программными модулями
типовой ИС
Модели ИС
конкретных
предприятий
Описание конфигурации
ИС для определенных
отраслей или типов
производства.
Модель ИС конкретного предприятия строится:
путем выбора фрагментов типовой модели в соответствии со
специфическими особенностями предприятия (BAAN Enterprise
Modeler);
путем автоматизированной адаптации этих моделей в результате
49 экспертного опроса (SAP Business Engineering Workbench).

50. АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ

CASE-технология – совокупность методов анализа,
проектирования, разработки и сопровождения ИС,
поддержанных комплексом взаимосвязанных средств
автоматизации.
Цель CASE-технологии – отделить процесс
проектирования ИС от ее кодирования и последующих
этапов разработки, максимально автоматизировать
процесс разработки систем.
Характеристики CASE-средств:
мощная графика для описания и документирования систем;
интеграция, обеспечивающая легкость передачи данных и
позволяющая управлять всем процессом проектирования и
разработки системы непосредственно через процесс планирования
проекта;
использование репозитория для хранения всей информации о
проекте.
50

51. ПРОЦЕССНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ

основано на концепции постоянного улучшения
процессов предприятия BPM (Business Process
Management), реализуемой с помощью
программных продуктов класса BPMS (Business
Process Management System).
BPM поддерживает процессный подход.
Отличие от реинжиниринга бизнес-процессов
(BPR) – непрерывный процесс
усовершенствования бизнес-процессов.
51

52.

52

53.

Основы методологии
проектирования ИС

54.

Основы методологии
проектирования ИС
СТРУКТУРНЫЙ ПОДХОД К
ПРОЕКТИРОВАНИЮ ИС

55.

СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС
Сущность структурного подхода заключается в декомпозиции
(разбиении) ИС на автоматизируемые функции: система разбивается
на функциональные подсистемы, которые в свою очередь делятся на
подфункции, подразделяемые на задачи и т.д. Процесс разбиения
продолжается до конкретных процедур. При этом система сохраняет
целостное представление, в котором все составляющие компоненты
взаимоувязаны.
В качестве основных принципов подхода используются следующие:
принцип "разделяй и властвуй" - принцип решения сложных проблем
путем их разбиения на множество меньших независимых задач;
принцип иерархического упорядочивания - принцип организации
составных частей ИС в иерархические древовидные структуры с
добавлением новых деталей на каждом уровне.
принцип абстрагирования - выделение существенных аспектов ИС и
отвлечение от несущественных;
принцип формализации – использование строгого методического
подхода к решению проблемы;
принцип непротиворечивости - обоснованность и согласованность
элементов;
принцип структурирования данных - данные должны быть
структурированы и иерархически организованы.

56.

СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС
В структурном анализе используются в основном две группы
средств,
иллюстрирующих
функции,
выполняемые
системой и отношения между данными. Каждой группе
средств соответствуют определенные виды моделей
(диаграмм), наиболее распространенными среди которых
являются:
SADT (Structured Analysis and Design Technique) модели и
соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

57.

Диаграммы функционального моделирования
Начало разработки данных диаграмм - середина 1960-х годов, когда
Дуглас Т. Росс предложил специальную технику моделирования,
получившую название SADT (Structured Analysis & Design Technique). Военновоздушные силы США использовали методику SADT в качестве части
своей программы интеграции компьютерных и промышленных
технологии (Integrated Computer Aided Manufacturing, ICAM) и назвали ее IDEF0
(Icam DEFinition). Целью программы ICAM было увеличение
эффективности компьютерных технологий в сфере проектирования
новых средств вооружений и ведения боевых действий.
В рамках программы ICAM было разработано несколько графических
языков моделирования, которые получили следующие названия:
IDEF0 — для документирования процессов производства и отображения
информации об использовании ресурсов на каждом из этапов
проектирования систем.
IDEF1 — для документирования информации о производственном
окружении систем.
IDEF2 — для документирования поведения системы во времени.
IDEF3 — специально для моделирования бизнес-процессов.
Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X.
Методология IDEF-SADT нашла применение в правительственных и
коммерческих организациях, поскольку на тот период времени вполне
удовлетворяла
различным
требованиям,
предъявляемым
к
моделированию широкого класса систем.

58.

Диаграммы функционального моделирования
Методология IDEF-SADT представляет собой совокупность методов, правил и
процедур, предназначенных для построения функциональной модели системы
какой-либо предметной области.
Модель SADT отображает структуру процессов функционирования системы и ее
отдельных подсистем, т. е. выполняемые ими действия и связи между этими
действиями, что позволяет в наглядной форме представить последовательность
определенных действий. Исходными строительными блоками модели IDEFO
процесса являются деятельность (activity) и стрелки (arrows).
Деятельность представляет собой некоторое действие или набор действий,
которые имеют фиксированную цель и приводят к некоторому конечному
результату. Иногда деятельность называют процессом. Модели IDEFO
отслеживают различные виды деятельности системы, их описание и
взаимодействие с другими процессами. На диаграммах деятельность или
процесс изображается прямоугольником, который называется блоком. Стрелка
служит для обозначения некоторого носителя или воздействия, которые
обеспечивают перенос данных или объектов от одной деятельности к другой.
Стрелки также необходимы для описания того, что именно производит
деятельность и какие ресурсы она потребляет. Это так называемые роли
стрелок — ICOM — сокращение первых букв от названий соответствующих
стрелок IDEFO. Различают стрелки четырех видов:
I (Input) — вход, т. е. все, что поступает в процесс или потребляется процессом.
С (Control) — управление или ограничения на выполнение операций процесса.
О (Output) — выход или результат процесса.
М (Mechanism) — механизм, который используется для выполнения процесса.

59.

Диаграммы функционального моделирования.
Методология
IDEF0
однозначно
определяет,
каким
образом
изображаются на диаграммах стрелки каждого вида ICOM. Стрелка
Вход (Input) выходит из левой стороны рамки рабочего поля и входит
слева в прямоугольник процесса. Стрелка Управление (Control) входит и
выходит сверху. Стрелка Выход (Output) выходит из правой стороны
процесса и входит в правую сторону рамки. Стрелка Механизм
(Mechanism) входит в прямоугольник процесса снизу. Т. о., базовое
представление процесса на диаграммах IDEF0 имеет следующий вид
(след. слайд).
Техника построения диаграмм представляет собой главную особенность
методологии IDEF-SADT. Место соединения стрелки с блоком
определяет тип интерфейса. При этом все функции моделируемой
системы и интерфейсы на диаграммах представляются в виде
соответствующих блоков процессов и стрелок ICOM.
Управляющая информация входит в блок сверху, в то время как
информация, которая подвергается обработке, изображается с
левой стороны блока. Результаты процесса представляются как
выходы процесса и показываются с правой стороны блока. В
качестве
механизма
может
выступать
человек
или
автоматизированная система, которые реализуют данную
операцию.
Соответствующий
механизм
на
диаграмме
представляется стрелкой, которая входит в блок процесса
снизу.

60. Обозначение процесса и стрелок ICOM на диаграммах IDEF0

61.

Диаграммы функционального моделирования
Построение модели IDEF-SADT начинается с представления всей
системы в виде простейшей диаграммы, состоящей из одного блока
процесса и стрелок ICOM, служащих для изображения основных
видов взаимодействия с объектами вне системы.
Поскольку исходный процесс представляет всю систему как единое целое,
данное представление является наиболее общим и подлежит
дальнейшей декомпозиции.
Для иллюстрации основных идей методологии IDEF-SADT рассмотрим
следующий простой пример. В качестве процесса будем представлять
деятельность по оформлению кредита в банке.
Входом данного процесса является заявка от клиента на получение
кредита, а выходом — соответствующий результат, т. е.
непосредственно кредит.
Управляющими факторами являются правила оформления
кредита,
которые
регламентируют
условия
получения
соответствующих финансовых средств в кредит.
Механизмом данного процесса является служащий банка, который
уполномочен выполнить все операции по оформлению кредита.
Пример исходного представления процесса оформления кредита
в банке изображен на след. Слайде.

62. Пример исходной диаграммы IDEF-SADT для процесса оформления кредита в банке (пример механизма)

63.

Диаграммы функционального моделирования
В конечном итоге модель IDEF-SADT представляет собой серию
иерархически взаимосвязанных диаграмм с сопроводительной
документацией, которая разбивает исходное представление системы
на отдельные составные части. Детали каждого из основных процессов
представляются в виде более детальных процессов на других
диаграммах. В этом случае каждая диаграмма нижнего уровня является
декомпозицией некоторого процесса из более общей диаграммы.
Для того, чтобы указать положение любой диаграммы или блока в
иерархии, используются номера диаграмм. Например, А21 является
диаграммой, которая детализирует блок 1 на диаграмме А2.
Аналогично, А2 детализирует блок 2 на диаграмме А0, которая
является самой верхней диаграммой модели. На след. слайде показано
типичное дерево диаграмм.
В настоящее время диаграммы структурного системного анализа
IDEF-SADT продолжают использоваться для построения и
детального анализа функциональной модели существующих на
предприятии бизнес-процессов, а также для разработки новых
бизнес-процессов.
Основной недостаток данной методологии связан с отсутствием
явных средств для объектно-ориентированного представления
моделей сложных систем.

64. Иерархия диаграмм

65.

МОДЕЛИРОВАНИЕ ПОТОКОВ ДАННЫХ (ПРОЦЕССОВ)
В основе данной методологии (методологии Gane/Sarson) лежит построение
модели анализируемой ИС - проектируемой или реально существующей. В
соответствии с методологией модель системы определяется как иерархия
диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс
преобразования информации от ее ввода в систему до выдачи пользователю.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют
основные процессы или подсистемы ИС с внешними входами и выходами. Они
детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция
продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока
не будет достигнут такой уровень декомпозиции, на котором процесс
становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные
потоки (потоки данных), переносящие информацию к подсистемам или
процессам. Те в свою очередь преобразуют информацию и порождают новые
потоки, которые переносят информацию к другим процессам или подсистемам,
накопителям данных или внешним сущностям - потребителям информации.
Т.о., основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы/подсистемы;
процессы;
накопители данных;
потоки данных.

66.

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

67.

Внешняя сущность диаграмм потока данных

68. Системы и подсистемы. При построении модели ИС она может быть представлена на контекстной диаграмме в виде одной системы как

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

69.

МОДЕЛИРОВАНИЕ ПОТОКОВ ДАННЫХ (ПРОЦЕССОВ)
Процессы. Процесс представляет собой преобразование
входных потоков данных в выходные в соответствии с
определенным алгоритмом. Физически процесс может быть
реализован различными способами: это может быть
подразделение
организации
(отдел),
выполняющее
обработку входных документов и выпуск отчетов, программа,
аппаратно реализованное логическое устройство и т.д.
Процесс на диаграмме изображается, как показано на след.
слайде. Номер процесса служит для его идентификации. В
поле имени вводится наименование процесса в виде
предложения с активным недвусмысленным глаголом в
неопределенной форме (вычислить, рассчитать, проверить,
определить, создать, получить), за которым следуют
существительные в винительном падеже, например:
"Ввести сведения о клиентах";
"Выдать информацию о текущих расходах";
"Проверить кредитоспособность клиента".
Информация в поле физической реализации показывает, какое
подразделение организации, программа или аппаратное
устройство выполняет данный процесс.

70.

Процесс на диаграмме
потока данных

71.

МОДЕЛИРОВАНИЕ ПОТОКОВ ДАННЫХ (ПРОЦЕССОВ)
Накопители данных. Накопитель данных представляет
собой абстрактное устройство для хранения информации,
которую можно в любой момент поместить в накопитель и
через некоторое время извлечь, причем способы
помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в
виде микрофиши, ящика в картотеке, таблицы в
оперативной памяти, файла на магнитном носителе и т.д.
Накопитель данных на диаграмме изображается, как
показано
на
след.
слайде.
Накопитель
данных
идентифицируется буквой "D" и произвольным числом.
Имя накопителя выбирается из соображения наибольшей
информативности для проектировщика.
Накопитель данных в общем случае является прообразом
будущей БД и описание хранящихся в нем данных должно
быть увязано с информационной моделью.

72.

Накопители данных

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

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

74.

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

75.

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

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

77.

Диаграммы "сущность-связь"
Данная нотация была предложена П. Ченом (Р. Chen) в 1976 года и
получила дальнейшее развитие в работах Р. Баркера (R. Barker).
Диаграммы "сущность-связь" (ERD) предназначены для графического
представления моделей данных разрабатываемой ИС и предлагают
набор стандартных обозначений для определения данных и
отношений между ними. С помощью этого вида диаграмм можно
описать отдельные компоненты концептуальной модели данных и
совокупность взаимосвязей между ними, имеющих важное значение
для разрабатываемой системы.
Основными понятиями данной нотации являются понятия сущности и
связи. При этом под сущностью (entity) понимается произвольное
множество реальных или абстрактных объектов, каждый из которых
обладает одинаковыми свойствами и характеристиками. В этом случае
каждый рассматриваемый объект может являться экземпляром одной
и только одной сущности, должен иметь уникальное имя или
идентификатор, а также отличаться от других экземпляров данной
сущности.
Примерами сущностей могут быть: банк, клиент банка, счет клиента,
аэропорт, пассажир, рейс, компьютер, терминал, автомобиль, водитель.
Каждая из сущностей может рассматриваться с различной степенью
детализации и на различном уровне абстракции, что определяется
конкретной постановкой задачи.

78.

ДИАГРАММЫ "СУЩНОСТЬ-СВЯЗЬ"
Каждая сущность должна обладать уникальным идентификатором. Каждая
сущность должна обладать некоторыми свойствами:
иметь уникальное имя;
иметь один или несколько атрибутов, которые либо принадлежат сущности,
либо наследуются через связь;
иметь один или несколько атрибутов, которые однозначно идентифицируют
каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими
сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями,
значимая для рассматриваемой предметной области. Связь — это ассоциация
между сущностями, при которой каждый экземпляр одной сущности
ассоциирован с произвольным (в том числе нулевым) количеством экземпляров
второй сущности, и наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для
рассматриваемой предметной области и предназначенная для квалификации,
идентификации, классификации, количественной характеристики или
выражения состояния сущности. Атрибут представляет тип характеристик,
ассоциированных с множеством реальных или абстрактных объектов (людей,
мест, событий, состояний, идей, предметов и т.д.). На диаграмме "сущностьсвязь" атрибуты ассоциируются с конкретными сущностями.
Первичный ключ (primary key) — атрибут или группа атрибутов, однозначно
идентифицирующая экземпляр сущности.

79.

ДИАГРАММЫ "СУЩНОСТЬ-СВЯЗЬ"
Для графического изображения ER-модели в виде диаграмм (ERдиаграмм) общепринятыми являются следующие обозначения для
введенных выше понятий: тип сущности, тип связи и атрибут.
Каждому из этих понятий соответствует свое графическое обозначение.
Типы сущностей можно классифицировать как сильные (не зависящие от
других типов) и слабые (зависимые от других типов).
Каждая связь характеризуется степенью, характеризующей количество
участвующих в этой связи сущностей. Связь со степенью два – бинарная
связь. В случае, если одни и те же сущности участвуют в некоторой
связи несколько раз, эта связь является рекурсивной. Основные типы
ограничений, накладываемых на связь – кардинальность и степень
участия.
Показатель кардинальности определяет количество возможных связей
для каждой из участвующих в этой связи сущностей. Наиболее
распространенными являются бинарные связи с показателями
кардинальности «один к одному»(1:1), «один ко многим» (1:M) и
«многие ко многим»(М:N).
Существует два варианта участия сущности в связи: полное
(обязательное) и частичное (необязательное). Степень участия
является полной, если для существования некоторой сущности
требуется находящаяся в связи с ней другая сущность. В противном
случае степень участия является частичной.

80.

ДИАГРАММЫ "СУЩНОСТЬ-СВЯЗЬ"
Атрибуты делятся на простые и составные, однозначные и
многозначные, а также производные. Простые и составные
атрибуты, соответственно, состоят из одного или нескольких
независимых компонентов. Однозначный атрибут содержит
одно значение для сущности, многозначный – несколько
значений. Производный атрибут представляет значение,
производное от значений связанных с ним атрибутов.
Атрибуты или их наборы могут выступать в качестве ключей
сущностей.
Сильный
тип
сущности
обозначается
на
диаграммах
прямоугольником, помеченным внутри именем этого типа. Для
обозначения слабого типа используется прямоугольник с
двойным контуром.
Тип связи изображается ромбом,
помеченным аналогично
именем типа связи. Ромб имеет двойной контур, если связь
соединяет слабую сущность с сильной. Участники каждой
связи на диаграммах соединяются дугами с метками 1, М или N,
определяющими показатель ее кардинальности. При этом
участники связи с полным участием соединяются с ромбом
двойной дугой, с частичным – одинарной.

81.

Атрибуты на диаграммах изображаются в виде эллипсов,
присоединенных линией к соответствующей сущности и
помеченных
именем
атрибута.
Эллипс
окружен
пунктирным
контуром,
если
атрибут
является
производным, двойным контуром, если атрибут –
многозначный. Если атрибут – составной, его компоненты
изображаются в виде присоединенных к нему эллипсов.
Имя первичного ключа на диаграмме подчеркивается.
В каждой схеме, описывающей связи между сущностями,
могут быть введены признаки, поясняющие семантику
взаимосвязи. Эти признаки называются ролями, и они
явно
указываются
путем
приписывания
дугам,
соединяющим сущности и связи. Примерами таких ролей в
описании структуры (связей) элементов ИС могут
служить такие понятия, как «наследует», «определяет»,
«входит» и т.д.

82. Диаграмма процесса анализа сырья, необходимого для получения продукции

Код
отбракованного
сырья
1 Отбракованное 1
сырье
Отбраковка
сырья
Код
анализа
сырья
Код
типа
сырья
Получение
сырья годного
1
1
Тип сырья
1
Взятие проб
сырья
M
Анализы
сырья
M M
Код типа
сырья годного
1
1
Тип сырья годного
Подтверждение
годности сырья
Основание для
отбраковки сырья

83.

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

84. Иерархия вложенности классов для примера "Автомобиль"

Иерархия вложенности классов для примера "Автомобиль"

85.

Методология объектно-ориентированного анализа и
проектирования
Следующий принцип ООАП — инкапсуляция. Этот термин
характеризует сокрытие отдельных деталей внутреннего
устройства классов от внешних по отношению к нему
объектов или пользователей.
Действительно, взаимодействующему с классом субъекту или
клиенту нет необходимости знать, каким образом реализовано
то или иное свойство класса, услугами которого он решил
воспользоваться.
Если продолжить рассмотрение примера с классом "Легковой
автомобиль", то можно проиллюстрировать инкапсуляцию
следующим образом. Основным субъектом, который
взаимодействует с этим классом, является водитель. Очевидно,
что не каждый водитель в совершенстве знает внутреннее
устройство легкового автомобиля. Более того, отдельные
детали этого устройства сознательно скрыты в корпусе
двигателя или в коробке передач. А в случае нарушения
работы автомобиля, являющейся причиной неадекватности
его
поведения,
необходимый
ремонт
выполняет
профессиональный механик.

86.

Методология объектно-ориентированного анализа и
проектирования
Третьим принципом ООП является полиморфизм. Под
полиморфизмом (греч. Poly — много, morfos — форма)
понимают свойство некоторых объектов принимать
различные
внешние
формы
в
зависимости
от
обстоятельств.
Применительно к ООАП полиморфизм означает, что
одноименные действия, характеризующие класс, могут
отличаться в зависимости от того, какому из классов они
относятся.
Рассмотрим, например, два объекта или класса: двигатель
автомобиля, электрический свет в комнате.
Для каждого из них можно определить операцию
"выключить". Однако сущность этой операции будет
отличаться для каждого из рассмотренных объектов.
Так,
для
двигателя
автомобиля
операция
Двигатель_автомобиля.выключить означает прекращение
подачи
топлива
и
его
остановку.
Операция
Комната.электрический_ свет. Выключить означает
простой щелчок выключателя.

87.

Методология объектно-ориентированного анализа и проектирования
Процедурно-ориентированная декомпозиция в этом случае уступила место
объектно-ориентированной
декомпозиции,
при
которой
отдельными
структурными единицами системы стали являться не процедуры и функции, а
классы и объекты с соответствующими свойствами. Как следствие, ПО
перестало быть последовательностью предопределенных на этапе
кодирования действий, а стало событийно-управляемым. В этом случае каждая
программа представляет собой бесконечный цикл ожидания некоторых
заранее определенных событий. Инициаторами событий могут быть другие
программы или пользователи. При наступлении отдельного события,
например, нажатия клавиши на клавиатуре или щелчка кнопкой мыши,
программа выходит из состояния ожидания и реагирует на это событие
адекватным образом. Реакция программы при этом тоже связывается с
последующими событиями.
Наиболее существенным обстоятельством в развитии методологии ООАП явилось
осознание того факта, что процесс написания программного кода может быть
отделен от процесса проектирования структуры ИС. Действительно, до того
как начать программирование классов, их свойств и методов, необходимо
определить, чем же являются сами эти классы. Более того, нужно дать ответы
на такие вопросы, как: сколько и какие классы нужно определить для решения
поставленной задачи, какие свойства и методы необходимы для придания
классам требуемого поведения, а также установить взаимосвязи между
классами.
Эта совокупность задач не столько связана с написанием кода, сколько с
общим анализом требований к будущей ИС, а также с анализом конкретной
предметной области, для которой разрабатывается система.

88.

Методология объектно-ориентированного анализа и проектирования
При проектировании ИС, основанной на использовании БД возникает необходимость в
предварительной разработке концептуальной схемы, которая отражала бы общие
взаимосвязи предметной области и особенности организации соответствующей
информации.
При этом под предметной областью принято понимать ту часть реального мира,
которая имеет непосредственное отношение к процессу функционирования ИС.
Другими словами, предметная область включает в себя только те объекты и
взаимосвязи между ними, которые необходимы для описания требований и условий
решения некоторой задачи.
Процесс выделения или идентификации компонентов предметной области получил
название концептуализации предметной области. При этом под компонентой
понимают некоторую абстрактную единицу, которая обладает функциональностью,
т. е. может выполнять определенные действия, связанные с решением поставленных
задач. На данном этапе появляется относительно новый тип специалиста, который
получил название аналитика или архитектора.
Особенности ЖЦ ИС в случае использования методологии
ООАП.
На
этапе анализа предметной области и формулировки требований
осуществляется определение функций, которые должна выполнять
разрабатываемая ИС, а также концептуализация предметной области. Эту
работу выполняют аналитики совместно со специалистами предметной
области. Результатом данного этапа должна являться некоторая
концептуальная схема, содержащая описание основных компонентов и тех
функций, которые они должны выполнять.

89.

Этап проектирования структуры ИС заключается в разработке ее детальной схемы, на
которой указываются классы, их свойства и методы, а также различные взаимосвязи
между ними. Как правило, на этом этапе могут участвовать в работе аналитики,
архитекторы и отдельные квалифицированные программисты. Результатом данного
этапа должна стать детализированная схема ИС, на которой указываются все классы и
взаимосвязи между ними в процессе ее функционирования.
Этап программирования
является наиболее традиционным для программистов.
Появление инструментариев быстрой разработки приложений (Rapid Application
Development, RAD) позволило сократить время и затраты на выполнение этого этапа.
Результатом данного этапа является собственно ИС, которая обладает требуемой
функциональностью и способна решать нужные задачи в конкретной предметной
области.
Этапы внедрения и сопровождения ИС связаны с необходимостью настройки и
конфигурирования ее среды, а также с устранением возникших в процессе ее
использования ошибок.
Иногда в качестве отдельного этапа выделяют тестирование ИС, под которым понимают
проверку ее работоспособности на некоторой совокупности исходных данных или при
некоторых специальных режимах эксплуатации. Результатом этих этапов является
повышение надежности ИС, исключающего возникновение критических ситуаций или
нанесение ущерба компании, использующей данное приложение.
Методология ООАП тесно связана с концепцией автоматизированной разработки
программного обеспечения (Computer Aided Software Engineering, CASE). При этом широко
используются различные способы визуального представления концептуальных схем.
Последнее, на что следует обратить внимание, это осознание необходимости построения
предварительной модели программной системы, которую, следует считать результатом
первых этапов ЖЦ программы. Т. о., мы переходим к теме, имеющей прямое отношение
к процессу построения моделей и, собственно, моделированию. Речь идет о
методологии системного анализа и системного моделирования.

90.

Методология системного анализа и системного моделирования
Центральным понятием системного анализа является понятие системы,
под которой понимается совокупность объектов, компонентов или
элементов
произвольной
природы,
образующих
некоторую
целостность. Определяющим при выделении некоторой совокупности
как системы является возникновение у нее новых свойств, которых не
имеют составляющие ее элементы. Примеры систем — персональный
компьютер, автомобиль, человек, ИС, др.
Важнейшими характеристиками любой системы являются ее структура и
процесс функционирования. Под структурой системы понимают
устойчивую во времени совокупность взаимосвязей между ее
элементами или компонентами. Именно структура связывает воедино
все элементы и препятствует распаду системы на отдельные
компоненты. Структура системы может отражать самые различные
взаимосвязи, в том числе и вложенность элементов одной системы в
другую. В этом случае принято называть более мелкую или вложенную
систему подсистемой, а более крупную — метасистемой.
Процесс функционирования системы тесно связан с изменением ее
свойств или поведения во времени. При этом важной характеристикой
системы является ее состояние, под которым понимается
совокупность свойств или признаков, которые в каждый момент
времени отражают наиболее существенные особенности поведения
системы.

91.

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

92.

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

93.

94.

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

95.

Унифицированный язык моделирования - UML
Отдельные языки объектно-ориентированного моделирования стали появляться
в период между серединой 1970-х и концом 1980-х годов, когда различные
исследователи и программисты предлагали свои подходы к ООАП. В период
между 1989—1994 гг. общее число наиболее известных языков моделирования
возросло до более чем 50. К середине 1990-х некоторые из методов были
существенно улучшены и приобрели самостоятельное значение при решении
различных задач ООАП. Наиболее известными в этот период становятся:
Метод Гради Буча (Grady Booch), получивший условное название Booch или
Booch'91, Booch Lite (позже — Booch'93).
Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling
Technique — ОМТ (позже — ОМТ-2).
Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented
Software Engineering — OOSE.
Каждый из этих методов был ориентирован на поддержку отдельных этапов
ООАП. Например, метод ОМТ-2 наиболее подходил для анализа процессов
обработки данных в ИС.
История развития языка UML берет начало с октября 1994 года, когда Гради Буч и
Джеймс Румбах из Rational Software Corporation начали работу по унификации
методов Booch и ОМТ. Проект так называемого унифицированного метода
(Unified Method) версии 0.8 был подготовлен и опубликован в 1995 г. Осенью того
же года к ним присоединился А. Джекобсон, главный технолог из компании
Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя
предыдущими. Вначале авторы методов Booch, ОМТ и OOSE предполагали
разработать унифицированный язык моделирования только для этих трех
методик.

96.

Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Джекобсон
сформулировали следующие требования к языку моделирования. Он должен:
Позволять моделировать не только ПО, но и более широкие классы систем и
бизнес-приложений, с использованием объектно-ориентированных понятий.
Явным образом обеспечивать взаимосвязь между базовыми понятиями для
моделей концептуального и физического уровней.
Обеспечивать масштабируемость моделей, что является важной особенностью
сложных многоцелевых систем.
Быть понятен аналитикам и программистам, а также должен поддерживаться
специальными инструментальными средствами, реализованными на
различных компьютерных платформах.
В этот период поддержка разработки языка UML становится одной из целей
консорциума OMG (Object Management Group). Хотя консорциум OMG был
образован еще в 1989 году с целью разработки предложений по
стандартизации объектных и компонентных технологий CORBA, язык UML
приобрел статус второго стратегического направления в работе OMG. В рамках
OMG создается команда разработчиков под руководством Ричарда Соли,
которая будет обеспечивать дальнейшую работу по унификации и
стандартизации UML. Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к
появлению первых документов, содержащих описание собственно языка UML
версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.).
Из более чем 800 компаний и организаций, входящих в настоящее время в состав
консорциума OMG, особую роль играет Rational Software Corporation. Эта компания
разработала и выпустила в продажу одно из первых инструментальных CASEсредств Rational Rose 98, в котором был реализован язык UML.

97.

В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в
рамках консорциума OMG. Очередной этап развития данного языка закончился в марте
1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha
R5). Статус языка UML определен как открытый для всех предложений по его доработке
и совершенствованию. Сам язык UML не является чьей-либо собственностью и не
запатентован кем-либо, хотя указанный выше документ защищен законом об авторском
праве.
Язык UML ориентирован для применения в качестве языка моделирования различными
пользователями и научными сообществами для решения широкого класса задач ООАП.
Следует отметить внимание компании Microsoft к технологии UML. Еще в 1996 г.
Microsoft и Rational Software Corporation объявили о своем стратегическом партнерстве,
которое, по их мнению, способно оказать решающее влияние на рынок средств
объектно-ориентированной разработки программ. В результате был разработан
Microsoft Visual Modeler for Visual Basic. На основе технологии UML Microsoft, Rational Software
и другие поставщики средств разработки программных систем разработали единую
информационную модель, которая получила название UML Information Model.
Предполагается, что эта модель даст возможность различным программам,
поддерживающим идеологию UML, обмениваться между собой компонентами и
описаниями.
Уже в настоящее время разработаны средства визуального программирования на
основе UML, обеспечивающие интеграцию, включая генерацию кода программ, с
наиболее распространенными языками и средами программирования, такими как
MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk.
Подводя итог анализу методологии ООАП и исторических предпосылок появления
UML, можно утверждать следующее: в ближайшие годы язык UML в его
современном виде станет основой для разработки и реализации во многих
перспективных инструментальных средствах: в RAD-средствах визуального и
имитационного моделирования, а также в CASE-средствах самого различного
целевого назначения.