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

Основы проектирования
информационных систем.
Модели
•
Введение
• Принципы моделирования
• Визуальное представление моделей
•
Конечные автоматы
• Пример с удалением комментариев
• Регулярные выражения
•
•
Системы потоков
Стохастические модели
• Марковские процессы
•
•
Дискретные цепи Маркова
Процессы размножения и гибели
• Системы массового обслуживания
Внутри «прибора»: параллельные процессы
• Структурный системный анализ
• Функциональные модели IDEF0
•
Системы и модели
•
•
•
Система – совокупность взаимодействующих
компонентов и взаимосвязей между ними.
Модель – упрощенное представление системы
(упрощенное представление реальности).
«Мы строим модель для того, чтобы лучше понимать
разрабатываемую систему».
Гради Буч
•
Модель дает полное, точное и адекватное описание
системы, имеющее конкретное назначение. Это
назначение называется целью модели.
Значение моделирования
???
В каких случаях разумно моделировать?
Будет ли от этого толк?
Что такое ХОРОШАЯ модель?
Резюме
►
►
►
►
►
►
Создаваемые человеком системы сложны. Для
понимания и планирования разработки/изменений
организационных и информационных систем
применяются упрощенные представления – модели.
В организационной/информационной системе
присутствуют структура и процессы.
Модели могут отражать статические свойства системы
(структуру) и/или ее динамические свойства
(процессы).
Модель не тождественна системе.
Модель отвечает на НЕКОТОРЫЕ вопросы о системе.
Модель должна иметь цель – множество вопросов, на
которые ей предстоит ответить (с желаемой
точностью).
Модель как проекция. Точка зрения модели
► При
моделировании
систем реального мира и
нетривиальных
программных систем
выбор проекций
неочевиден.
► Проекция (точка
зрения) определяет, на
какие вопросы может
ответить модель.
Границы модели
► Сложные
системы, как правило, открыты – они
взаимодействуют с внешним миром.
► Проекцию чего следует включить в модель?
Если усеченный цилиндр стоит на столе, то
следует ли изображать стол? А следует ли
изображать реальное положение такого
цилиндра, если он лежит?
► Приходится принимать решения о границах
моделируемой системы – границах модели.
Цель, точка зрения, границы
модели – главные вопросы
► Цель
определяет возможный набор точек
зрения (часто – единственную возможную
точку зрения) и допустимые границы модели.
► Невозможность задать границы модели,
соответствующие цели – признак того, что,
возможно, цель модели выбрана неверно.
Задачи моделирования
•
•
•
•
Визуализировать систему в ее текущем
или желаемом состоянии.
Описать структуру или поведение
системы.
Получить шаблон, позволяющий
сконструировать систему.
Документировать принимаемые
решения.
Сверхзадачи моделирования
•
•
•
•
Исследовать факторы, определяющие
эффективность работы системы согласно
выбранному критерию.
Выявить «узкие места».
Определить (качественно или количественно)
эффективную стратегию управления
системой.
Описать структуру системы и протекающие в
ней процессы с возможностью генерации
соответствующего программного кода.
Сфера применения
•
•
•
•
•
•
•
•
Бизнес-процессы, организация деятельности
предприятия, бухгалтерия, документооборот…
Производство, строительство, транспорт…
Разработка программного обеспечения.
Сложные информационные системы: ИПС, системы
семантического анализа, обработка текстовых
корпусов, системы параллельных вычислений…
Игры.
Эко-, био- и социальные системы.
Системы искусственного интеллекта, описание
деятельности мозга.
…
Типы моделей. Общий взгляд
•
•
Структурная (подчеркивает организацию системы).
Поведенческая (отображает процессы, динамику).
С другой стороны:
•
Математическая, физическая, …
Что может отражать модель?
•
Структурные сущности (классы, интерфейсы,
кооперации, варианты использования)…
•
Поведенческие сущности (взаимодействия, автоматы,
деятельность)…
•
Зависимости, ассоциации, обобщения, цепочки
ответственности…
Немного терминологии
Какие сущности могут быть полезны при моделировании?
► Класс
► Интерфейс
► Кооперация
► Вариант
использования
► Деятельность
► Взаимодействие
► Последовательность
► Автомат
Понятный частный пример
Веб-ресурс
Структура. Классы.
Варианты использования.
•
•
•
•
Взаимодействия клиент – сервер.
Потоки запросов.
Обеспечение функциональности, клиентское и
серверное программирование.
•
•
•
•
•
Повышение эффективности с точки зрения пользователя.
Достижение коммерческих целей.
Структура и процессы с точки зрения разработчика.
Развертывание, продвижение, сопровождение.
Принципы моделирования
1.
2.
3.
4.
Выбор модели оказывает решающее воздействие на
подход к решению проблемы и на то, как будет
выглядеть решение.
У каждой модели есть точка зрения и своя степень
точности.
Лучшие модели – те, что ближе к реальности.
Наилучший подход – использовать совокупность
моделей, почти независимых друг от друга.
О выборе модели
Гиппарх
(125 г. до н.э.)
Аристотель
(384-388 г. до н.э.)
Аристарх Самосский
(III в. до н.э.)
Целлариус
«Небесный атлас»
(1660 г.)
Коперник
(1473-1543 г.)
Еще о выборе модели
► 1596
– 1650
► Как жили до декартовой
системы координат?
► Какие были модели
геометрической
информации?
И еще о выборе модели
Реляционнаяотделы
база данных
программирования моделирования
Лаб. 1
Лаб. 2
Лаб. 3
Проекты
QW237-SD
AVP-2008
Птичкин
IDEF0-55
Воробьев
Грачев
Орлов
Системная архитектура
Аспекты представления системы:
словарь,
функциональность
сборка системы,
конфигурирование
проектирование,
дизайн
реализация
процессы,
взаимодействия
развертывание
поведение
производительность,
масштабируемость,
пропускная способность
варианты
использования
топология системы,
распределение,
поставка,
установка
Визуальное представление модели
•
Чертеж, карта, макет, …
Визуальное представление модели
•
Блок-схема
Визуальное представление модели
•
Граф переходов между состояниями
включение
off
включение
on
проверка
готовности
выключение
работа
установка
параметров
подготовка
Визуальное представление модели
•
Диаграмма «заполнить форму» - стандарт IDEF0
Пустая
форма
Требование полноты данных
Возврат к заполнению формы
Данные
Ожидать завершения
ввода данных
Значения
полей
формы
Проверить, все ли
данные внесены
Заполненная форма
Не все
данные
Вывести сообщение о
неполноте данных
Визуальное представление модели
Отдел обслуживания
клиентов
Отдел продаж
Склад
Заказать товар
Обработать заказ
Подобрать товар
Отгрузить заказ
Получить заказ
Выставить счет
Оплатить счет
Закрыть заказ
Визуальное представление модели
•
Диаграмма (неформальная)
Визуальное представление модели
•
Диаграмма (неформальная)
Наши задачи
•
•
•
•
•
•
Получить представление о разнообразии моделей.
Прочувствовать специфику некоторых классов
систем.
Осознать, что база моделирования – это выбор
адекватной модели и удачного набора точек зрения.
Согласиться с тем, что необходимы формальные
стандарты моделирования.
Рассмотреть бегло один из таких стандартов – IDEF0
(Integration DEFinition 0) – функциональное
моделирование (Function Modeling).
И чуть более подробно – другой стандарт – UML
(Unified Modelling Language)
Конечные автоматы
(Finite state machine)
•
Автомат – это поведение, специфицирующее
последовательность состояний, через которые
проходит объект за время своего существования в
ответ на события (стимулы), а также его реакцию на
эти события.
•
Термины и понятия
•
•
•
•
•
Состояние
Событие (стимул)
Переход
Деятельность (activity)
Действие (action)
Конечные автоматы:
строгое определение
Конечный автомат может быть задан параметрами:
•
•
•
•
•
Q
q0  Q
FQ


