- •Министерство образования и науки, молодёжи и спорта украины
- •Содержание
- •Тема.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. Анализ, верификация и оптимизация проектных решений средствами сапр
- •Список литературы
2.13. Множество моделей по
Выше уже говорилось, что модели ПО обычно бывают или моделями анализа, или моделями проектирования. На самом деле моделей оказывается значительно больше, правда, не все они визуализируются. Посмотрим, почему их оказывается много.
Прежде всего, модели в проекте "множатся" из-за разных видов деятельности процесса разработки ПО (рис.2.8).
При анализе на ПО смотрят как на то, что реализует определенную бизнес-функциональность, нужную заказчику. При этом несущественными оказываются принципы и детали реализации. При проектировании, наоборот, на первое место выходят принципы реализации ПО. А при тестировании детали реализации снова неважны - на ПО смотрят как на черный ящик, реализующий (не важно каким способом) некоторый набор пользовательской функциональности. При развертке у заказчика на ПО смотрят как на набор файлов, хранилищ данных и т. д.
Рис. 2.8. Модели "множатся" из-за разных видов деятельности
Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры, технические писатели, менеджеры, заказчик, пользователи, продавцы-маркетологи и т. д. (рис.2.9). Для всех этих специалистов нужна разная информация о программной системе. Представьте, что произойдет, если, например, продавцу или заказчику-непрограммисту в ответ на просьбу получше ознакомиться с ПО вы дадите почитать программные коды…
Рис. 2.9. Модели "множатся" из-за разного рода специалистов в проекте
Большое количество конфликтов и трудностей в проектах возникает просто из-за того, что одни специалисты не могут понять других. Например, частой является ситуация, когда инженерам по аппаратуре трудно понять программистов, которые создают ПО, взаимодействующее с этой аппаратурой. Программисты объясняют алгоритмы работы своих программ в терминах процедур, переменных, классов и т. д. И наоборот, инженеры "заваливают" программистов деталями реализации и функционирования своих устройств. Другой пример - очень часто технические писатели, создающие пользовательскую документацию для ПО, плохо разбираются в том программном обеспечении, которое они описывают. И документация получается никуда не годной, для галочки. Еще пример: менеджеры (особенно высокопоставленные, в больших проектах) часто не понимают реальных проблем проекта и склонны "расхлебывать" то, что уже произошло, а не реагировать на первые признаки неурядиц. Подобные проблемы легче разрешаются, если в проекте существуют или могут быть созданы по требованию разные модели, предназначенные для различных специалистов, на которых в доступной форме и без лишних деталей представлена нужная информация.
Итак, разные виды деятельности при разработке ПО и разные категории специалистов, задействованные в программном проекте, - все это приводит к созданию и использованию различных моделей, выполненных с разных точек зрения.
Точка зрения моделирования (viewpoint) - это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Далее будут рассматриваться только визуальные модели ПО, хотя многое из сказанного ниже справедливо также и для произвольных моделей.
На первый взгляд, введенное выше определение очевидно и ничего нового не привносит. Например, при создании различных инженерных объектов активно используется эта же концепция - принципиальная схема, монтажная схема, генеральный план, различные проекции и "разрезы" деталей, зданий и пр. Все это является моделями создаваемой системы, выполненными с разных точек зрения. Однако в обычных инженерных областях есть стандартные, зафиксированные точки зрения на систему, и им соответствуют стандартные же модели. Например, электрик при создании электропроекта жилого дома не изобретает различные виды чертежей и описаний, а руководствуется существующими нормативами (в России это свод документов, называемый ПУЭ - Правила Устройства Электроустановок). То же самое касается и проектировщиков зданий, конструкторов автомобилей, самолетов и т. д.
В случае с визуальным моделированием ПО таких стандартизированных видов моделей, к сожалению, не существует. Есть, конечно же, типы диаграмм в UML, но какие из них и когда использовать, какую часть системы с их помощью "прорисовывать" - решать самим разработчикам. Более того, само разбиение UML на разные типы диаграмм условно - диаграммы можно смешивать.
Забегая вперед, заметим, что, например, диаграммы объектов UML предназначены для моделирования фрагментов системы, и сразу появляется вопрос - каких именно фрагментов? Решать приходится разработчикам, использующим эти диаграммы. Далее, существует очень много разных стратегий по созданию диаграмм случаев использования (use case diagrams): одни авторы считают, что нужно создавать не много случаев использования, (даже для крупных систем), другие предпочитают строить огромные "полотна", одни считают, что не нужно подробно изображать окружение системы на этих диаграммах (только тех актеров, которые непосредственно взаимодействуют с системой), другие, наоборот, считают это важным и т. п. Какой из этих способов избрать, или создать свой собственный, - опять-таки решать разработчикам конкретной системы.
Один из классиков визуального моделирования, Грэди Буч, многократно подчеркивал в своих книгах, что его метод - это не поварская книга готовых рецептов. Создание полезных визуальных моделей является более сложным делом, чем создание чертежей и спецификаций в других инженерных областях. И правильно выбранная и ясно сформулированная точка зрения на систему, которая не "плывет" при моделировании, - это один из основных критериев того, что модель действительно принесет пользу.
Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть для кого она предназначается). Важным вопросом, на который нужно честно себе ответить в самом начале моделирования - это зачем вы используете UML. Это и есть определение цели моделирования. Потому что так создавать модели правильнее? И все проблемы (даже те, о которых ничего еще не известно) волшебным образом исчезнут, развеются? Очень часто, например, при создании модели случаев использования присутствует именно такая "цель" моделирования. А потом оказывается, что никакие проблемы не "вылечились", а наоборот, возникли новые (например, созданные нами диаграммы никто не понимает и не принимает). Да и сам аналитик чувствует, что диаграммы получились какие-то странные….
А может все происходить совсем не так. Например, аналитик действительно задался целью выявить требования к системе - не навязать свое собственное видение другим, а выяснить нужную информацию, смоделировать и изложить ее доступно. Для этого он и использует диаграммы случаев использования. Ему важно, чтобы будущие пользователи системы могли участвовать в этом процессе, диаграммы рисуются для них, они понятны и не избыточны. И эти же диаграммы структурируют и проясняют информацию для самого аналитика.
Типична ситуация, когда UML используется, чтобы создавать модели ПО "вообще" - потому что так правильно, потому что люди недавно узнали, что такое UML и т.д. В этом случае какая-то точка зрения при моделировании все-таки есть, но она, как правило, не осознается авторами таких описаний. Цели моделирования расплывчаты и туманны, а люди, которым предназначены данные модели, вообще "потеряны". В результате такие диаграммы никому не нужны, а средства, затраченные на их создание, оказываются выброшенными на ветер.
Важно понимать, что цель модели - это не какая-то гипотетическая задача типа "описания архитектуры, потому, что создавать модели правильно?", а целевая аудитория - это не абстракция типа "люди, желающие познакомиться с ПО". И то и другое - что-то очень конкретное, реально существующее в проекте или рядом с ним. Ведь разработчики ПО не могут позволить себе за деньги заказчика создавать нечто на все века и для всех народов. И цель моделирования, и аудитория, которая будет работать с диаграммами, всегда существуют, важно лишь ясно понимать, какие они…
Вот полезный практический прием для фокусировки на целевую аудиторию, для которой предназначена создаваемая вами модель. Можно выбрать одного представителя такой аудитории - конкретного и известного вам человека - и создавать диаграммы, понятные именно ему. При этом важно не обсуждать чрезмерно с ним ваши модели, поскольку это может создать дополнительный контекст, которого другие пользователи моделей будут лишены. Полезно представлять воображать себе этого человека при работе над моделями - его реакции, вопросы, недоумения и пр. И, исходя из этого, корректировать, исправлять созданное. И, конечно же, полезно проверить свои предположения, показав ему, что получилось.
Кроме того, важно, чтобы точка зрения была "живая", а не выдумывалась аналитиком или бездумно копировалась из книжек и тренингов, посвященных UML. Незаметно для себя аналитик может придумать свой собственный проект, своих собственных пользователей системы, заказчика и т.д. Он может исподволь навязывать самому себе определенное восприятие реально существующих людей, задач, сильно искажая реальное положение дел. И именно в контексте этой воображаемой ситуации он будет создавать свои модели… Идеальный аналитик должен обладать гибкостью сознания, а также чуткостью и искренним стремлением к тому, чтобы сделать каждый конкретный проект, где он участвует, более гармоничным, более адекватным. И в любом случае иметь дело с реальной ситуацией, облегчая, распутывая и освобождая ее. Тут важно не путать:
профессионализм с жесткостью и агрессивностью, приверженностью к какому-либо одному способу работы, жестко фиксированному набору приемов, техник;
функции конструктивного лидера, созидателя, с навязыванием фантазий и бесплодным формотворчеством;
и т.д.
И вовремя пресекать свои собственные нежелательные "увлечения", не бояться порой непростых поисков нужных выразительных форм, акцентов и точек зрения на ситуацию.