- •Министерство образования и науки, молодёжи и спорта украины
- •Содержание
- •Тема.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. Анализ, верификация и оптимизация проектных решений средствами сапр
- •Список литературы
4.12. Контрольные вопросы
Почему нужно строить разные диаграммы при моделировании системы?
Какие диаграммы соответствуют статическому представлению о системе?
Вы разрабатываете компьютерную программу для игры в шахматы. Какая диаграмма UML была бы полезной в этом случае? Почему?
Составьте список вопросов потенциальному пользователю такой программы. Объясните, почему вы хотели бы задать именно их.
Лекция 5. Диаграмма классов: крупным планом
Диаграмма классов - один из наиболее часто используемых видов диаграмм UML. Обычно создание диаграммы классов знаменует собой окончание процесса анализа и начало процесса проектирования. Мы уже встречались с ними в лекции "Виды диаграмм", а теперь изучим их более внимательно. В этой лекции мы рассмотрим такие вопросы: как класс изображается на диаграмме UML; а что внутри; как использовать объекты класса; всегда ли нужно создавать новые классы; отношения между классами
5.1. Как класс изображается на диаграмме uml?
Архитектор программного обеспечения в первую очередь обращает внимание на объекты предметной области. Программист же концентрируется на поведении этих объектов, пользуясь классами, к которым они принадлежат. Вот поэтому-то диаграмма классов и является одной из важнейших диаграмм UML. Она используется для документирования программных систем, и основным ее компонентом является класс. Что такое класс, мы уже говорили ранее, когда знакомились с видами диаграмм UML. В предыдущей лекции мы рассматривали назначение диаграммы классов, знакомились с примерами готовых диаграмм, но не вникали в тонкости обозначений, используемых на диаграмме. В тех примерах все казалось нам очень понятным и логичным. Тем не менее, некоторые нюансы все же следует рассмотреть, и как раз этим мы сейчас и займемся.
Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части. В первой части указывается название класса. Как правило, имя класса состоит из одного, максимум двух слов. Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области. Третья часть содержит перечень операций, отражающих его поведение в модели предметной области (рис.5.1). Все очень просто, не так ли?
Рис. 5.1. Изображение класса
5.2. А что внутри?
Мы узнали, как класс изображается и выглядит "снаружи". А что же внутри объектов класса? Пользователю об этом знать необязательно, более того, абсолютно не нужно. Для человека, использующего его, объект выступает в роли черного ящика. Скрывая от пользователя внутреннее устройство объекта, мы обеспечиваем его надежную работу. Сейчас мы рассмотрим, как убрать из поля зрения пользователя то, что ему знать не нужно.
Читателя может слегка смутить слово "пользователь", которым мы злоупотребляли в предыдущем абзаце. Зачем вообще пользователю какие-то объекты и классы? Внесем ясность. Программист, использующий в своей программе созданные кем-то компоненты, как раз и выступает в роли такого пользователя. Зачем ему знать что внутри - он знает, какие атрибуты надо модифицировать и какие операции использовать, чтобы заставить объект работать именно так, как ему нужно! Более того, а многие ли из нас знают, как именно устроен и по каким принципам работает, например, телевизор - объект класса "Бытовой прибор"?
Сокрытие от пользователя внутреннего устройства объектов называется инкапсуляцией. Если говорить более "научным" языком, то инкапсуляция - это защита отдельных элементов объекта, не затрагивающих существенных характеристик его как целого. Инкапсуляция нужна не только для того, чтобы создать иллюзию простоты объекта для пользователя (по словам Г. Буча). Но вернемся к примеру с телевизором. Нам этот прибор кажется очень простым только потому, что при работе с ним мы используем простой и понятный интерфейс - пульт дистанционного управления. Мы знаем: для того чтобы увеличить громкость звука, надо нажать вот эту кнопку, а чтобы переключить канал - вот эту. Как телевизор устроен внутри, мы не знаем. Более того - в отсутствие пульта ДУ такое знание было бы неудобным для нас и весьма опасным для самого телевизора, вздумай мы увеличить громкость с помощью паяльника. Поэтому-то пульт ДУ и защищает от нас "внутренности" телевизора! Вот так инкапсуляция реализуется в реальном мире.
В программировании инкапсуляция обеспечивается немного по-другому - с помощью т. н. модификаторов видимости. С их помощью можно ограничить доступ к атрибутам и операциям объекта со стороны других объектов. Звучит это немного пугающе, но на самом деле все просто. Если атрибут или операция описаны с модификатором private, то доступ к ним можно получить только из операции, определенной в том же классе. Если же атрибут или операция описаны с модификатором видимости public, то к ним можно получить доступ из любой части программы. Модификатор protected разрешает доступ только из операций этого же класса и классов, создаваемых на его основе. В языках программирования могут встречаться модификаторы видимости, ограничивающие доступ на более высоком уровне, например, к классам или их группам, однако смысл инкапсуляции от этого не изменяется. В UML атрибуты и операции с модификаторами доступа обозначаются специальными символами слева от их имен (табл.5.1).
Таблица 5.1. Модификаторы доступа
Символ |
Значение |
+ |
public - открытый доступ |
- |
private - только из операций того же класса |
# |
protected - только из операций этого же класса и классов, создаваемых на его основе |
Рассмотренный ранее пример с телевизором средствами UML (конечно же, это очень высокоуровневая абстракция) можно изобразить так (рис.5.2):
Рис. 5.2. Класс ”Телевизор”
Не правда ли, все понятно и предельно просто? Зачем, например, пользователю знать числовые значения частот каналов? Он знает, что достаточно запустить процедуру автоматического поиска каналов и телевизор все сделает за него. Вот вам и инкапсуляция - оказывается, она повсюду вокруг нас. Оглянитесь и подумайте, сколько вещей вокруг имеют скрытые свойства и выполняют скрытые операции. Испугались? Вот то-то же!