– конечное множество состояний
– начальное состояние
– множество заключительных состояний
– конечное множество входных символов
– заданное отображение Q  Q
(функция переходов)
 = (qi , b), где b 
Конечные автоматы:
классы
1.
Детерминированные и недетерминированные.
2.
«С памятью» или без оной.
•
•
•
•
•
Автомат Мура – выходные сигналы зависят только от
текущего состояния.
Автомат Мили - выходные сигналы зависят как от текущего
состояния, так и от текущих значений входных сигналов.
Иначе говоря:
В автомате Мура все действия привязаны к состояниям.
В автомате Мили все действия привязаны к переходам.
В реальных ситуациях модель обычно представляет собой
комбинацию машин Мура и Мили.
Пример: светофор
таймер
таймер
таймер
таймер
Пример: из жизни хищника
действия
…
стимулы
состояние
1. сытый
охотник
добыча
убежать
спать
2
2. голодный
убежать
2
съесть
2
1
Пример: система климат-контроля
простой
холодно
жарко
t0 ОК
t0 ОК
обогрев
охлаждение
жарко
активация
готов
активен
холодно
Задача: анализ текста
•
В тексте возведение в степень обозначалось двумя идущими подряд
звездочками. Решено заменить это обозначение на '^' (так что, к
примеру, 'x**y' заменится на 'x^y'). Как это проще всего сделать?
Исходный текст разрешается читать символ за символом,
получающийся текст требуется печатать символ за символом.
состояние
очередной
входной
символ
новое состояние
действие
основное
'*'
после *
нет
основное
x  '*'
основное
печать х
после *
'*'
основное
печать '^'
после *
x  '*'
основное
печать '*' х
Задачи
•
•
•
•
(анализ текста)
Описать автомат, удаляющий из текста заданную
подстроку.
Описать автомат, удаляющий из текста программы
комментарии ( /* … */ ).
Описать автомат, удаляющий из HTML-кода (или
модифицирующий) заданные HTML-теги.
Подумать над автоматом для определения в тексте
фрагментов, представляющих собой, например, URL
или e-mail.
Автомат, удаляющий из текста программы комментарии
1 вариант
•
/
/
Вне комм.
*
/
Внутри комм.
после */
/
/
Вне комм.
после /
Внутри комм.
после *
*
*
/
Вне комм.
после /*
*
Внутри комм.
*
*
Автомат, удаляющий из текста программы комментарии
2 вариант
•
print(s)
/
0
3
/
Вне комм.
Внутри комм.
после *
*
/
print('/'+s)
Вне комм.
после /
1
*
/
Внутри комм.
*
*
Конец анализируемого текста
2
Автомат, удаляющий из текста программы
комментарии
•
Матрица стимулов (входных символов)
состояния
0
1
0
/
/
1
*
/
3
*
*
2
3
2
*
/
Автомат, удаляющий из текста программы
комментарии
•
Матрица действий
состояния
0
0
вывод очередного
символа
1
вывод '/ ' и
очередного
символа
2
3
1
2
3
К.А.: модель банкомата
Ожидание
Так работаетТакой
банкомат
Сбербанка
банкомат
умнее
(не слишком эффективно)
Вставлена карта
Неверный код
Запрос pin-кода
Запрос операции
Остаток на счете
Снятие наличных
Запрос суммы
да
Нет денег
Выдача денег,
чека, …
ОК
Выполнение операции
Запрос на продолжение
нет
Возврат карты
Завершение работы
Обобщение и развитие темы
•
•
•
•
•
Бесконечное число состояний.
Описание вероятностных характеристик
переходов.
Акцент на описании процесса переходов
Расчет характеристик процесса.
Попытка управления процессом с точки
зрения некоторого функционала
качества.
Системы потоков
Sn = f(Sn-1)
Динамические системы
Системы потоков
• регулярные
• нерегулярные
Системы массового обслуживания (СМО)
(системы с очередями)
запросы
прибор
ДС: Фракталы
zn+1 = f(zn) = azn2 + bzn + C
Регулярные системы потоков
•
Одноканальные
λ
μ
λ – интенсивность поступления запросов
μ – интенсивность обслуживания (пропускная способность)
μ>λ
– условие стабильности
Другие возможные задачи
•
•
•
•
•
Оптимизация по стоимости или времени
протекания процесса.
Несколько начальных или конечных
состояний.
Комбинированные потоки.
…
Стохастические модели.
Стохастические модели
Стохастические модели акцентируют внимание на
явном количественном описании вероятностных
характеристик тех или иных ситуаций в жизненном
цикле системы.
Такие модели могут быть дискретными или
непрерывными.
Основные цели построения стохастических моделей:
•
•
•
•
•
•
•
Исследование (качественное или количественное) поведения
системы (как правило, в стационарном режиме).
Расчет значимых характеристик системы.
Поиск управляющих воздействий, оптимизирующих
функционирование системы с учетом обратных связей.
Решение: аналитическое либо численное.
Стохастическая одноканальная
модель
•
•
•
Время поступления запросов случайно.
=> случайно количество запросов.
Время обслуживания также случайно.
λ
μ
Теперь одноканальная модель
уже не кажется тривиальной
Марковские модели
•
Для ряда задач очень эффективны
модели, в которых вероятности
перехода из текущего состояния в
другие не зависят от предыстории (то
есть от того, как именно система
перешла в это состояние). Такие модели
называются марковскими.
Дискретные цепи Маркова
•
Задача путешественника
3/4
2
1/4
pij -
1/4
1
1/4
1/4
3
1/2
3/4
вероятность перехода
из состояния
i
в состояние
j
Задача путешественника
•
•
Матрица
вероятностей
перехода
0
P=
1/4
3/4 1/4
0
3/4
1/4 1/4 1/2
Вероятность попадания в состояние j из
состояния i за m шагов
pij(m) =  pik(m-1) pkj
k
Процессы размножения и гибели
•
•
•
Состояния характеризуется объемом популяции.
Возможны переходы только в «соседние» состояния.
Вероятности переходов, вообще говоря, зависят от
состояния.
Pij =
dj
1 - bj - dj
bj
0
j = i-1
j=i
j = i+1
в остальных случаях
Процессы размножения и гибели
•
Матрица вероятностей перехода
1-b0
b0
0
0
0
0
0
0
…
d1
1-b1- d1
b1
0
0
0
0
0
…
0
d2
1-b2- d2
b2
0
0
0
0
…
0
0
d3
1-b3- d3
b3
0
0
0
…
0
0
0
d4
1-b4- d4
b4
0
0
…
0
0
0
0
d5
1-b5- d5
b5
0
…
0
0
0
0
0
d6
1-b6- d6
b6
…
0
0
0
0
0
0
…
…
…
Процессы размножения и гибели
Рассмотрев вместо вероятностей интенсивности переходов, получаем
классический процесс общего вида.
•
Вероятность ровно одного «рождения» в промежутке Δt :
k Δt + o(Δt)
•
Вероятность ровно одной «гибели» в промежутке Δt :
k Δt + o(Δt)
0
0
1
1
•
1
к-1
2
2
…
К-1
k
К
k
К+1
k+1
Основное применение модели: анализ потоков в системах с
обслуживанием запросов.
…
Процессы размножения и гибели
Для процесса общего вида:
i
= p0  
i=0
i
K
pk+1
Формула Литтла:
=
i
i p k
N = λT
Среднее число запросов в системе равно
произведению интенсивности их поступления на
среднее время пребывания запроса в системе.
Системы массового обслуживания
(Queueing systems) – «СМО»
•
•
•
•
•
Совокупность «приборов» («каналов»).
Потоки запросов (однородные или неоднородные).
Характеристики входных потоков.
Характеристики «приборов».
Стратегия обслуживания.


Вопросы, представляющие интерес
•
Среднее количество запросов в системе.
•
Ожидаемое время, проведенное запросом в системе
(или в очереди).
•
Ожидаемый промежуток времени непрерывной
загрузки прибора.
•
Ожидаемый пик нагрузки.
•
Дисциплина обслуживания, приоритеты.
Распределение запросов по приборам (каналам).
Основные характеристики СМО
•
ξ : коэффициент использования =
произведение средней интенсивности поступления
запросов на среднее время обслуживания
•
N : среднее число запросов в системе
•
T : Среднее время пребывания в системе
0
0
1
1
1
к-1
2
2
…
К-1
k
К
k
К+1
k+1
…
Простейшие классические СМО: 1
М/М/1
 k =  ; k = 
Проще не бывает: в любом состоянии интенсивности
поступления запросов и интенсивности их
обслуживания – константы.
Оказывается, что в этом случае процессы поступления и
обслуживания запросов обладают замечательным
свойством – отсутствием последействия (прошлая
история случайного процесса не влияет на
предсказание будущего). То есть, эти процессы
являются марковскими.
Простейшие классические СМО: 1
 k =  ; k = 
М/М/1
Вероятность прихода k запросов в промежутке t :
Pk(t) =
(t)k e-t
k!
- распределение Пуассона
Плотность распределения интервала между соседними
запросами:
a(t) = e
-t
- показательное распределение
Простейшие классические СМО: 1
 k =  ; k = 
М/М/1
ξ = /μ
pk = p 0 ξ k;
p0 = 1 - ξ
N =  k pk = ξ / (1-ξ)
T = 1 / (  (1- ξ) )
Простейшие классические СМО: 1
М/М/1
k = ; k = 
Пуассоновский входящий поток
Постоянная интенсивность
поступления / обслуживания
Показательное распределение промежутков
Отсутствие последействия
Простейшие классические СМО: 2
М/М/1
k =  / (k+1);
pk = p0 ( / )k / k!
ξ = 1 – e- /
N = /
T = 1 / (  (1- ξ) )
k = 
Простейшие классические СМО: 3
М/М/
k = 
k = k 
N =  / 
T = 1 / 
- немедленное обслуживание
Простейшие классические СМО: 4
М/М/m
- несколько приборов
k = 
k = min { k, m }
ξ =  / m
Простейшие классические СМО: 5
М/М/1/K
- конечный накопитель
(k=1 - система с удалением
заблокированных запросов)
, k<K
k =
, k>=K
k = 
Простейшие классические СМО: 6
М/М/m
- система с несколькими
приборами и потерями
, k<m
k =
0, k>=m
k = k
Внутри «прибора»:
параллельные процессы
•
•
Как управлять очередью?
Проблема взаимного исключения при совместном
доступе к ресурсам (синхронизация процессов).
процесс
Критическая секция
Параллельные процессы. 1
flag1:= false
flag2:= false
Процесс 1
Процесс 2
flag1:= true
flag2
flag2:= true
flag1
no
yes
no
yes
Критическая секция 1
Критическая секция 2
flag1:= false
flag2:= false
Параллельные процессы. 2
flag1:= false;
flag2:= false
Процесс 1
Процесс 2
flag1:= true
letPass:= 2
flag2:= true
letPass:= 1
flag2 &
(letPass=2)
yes
Критическая секция 1
flag1:= false
flag1 &
(letPass=1)
no
yes
Критическая секция 2
flag2:= false
no
Параллельные процессы: семафор
Персоналиии «проблемы взаимного исключения»:
•
•
Эдсгер Дейкстра
Гарри Петерсен
(1965 г.)
(1981 г.)
Объекты класса «семафор» принимают целочисленные
неотрицательные значения и имеют методы:
V(s)
s:= s + 1
P(s)
s=0
no
yes
s:= s - 1
Параллельные процессы: семафор
semaphore:= 1
Процесс 1
semaphore.P()
Критическая секция 1
semaphore.V()
Процесс 2
semaphore.P()
Критическая секция 2
semaphore.V()
Параллельные процессы: писатели и
читатели
блокировка
жесткая
исключительная
рекомендательная
разделяемая
Структурный системный анализ
Рассмотрим систему на высоком уровне абстракции как совокупность
объектов, характеризующихся
•
делимостью,
•
связностью,
•
упорядоченностью,
•
интегральностью.
Основные принципы структурного системного анализа:
•
•
•
Разбиение процесса на функциональные блоки
•
иерархичность взаимосвязей ,
•
декомпозиция (детализация),
На каждом уровне абстракции – ограниченное число наиболее
существенных компонентов.
использование графических нотаций
Структурный системный анализ
Сфера применения: проектирование производственноэкономических и инженерно-технических систем.
•
•
•
•
•
•
анализ информационных потоков на предприятии,
ре-инжиниринг бизнес-процессов,
компьютеризация деятельности предприятия,
разработка систем автоматизированного
проектирования,
разработка баз данных,
разработка программных приложений, реализующих
управление информационными потоками (например,
системы электронного документооборота)
Исторические вехи
SA – Structured Analysis
•
•
•
(1960-е – середина 1970-х)
системы автоматизированного проектирования,
структурный анализ при создании алгоритмических языков.
SADT – Structural Analysis and Design Technique (1974)
•
•
методология структурного проектирования
Программа ICAM - Integrated Computer-Aided
Manufacturing (конец 1970-х)
•
•
интегрированная компьютеризация производства США
•
начало разработки методологии IDEF (ICAM Definition)
Исторические вехи
•
Развитие объектно-ориентированных методов (1980-е)
•
«Война методов»
•
•
Object-Oriented Software Engineering (OOSE)
Object Modeling Technique (OMT) …
Unified Modeling Language – UML (1994)
•
•
•
•
объектно-ориентированное моделирование системы в целом,
от концепции до исполняемых компонентов;
решение проблемы масштабируемости;
создание языка моделирования
•
•
наглядного и интуитивно понятного для разных категорий
специалистов, работающих над проектом,
легко конвертируемого в программный код.
Исторические вехи
XXI век. Дальнейшее развитие
•
методологии,
•
стандартов IDEF, UML …,
•
графических нотаций,
•
инструментальных средств моделирования.
Использование инструментальных средств
•
предполагает следование стандартам и
соблюдение строгой формализации при
разработке моделей;
•
позволяет генерировать соответствующие
программные модули.
Графические нотации
•
Диаграммы функционального
моделирования (Structured Analysis and Design
Technique, SADT)
•
Диаграммы "сущность-связь" (EntityRelationship Diagrams, ERD)
•
Диаграммы потоков данных (Data Flow
Diagrams, DFD).
•
…
Примеры диаграмм SADT (IDEF0)
Примеры диаграмм ERD
Пример диаграммы IDEF3
Стандарты IDEF
IDEF0 (Integration Definition For Functional Modelling) функциональные модели:
•
•
•
IDEF1X – информационные модели
•
•
структура информации, необходимой для поддержки
функций системы
IDEF2 – динамические модели
•
•
•
функции информационной среды
информация и объекты, связывающие эти функции
изменение во времени функций, информационных потоков и
ресурсов системы
IDEF3, IDEF4, … , IDEF14
Функциональные модели IDEF0
Цель: документирование информационных и производственных
процессов и отображение информации об использовании
ресурсов на каждом из этапов проектирования системы.
Функциональная модель SADT отображает структуру процессов
функционирования системы и ее отдельных подсистем, т. е.
выполняемые ими действия и связи между этими действиями
Основные сущности:
•
функциональные блоки
•
объектные потоки
Графическая нотация:
функциональная диаграмма IDEF0
Основные концепции IDEF0
1.
Модель
•
Модель дает полное, точное и адекватное
описание системы.
•
Модель имеет конкретное назначение. Оно
называется целью модели.
•
Цель определяет возможный набор точек
зрения (часто – единственную возможную
точку зрения) и допустимые границы
модели.
Основные концепции IDEF0
2.
Блочное моделирование
•
Система представляется в виде
функциональных блоков
•
Связи и взаимодействия между блоками
характеризуются объектными потоками.
•
Модель представляет собой набор
взаимосвязанных диаграмм.
Основные концепции IDEF0
3.
Принцип декомпозиции (Decomposition)
- разбиение сложного процесса на
составляющие его функции.
4.
Глоссарий (Glossary)
- набор соответствующих определений,
ключевых слов, и т.д., характеризующих
каждый объект модели.
Основные элементы диаграммы IDEF0
•
функциональный блок (Activity Box)
- изображается прямоугольником.
•
интерфейсная дуга (Arrow)
- изображается стрелкой.
уровень доступа
login
password
запрос
база данных
Обслужить
пользователя
администратор
протокол
база данных
монитор системы
Функции - основа IDEF0-модели
Название функции – глагол.
Функция описывает не то, что обязательно происходит,
но то, что может произойти при определенных
сочетаниях входов, управлений, механизмов.
Функция в IDEF0 существует вне времени, сама по себе
она атомарна.
Функция изображается прямоугольником (блоком).
Стрелки, касающиеся сторон блока, изображают
условия выполнения функции и те условия для
выполнения других функций, которые данная
функция порождает.
Объектные потоки
Условия выполнения функций при моделировании
информационных и организационных систем чаще
всего представляют собой наборы объектов
(реальных или искусственных) – объектные потоки.
Каждый объектный поток на диаграмме IDEF0 должен
иметь название (имя существительное).
Объектные потоки на диаграммах IDEF0 изображаются в
виде стрелок.
Имена и другие характеристики объектных потоков
входят в словарь данных модели. Этот словарь может
затем использоваться для создания моделей
«сущность-связь».
Функциональный блок
управление
уровень
доступа
(Control)
login
password
вход
запрос
(Input)
Обслужить
Функция
пользователя
база данных
механизм
администратор
(Mechanism)
протокол
выход
(Output)
база данных
вызов системы
монитор
(Call)
Функциональный блок: примечания
•
Входы (объекты соответствующих потоков) исчезают
в результате выполнения функции.
•
Выходы возникают в результате выполнения
функции.
•
Объектные потоки управления – это существенные
ограничения, которые определяют, как входы
преобразуются в выходы.
•
Механизмы, вообще говоря, могут не быть
объектными потоками (есть различные школы
моделирования).
•
Вызовы обращены к другим моделям (использующим,
как правило, другую точку зрения).
Фрагмент диаграммы IEDF0
стандарты на специальность
студент
учиться
студент,
переживший семестр
студент, сдавший сессию
отчисленный
студент
сдать сессию
студент,
сдавший
все экзамены
Функциональный блок: примечания
Итак,
•
Диаграммы содержат блоки и дуги
•
Блоки представляют функции
•
Блоки имеют доминирование
•
Дуги изображают
•
•
•
объекты
взаимосвязи между блоками
наборы объектов
Синтаксис диаграмм
Объектные потоки ICOM
прямолинейный сегмент
поворот под углом 900, скруглен
расщепление
слияние
UML
Unified modelling language
Унифицированный язык моделирования
Диаграммы
Структурные
Диаграммы
поведения
Диаграммы
взаимодействия
Структурные диаграммы
Диаграмма классов
(Structure diagram)
Диаграмма
компонентов
Диаграмма объектов
(Component diagram)
Диаграмма композитной
(составной структуры)
(Composite structure diagram)
(Object diagram)
Диаграмма развёртывания
(Deployment diagram)
Диаграмма
профилей
Диаграмма
пакетов
(Profile diagram)
(Package diagram)
Диаграммы поведения
Диаграмма
деятельности
Диаграмма
прецедентов
(Activity diagram)
(Use case diagram)
Диаграммы
взаимодействия
Диаграмма
состояний
(Interaction Diagrams)
(State Machine diagram)
Диаграмма
последовательности
Диаграмма
коммуникации
(Sequence diagram)
(Communication
diagram)
Диаграмма
обзора
взаимодействия
(Interaction
overview
diagram)
Диаграмма
синхронизации
(Timing
diagram)
Взаимосвязь между диаграммами
(один из возможных взглядов)
Диаграмма классов
►
Центральное место в объектно-ориентированном
программировании занимает разработка логической
модели системы в виде диаграммы классов. Диаграмма
классов (class diagram) служит для представления
статической структуры модели системы в терминологии
классов объектно-ориентированного
программирования.
►
Диаграмма классов представляет собой граф,
вершинами которого являются элементы типа
«классификатор», связанные различными типами
структурных отношений.
Диаграмма классов может также содержать
интерфейсы, пакеты, отношения и даже отдельные
экземпляры, такие как объекты и связи.
Диаграмма классов
►
Класс (class) в языке UML служит для обозначения множества
объектов, которые обладают одинаковой структурой, поведением
и отношениями с объектами других классов.
Имя пакета
Student::RegUser
Имя класса
name: String(15)
address: String(35)
userID: String
phoneNmbr: String
(для абстрактного класса
выводится курсивом)
logon()
requestCatalogue()
Атрибуты (свойства) класса
Методы (операции) класса
Имена классов
образуют словарь
предметной области
Атрибуты класса
квантор видимости
<квантор
видимости><имя атрибута>[кратность]:
<тип атрибута> = <исходное значение>{строка-свойство}
квантор видимости
► «+» обозначает атрибут с областью видимости типа
общедоступный (public). Атрибут с этой областью видимости
доступен или виден из любого другого класса пакета, в котором
определена диаграмма;
► «#» обозначает атрибут с областью видимости типа защищенный
(protected). Атрибут с этой областью видимости недоступен или
невиден для всех классов, за исключением подклассов данного
класса;
► «-» обозначает атрибут с областью видимости типа закрытый
(private). Атрибут с этой областью видимости недоступен или
невиден для всех классов без исключения.
Атрибуты класса
<квантор видимости><имя
имя атрибута>[кратность]:
атрибута кратность
<тип
атрибута> = <исходное значение>{строка-свойство}
тип атрибута
{строка-свойство}
►
Имя атрибута
студент
regUser
►
Кратность
(границы – целые положительные числа)
счет
факультет
visibility
…
[1..2]
[2..5,10..15]
[2..*]
[*]
- любое положительное число или 0
[1]
- ровно 1
►
Тип атрибута
String
Integer Color
►
Строка-свойство служит для указания значений атрибута, которые
не могут быть изменены при работе с данным типом объектов.
Цвет
Многоугольник
Атрибуты класса: примеры
<квантор видимости><имя атрибута>[кратность]:
<тип атрибута> = <исходное значение>{строка-свойство}
►
цвет: Соlоr
имя_студента [1..2]: String
►
видимость: Boolean
►
►
форма: эллипс formType: ellipce
цвет:Соlоr = (255, 0, 0)
форма: Прямоугольник = квадрат
занятие: Программирование
стипендия : Currency = $30
►
стипендия: Currency = {$30}
►
►
►
►
абстрактный атрибут
Подчеркивание означает, что
атрибут может принимать
подмножество значений из
некоторой области.
«Все объекты данного класса
могут иметь несколько
различных форм, каждая из
которых является
прямоугольником»
Операции (методы) класса
Квантор видимости><имя
видимости
(список параметров):
параметров)
<квантор
операции>(список
<выражение типа возвращаемого значения >{строка-свойство}
►
Квантор видимости
 «+» - область видимости типа общедоступный (public)
 «#» - область видимости типа защищенный (protected)
 «-» - область видимости типа закрытый (private)
►
Список параметров
набор разделенных запятой формальных параметров в формате:
<вид параметра><имя параметра>:<выражение типа>=
<значение параметра по умолчанию>
 вид параметра - одно из ключевых слов «in» (по умолчанию), «out»
или «inout»
 синтаксис зависит от конкретного языка программирования и
подчиняется принятым в нем ограничениям
Операции (методы) класса
<квантор видимости><имя операции>(список параметров):
<выражение
выражение типа возвращаемого значения >{строка-свойство}
{строка-свойство}
►
Выражение типа возвращаемого значения
►
Строка-свойство
является зависимой от языка реализации спецификацией типа или типов значений
параметров, которые возвращаются объектом после выполнения соответствующей
операции. Двоеточие и выражение типа возвращаемого значения могут быть
опущены, если операция не возвращает никакого значения.
служит для указания значений свойств, которые могут быть применены к данному
элементу. Строка-свойство не является обязательной, она может отсутствовать,
если никакие свойства не специфицированы.
 Операция с областью действия на весь класс показывается
подчеркиванием имени и строки выражения типа. По умолчанию под
областью операции понимается объект класса. В этом случае имя и
строка выражения типа операции не подчеркиваются.
 Операция, которая не может изменять состояние системы и,
соответственно, не имеет никакого побочного эффекта, обозначается
строкой-свойством «{запрос}» («{query}»).
Операции (методы) класса: примеры
►
+создать()
+create()
— может обозначать абстрактную операцию по созданию отдельного объекта
класса, которая является общедоступной и не содержит формальных параметров.
Эта операция не возвращает никакого значения после своего выполнения
►
+нарисовать(форма: Многоугольник = прямоугольник,
цвет_заливки: Color = (О, О, 255))
— может обозначать операцию по отображению на экране монитора
прямоугольной области синего цвета, если не указываются другие значения в
качестве аргументов данной операции
►
выдать_сообщение():{"Ошибка деления на ноль"}
— смысл данной операции не требует пояснения, поскольку содержится в строкесвойстве операции. Данное сообщение может появиться на экране монитора в
случае попытки деления некоторого числа на ноль, что недопустимо
Отношения между классами
► зависимость
Клиент зависимости
► ассоциация
(dependency relationship)
Источник зависимости
(association relationship)
 aгрегация (aggregation relationship)
 композиция (composition relationship)
► обобщение
(generalization relationship)
Отношения ассоциации
Символ порядка классов
в ассоциации
Имя ассоциации
компания
1
работает
1..*
сотрудник
Кратность ассоциации
компания
имеет в штате
сотрудник
Отношения ассоциации
►
Ассоциации могут быть бинарными (связывающими
2 класса), тернарными, N-арными…
футбольная команда
*
год
►
*
*
матч
Исключающая ассоциация
Счет в банке
Физическое лицо
xor
Юридическое лицо
Отношения агрегации
целое
состоит из
часть
настольный компьютер
контейнер
системный блок
коллекция
включает в себя
клавиатура
элемент
монитор
мышь
представляет собой набор
элемент
Отношения композиции
(частный случай агрегации)
окно приложения
заголовок
►
рабочая
область
полоса
прокрутки
меню
панель
инструментов
Составляющие элементы не могут существовать в
отрыве от целого
Отношения обобщения
класс-предок
класс-потомок
геометрическая фигура
квадратмногоугольник
прямоугольник
прямоугольник
окружность эллипс
эллипс
параллелограмм
квадрат
►
Наследуются атрибуты и методы
окружность
…
…
…
Пример диаграммы классов
3..*
Point
1
Poligon
Circle
radius
*
*
Style
1
Color
borderType
isFilled
stroke()
fill()
1
Примеры диаграмм классов
Диаграммы вариантов использования
(диаграммы прецедентов)
(use case diagram)
Цели:
► Определить общие границы и контекст моделируемой
предметной области на начальных этапах
проектирования системы.
► Сформулировать общие требования к функциональному
поведению проектируемой системы.
► Разработать исходную концептуальную модель системы
для ее последующей детализации в форме логических
и физических моделей.
► Подготовить исходную документацию для
взаимодействия разработчиков системы с ее
заказчиками и пользователями.
Диаграммы вариантов использования
Отношения между акторами и прецедентами:
► Отношение
ассоциации
1
(association relationship)
*
► Отношение
расширения
(extend relationship)
«extend»
► Отношение
обобщения
► Отношение
включения
(generalization relationship)
потомок наследует все свойства и поведение родителя
«include»
(include relationship)
Диаграммы вариантов использования
Проверить условия
на запрос каталога
клиентом
Оформить заказ
на покупку товара
Оформить заказ
на покупку ноутбука
Выдавать каталог
только по запросу
клиента
«extend»
«include»
Запросить каталог
всех товаров
Выписать счет
на покупку ноутбука
Диаграммы вариантов использования
► На
диаграмме отражаются отношения
между акторами (actors) и прецедентами
– возможными вариантами использования
системы.
► Каждый вариант использования
 Связан хотя бы с одним актором
 Кем-то инициирован
 Имеет существенный для системы результат
Примеры диаграмм
вариантов использования
Диаграмма состояний
(State Chart/State Machine diagram)
► Цель
- описать возможные
последовательности состояний и
переходов, которые в совокупности
характеризуют поведение элемента
модели в течение его жизненного цикла.
► Диаграмма
состояний представляет
динамическое поведение сущностей
Диаграмма деятельности
(activity diagram)
► Цель
- моделирование процесса
выполнения операций.
► Каждое состояние на диаграмме
деятельности соответствует выполнению
некоторой элементарной операции, а
переход в следующее состояние
срабатывает при завершении этой
операции.
► В определенном смысле можно считать,
что это частный случай диаграммы
состояний.
Диаграмма деятельности
Сущности и графические нотации
► Состояние
действия
(action state)
► Переход
 Ветвление
 Параллельные ветви (разделение и слияние)
► Дорожка
Примеры диаграмм деятельности
Диаграмма последовательности
(sequence diagram)
► Цель
- моделирование взаимодействия
объектов во времени.
► Представляет временные особенности
передачи и приема сообщений между
объектами.
► Сущности:




Объект
Линия жизни объекта
Фокус управления
Сообщения (рекурсия, рефлексия)
Примеры диаграмм последовательности