- •Министерство образования и науки, молодёжи и спорта украины
- •Содержание
- •Тема.1. Основные понятия и методология проектирования сложных обьектов и систем Лекция 1. Основные понятия и методология
- •1.1. Основные определения
- •1.2. Сущность процесса проектирования
- •1.3. Методология системного подхода к проблеме проектирования сложных систем
- •1.4. Системный подход к задаче автоматизированного проектирования технологического процесса
- •1.5. Системный анализ сложных процессов
- •1.6. Этапы проектирования сложных систем
- •Техническое задание
- •Этап нир
- •Этап окр
- •Этап разработки технического проекта объекта
- •Рабочее проектирование
- •Проектирование технологии изготовления спроектированного объекта
- •1.6. Контрольные вопросы и упражнения
- •Тема.2. Системный ( структурный ) уровень компьютерного проектирования сложных обьектов Лекция 2. Определение визуального моделирования
- •2.1. О пользе чертежей
- •2.2. По и другие инженерные объекты
- •2.3. Чертить по.
- •2.4. Метафора визуализации
- •2.5. Графовая метафора
- •2.6. Определение визуального моделирования
- •2.7. Средства визуального моделирования
- •2.8. О программных инструментах
- •2.9. Визуальное моделирование на фоне эволюции средств программирования
- •2.10. Семантический разрыв визуальных моделей и программного кода
- •2.11. Где выход?
- •2.12. Предметная область, модель, метамодель, метаметамодель.
- •2.13. Множество моделей по
- •2.14. Граф модели и диаграммы
- •2.15. Об операциях над графом модели и диаграммами
- •2.16. Контрольные вопросы
- •Лекция 3. Что такое The uml
- •3.1. Назначение языка
- •3.2. Историческая справка
- •3.3. Способы использования языка
- •3.4. Структура определения языка
- •3.5. Терминология и нотация
- •3.6. Контрольные вопросы
- •Лекция 4. Виды диаграмм uml
- •4.1. Почему нужно несколько видов диаграмм
- •4.2. Виды диаграмм
- •4.3. Диаграмма прецедентов (use case diagram)
- •4.4. Диаграмма классов (class diagram)
- •4.5. Диаграмма объектов (object diagram)
- •4.6. Диаграмма последовательностей (sequence diagram)
- •4.7. Диаграмма взаимодействия (кооперации, collaboration diagram)
- •4.8. Диаграмма состояний (statechart diagram)
- •4.9. Диаграмма активности (деятельности, activity diagram)
- •4.10. Диаграмма развертывания (deployment diagram)
- •4.11. Ооп и последовательность построения диаграмм
- •4.12. Контрольные вопросы
- •Лекция 5. Диаграмма классов: крупным планом
- •5.1. Как класс изображается на диаграмме uml?
- •5.2. А что внутри?
- •5.3. Как использовать объекты класса?
- •5.4. Всегда ли нужно создавать новые классы?
- •5.5. Отношения между классами
- •5.6. Контрольные вопросы
- •Лекция 6. Диаграмма активностей: крупным планом
- •6.1. А ведь это вовсе не блок-схема!
- •6.2. Примеры использования таких диаграмм
- •6.3. Советы по построению диаграмм активностей
- •6.4. Контрольные вопросы
- •Лекция 7. Диаграммы взаимодействия: крупным планом
- •7.1. Диаграммы последовательностей и их нотация
- •7.2. Диаграммы кооперации и их нотация
- •7.3. Рекомендации по построению диаграмм взаимодействия
- •7.4. Контрольные вопросы
- •Лекция 8: Диаграммы прецедентов: крупным планом
- •8.1. Несколько слов о требованиях
- •8.2. Диаграммы прецедентов и их нотация
- •8.3. Моделирование при помощи диаграмм прецедентов
- •8.4. Контрольные вопросы
- •Лекция 9: Элементы графической нотации диаграммы развертывания. Паттерны проектирования и их представление в нотации uml
- •9.1. Диаграмма развертывания, особенности ее построения
- •9.1.1. Узел
- •9.1.2. Соединения и зависимости на диаграмме развертывания
- •9.1.3. Рекомендации по построению диаграммы развертывания
- •9.2. Паттерны объектно-ориентированного анализа и проектирования, их классификация
- •9.2.1. Паттерны проектирования в нотации языка uml
- •9.2.2. Паттерн Фасад и его обозначение в нотации языка uml
- •9.2.3. Паттерн Наблюдатель и его обозначение в нотации языка uml
- •Лекция 10: Визуальное моделирование систем реального времени
- •10.1. Системы реального времени
- •10.2. Структурное подобие срв и аппаратуры
- •10.3. Многоуровневые открытые сетевые протоколы и блочная декомпозиция
- •10.4. Композитные компоненты
- •10.5. Интерфейс
- •10.6. Порт
- •10.7. Соединитель
- •10.8. Реактивные системы
- •10.9. Обзор примера
- •10.10. Контрольные вопросы
- •Лекция 11. Визуальное моделирование бизнес-процессов
- •11.1. Новая концепция бизнеса - ориентация на бизнес-процессы
- •11.2. Erp-системы
- •11.3. Моделирование бизнес-процессов
- •11.4. Пример бизнес-процесса
- •11.5. Декомпозиция бизнес-процессов
- •11.6. Исполняемая семантика бизнес-процессов
- •11.7. Бизнес-процессы и web-сервисы
- •11.8. Обзор bpmn
- •11.8.1. Действия (activities)
- •11.8.2. Связи (connecting objects)
- •11.8.3. Участники (swimlanes) бизнес-процесса
- •11.8.4. Порты (gateways)
- •11.9. Контрольные вопросы
- •12. Лекция: Этапы проектирования ис с применением uml
- •12.1. Разработка модели бизнес-прецедентов
- •12.2. Разработка модели бизнес-объектов
- •12.3. Разработка концептуальной модели данных
- •12.4. Разработка требований к системе
- •12.5. Анализ требований и предварительное проектирование системы.
- •12.6. Разработка моделей базы данных и приложений
- •12.7. Проектирование физической реализации системы
- •Тема.3. Математические модели обьектов проектирования Лекция 14. Математические модели объектов проектирования
- •14.1. Общие сведения о математических моделях
- •14.1.1. Компоненты математического обеспечения
- •14.1.2. Требования к математическим моделям и численным методам в сапр
- •14.1.3. Место процедур формирования моделей в маршрутах проектирования
- •14.2. Классификация математических моделей
- •14.3. Методика получения математических моделей элементов
- •14.3.1. Преобразование математических моделей в процессе получения рабочих программ анализа
- •14.3.2. Формализация получения математических моделей систем
- •Тема.4. Математическое обеспечение компьютерного проектирования Лекция 15. Математическое обеспечение компьютерного проектирования
- •15.1. Методы и алгоритмы анализа на макроуровне
- •15.2. Алгоритм численного интегрирования соду
- •15.3. Методы решения систем нелинейных алгебраических уравнений
- •15.4. Методы решения систем линейных алгебраических уравнений
- •15.5. Организация вычислительного процесса в универсальных программах анализа на макроуровне
- •15.6. Математическое обеспечение анализа на микроуровне
- •15.7. Методы анализа на микроуровне
- •15.8. Структура программ анализа по мкэ на микроуровне
- •15.9. Математическое обеспечение анализа на функционально–логическом уровне
- •15.10. Математические модели дискретных устройств
- •15.11. Методы логического моделирования
- •15.12. Математическое обеспечение анализа на системном логическом уровне
- •15.13. Аналитические модели смо
- •15.14. Имитационное моделирование смо
- •15.15. Событийный метод моделирования
- •15.16. Сети Петри
- •Тема.5. Интегрированные системы автоматического проектирования
- •16.2. Этапы развития информационных систем и технологий на машиностроительных предприятиях
- •16.3. Современные ит и их значение для предприятия
- •16.4. Жизненный цикл изделия
- •16.5. Обеспечение информационных систем на предприятии
- •16.6. Иерархия автоматизированных систем на предприятии
- •16.7. Общепроизводственные системы
- •Тема.6. Системы и технологии управления проектированием и
- •17.1.2. Программные продукты компании sap
- •17.1.2.1. Базисная технология системы r/3 фирмы sap
- •17.1.2.2. Sap erp
- •17.1.2.2. Sap plm
- •17.2. Информационная безопасность в cals-системах
- •17.2.1. Основные понятия и определения
- •17.2.2. Технологии построения защищенной сети виртуального предприятия
- •Лекция 18. Case – технологии Тема.7. Case-технологии компьютерного проектирования
- •Ibm Rational Rose
- •Visio поддерживает множество локальных языков
- •Тема.8. Case-средства анализа и синтеза проектных решений ис
- •Основы методологии проектирования ис
- •Структурный подход к проектированию ис
- •Состав функциональной модели
- •Иерархия диаграмм
- •Внешние сущности
- •Системы и подсистемы
- •Накопители данных
- •Потоки данных
- •Пример использования структурного подхода
- •Тема.9. Анализ, верификация и оптимизация проектных решений средствами сапр
- •Список литературы
Лекция 8: Диаграммы прецедентов: крупным планом
Мы уже познакомились с диаграммами UML нескольких видов. Все они описывают, как устроена и как работает система. Но иногда важно показать, как ведет себя система с точки зрения внешнего наблюдателя, показать, что именно делает система, а не то, как она это делает. Для этого в UML имеется диаграмма прецедентов. О ней-то мы наконец и поговорим. В этой лекции мы рассмотрим такие вопросы: несколько слов о требованиях; диаграммы прецедентов и их нотация; моделирование при помощи диаграмм прецедентов
8.1. Несколько слов о требованиях
Итак, поговорим о требованиях. Что это такое, мы, в общем, понимаем - когда заказчик описывает нам, чего же именно он хочет, мы всегда слышим фразы типа "хотелось бы, чтобы проверка обновлений проводилась автоматически, как в антивирусах", "хочу большую зеленую кнопку в центре окна, которая начинает процесс", "программа должна позволять просматривать и печатать отчеты", "и чтоб красивенько все было, с полупрозрачностями, как в Висте", "при выходе должно выводиться подтверждение" и т. д. и т. п. Конечно, как настоящие разработчики, мы понимаем и то, что заказчик никогда не знает, что именно ему нужно, а если понимает, то объяснить не может. Но ведь фразы-то всегда, по сути, одинаковы! Они описывают, как заказчик представляет себе систему, чего заказчик хочет от системы, функциональность, которой он от нее ожидает, требования, которые к ней предъявляет.
Если обратиться к классикам, например, к той же "банде трех" (Якобсон, Буч, Рамбо), мы узнаем, что требование - это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс разработки ПО в виде " черного ящика " (уверены, читатель знает, что это такое, если нет - "Википедия" к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого "черного ящика" будет подаваться именно набор требований к программному продукту (рис.8.1)!
Рис. 8.1. Процесс разработки ПО
Кстати, какую диаграмму напоминает этот рисунок? Правильно, диаграмму активностей. И выбор именно этой диаграммы тут абсолютно оправдан - помните, мы говорили, что диаграммы активностей часто используют для описания бизнес-процессов? Единственный нюанс: обычно процесс разработки не заканчивается с выпуском программного продукта - грядет новая итерация, новые, уточненные требования, новая версия и т. д.
Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего "черного ящика" подается набор требований. Но в какой форме? Как их документируют, эти требования? Думаю, большинство читателей помнит, что такое техническое задание - основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, по сути, не что иное, как требования к создаваемой системе!
Техническое задание - вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов:
диаграммы прецедентов;
нефункциональные требования.
Диаграммы прецедентов составляют модель прецедентов (вариантов использования, use-cases). Прецедент - это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой системой в ответ на запрос пользователя, т. е. определяет способ использования этой системы. Именно по этой причине use cases, или прецеденты, часто в русской терминологии фигурируют как варианты использования. Варианты использования чаще всего применяются для спецификации внешних требований к проектируемой системе или для спецификации функционального поведения уже существующей системы. Кроме этого, варианты использования неявно описывают типичные способы взаимодействия пользователя с системой, позволяющие корректно работать с предоставляемыми системой сервисами.
Нефункциональные требования - это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный список дополнительных требований к системе (рис.8.2).
Рис. 8.2. Требования к системе
Но вернемся же к прецедентам (вариантам использования). Идентифицировать прецеденты и действующие лица - обязанность системного аналитика. И делает он это для того, чтобы:
четко разграничить систему и ее окружение;
определить, какие действующие лица и как именно взаимодействуют с системой, какой функционал (варианты использования) ожидается от системы;
определить и описать в словаре предметной области (глоссарии) общие понятия, которые необходимы для детального описания функционала системы (прецедентов).
Подобный вид деятельности обычно выполняется в такой последовательности:
Определение действующих лиц.
Определение прецедентов.
Составление описания каждого прецедента.
Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).
Вначале требования оформляются в виде обычного текстового документа, который создается или самим пользователем, или пользователем и разработчиком вместе. Далее требования оформляют в виде таблицы. В левую колонку помещают прецеденты, а в правую - действующих лиц, участвующих в прецеденте.
Рассмотрим пример. Секретарь размещает на сервере меню обеденных блюд на неделю. Сотрудники должны иметь возможность ознакомиться с меню и сделать заказ, выбрав блюда на каждый день следующей недели. Офис-менеджер должен иметь возможность сформировать счет и оплатить его. Система должна быть написана на ASP.NET. Такое вот нехитрое интернет-приложение для автоматизации заказов обедов в офис.
Думаем, здесь все понятно. Таблица с описанием требований может быть, например, такой (табл.8.1):
Таблица 8.1.
-
Прецедент
Действующее лицо
разместить меню
секретарь
ознакомиться с меню
сотрудник, секретарь, офис-менеджер
сделать заказ
сотрудник, секретарь, офис-менеджер
сформировать счет
офис-менеджер
оплатить счет
офис-менеджер
Здесь нигде не сказано о том, что система должна быть написана на ASP.NET. Почему - понятно: это ведь нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. Читатель, внимательно прочитавший предыдущие лекции, заподозрит, что в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно бы применить генерализацию. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис.8.3):
Рис. 8.3. диаграмма прецедентов, построенная на основе таблицы 8.1.