Список вопросов к экзамену по дисциплине “Разработка САПР”

(9 семестр, осень-зима 2012 года)

1. Четырехуровневая архитектура UML. Виды моделей в UML.

2. Интерфейс как элемент UML диаграммы. Назначение и свойства. 237

3. Класс как элемент UML диаграммы. Назначение и свойства.

4. Пакет как элемент UML диаграммы. Назначение и свойства. 240

5. Утилита как элемент UML диаграммы. Назначение и свойства. 239

6. Шаблон как элемент UML диаграммы. Назначение и свойства. 238

7. Ассоциация как способ описания взаимоотношений между классами UML диаграммы. Бинарная аcсоциация.

8. Виды ролей в UML.

9. Обозначение множественности на диаграммах в UML.

10. Назначение квалификатора.

11. Назначение диаграммы классов. Задание атрибутов и операций на диаграмме классов.

12. Агрегирование в UML.

13. Виды зависимостей на диаграммах классов и способ их обозначения.

14. Связи между объектами на диаграммах UML. 239

15. Назначение UML-диаграммы вариантов использования. Пример построения.

16. Назначение и виды UML-диаграмм взаимодействия. Примеры построения. 241 244

17. Назначение UML-диаграммы последовательности. Пример построения. 241

18. Назначение UML-диаграммы деятельности. Пример построения. 254

19. Назначение и виды UML-диаграмм состояний. Примеры построения. 246

20. Назначение UML-диаграммы компонентов. Пример построения.

21. Назначение UML-диаграммы развертывания. Пример построения.

22. Формальная структура принятия решений. Матрица решений.

23. Понятие оценочной функции. Варианты записи выражений для оценочной функции.

24. Графическое представление поля выбора решения. Конусы неопределенности.

25. Понятие функции предпочтения в задаче принятия решения в условиях неопределенности.

26. Минимаксный критерий.

27. Критерий Байеса-Лапласа.

28. Критерий Сэвиджа.

29. Критерий Гурвица.

30. Принципы экстремального программирования (XP).

31. Состав группы заказчиков при экстремальном программировании.

32. Состав группы разработчиков при экстремальном программировании.

33. Основные виды документов, создаваемых в процессе экстремального программирования.

34. Достоинства и недостатки экстремального программирования.

35. Методология SCRUM.

36. Предмет и основные задачи мехатроники. Структура типовой мехатронной системы.

37. Понятие и назначение интеллектуального мехатронного модуля.

38. Метрики качества программного кода.

39. Назначение и порядок использования системы управления версиями программного приложения.

система представляется в виде набора более простых сущностей, которые относительно самодостаточны.

Модель - это некий (материальный или нет) объект, отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...

Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями).

с помощью диаграмм можно визуализировать систему с различных точек зрения. Одна из диаграмм, например, может описывать взаимодействие пользователя с системой, другая - изменение состояний системы в процессе ее работы, третья - взаимодействие между собой элементов системы и т. д. Сложную систему можно и нужно представить в виде набора небольших и почти независимых моделей-диаграмм, причем ни одна из них не является достаточной для описания системы и получения полного представления о ней, поскольку каждая из них фокусируется на каком-то определенном аспекте функционирования системы и выражает разный уровень абстракции. Другими словами, каждая модель соответствует некоторой определенной, частной точке зрения на проектируемую систему.

ни одна отдельная диаграмма не является моделью. Диаграммы - лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, но не одна диаграмма, вырванная из контекста.

1

UML имеет четырехуровневую архитектуру:  - мета-метамодель;  - метамодель;  - модель;  - пользовательские объекты.  Пользовательские объекты определяют объекты конкретной предметной области например: процессор, монитор, жёсткий диск и т.д.. Модель является определенным взглядом на предметную область. 

UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы:

• четыре типа диаграмм представляют статическую структуру приложения;

• пять представляют поведенческие аспекты системы;

• три представляют физические аспекты функционирования системы (диаграммы реализации).

Графическая аннотация языка UML состоит из следующих видов диаграмм:

1. Статические диаграммные структуры (Static Structure Diagrams). В этой структуре выделяют классы:

• Class Diagram

• Object Diagram

• Package Diagram

2. Диаграмма вариантов использования или прецедентов (Use-case).

3. Диаграммы взаимодействия (Interaction Diagrams)

• Sequence Diagram

• Collaboration Diagram

4. Диаграмма поведения (Behavior Diagrams)

• State Diagram

• Activity Diagram

5. Диаграмма реализация (Implementation Diagram)

• Component Diagram

• Deployment Diagram

