
- •Занятие №1 (07.09.12)
- •Занятие №2 (14.09.12) Жизненный цикл по
- •Постановка задачи
- •Анализ требований и определение спецификаций
- •Проектирование (технический проект)
- •Реализация (рабочая документация, рабочий проект)
- •Подходы к созданию по. Спецификации. Диаграммы перехода состояний
- •Занятие №4 (05.10.12) Структурный подход. Функциональное моделирование.
- •Функциональное моделирование на примере sadt
- •Основные элементы нотации
- •Иерархия
- •Ветвление дуг
- •Стоимостной анализ
- •Отчеты в bPwin
- •Занятие №5 диаграммы потоков данных
- •Лекция 6. (19.10.2012) Моделирование потоков данных
- •Занятие 6. Моделирование данных
- •Лекция 7 (02.11.12) Раздел №3 Объектный подход. Uml.
- •Модели использования. Варианты использования (UseCase, прецеденты)
- •Диаграммы вариантов использования (Diagram Use Case)
- •Логическая модель и модель реализации.
- •Диаграммы классов. Этапы анализа.
- •Диаграммы классов. Этапы проектирования. (уровни спецификаций) (Диаграммы пригодности)
- •Диаграммы классов уровня реализации
- •Занятие №8 Описание поведения
- •Концептуальные диаграммы последовательности
- •Детализированные диаграммы последовательностей.
- •Диаграммы коопераций
- •Диаграммы состояний
- •Диаграмма пакетов
- •Занятие №9. Модели реализации. Модели развертывания. (Физическое проектирование)
- •Диаграммы размещения (развертывания).
Стоимостной анализ
Activity Based Costing (ABC) – стоимостной анализ- методика для количественной оценки затрат, связанной как с определенными работами, так и с общей стоимостью процесса.
Рекомендации по построению IDEF0-диаграмм:
Диагональное расположение работ.
Максимальное расстояние между стрелками на одной грани работ
Максимальное расстояние между работами, поворотами и пересечениями стрелок
Объединение похожих информационных стрелок
Отчеты в bPwin
ModelReport – отчет по моделям, выдаст информацию о цели моделирования, данные об авторе и т.д.
DiagramReport – вкл. Список компонентов
DiagramObjectReport- все объекты, работы, стрелки
ActivityBasedCostingReport – стоимостной
ArrowReport
DataUsageReport – о результатах связывания моделей процессов и моделей данных.
ModelConsistencyReport – отчет об ошибках модели
Типы ошибок:
Синтаксические
Принципиальные
Структурные
Безымянные работы и стрелки
Несвязанные граничные стрелки
Неразрешенные стрелки (затуннелированные стрелки, в основном в квадратных скобках)
Работы без выхода или управления
Занятие №5 диаграммы потоков данных
DFD-Date Flow Diagram – методология графического структурного анализа, описывающая внешнее по отношению к системе источники и приемники данных, логические функции, потоки и хранилища данных.
Возникли в середине 70-х.
Элемент нотации |
Нотация Йордана |
Нотация Гейн-Сарсона (BPwin) |
Внешняя сущность - материальный объект или физическое лицо, выступающая в качестве источника или приемника информации. То с чем система взаимодействует. |
Квадрат, внутри которого указывается наименование |
Кубик с номером и названием на главной грани. |
Процесс (работа, система, подсистема) – осуществляет преобразование данных. |
Круг и номером и наименованием внутри |
Квадрат со скругленными краями, разделенный на три горизонтальных части: номер, название, механизм. |
Поток данных – процесс передачи информации. |
Стрелка. Над ней данные. |
Стрелка. Над ней данные. |
Хранилища (накопители данных) – абстрактное устройство для хранения данных. |
Две параллельные линии между которыми данные. |
Две параллельные линии. С слева закрыты еще двумя параллельными в которых указывают номер, в свободной части - данные. |
Этапы построения DFD-диаграмм.
Построение контекстной диаграммы.
Действия:
Классификация требований и организация их в основные функциональные группы- процессы.
Идентификация внешних объектов – внешних сущностей.
Идентификация основных видов информации – потоков данных между системой и внешними объектами.
Построение контекстной диаграммы, путем объединения всех процессов в один и группировки потоков.
Формирование детализирующих диаграмм, для каждого процесса контекстной диаграммы.
Правила балансировки. При детализации подсистемы можно использовать компоненты только тех подсистем, с которыми существует информационная связь.
Условия завершения детализации процесса:
Процесс взаимодействует с двумя - тремя потоками данных
Возможно описание процесса неким алгоритмом
Процесс выполняет единственную логическую функцию
Правила моделирования потока данных:
Ограничение количества процессов на каждом уровне иерархии (3-7)
Наличие номеров диаграмм и процессов
Уникальность меток и наименований
Совмещение декомпозиции потоков и декомпозиции процессов
Правило сохранения информации: Все поступающие куда-либо данные должны быть считаны, обработаны и сохранены.