
- •Основные требования к методологии проектирования программного обеспечения
- •Основные требования к методикам и методам проектирования ПО
- •Сложная система.
- •Разработка технического задания.
- •Диаграмма Use-Case (диаграмма прецедентов)
- •Методология быстрой разработки приложений – RAD.
- •Структурный подход в проектировании.
- •Методология Гейна/Сарсона.
- •Нотация Йордена/Де Марка
- •Синтаксис графического языка IDEF0.
- •Модель IDF3
- •Типы отношений.
- •Диаграмма атрибутов
- •Диаграмма потоков данных (ДПД, DFD)
- •Методология RUP и пример ее использования на простом примере о торговой фирме.
- •Спецификации прецедента «обновить данные из внешней системы».
- •Возможные отношения между сценариями.
- •UML, разновидности предметов, существующих в UML.
- •Операции
- •Группировка
- •Множественность. Как ее обозначить?
- •Реализация
- •Деревья наследования
- •Автомат
- •Диаграмма деятельности.
- •Зацикливание, выбор вариантов и циклы.
- •Оценка производительности распределенных информационных систем на этапе проектирования
- •Модели реализации.
- •Компонентная диаграмма
- •Computer-Aided Software/System Engineering (CASE)
- •Критерии классификации CASE-систем.
- •Тестирование ПО
- •Этапы тестирования.
- •Нагрузочное и предельное тестирование
- •Интеграционное тестирование при структурном подходе к программированию.
- •Тестирование при объектно-ориентированном подходе.
- •Сложность тестирования интеграционного класса.
- •Структурное тестирование программного обеспечения
- •Способ тестирования базового пути.
- •Потоковый граф
- •Графы и отношения
- •Отношения (симметричность, транзитивность)
- •Тестирование циклов
- •Тестирование очередей и потоков данных.
- •Как тестировать очереди.
- •Тестирование потока транзакций.
- •Тестируем декларацию.
- •Лекция 03.05.2011
- •Международные стандарты на разработку ПО
- •Стандарты, регламентирующие документирование программных средств и баз данных.
- •Профиль стандартов документирования объектов
- •Эксплуатационная документация
- •Исследовательская документация
- •Пользовательская документация
- •Лекция 10.05.2011
- •Характеристики качества программных средств
- •Модель качества ПП
- •Основные количественные характеристики программных средств и их атрибуты
- •Основные качественные характеристики программных средств и их аттрибутов.
- •Пример требований к количественным характеристикам качества программного средства.
- •Характеристики качества баз данных.
- •Жизненный цикл профилей стандартов

Полиморфная операция. Есть некоторая операция, которую наследуют наследники.
Полиморфизм – возможность с помощью одного имени обозначать операции из различных классов (но относящихся к одному суперклассу).
Диаграмма классов системы управления полетов.
Справа вверху ставится цифра NN – это количество экземпляров «НЕ БОЛЕЕ, ЧЕМ NN». Раньше она говорила, что это «ровно NN», но это она погорячилась.
|
роль |
|
|
|
|
агрегация |
|
|
|
|
|||
|
|
|
|
|
|
1 |
|
|
|
|
|
||
|
клиент |
3 |
6 |
|
датчик |
|
|
||||||
|
|
|
Контроллер СУ |
1 |
|
|
|
|
|
|
|
||
Определяет |
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|||||
1 |
1 xor |
|
|
|
|
|
|
|
|||||
полет |
|
|
1 |
|
|
|
|
|
|||||
|
|
|
|
|
|
Регулятор узлов |
|
|
|||||
|
|
|
|
Регулятор скорости |
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ПрограммаПолета |
|
|
|
|
|
|
Регулятор |
|
|
|
|||
ТракеторияПолета |
|
,Перезапуск >=64мс- |
|
|
|
|
|
|
|
||||
ВыполнятьПрограмму () |
|
|
|
|
|
|
Включить() |
|
|
|
порт |
||
ПрогнозПолета() |
|
|
|
|
|
|
Выключить() |
|
|
|
Динамические модели отображают изменение состояния в процессе работы системы. Поэтому сюда входят автоматы и диаграммы взаимодействий.
Автомат (state-машины) – описывает поведение разрабатываемой системы в терминах последовательности состояний, через которые проходит объект в течение своей жизни.
Взаимодействие – описывает поведение в терминах обмена сообщениями между объектами.
Автомат
Автомат отображается с помощью:
1.Диаграмм схем состояний
2.Диаграмм деятельности
Взаимодействия (между объектами) отображаются с помощью:
1.Диаграмм сотрудничества (кооперации, collaboration)
2.Диаграммы последовательности действий.
Состояние обозначается прямоугольником со скругленными углами.
Имя состояния
Событие – происшествие, вызывающее изменение состояния.
Действие – набор операций, запускаемых этим событием.
событие/действие
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 30 |