В UML существуют следующие модели (каждая модель представлена соответствующим типом диаграммы):  - модель вариантов использования (Use Case Model). Предназначена для описания требований к системе и подсистемам; Описывает взаимодействие действующих лиц с системой, представленное вариантами использования. Каждый вариант использования – потенциальное требование к системе - модель классов (Class Model). Служит для описания статической структуры системы: иерархии классов и отношений между ними;  - модель взаимодействий: объекты (Collabo-ration Model) и сценарии (Sequence Model). Служит для описания механизмов взаимодействия объектов системы, реализующих ту или иную функцию;  - поведенческая модель диаграммы переходов и состояний (Behavior Model). Предназначена для описания алгоритмов поведения объектов системы;  - модель процессов: физическая архитектура системы (Deployment Model). Описывает распределение процессов по процессорам в физическом проекте системы;  - модель программных модулей (Component Model). Описывает распределение классов и объектов системы по модулям в физическом проекте системы;  - модель действий (Activity Model). Предназначена для описания алгоритмов системы (для методов классов, нескольких классов) и является вариантом поведенческой модели без сообщений.  Метамодель определяет язык описания моделей. В UML метамодель описывается с помощью диаграмм классов UML. мета-метамодели рассматривается классификация подходов разработки программного обеспечения (ПО). Наибольшее распространение получили два семейства методов: структурные методы проектирования программных систем и объектно-ориентированные, приобретающие все большую популярность в последние годы. 

Метамодельопределяет язык описания моделей. В UML метамодель описывается с помощью диаграмм классов UML. Мета-метамодельявляется описанием различных метамоделей. На уровне мета­метамодели рассматривается классификация подходов разработки ПО. Самыми распространенными являются два семейства методов: а) структурные методы проектирования программных систем и б) объектно-ориентированные методы. Следует отметить, что ОО методология активно трансформируется в компонентно-ориентированную, поддерживаемую компонентными программными моделями (COM, DCOM, JavaBeans, EJB) и соответствующими платформами, языками программирования и инструментальными средствами разработки (например, IDE и RAD).

2

Кроме классов, важным элементом диаграмм классов являются интерфейсы.

Интерфейс обозначается так:

Интерфейс (interface) в UML

(стр. 96) означает класс, в котором все операции открытые и не имеют

тел методов. Это соответствует интерфейсам в Java, COM (Component

Object Module) и CORBA. Поскольку это специальный вид класса, то он

изображается с помощью пиктограммы с ключевым словом «interface». Обычно ключевые слова представляются в виде текста, заклю_

ченного во французские кавычки («елочки»). Вместо ключевых слов

можно использовать специальные значки, но тем самым вы заставляе_

те всех запоминать их значения.

Интерфейс – это класс, не имеющий реализации, то есть вся его функ_

циональность абстрактна. Интерфейсы прямо соответствуют интерфейсам в C# и Java и являются общей идиомой в других типизированных языках. Интерфейс обозначается ключевым словом «interface». Классы обладают двумя типами отношений с интерфейсами: предоставление или требование. Класс предоставляет интерфейс, если его можно заменить на интерфейс. В Java и .NET класс может сделать это, реализуя интерфейс или подтип интерфейса. В C++ создается подкласс класса, являющегося интерфейсом.

3 Классы

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5.1). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса (рис. 5.1, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис. 5.1, б) и операциями (рис. 5.1, в).

Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех разделов или секций. Иногда в обозначениях классов используется дополнительный четвертый раздел, в котором приводится семантическая информация справочного характера или явно указываются исключительные ситуации.

Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется горизонтальной линией, чтобы сразу отличить класс от других элементов языка UML. Примеры графического изображения классов на диаграмме классов приведены на рис. 5.2. В первом случае для класса "Прямоугольник" (рис. 5.2, а) указаны только его атрибуты — точки на координатной плоскости, которые определяют его расположение. Для класса "Окно" (рис. 5.2, б) указаны только его операции, секция атрибутов оставлена пустой. Для класса "Счет" (рис. 5.2, в) дополнительно изображена четвертая секция, в которой указано исключение — отказ от обработки просроченной кредитной карточки.

Классы - это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами - атрибутами, операциями, отношениями и семантикой.

В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Если используется составное имя (в начале имени добавляется имя пакета, куда входит класс), то имя класса должно быть уникальным в пакете.

Атрибут - это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов.

Операция - реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.

На рис. 11.1 приведено графическое изображение класса «Заказ» в нотации UML.

 Рис. 11.1. Изображение класса в UML

Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным):

<

признак видимости> <имя атрибута> : <тип данных>

= <значение по умолчанию>

<признак видимости> <имя операции> <(список аргументов)>

Видимость свойства указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости:

1. public (общий) - любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;

2. protected (защищенный) - только любой потомок данного класса может пользоваться его защищнными свойствами. Обозначаются знаком «#»;

3. private (закрытый) - только данный класс может пользоваться этими свойствами. Обозначаются символом «-» .

Еще одной важной характеристикой атрибутов и операций классов является область действия. Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами:

1. instance (экземпляр) - у каждого экземпляра класса есть собственное значение данного свойства;

2. classifier (классификатор) - все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).

Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов:

1. не содержащие ни одного экземпляра - тогда класс становится служебным (Abstract);

2. содержащие ровно один экземпляр (Singleton);

3. содержащие заданное число экземпляров;

4. содержащие произвольное число экземпляров.

Принципиальное назначение классов характеризуют стереотипы. Это, фактически, классификация объектов на высоком уровне, позволяющая определить некоторые основные свойства объекта (пример стереотипа - класс «действующее лицо»). Механизм стереотипов является также средством расширения словаря UML за счет создания на основе существующих блоков языка новых, специфичных для решения конкретной проблемы.

4