Примеры событий:
Баланс <0 |
– изменение состояния. |
Помехи |
– сигнал «объект с именем таким-то» (имя объекта). Что-то нужно |
|
изменить. |
Уменьшить |
– вызов действия, которое приводит к запуску какого-то другого блока. |
(давление) |
|
After (5сек) |
– по истечении временного периода что-то сделать. Т.е. каждые 5 секунд |
|
происходит какое-то событие. |
When (time = 17.00) |
– наступление абсолютного времени. |
Примеры действий, соответствующих этим событиям
Кассир.Прекратить выплаты() |
– операция, которая прекращает выплаты, если |
|
баланс меньше нуля. |
fit := new(фильтр); fit.убратьПомехи() |
– запускается сразу два события. |
Send Ник.Привет |
– send используется для посыла сигнала. |
Обозначения:
Переход в начальное состояние:
Переход в конечное состояние:
«очки» означают детализацию этого состояния
|
After(10c)/самопроверка() |
|
инициализация |
ожидание |
Тревога/ |
блокироватьПериметр()
Сброс/разблокироватьПериметр()
Имя состояния
Имя состояния
Активна
entry/установитьТревогу() do/подтверждатьТревогу() exit/СбросТревоги()
After(5c)/ПриемКоманды()
С одной стороны, система включена круглые сутки. Поэтому нет блока «переход в конечное состояние». Но есть exit. Где его нарисовать в этой схеме – она сомневается. Может быть, где-то внутри «активна».
Пример сохранения истории.
команды |
Активна |
|
|
|
Н |
|
запрос |
|
проверка |
|
звонок |
ждать
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 31 |

Диаграмма деятельности. |
|
|
|
Диаграмма деятельности представляет собой особую форму конечного автомата, в котором |
|||
показывается процессы вычислений и потоки работ. |
|||
Пример диаграммы деятельности. |
|
|
|
Черная жирная линия называется линией синхронизации. |
|||
Покупатель |
|
Интернет-магазин |
|
|
Вход в каталог интернет- |
|
|
|
магазина |
|
|
|
*поиск по ключу+Ввод критерия |
Подготовка к |
|
|
|
поиска |
приему заказа |
|
*поиск по |
|
Поиск по каталогу |
|
разделу+ |
|
|
|
Переход по |
|
Формирование |
|
разделу каталога |
|
|
|
|
результата поиска |
|
|
|
|
|
|
Исследование |
|
|
|
товаров |
|
|
|
[товар выбран] |
Положить |
Выполнить заказ в |
|
товар в корзину |
||
|
[товар не |
корзине |
|
|
|
||
|
|
|
|
|
выбран] |
|
|
Диаграмма сотрудничества (кооперации). |
|
||
Синтаксис объекта: ИмяОбъекта:ИмяКласса |
|
||
Имя |
- Обозначение объекта. |
|
|
свойства |
|
|
|
|
Если не хочу называть объект, то просто пишу: «:ИмяКласса» |
||
Подчеркивание означает конкретный объект. Например: |
Адам:Человек :Пользователь Агент: МойКомпьютер:
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 32 |

Пример. Поток синхронных событий.
Имеем: клиент, бармен и официант. Любой объект из класса «Клиент» может выпить.
Сообщение (направление и название сообщения)
|
|
2:заказать(смесь(3)) |
|
2.2:принести(напиток(3)) |
|
|
:Клиент |
|
Б1:Бармен |
|
О1:Официант |
||
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
|
|
|
2.1:НапитокИзготовить(сместь(3))
3:выпитьСместь(3)
Система управления полетами.
|
|
П1:Программа полета |
|
8:Прогноз() |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1:выполнитьУправление() |
|||
|
|
|
|
|
4:ТекущаяСкорость() |
|||
|
|
|
К1:КонтроллерСУ |
|
||||
|
|
|
|
|
|
|
5:ТекущийУгол() |
|
2:ВключитьИзмСКор() |
|
|
|
7:[T≤Tзад+:ВклРегУглов |
||||
|
7:[T>Tзад+:ВклРегСкорости() |
|||||||
3:ВключитьИЗмУгл() |
|
|
||||||
|
|
|
|
|
У:РегуляторУглов |
|||
|
|
|
|
|
|
|
|
|
Д:Датчик |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
С:РегуляторСкорости |
|
|
||
|
|
|
|
|
|
|
|
|
А теперь то же самое, но диаграммой последовательности действий. В прямоугольниках если не подчеркнуто или не стоит имя класса перед «:» – то это класс. А нужен объект!
|
П1:Программа полета |
|
К:КонтроллерСУ |
|
|
Д:Датчик |
|
С:РегуляторСкор |
|
С:РегуляторУглов |
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Означает |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
активность |
|
|
|
ВключитИзмСкор |
|
|
|
|
|
|
|
|||||
объекта |
|
|
|
ости() |
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
ВклИзмУглов() |
|
|
|
|
|
|
|
ТекСкорость()
[T>Tзад+ВклРегСкор()
Прогноз() |
ТекУгол() |
[T≤Tзад+ВклРегУглов()
Диаграмма последовательности действий пользователя и автоматизированного кассового аппарата
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 33 |

Стрелка со сплошной заливкой наконечноника означает процедурную передачу управления.
Стрелка с двухреберным наконечником обозначает непроцедурную передачу управления.
Стрелка с однореберным наконечником обозначает асинхронное взаимодействие между объектами.
Пунктирная стрелка с двухреберным наконечником обозначает возврат из вызова процедуры.
:Пользователь – означает любой объект из класса пользователь.
:Пользователь |
:АКМ |
:Банк |
|
|
:Транзакция |
requestAccount |
(Запрос Счета) |
|
счет |
|
|
requestAmount |
|
|
сумма |
|
|
|
|
transactionRequest |
|
|
transactionAuthorization |
X – уничтожить объект
Мы хотим снять деньги. НО, прежде чем снять деньги, мы должны запросить, а есть ли они. Банк – огромная гетерогенная система, К которому мы, вроде, Не имеем отношения. Но мы хотим обратиться к хостовому компьютеру этого банка – вот мы его и обозначили выше прямоугольником :БАНК на схеме выше.
Мы создали объект, и мы же его уничтожили на схеме выше.
Романова Т.Н. – Технология программирования [2011]by Melvin |
Страница 34 |